Implemented Min/Max Setpoints and Comfort Mode

[rkoshak]

This PR implements the dual setpoints for the AC and comfort mode.

Items:

• TempSetpoint is replaced with a MinTempSetpoint used to control the heater and MaxTempSetpoint used to control the AC. MaxTempSetpoint is ignored in EU SystemType. Both has a C and F version as well mirroring the way TempSetpoint works (I don't think they are necessary and will remove them in a later PR). Defaults to use for these setpoints are defined in defaults.js.
• Comfort_Value represents the hysteresis value. This can be any number between 0.5 and 10. The sitemap is set to increment it by .5 when in C mode and 1 when in F mode. The default to use for this Item is defined in defaults.js.
• Comfort_Mode represents the hysteresis mode. If it's "COMFORT" the value defined in defaults.js is used for the hysteresis (0.5 for C and 1 for 2 for F). User can change this by modifying defaults.js. If it's "ECO" the number in Comfort_Value is used for the hysteresis.

All the new Items except for the C and F versions of the setpoints are configured to restoreOnStartup.

Things:

• No new things but there are new Channels on the Sensors and Setpoints Thing to publish and subscribe for the new MaxTempSetpoint, MinTempStepoint, Comfort_Value and Comfort_Mode Items.

Channel	Subscribes to	Publishes to
MaximumTempSetpoint	hestia/local/cmnd/setmaxtempsetpoint	hestia/local/maxtempsetpoint
MinimumTempSetpoint	hestia/local/cmnd/setmintempsetpoint	hestia/local/mintempsetpoint
Hysteresis	hestia/local/cmnd/hysteresis	hestia/local/hysteresis
Comfort Mode	hestia/local/cmnd/comfortmode	hestia/local/comfortmode

When OH publishes to the topics it does with retained messages.

Rules: There were surprisingly few Rules that needed to be changed which was nice.

• SystemType Changed: removed references to TempSetpoint, set the MinTempSetpoint and MaxTempSetpoint to the defaults
• Initialization: if NULL or UNDEF, set MinTempSetpoint, MaxTempSetpoint, Comfort_Mode and to the defaults
• Synchronize Temp Proxies: Added MinTempSetpoint, MinTempSetpointF, MinTempSetpoint, MaxTempSetpoint, MaxTempSetpointC, MaxTempSetpointF as triggers so they all keep in sync.
• Added a new Rule, Comfort Mode Changed, which reverts the change if it's anything except "COMFORT" or "ECO"
• Heating/Cooling Check: This is where the main logic resides. Added checking to make sure MinTempSetpoint, MaxTempSetpoint, Comfort_Mode, and Comfort_Value are not NULL or UNDEF before running the Rule, removed reference to TempSetpoint. Rewrote the Action to use the MinTempSetpoint for heating and the MaxTempSetpoint for cooling and to take account the hysteresis. If in COMFORT, the value in defaults.js is used. If in ECO, the value in Comfort_Value is used.
• Sensor or Setpoint Changed: Added MinTempSetpoint, MaxTempSetpoint, Comfort_Value, and Comfort_Mode as triggers. Added a new condition clause to revert and change to Comfort_Value that is outside the 0.5 <= Comfort_Value <= 10 range. If the value is higher 10 is used, if lower 0.5 is used. I may need to revisit this to account for differences in C and F. The Action was modified to call HeatingCheck or CoolingCheck if the Rule was triggered by a change to one of the Comfort Items. If the change was to MinTempSetpoint HeatingCheck is called and if it;s to MaxTempSetpoint CoolingCheck is called. These were the most complex changes made. Removed references to TempSetpoint.
• TempUnit Changed: Removed references to TempSetpoint and added reinitialization of MinTempSetpoint, MaxTempSetpoint, and Comfort_Value to the defaults for the new unit type.

Sitemap:

• In US mode I added the Comfort Mode switch under Temperature and removed the temperature setpoint from that Frame. I added the MinTempSetpoint to the Heating Frame and the MaxTempSetpoint to the Cooling Frame.
• In EU mode I put the Comfort Mode switch under the Heating Frame.
• The Comfort Range (i.e. hysteresis value) I placed under Settings.

Begins to solve #14 .

[jaythomas]

• Any suggestions on an easy way to check this out on a running unit? I'd like to do some live testing on my personal system.
• How does this affect the logic defined in default.rules? Will it affect my custom gpio pinout for my 5-wire setup?

[rkoshak]

@gulliverrr is working on a new SD card for testing with. I don't know the status of that but it would be the easiest way to test it out. I wrote a quick post showing how to upgrade and deploy the new code at https://community.hestiapi.com/t/interoperability-with-other-openhab-instance/1586/8 (@gulliverrr, if I recall correctly you found a missing command on that post but I can't find where we had that discussion). The above requires a newer version of openHAB than 2.4.

