Creating my own Thermostat deadband / hysteresis

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.

My actual rule is below. Any ideas?

Should the hardware thermostat or it's Hubitat thermostat device have an adjustable hysteresis setting set it to .5, giving a 1 degree range.

If not, should the Hubitat thermostat device have a hysteresis attribute, try setting that with RM, hopefully it feeds back to the real device.

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.

A hysteresis of 1 gives a 2 degree range from the heat or cool setpoint, 1 degee up or down.

Most modern thermostats use hysteresis. Try setting it to .5, hopefully it's a real setting.

Sorry, I should have specified, I set it to 1.0 which is the minimum. That is why I was trying to use the RM to create my own .5

:disappointed_relieved: :cry:

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:

1 Like

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!

1 Like

Well the refresh worked well so far with the Downstairs thermostat. However, the Upstairs thermostat is not functioning the same.

Rule:

Downstairs:

Upstairs: Only shows the Refreshing values line. Which is weird. They are both the same model and using the same driver.

I updated the rule, so it won't actually turn off the thermostat - just in case there is an issue and the thermostat doesn't turn back on.

The rule works sometimes but then other times does not, throwing this error:

Thinking of taking a break and maybe a fresh perspective will give me what I need.

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

1 Like

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

I can't say without seeing the entire rule. However, a missing END-IF can have a profound effect on the logic, so they are generally recommended.

If it's working, leave it be!

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.

I'll continue to monitor it. Fingers crossed!

My OCD requires this error be corrected or avoided if it was on my system :crazy_face:

Haha I hear you. So you think having the error is a bigger issue than having the rule check more often since it will be changed instead of decreased?

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.

1 Like

Thanks. I did not have an ELSE in my rule either. Added ELSE Exit rule and change the trigger to changed instead of decreased. We shall see