Min and Max temperature values

[gulliverrr]

In order to allow simultaneously enabled heating and cooling Min and Max temperature values are needed in order to activate each function accordingly. Below Min heating is activated. Above Max cooling is activated.

[Wee-bear]

Yes, this is a definite need/improvement, I can't wait. Rather than calling them "Min" and "Max" I think it would be more intuitive to have AC and Heat set-points for each schedule as this is common lingo for other thermostats. Min and Max could be confused with range to keep heat/cooling within like bracketing. (Heat would go to Max then allowed to cool to Min before engaging)

[rkoshak]

How/should hysteresis be added as part of this? Here is the issue I'm facing. With a forced air US HVAC system the the system can rapidly turn on and off when the temp is bouncing around the setpoint. This can damage the furnace, not to mention that it's much less efficient. So for my "production" HestiaPi I've added a little bit of a buffer (hysteresis) so that the temperature needs to drop to three degrees F below the setpoint before the heater turns on. AC would work the same, letting the temp rise a few degrees above the setpoint before turning on. But in my case it's currently hard coded into the Rule.

I would make the hysteresis buffers configurable from the sitemap of course and they would impact the behavior of this Min and Max temp as well. The Min would have to be less than the heating setpoint minus the hysteresis and the Max would have to be more than the AC setpoint plus the hysteresis. I can definitely code it to prevent that.

Alternatively, I can code it as a simple "Echo/Comfort" mode and just hard code in 3 degrees F (and the C equivalent) for Echo mode and use a much more modest buffer for Comfort mode.

Another alternative I can use is to use time instead of temperature. In that case I'd add in a control so the heat/AC/Fan cannot turn on or off again until it has been at least five minutes since it last changed state.

Maybe this should be Comfort mode and the three degree buffer be Echo mode?

Do EU systems have the same problem as a US forced air system with rapidly turning on and off or should I only do the timeout (if we decide to go that way) for US systems?

I keep wiping out my hard coded hysteresis as I move a checked in copy of the code to my production HestiaPi so this is the next thing on my list to work on.

[Wee-bear]

