Configuring a second thermometer

#1

I am finishing my integration with ANAVI Thermometer, so I can switch the control of the temperature when we go to sleep (it is already placed in our bedroom).

I have successfully created a MQTT generic thing for the thermometer, added the channels for Anavi’s temperature and humidity, and linked two new items, AnaviTemp and AnaviHumi. I have created an additional item ThermometerSwitch for selecting the leading sensor, with two possible values: Anavi and My for HestiaPi (so I can get easily to AnaviTemp and MyTemp)

Finally, I have successfully modified the Process Sensor Changes rule (following @rlkoshak comprehensive How to customize a rule guide), adding AnaviTemp changed and AnaviHumi changed to triggers, and modifying the logic this way:

var OPENHAB_CONF = Java.type('java.lang.System').getenv('OPENHAB_CONF');
load(OPENHAB_CONF + '/automation/lib/hestia/utils.js');
load(OPENHAB_CONF + '/automation/lib/hestia/defaults.js');

var process = true;
var logName = "sensor";
var device;

logDebug(logName, "Changed "+event.itemName);

if (event.itemName.indexOf("Anavi") == 0) {
  if (items["ThermometerSwitch"] != "Anavi") {
    process = false;
  } else {
    device = event.itemName.replace("Anavi", "");
  }
} else {
  if (items["ThermometerSwitch"] != "My" && event.itemName != "MyPressure") {
    process = false;
  } else {
    device = event.itemName.replace("My", "");
  }
}

if (process) {
  // Update the proxy
  events.sendCommand("My"+device+"Proxy", newState);

  // Verifying the newState can be parsed is already checked in the but only if...
  var newReading = parseFloat(newState.toString());


  var prev = items["Previous"+device+"Reading"].floatValue();
  if(prev == NaN) prev = 0;

  var hyst = (device == "Temp") ? DEFAULTS.get("Temp"+items["TempUnit"]+"_DIFF") : DEFAULTS.get(device+"_DIFF");

  logDebug(logName, "Processing " + device + " with value " + newState + " and prevState " + prev + " and delta " + delta);
  var delta = Math.abs(newReading - prev);
  if(delta > hyst) {
    logDebug(logName, "Updating Previous"+device+"Reading with " + newState);
    events.postUpdate("Previous"+device+"Reading", newState);
  }
  else {
    logDebug(logName, "Ignoring " + device + " sensor reading, change is too small");
  }
} else {
  logDebug(logName, "Skipping "+event.itemName+", ThermometerSwitch is "+items["ThermometerSwitch"]);
}

Everything works great!.. but. When I switch ThermometerSensor to Anavi, the readings in the Hestia touch display follow Anavi’s instead of Hestia’s. It seems the code above (probably MyTempProxy publishes the readings to the MQTT topic (instead of MyTemp maybe, which is the item from the sensor?)

I am following a correct path? Is this the right point for the modifications or I should take a different approach?

#2

As you surmise, MyTempProxy is linked to the MQTT Thing and any changes to it get published and picked up by the UI.

MyTemp is linked to the Exec binding Thing that calls the script to get the current readings locally.

Honestly, doing away with the proxies and using Units of Measurement to handle the C to F conversions is high on my list of things I want to do. It’s really complicated and makes doing what you are trying to do right now more complicated than it needs to be.

Before getting into your problem, you can move all of the process stuff to the “but only if…” clause of the rule instead of making it part of the rule. So this code above would just be skipped if the triggeringItem is Anavi but ThermometerSwitch isn’t. You can do the same for the “My” sensors when ThermometerSwitch isn’t “My”.

But if I understand correctly, what you really want is that the LCD on the HestiaPi always shows it’s own sensor readings but the decisions on whether to turn on/off the heat/cooling would be based on the Anavi device readings when the TermometerSwitch is set to Anavi.

Unfortunately this is going to be a little tough to implement. The problem is that all the rest of the rules depend on MyTempProxy when deciding whether to turn on/off the devices. And MyTempProxy is the one that is linked to the MQTT channel that drives the LCD. So I think there are two choices:

  1. modify all the rules to use some other Item instead of MyTempProxy when making it’s decisions
  2. create another Item and move the channel from MyTempProxy to this new Item. Then modify the rule above to sendCommand to both MyTempProxy and the new Item , but only if the reading is from the local sensor, with the new temperature reading. The command to the new Item will drive what’s displayed on the LCD and the command to MyTempProxy will drive the rules.

I think 2 will be less work over all, but there may be some side effects that I’m not aware of off the top of my head that might crop up.

To further elaborate on 2, the rule will need to trigger on MyTemp and on AnaviTemp. You will process the reading for both sensors. Where there is a difference is your if statement that checks ThermometerSwitch will control whether or not to send the command to the new Item that’s linked to the LCD. Only command that Item when ThermometerSwitch is “My”. For commanding MyTempProxy, only command it when the triggering Item is MyTemp and ThermometerSwitch is “My” or when AnaviTemp is the triggeringItem and ThermometerSwitch is “Anavi”. If the new Item is called LocalTemp it’s look something like…

Over all I think you are on the right track.

#3

Great refactor! I was striving to use return to simply that logic, but I got errors when using return in a rule. That would help to simplify the code

I agree, I wouldn’t like to change rules too much, so I can keep track of upstream changes. I would like to keep synchronized with new versions, so 2 option seems to be cleaner. I have already modified the UI, so I could even change the MQTT channel and subscribe to a new one…

Thank you for your insights! I will get back with my final setup.

#4

I made it! I finally created new items for local readings with their new rule to update them. I had to change the topics in the UI, but I already changed it for showing Anavi’s readings so… not a big deal

I have documented everything at https://blog.atd.singularities.org/2020/10/08/anavi-thermometer-hestiapi-integration/

2 Likes