Thermostat Scheduler Away mode issue when activating schedule

I have come in to a situation that I was not aware of when remotely managing new rules and after some tests, I believe this might be a bug.

Here is one of my Scheduler screens...

I have a switch to disable and enable the scheduler depending on certain rules and#or apps. Anyway, when this rule is enabled again, the scheduler goes back in to action as expected when someone is home, but if we are in away mode, it will come back to it's regular schedule and completely ignores the fact that it's away and should use the ECO offset.

This can be reproduced every time, just by using the either a Restriction switch and or just by hitting the Set Schedule Temperatures button.

Another possible bug is that when the scheduler gets activated again via the Restriction switch, I need to have a rule to run the Set Schedule Temperatures method or else it will just stay at the old temps until sheduler gets to a new "program" in it's schedule. Not sure if this is intended behavior but I can live having the rule to do this.

1 Like

I will look into this...

About having to Set Scheduled Temperature after the restriction is removed, this is the expected behavior. In general, Thermostat Scheduler does things only upon the scheduled events (or Away/Return), so the expected situation with a restriction is that it would prevent such a change -- not that it would initiate setting anything when lifted.

This problem with not honoring Away after a restriction is a bug, and will be fixed in an upcoming release.

1 Like

@bravenel Hi Bruce, wondering if you had a chance to look at this, I'm on the latest version, 2.3.5.105, and still does the exact same thing.

BTW This also happens when booting up, if the mode is away, it will not use it but set the regular mode temperatures, noticed this when I updated the hub that has this app on remotely with no one home and got a SMS that the temps changed on the thermostats when no one is home (small rule I had installed when doing tests) .

The app doesn't run upon booting up, unless something explicitly causes it to run.

I need you to articulate the exact sequence. This was tested extensively...

@bravenel After doing more tests and creating a new schedule on my dev hub, all was working, so I redid all my schedules on the production hub just to be sure and the bug was back! So after some more thinkering, I finally found what is going on. What I'm experiencing is only when using a variable as the thermostat setpoint. If I change the variables and use fix numbers all works as expected.

Hope this helps track down the :beetle:

Thanks. I will investigate further...

Please clarify for me: Are you saying that the problem with the Restriction switch only manifests when the setpoint is a variable?

Again, I really need you to tell me the exact sequence of events that causes the problem.

ok easiest way to reproduce this is to setup a simple scheduler like in the picture...

You must use a variable for the temperature, set "Use EcoMode for Away" and set an offset in the "EcoMode offset" field.
Now set the presence of the hub to away and as expected "EcoMode" is enabled and the thermostat will go down the amount of degrees set.
But if you go in the Scheduler page and hit the [Set Scheduled Temperatures] button, it will actually set it back to the "non EcoMode" temperature, yet it states that EcoMode is activated next to the "EcoMode Offset".
If you all this with a temperature setting that is a fix number (not a variable), the temperature does not change and keeps the EcoMode temperature as expected.

If this is not clear, let me know and I'll just do a video screen capture of what is going on.

Thanks. Found and fixed.

1 Like

Thanks!

Just checking on this. I am having a similar problem with a pretty straightforward setup.

When in Away mode (unchanged system definition) and Scheduled Setpoints are activated (programmatically or via the button on the thermostat scheduler) the non-Away setpoints are sent to the thermostat.

It sounds like you've addressed this already, but I'm not seeing a change in behavior. I'm running 2.3.5.130. Has it been fixed since then?

Thanks!