Rule Machine - Thermostat wierdness (dropped HE version as irrelevant)

I updated as far as 2.1.5.120 and did not notice any issues. However, updating to 2.1.5.124 has introduced some wierdness.

With all the thermostat troubles I had with Thermostat Scheduler, I finally gave up on it and wrote a Rule Machine 4 rule to control the thermostat. It was rock solid until I tried 2.1.5.124. Something apparently changed, and not for the better.

The wierdness is that the mode change and thermostat changes for away, home, or night have not been working as solidly as they did through 2.1.5.120 (I missed 121 and 123). We went away and when I checked my home through the app, the thermostat setings were still at the home settings, not the away settings. Likewise, at least once when I returned home and the mode switched to home, the rule which should have changed it apparently did not do so.

Was there anything in the hot fixes that could explain why it was working reliably in 2.1.5.120 but is giving me issues with 2.1.5.124?

I noticed the same failure to follow my rule in 2.1.5.20 so I just backed down to 2.1.4.130. If it behaves now, I will likely stick with 2.1.4.130 for now.

I was just about to make the jump to 2.1.5.124 when I saw this post. Heating is a big use case for my Hubitat, so i think I will stay on 2.1.4.130, but can you tell me what kind of issues you were seeing ?

The main issue is that I made a rule to operate the thermostat, switching temperature setpoints based on whether we were away, home, or at night. The wierdness was that my rule stopped behaving reliably so that I would come home and the setpoints would not change.

This is the rule:

I use a different approach, and arguably more complex. I only have virtual thermostats, so I have temperature sensors that report into those thermostats. I then have the app, thermostat scheduler to create my different schedules, which then turn on z-wave outlets to turn on fa

I think I will stick around on this version and see what is in store in future updates.

I used a Zen Thermostat up until about a year ago. If I remember correctly, in the advanced settings there was a config for the maximum difference between the heating and cooling setpoints, and that maximum difference was seven degrees (W7-I think). If I changed a setpoint and the resulting difference was more than the max, the thermostat would, eventually and automatically, change the other setpoint to be within that max spread. Might be something to research?

The setting is that there has to be a minimum spread between the heating and cooling. I don't recall seeing anything about my settings which worked fine up until recently.

As it is, I am sitting here and seeing it have the same issues with 2.1.4.130 so I am trying the upgrade to 2.1.5.124 again since it is apparent that it is something else going on. I don't know if it is my WiFi network interfering with the Zigbee mesh. That is a possibility. To see if I can rule that out, I am changing the WiFi settings in my router to use WiFi Channel One, which is about as far away from the Zigbee channels as I can get.

1 Like

I had some problems sending both heating and cooling setpoints at the same time to my GoControl thermostat. There were a few times when heating setpoint would update but not cooling, or vice versa.

Ended up splitting into three rules...one to send heating settings if thermostat is in heating mode, one to send cooling setpoints if thermostat is in cooling mode, and a third to trigger either the first or second if the thermostat mode changes. Haven't missed anything since.

It is encouraging to see that the rule fired and thermostat changed as it is supposed to this morning after forcing the router to use WiFi channel One. If this keeps up, it will be more confirmation that the issue was not Rule Machine or 2.1.5.124, but was a WiFi-Zigbee conflict. Also, if It continues to behave, I'll flag this as the solution.

I am marking this as solved. I believe the real problem was a WiFi/Zigbee conflict. My thermostat is on the hub which uses Zigbee channel 20. WiFi was set on Auto. Apparently, when I set up a guest login, the WiFi channel(s) changed to conflict with Zigbee channel 20 sufficiently that the thermostat started not responding as it had before. I disabled the guest network (since our guests have departed), and forced the WiFi channel to channel 1. Since doing this, the thermostat has been responding properly again.

For all who have a Zigbee thermostat and are having problems, check your WiFi settings. It may be part or all of the problem

Edit: I wrote too soon. After working all day, it missed the change from home to night. :frowning_face:

In addition to my above remarks, there was one factor I was overlooking. I have a WiFi extender. When we had company, I moved it which likely caused a change of channels. After the company left, I put it back in its original position which likely caused a second change of channels. It is this change that likely was the cause of the issues. Ihad previously changed the main router's channel to WiFi channel 1. However, I had not reset the WiFi extender. Yesterday evening, I reset the extender by unplugging it and plugging it in again. Since doing this, the thermostat appears to be again behaving.

So, it again seems to confirm that a WiFi/Zigbee channel conflict was the cause of the issue.

I also did the update on Saturday and my heating is working fine, so most likely it is down to network.

1 Like

Thanks for the confirmation.

Update 10/16/2019: I unplugged the WiFi extender after noticing that the thermostat was again not responding to the mode changes as specified in my rule. It appears to be working okay again. Another indicator that the problem was a WiFi/Zigbee conflict.

Unfortunately, I am so heavily invested in Zigbee devices. I don't want to switch to Z-Wave given the problems I have read about with Z-Wave on this forum. I don't know if it would be any more reliable, but it would cost a significant amount to change over.

I need to figure out whether I can specify a channel for the range extender. If so, I can perhaps choose one that wont' conflict with the Zigbee channels.