response_container_BBPPID{font-family: initial; font-size:initial; color: initial;} Hello Richard,  3 degrees would be far too much for my liking. I like how it currently works so an Eco option would good for those that want it. It could have a spot to enter how wide a range you want.  Paul  Sent from my BlackBerry — the most secure mobile device — via the Bell Network From: notifications@github.comSent: April 23, 2020 11:43To: hestia-touch-openhab@noreply.github.comReply to: reply@reply.github.comCc: psweber@gmail.com; comment@noreply.github.comSubject: Re: [HestiaPi/hestia-touch-openhab] Min and Max temperature values (#14)

How/should hysteresis be added as part of this? Here is the issue I'm facing. With a forced air US HVAC system the the system can rapidly turn on and off when the temp is bouncing around the setpoint. This can damage the furnace, not to mention that it's much less efficient. So for my "production" HestiaPi I've added a little bit of a buffer (hysteresis) so that the temperature needs to drop to three degrees F below the setpoint before the heater turns on. AC would work the same, letting the temp rise a few degrees above the setpoint before turning on. But in my case it's currently hard coded into the Rule. I would make the hysteresis buffers configurable from the sitemap of course and they would impact the behavior of this Min and Max temp as well. The Min would have to be less than the heating setpoint minus the hysteresis and the Max would have to be more than the AC setpoint plus the hysteresis. I can definitely code it to prevent that. Alternatively, I can code it as a simple "Echo/Comfort" mode and just hard code in 3 degrees F (and the C equivalent) for Echo mode and use a much more modest buffer for Comfort mode. Another alternative I can use is to use time instead of temperature. In that case I'd add in a control so the heat/AC/Fan cannot turn on or off again until it has been at least five minutes since it last changed state. Maybe this should be Comfort mode and the three degree buffer be Echo mode? Do EU systems have the same problem as a US forced air system with rapidly turning on and off or should I only do the timeout (if we decide to go that way) for US systems? I keep wiping out my hard coded hysteresis as I move a checked in copy of the code to my production HestiaPi so this is the next thing on my list to work on.

—You are receiving this because you commented.Reply to this email directly, view it on GitHub, or unsubscribe.

[gulliverrr]

Although I'll try staying away from this "brainstorming" thread so that I don't influence any direction, I'll comment on a few points. Not sure if the forum would be a better place to get people involved...

Another alternative I can use is to use time instead of temperature. In that case I'd add in a control so the heat/AC/Fan cannot turn on or off again until it has been at least five minutes since it last changed state.

I believe there are scenarios where opening a door or a window may affect incorrectly the current temp and trigger heating or AC. This is not the scenario you describe above but I thought of mentioning it here in case it fits other logic too. About your suggestion, I believe the "five" minute window can still cause on and offs (every "five" minutes).

Do EU systems have the same problem as a US forced air system with rapidly turning on and off or should I only do the timeout (if we decide to go that way) for US systems?

It is my understanding that EU mostly uses circulating hot water logic where heating units keep providing heat for some time after the circulation stops and temp can overshoot in certain configurations. They are also generally slower systems to start. I don't see how the hysterisis logic can cause any problems in the EU logic...

[rkoshak]

I believe there are scenarios where opening a door or a window may affect incorrectly the current temp and trigger heating or AC. This is not the scenario you describe above but I thought of mentioning it here in case it fits other logic too.

This is a scenario that I don't think we can determine and decide what should happen for all users. We have no way to tell the difference between a rapid temperature change caused by an open door or just a rapidly changing temperature. In spring and fall where I live, it is not unusual to see a 70+ degree F change over the course of a single day (usually in the downward direction when a cold front moves through). Even a reasonably well insulated house will see a relatively rapid drop in temp in that circumstance which is hard to distinguish from someone opening the window.

The best way to handle the an open door or window I think is to have sensors on them and take that into account when deciding to turn on/off the heat which would be outside this issue I think.

I'm not a big fan of the time based control but I think there does need to be something to prevent the HVAC from cycling too fast for those with central air, even in comfort mode. So it sounds like the protection is only required for US systems with forced air. So the comfort mode for that can be like it is now without problem.

I wasn't really approaching this discussion as brain storming as trying to understand what the original intent for the Issue was.

[rkoshak]

I'm pretty sure I'm going to need help with the UI part of this. I assume that when the user taps the heating icon they should see the "min" setpoint and when they tap the cooling icon they should see the "max" setpoint. BasicUI is pretty straight forward but I have quite a bit of a learning curve with JS and Vue and just understanding how the LCD UI works.

[gulliverrr]

@jaythomas could you lend a hand?

[jaythomas]

I don't think anything needs to be done in the UI. If you set the target temperature in the UI then the openhab side should handle within the rules to know to keep pushing the temperature for N more degrees. The value N could be adjusted from 1 to 2 to 3 all within the openhab settings page.

[rkoshak]

What needs to change is there will now be two separate target temperatures, one for heating and a different one for cooling. The issue is to be able to have two temp setpoints, a min and a max.

It's possible to instead have the one temperature setpoint and a buffer but then that makes the setpoint on the UI all but meaningless.

For example, let's say we can create a buffer of four degrees. First of all, adjusting the number of degrees between when the heating comes on and the cooling comes on would only be adjustable from BasicUI. Then you have the issue that when the LCD UI shows "70" what that really means is the heater will come on at <68 and the AC will come on at >71. And of course, if you adjust the buffer than that 68 and 71 will change too.

In short, something would need to change on the UI so the user can either adjust the buffer from the UI or, what I assume would be easiest to implement an I'll assert is more intuitive to the user, let the user set two target temps on the UI.

[jaythomas]

I'm all for having as much control from the thermostat LCD to avoid the need for using a phone and wi-fi connection and openHAB altogether, but the design decisions thus far have been to do as much of the "one time" setup from Openhab to avoid as much burden on the touch UI as possible.

Let me brainstorm on it this weekend and see what I can come up with. We may be able to have the best of both worlds.

[rkoshak]

I have the openHAB part of this up and running and working well. for consistency I followed the same pattern as the Modes for the topics but if that's a problem it's easily changed.

• OH publishes changes to max temp setpoint (controls Cooling) to hestia/local/cmnd/maxtempsetpoint
• OH subscribes for changes to max temp setpoint to hestia/local/stat/setmaxtempsetpoint
• OH publishes changes to min temp setpoint (controls heating) to hestia/local/cmnd/mintempsetpoint
• OH subscribes for changes to min temp setpoint to hestia/local/stat/setmaxtempsetpoint

So the LCD UI would publish to the "stat" topic for each and subscribe to the cmnd topic it for each.

If it is determined that no changes will be made to the LCD I recommend closing this issue as won't fix because it doesn't make any sense to have two setpoints but only be able to adjust one of them from the LCD.

[jaythomas]

What about a minimal change where the displayed target temperature for heating is the lower bound and the displayed target temperature for cooling is the upper bound? So for instance:

• Heating displays the mintempsetpoint of 70
• Cooling (hidden from view in this case) displays the maxtempsetpoint of 73
• In the bottom right corner, you can see the "comfort range"/margin number, in this case 4 degrees. That tells me heating won't kick on until the temperatures get as low as 66: 4 degrees below the mintempsetpoint. Likewise this also means my cooling won't kick on until it gets 77 degrees: 4 degrees above the maxtempsetpoint.

I think the "comfort range" (or whatever the agreed-on terminology for this number) is a vital part of this feature. My heat pump gave out because the switch burned up from my thermostat flipping on and off rapidly when the temperature was straddling the target number. :hot_face: Anyway, we would just need openhab to report this number as well and I think your change sounds good.

[rkoshak]

I think that approach makes intuitive sense. The comfort range is a nice touch and it is easy enough to get OH to report. I just need to understand the intent here. Do you mean this to be the difference between minimum and maximum temp setpoints or hysteresis?

My heat pump gave out because the switch burned up from my thermostat flipping on and off rapidly when the temperature was straddling the target number. 🥵

The minimum and maximum setpoints wouldn't actually address this problem so reporting the difference between the min and max setpoints wouldn't be useful to avoid this. For that problem we need hysteresis so that when the measured temp approaches the setpoint and bounces above and below it because of noise in the sensor it doesn't cause the heater/cooler to flap on and off.

On my production system, I've implemented a three degree hysteresis so that the temperature needs to drop 3 degrees F below the setpoint before the heater will turn on and it will not turn off the heater until the setpoint is reached. This prevents the heater from flapping because the drop has to be greater than the usual noise in the sensor. With 3 degrees in my house it has the heater come on for at least 10-15 minutes and then there is at least 10-15 minutes before it turns on again, and that's only when it's really code (below 20 degrees F).

I really am keen to add hysteresis to avoid just this problem and debated whether to add it as part of this PR. I noticed the flapping early on and quickly hard coded something to avoid burning up my furnace. I'm sorry I didn't come to HestiaPi soon enough to avoid burning up your pump.

The term "comfort range" works for me though we could make this even simpler on the LCD and put the actual value on BasicUI. @gulliverrr suggested having a "Comfort Mode" which wouldn't apply a hysteresis (or apply a very small one) and an "Eco Mode" which would. The LCD could have a button to switch between the two modes. On BasicUI we can put the size of the hysteresis buffer (e.g. how far below the setpoint the temp must get before the heater turns on, how far above the setpoint the temp must get before the AC turns on) where it can be adjusted. Then the LCD UI would only need a toggle or perhaps nothing at all since it's more of a setting than something that would need to be adjusted frequently.

What do you think?

The code I have now doesn't support a dynamic hysteresis yet but I can easily add it (well, it's quite complex actually with the two setpoints but I know how to do it). This would definitely be exposed to MQTT to aid integration with other systems.