If possible, I would test on a separate SD card to minimize the disruption to your live system.

default.rules have been almost completely replaced. It just has a little rule to kick off the JavaScript Initialization Rule. All the Rules are now written in JavaScript and accessible through PaperUI. If you post what you changed I can point you where to make the changes yourself or incorporate the changes for you and post them here with instructions on how to apply them. At a high level, depending on what needs to change, you would disable the default rule(s) and use the REST API to import the new Rule (a curl command).

I wrote up a general guide for the best way to customize the Rules at https://community.hestiapi.com/t/how-to-customize-a-rule/1644. Following this approach it is easier to preserve customization during future upgrades (tutorial for that is to be written).

I'm also working on some activity diagrams to help explain how the individual Rules work together. Here are those I've done so far. Note, they do not reflect these changes yet (i.e. MinTempSetpoint, MaxTempSetpoint, Comfort).

NOTE: These drawings were made using draw.io and the source for them will be checked in somewhere so they can be modified as needed moving forward.

[jaythomas]

Nice work on diagram and documenting. I would suggest checking the diagrams in this git repo so changes can be tracked with the code.

@gulliverrr is working on a new SD card for testing with.

So should I wait on that image before testing?

Regarding the changes I've made to the default.rules, I've only modified the pins that are being switched on and off as you can see the pin I added to energize the reversing valve in my heat pump for cooling:

rule "CoolingPin changed"
when
    Item CoolingPin changed
then
    switch(CoolingPin.state) {
      case ON: {
        Pin23.sendCommand(ON)
        Pin12.sendCommand(ON)
        //CoolingPinTopic.sendCommand(ON)
        logInfo("Default","CoolingPin set to ON.")
      }
      case OFF: {
        Pin12.sendCommand(OFF)
        Pin23.sendCommand(OFF)
        //CoolingPinTopic.sendCommand(OFF)
        logInfo("Default","CoolingPin set to OFF.")
      }
    }
end

If that can be modified without needing to ssh into the unit that's great, but if this has moved to another script file just let me know where I need to change.

[gulliverrr]

So should I wait on that image before testing?

@jaythomas I haven't checked the PR yet but the new image should not affect OH files/configuration that much. Some HestiaPi scripts (under /home/pi/scripts) will be modified but shouldn't stop you from testing UI stuff.

[rkoshak]

Regarding the changes I've made to the default.rules, I've only modified the pins that are being switched on and off as you can see the pin I added to energize the reversing valve in my heat pump for cooling:

OK, that's not too bad. Are you running in US mode and turning on the CoolingPin (Pin23) and the HeatingPin (Pin12) at the same time or are you running in EU mode and turning on the HeatingPin (Pin23) and the HotWaterPin (Pin12) at the same time?

The mode will determine the best approach to take. In US mode, what about the Fan (Pin18)? If in EU mode, I think it's a bit more straight forward.

But if this Rule exists at all, I imagine that you are in US mode since as, if I recall correctly, there is no "CoolingPin changed" Rule in the EU rules file. So if I assume US mode I need to understand how the Fan works in your system. Do you turn it on only for heating? Which pins control the heating since you are using the same pin here? Or is it the case that during heating you turn on Pin12 (Heating) and Pin18 (Fan) and for cooling you turn on Pin12 (Heating) and Pin23 (Cooling)?

So I think I need to know more to tell you what to change. If I make assumptions

