A couple of months ago I bought 2 Centralite Pearl thermostats to replace thermostats that wouldn't work within HE. They are easy to manage and look decent but the WAF has gone down quite a bit due to the deadband settings of these thermostats. With the old thermostats they kept it pretty close to 1 temperature all the time. Now with the Pearl's if we set the cool point to 75, it can range from 76 to 74 (A/C turns on at 76, and then doesn't turn off until 74) This causes the house to feel too hot or too cool at times.
So my idea was to create a rule to create my own deadband. Idea: Thermostat cooling point is set to 75 and at 76 it starts cooling. I then have a rule looking for temperature drop and once the temperature of the thermostats equals the set coolpoint, the thermostat shuts off. Wait 5 minutes and then it turns back on. In theory this should work but I've having some issues executing it. For one thing the thermostat doesn't always check in regularly. It seems to check in (or poll I think is what it's called in HE) every 6 or 10 minutes. Sometimes this is enough time to not trigger a decrease in temperature. So I updated the trigger event to be changed instead of decreased but still having issues with it working.
The physical device itself does have a hysteresis setting. Default is 1.8 degrees and I've changed it to 1.0. I've read other threads that this is just a dummy setting and doesn't actually do anything.
So I was using a custom driver created by someone on the forums here, and I just changed to the Generic Zigbee Thermostat driver. The only reason I was using that was for the Hold feature, which I never use. The generic driver provides more granularity on the temperature reported by the thermostat in HE. So I've updated the rule back to decreased. I'm going to monitor for a little bit and see how it functions.
Perhaps refreshing the Hubiat Thermostat will improve your results. I use a keypad as part of an Average Temperature thermostat device with the following:
I think that could definitely help. As long as the refresh pulls the current temperature that would help to be consistent with temperature reporting. Thanks!
Before converting my RM rules to Groovy apps, I bumped into this error. Did a quick workaround by using 'changed' on the RM temperature trigger, then adding an if testing the temperature direction in the actions. YMMV
Thanks for the tip, The only reason I was using decreased is to prevent the rule from running too much, since the temperature will be changing very frequently, I didn't want it to run every few minutes.
I didn't have an END IF before, do I need that? I added one in and I'm not sure if it's a coincidence or not, but now I'm not receiving that error anymore.
It just worked successfully using the same setup in the screenshot above, but with an END IF after -->Adjust Cool: -1
Kudos @arnb I appreciate all the help. I can confirm I am getting the error still, but it seems that I only get the error when the temperature is increasing, as long as it's not negatively affecting the way the rule works, then I'm ok with it.
It all depends upon how often the real thermostat updates the Hubitat device or vice versa. Check the device events log to make that determination. I feel processing an error is more overhead than executing an if statement for the condition with an Exit Rule if true.
I program in Groovy and AFAIK the subscribe commands choice for a thermostat temperature update is the equivalent of RM Changed. So my guess is the rule is triggered by all temperature changes and filters the Increased and Decreased conditions without triggering the Actions.