[jaythomas]

Apologies for the terminology confusion. What I am referring to is indeed hysteresis. I didn't realize this was the term for it. If you have a static hysteresis value of 3 coded in the rules I think that is sufficient for now. I don't want to impede this feature request with something non-trivial. We can always make hysteresis dynamic later if it's a feature others would like. Regarding implementation, I can do the frontend modification and test your openhab-side changes if you could provide me a branch name where I might find these modifications and some instructions as how best to apply them to a unit for testing.

[rkoshak]

I'll submit the PR later today or tomorrow depending on how my day develops. :-)

[gulliverrr]

Seems like I arrived late to the party... I'm really happy with the solution you agreed on. Less info on the LCD is also good. @jaythomas I believe "Comfort" and "ECO" are pretty standard lingo in the thermostats. @rkoshak I would suggest (although this may be what you suggest too) to have a hysteresis value for comfort too. Additionally a 1° in F is not much but in C (Europe) 1° can be a significant difference for some. 22° C is 71.6° F while 23° is 73.4°. So I suggest (for Europe only?) to go down to 0.5 or even have a 0.5 step.

[rkoshak]

For comfort I will have a 1 degree F two degrees F or .5 for C. I can't do 1 degree F because F is rounded to the nearest integer and 1 degree won't actually provide the buffer if the temp is hovering around (setpoint - .5).