Changed to make to the "Cooling Control" Rule (this Rule get's called when the "Heating/Cooling Check" Rule determines the AC needs to be turned ON or OFF:

• Modify the "The command is different from the current cooling and fan states" condition to remove the checking of the Fan states

(items["CoolingPin"] != command);

• Delete the "Prevent the Heating and Cooling from being ON at the same time" condition entirely

• In the Action, remove all references to the Fan and add lines to sendCommand ON/OFF to HeatingPin in addition to CoolingPin. The timer that makes sure the Fan turns on before the AC turns on can be removed as well

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

logInfo("cooling", "Turning " + command + " the cooling: curr temp = " + items["MyTemp"] +
                 " setpoint = " + items["MaxTempSetpoint"] +
                 " mode = " + items["CoolingMode"]);

if(command == ON){
  commandIfDifferent("MainSwitch", ON);
  commandIfDifferent("CoolingPin", ON);
  commandIfDifferent("HeatingPin", ON);
  events.sendCommand("CoolingMode", items["CoolingMode"]); // update the LCD
}
else {
  commandIfDifferent("CoolingPin", OFF);
  commandIfDifferent("HeatingPin", OFF);
}

And then under the Rule "Map Pin to GPIO" (this Rule takes the Pin Items (e.g. HeatingPin, CoolingPin) and sends the command to the appropriate GPIO Pin Item (e.g. Pin23) based on the mapping defined in defaults.js:

• The "Fan Protection" condition needs to be modified to only make sure the Fan cannot be turned OFF when the Heating is ON but the Cooling is OFF. Obviously this is only required if the Fan does indeed need to come on when Heating. If not you can probably eliminate this condition entirely.

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

var ok = true
if(event.itemName == "FanPin"){
  logInfo("pins", "FanPin commanded to " + newState);
  if(items["SystemType"] == "US" &&
     (items["HeatingPin"] == ON && items["CoolingPin"] == OFF) &&
     newState == OFF){
    logWarn("pins", "Cannot turn off the fan when heating! Restoring fan states!");
    commandIfDifferent("FanMode", "AUTO");
    commandIfDifferent("FanCtrl", "OFF");
    events.sendCommand("FanPin", ON);
    ok = false;
  }
}
(ok);

If that can be modified without needing to ssh into the unit that's great, but if this has moved to another script file just let me know where I need to change.

All Rules can be edited through PaperUI now. But the overall way the Rules work is significantly different from the way the old Rules worked, avoiding lots of duplicated code and adding in a lot more checks. My second link in the previous post should give you the orientation you need to modify the Rules using just the browser and hopefully the activity diagrams above show how the events move from one Rule to the next (the rounded corner rectangles are each individual Rules). One of my goals with moving everything to JSONDB, beyond the startup improvements, was to make as much as is possible viewable and modifiable through PaperUI so users almost never need to ssh to the machine to modify the behaviors. Certain goals like setting up email notifications using only the browser interface are only possible with this as well.

As described in the link above, disable and clone the Rules before modifying them so you have easy reference back to the original. Also, any change you make will automatically create a backup in /var/openhab2/jsondb/backup, but it's much easier to just review the disabled Rule in PaperUI).

[jaythomas]

Thanks for the info, I think I can figure it out. What's the easiest way to deploy this code to a unit that I've imaged?

[gulliverrr]

@jaythomas should I wait for your commit on the UI to merge to main?

[jaythomas]

@gulliverrr I haven't tested it to know if its stable enough to merge into master, but that's up to you.

[gulliverrr]

Sure, I didn't mean that. Actually it will make no difference to have it checked in before your UI commit so I will go ahead and continue testing it and merge it.

[rkoshak]

What's the easiest way to deploy this code to a unit that I've imaged?

Follow the steps at https://community.hestiapi.com/t/interoperability-with-other-openhab-instance/1586/8.

[jaythomas]

Thanks, didn't see the thread originally. I'm going to fire this up on a live unit now and test it throughout the evening.

[gulliverrr]

@gulliverrr, if I recall correctly you found a missing command on that post but I can't find where we had that discussion

https://community.hestiapi.com/t/interoperability-with-other-openhab-instance/1586/16

It is only for changing the default (F) temp unit so one could get away without it... I have added this to my new image

NOTE: These drawings were made using draw.io and the source for them will be checked in somewhere so they can be modified as needed moving forward.

I would suggest the docs folder. Definitely worth checking them in in code and png format so that I link to them from the wiki.

[rkoshak]

I would suggest the docs folder. Definitely worth checking them in in code and png format so that I link to them from the wiki.

Will do. I need to complete them and update them for the latest changes first. Expect a PR sometime this week.