For Eco I will have a 3 degrees F or 1 degree C and provide a setpoint on BasicUI for users to adjust as desired.

As an update, I ran into a bug in the logic I've not sorted out which I think is unrelated to the hysteresis stuff and was actually latent in the min/max setpoint code. But the short of it is it might be a couple days before I can submit the PR if it takes too long to track down. If it's helpful, I can submit what I have now and then add a commit later. The bug occurs during initialization so if it doesn't barf during startup it should work just fine for testing.

[jaythomas]

If you get stuck feel free to open a draft PR and someone can give a second set of eyes on the problem. I'm not very familiar with OpenHAB's DSL but can give it a shot if need be.

[rkoshak]

Sorry for the delay. I've had my afternoons filled with other activities and have not have a chance to get back to this. I'm hoping to get a PR posted today or tomorrow. I've found one more bug with making sure that the hysteresis is smaller than the gap between the min setpoint and the max setpoint. I might just post it anyway if it turns out to be hard to fix.

I've a question though @gulliverrr and @jaythomas. Imagine this scenario:

• Heater comes on at 68 (min setpoint minus hysteresis)
• Heater turns off at 70 (min setpoint)
• AC turns off at 71 (max setpoint)
• AC turns on at 73 (max setpoint plus hysteresis)

1. User is adjusting the min setpoint upwards on the LCD, min setpoint moves to 71
2. The min setpoint is now equal to the max setpoint. Because of the hysteresis this is probably OK (it would not be OK without the hysteresis).
3. User adjusts the min setpoint upwards on the LCD again, min setpoint moves to 72.
4. The min setpoint is now greater than the max setpoint. That should not be allowed. So we increase the max setpoint to 73.

When step 4 happens an MQTT message will be sent to the LCD. Does the LCD switch to the cooling page when it processes that message or does it stay on the heating screen? What is appropriate? I can see arguments for both approaches (changing to the cooling screen on the LCD shows the user that they are getting over the max setpoint, but as a user I'd be annoyed if it switched while I was trying to adjust the min setpoint on the heater screen).

[jaythomas]

Regarding the switching behavior, the touchscreen has no way to know what caused a message to trigger. If the user adjusts the min setpoint and the max setpoint auto-adjusts, the touchscreen won't know if that mqtt message with the new information happened because of interaction with the LCD or from another source such as somebody adjusting the temperature from their phone. This issue was brought up in a previous issue (https://github.com/HestiaPi/hestia-touch-one-ui/issues/11) where I suggested you could get around the issue by implementing an origin ID and attaching that to every relevant message.

If you were on the heating screen, instead of switching to cooling you could flash the cooling icon, but even that I don't think would have any meaning to the user. The user could intuit "hey something changed in the cooling mode let me tap over and see" but more than likely they would think "the screen just did something glitchy" as screen animations are very low framerate.

[gulliverrr]

Switching to another screen could be annoying while user wants to do something else. Stopping min from going over max, can (should) only be handled in the backend (OH) so via a few MQTT messages exchanged with the LCD which can be enough time for user to see the desired temp reached and look away while the screen resets back to the previous temp. So this is even more annoying. I would stick with the existing functionality, that is to (secretly) increase max setpoint.

[rkoshak]

I can't necessarily do it secretly. When either setpoint is changed, the new value is published and the LCD will see that new value. It doesn't know where that change came from or why so it will do what ever it does when you change a setpoint from BasicUI, for example.

[jaythomas]

I think he means if you have the basic UI open on your phone and you change the cooling setpoint but the LCD is displaying the heat setpoint, you won't see any visual change on the LCD. The javascript will still receive the MQTT message and change the cooling setpoint in Vuex.

The frontend UI changes should be very minimal and I don't mind taking care of that side.

[gulliverrr]

By "secretly" I meant that on step 4. the max setpoint will be adjusted (secretly) but this is will not be shown (unless someone is keeping an eye on the Basic/Web UI).

[rkoshak]

OK, the PR is checked in. I've fairly thoroughly tested with SystemType=US, TempUnit=F. I've done some preliminary testing with SystemType=US, TempUnit=C. I've not tested SystemType=EU but it's the same code that runs for heating in both SystemTypes so it should be OK. I've not tested trying to change the temp unit live yet.

See the PR for details about what changed and what the MQTT topics are. This PR includes both the min/max setpoints and a complete implementation for hysteresis.

The comfort mode works as follows, from the user's perspective. When the system is in COMFORT mode, the hysteresis value defined in defaults.js is used. The checked in version has 0.5 for C and 1 for F. This is essentially the same thing as no hysteresis at all because the Rules round C to the nearest 0.5 and F to the nearest integer anyway so these values don't actually provide any buffer at all.

When in ECO mode, the value from the Comfort_Value Item (under Settings labeled "Comfort Range") is used for the hysteresis. If MinTempSetpoint is 65 and Comfort_Value is 3, the heating will turn on at temp 62 and turn off at temp 65. If MaxTempSetpoint is 70 and Comfort_Value is 2, the cooling will turn on at 72 and turn off at 70.

A larger Comfort value results in the devices running for longer periods of time but far less frequently, which is more energy efficient and easier on the devices (some HVAC devices can burn up when cycled too often and too frequently). But it also means wider swings in temperature the person has to experience.

Any default value, name, label, etc. can be changed.

[gulliverrr]

@rkoshak #52 fixes #14. Closing this...

[jaythomas]

@rkoshak can you clarify these MQTT commands for me?

I am able to subscribe to hestia/local/mintempsetpoint and hestia/local/maxtempsetpoint and receive temperature updates from openhab, but when I try to send the complimentary commands from the javascript client no change is observed on the openhab side.

I've tried sending: hestia/local/setmintempsetpoint hestia/local/setmaxtempsetpoint hestia/local/cmnd/setmintempsetpoint hestia/local/cmnd/setmaxtempsetpoint

[jaythomas]

I take that back, hestia/local/mintempsetpoint works, there just seemed to be a hiccup. Disregard the previous comment. :smile:

Has something changed with hestia/local/temperature though? I am not seeing the temperature come across any longer, either that or there is a very huge delay.

[jaythomas]

So 3 issues I see testing the latest changes:

• Temperature is not sent over to the thermostat
• Settings are not persisting across reboot. I tried clearing my openhab cache, resetting permissions, and rebooting again to no avail
• GPIO pins were not activated when sending commands to energize the fan or cooling. Again, hard to say if the issue is something with my setup but I did follow the recommended upgrade procedures from a clean 1.1 ONE img file

Regardless of these issues, I made the appropriate changes on the frontend. If someone has a working setup without any of the issues mentioned above feel free to test them.

[rkoshak]

Temperature is not sent over to the thermostat

This is weird. I've got exactly this code deployed on two machine and the temp is showing up on the LCD on both of them.

Does the LCD remain 0?

What happens when you run /home/pi/scripts/bme280.py from the command line? I've seen this once before where my sensor stopped working right with the Python script. Unplugging and replugging the sensor into the jumper cables sorted it out. When that was a problem, calling the script from the command line showed an error and a stack trace indicating that the script could communicate with the sensor.

If that isn't the problem:

1. Open /var/lib/openhab2/etc/org.ops4j.pax.logging.cfg for editing.
2. Find the line log4j2.logger.events.level = OFF and change it to log4j2.logger.events.level = INFO. Should be around line number 50.
3. tail -f /var/log/openhab2/events.log in a terminal.
4. Either wait for a bit or force the issue (see below) for the temp to change enough to show up. You should see lines along the lines of:

2020-06-03 13:24:07.422 [vent.ItemStateChangedEvent] - GetTemp changed from OFF to ON
2020-06-03 13:24:07.917 [vent.ItemStateChangedEvent] - GetTemp changed from ON to OFF
2020-06-03 13:24:07.991 [vent.ItemStateChangedEvent] - MyTemp changed from 78 to 77
2020-06-03 13:24:08.003 [.event.RuleStatusInfoEvent] - e407446b-dadb-4822-a2c0-8cd84e6e5a1f updated: RUNNING
2020-06-03 13:24:08.382 [ome.event.ItemCommandEvent] - Item 'MyTempProxy' received command 77
2020-06-03 13:24:08.447 [.event.RuleStatusInfoEvent] - e407446b-dadb-4822-a2c0-8cd84e6e5a1f updated: IDLE
2020-06-03 13:24:08.468 [nt.ItemStatePredictedEvent] - MyTempProxy predicted to become 77
2020-06-03 13:24:08.783 [vent.ItemStateChangedEvent] - PreviousTempReading changed from 78 to 77
2020-06-03 13:24:08.835 [vent.ItemStateChangedEvent] - MyTempProxy changed from 78 to 77
2020-06-03 13:24:08.941 [.event.RuleStatusInfoEvent] - bb0b73b3-a99b-4f57-b441-e0265c37813a updated: RUNNING
2020-06-03 13:24:08.960 [.event.RuleStatusInfoEvent] - bb0b73b3-a99b-4f57-b441-e0265c37813a updated: IDLE
2020-06-03 13:24:08.993 [.event.RuleStatusInfoEvent] - 4a43616b-e5d0-4816-bed8-5554b6ea34a4 updated: RUNNING
2020-06-03 13:24:09.063 [.event.RuleStatusInfoEvent] - 4a43616b-e5d0-4816-bed8-5554b6ea34a4 updated: IDLE
2020-06-03 13:24:10.034 [ome.event.ItemCommandEvent] - Item 'MyTempProxyF' received command 77
2020-06-03 13:24:10.085 [vent.ItemStateChangedEvent] - MyTempProxyF changed from 78 to 77
2020-06-03 13:24:10.112 [.event.RuleStatusInfoEvent] - 4a43616b-e5d0-4816-bed8-5554b6ea34a4 updated: RUNNING
2020-06-03 13:24:10.203 [.event.RuleStatusInfoEvent] - 4a43616b-e5d0-4816-bed8-5554b6ea34a4 updated: IDLE
2020-06-03 13:24:11.330 [ome.event.ItemCommandEvent] - Item 'MyTempProxy' received command 77
2020-06-03 13:24:11.373 [nt.ItemStatePredictedEvent] - MyTempProxy predicted to become 77

The first two show openHAB requesting a temp reading. The third line shows that the temp has changed. The lines with "RUNNING" and "IDLE" show rules running in response to the change. The rest of the lines show the new temp reading flowing to the proxy Items. You can correspond the UID for the Rule by looking in PaperUI. The Rules are actually sorted by UID and the UID is shown in small light text under the Rule name and description.

To force a temp change:

1. From a command line run openhab-cli console
2. Use habopen for the password.
3. When the prompt comes up issue the command smarthome.
4. Issue the command status MyTempProxy and take note of the value. This is the current state of the Item.
5. Then issue the command send MyTempProxy 65 to change the temp to 65. Pick a number different from the value returned by step 4. This will cause 65 to be published to hestia/local/temperature if MQTT is working correctly. It will also cause the rest of the Rules to react as if the new temp is that value. The next time the python script is called MyTemp should change to the new value. In both cases you should see logs like the above.

This is really handy for testing. If you prefer working in the browser, you can install the REST API Docs add-on under the Misc tab in PaperUI and issue the commands through the REST API.

NOTE: if you open Rules in PaperUI, you can see the Rules running as the yellow "IDLE" status changes to a green "RUNNING". This can be handy to see if Rules are running.

If you see the logs and do not see the MQTT message, look in PaperUI under Configuration -> Things and search for "broker". Does the "Mosquitto MQTT Broker" show as ONLINE? If not there is something wrong with Mosquitto or OH's connection to Mosquitto.

Settings are not persisting across reboot. I tried clearing my openhab cache, resetting permissions, and rebooting again to no avail

Look in PaperUI -> Add-ons -> PERSISTENCE. Is MapDB installed? If not install it.

If so, look in /var/lib/openhab2/persistence/mapdb. You should see three "storage" files. Do these exist? What size are they? What ownership and permission do they have? If not owned by openhab:openhab, run openhab-cli reset-ownership.

In PaperUI -> Configuration -> Items do you have a RestoreOnStartup Group Item?

Look at /etc/openhab2/persistence/mapdb.persist. Does it exist and does it contain the following?

Strategies {
  everyMinute  : "0 */1 * * * ?"
  default = everyChange
}
Items {
        RestoreOnStartup* : strategy = everyUpdate, restoreOnStartup
}

Look in /var/log/openhab2/openhab.log at around the time that OH is first starting. You should see lines along the lines of:

2020-05-28 16:10:16.362 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'default.rules'
2020-05-28 16:10:39.601 [INFO ] [.model.script.initialization.kickoff] - OH is loaded, kicking off initialization, Initialized == NULL
2020-05-28 16:10:40.035 [INFO ] [.model.script.initialization.kickoff] - Commanding Initialization Rule to start
2020-05-27 13:52:29.163 [INFO ] [marthome.model.script.initialization] - Initializing settings...

After that, if the restoreOnStartup failed than you will see a line for all of the settings Items along the lines of

2020-05-27 13:52:30.871 [INFO ] [marthome.model.script.initialization] - Comfort_Mode is undefined, initializing to COMFORT

Do you see lines like those even after the first boot?

Do you see any errors what-so-ever in openhab.log?

GPIO pins were not activated when sending commands to energize the fan or cooling. Again, hard to say if the issue is something with my setup but I did follow the recommended upgrade procedures from a clean 1.1 ONE img file

Run grep -i GPIO /var/log/openhab2/openhab.log. Do you see any errors?

Now run grep pins /var/log/openhab2/openhab.log. Do you see any lines saying "Commanding Pin12 to ON for HeatingPin" (or any other pin)?

In actuality, as long as there is no valid temperature reading I don't think the rules will get to the point where it will actually turn on or off the device. I may need to adjust the error checking to allow for a boost even when the temp sensor isn't at a valid state. What makes things complicated for heating is if second stage heating is enabled the second stage requires a valid temp reading even for a boost.

I'll give the new UI a go and provide feedback.

[rkoshak]

I may have found at least part of the problem. Before I submitted the PR I removed a bunch of unused Items, among them are Comfort_ValueC and Comfort_ValueF. But it appears that I still have the line in the Initialization Rule to initialize that Item which kills the whole Initialization Rule. As a result most of the Items never receive their first initial values (explaining the restoreOnStartup problem) and the Rules won't run, including the Rule that translates the temp sensor value received from the python script to the MyTempProxy Item which is how it get's published to MQTT. It also prevents the Rule that triggers the GPIO Pins.

The easiest thing to do would be edit the file manually rather than waiting for a new PR.

1. Open PaperUI -> Rules and scroll down to the Initialization Rule and click on it.
2. Click on the cog shaped icon under "Initialize all the setting Items"
3. In the "Script" text box, scroll down to the comment that reads "// Initialize setpoint Items"
4. Remove the line that reads "Comfort_Value"+unit, comfDef, max, min);

I think this might explain all of the behaviors you are seeing. I'll leave the post above in place as it has some good generic debugging information.

[rkoshak]

The fix has been submitted as a PR.

[jaythomas]

Thank you. I will let you know if I can replicate any of the other issues once I have a fresh image. Let's consider this closed.