Thermostat Scheduler 2.0: Not setting correct setpoints by time

I've been struggling with the new Thermostat Scheduler. Migrated over to the new Thermostat Controller and Scheduler.

The scheduler is not setting the temps when the time period changes. So I'm trying to do it manually. When clicking the Set Temperatures button, the scheduler is not using the correct time period. The correct time period is bold, but the wrong time period's temperatures are being used. I've been having the same issue throughout the last 3 minor releases. I had created a more complicated scheduler that had the same problem. For troubleshooting, I recreated a basic scheduler where all the days are exactly the same and it's still off.

I will look into it.

Thank you. And for your information, The time variables are updated by a Rule. Depending on the day of the week, the Morning Start and Night Start changes. The same issue occurs when the time is fixed or is a variable.

Did you refresh the page after hitting Set Scheduled Temperatures? It is not a dynamic page. I'm not seeing any problem with this. It sets the temperatures specified in the row where the period name is blue. Also, look at the logs, and show a screenshot of those, as that's where you will see what it actually does.

I do refresh, but maybe not every time. I usually hit done and go to my dashboard or other things and open the scheduler again.

I've restarted the hub. I haven't made any changes or updates, nor clicked on Set Temp or Update.
Right now, it's not even picking the correct row. It should be on Wake, but thinks it's Late Night.

When I click Set Temperatures, the Control Thermostat Manually section updates the thermostat temps at the top immediately on its own. No refresh required.

And logs show:

So right now, the wrong time period is highlighted, and an even "wronger" :smiley: time period's temps are being used.

It would appear that something is messed up with your hub. Check you time zone and lat/long settings on the Hub Details page.

I'm not able to reproduce these issues at all.

Triple checked. All of those settings are correct. I deleted the late night period, and the scheduler works correctly. Is there some clue as to root cause in the odd sorting of the time periods? If I set late name to 11:59 pm I would expect it to auto sort to the bottom. If I set it to 12:01, that line should sort to the top.

Steps i use in creating the periods. New controller, set all options above, remove the two default periods I don’t want, add the late night period, set all the times/temps/etc.

Next test will be for me to only delete one of the unwanted defaults and rename the other. Finally, don’t delete any and ignore the unwanted one and set the others.

Some test results. All tests are making changes which dynamically update anyway, clicking done, and then going back into the controller.

  1. start times from 12:00 am to 12:59 am sort incorrectly. It always sorts to the middle row (actually next to last). When setting other periods to something appropriate for testing, the 12:00 pm to 12:59 pm sorts as expected - after 11:59 and before 1 pm.
  2. deleting the late night and Night period and clicking set temperature still sets the temp to the now nonexistent Night period even though it’s Day.
  3. adding a new period with a unique name has all variable unset (expected)
  4. adding a new period with a previously existing name Night is prepopulated with previous settings. (Not expected) These settings are what’s being used in #2 above.
  5. deleting all the periods results in all the 4 default periods reappearing with previous settings prepopulated. (Not expecting the prepopulation).

Thanks for your diligence in testing this.

Obviously there is some bug wrt 12:00 AM sort, most likely that it fails to subtract 12 from the hour for sorting purposes (i.e., it should sort using 24 hour clock, not 12 hour clock).

With respect to the re-population of a restored period, I can see this cutting both ways. Certainly the app could be made to wipe out all such settings. But there is the case of someone who removes a period and then changes their mind and wants it back. For this user the re-population from before is very helpful.

I agree that remembering and prepopulating can be useful. I’ve been saved a few times. It was unexpected, but not wrong. The issue is that the scheduler is still using the “deleted” setpoints.

Please let me know if there is anything more I can test or try. I think I’ve removed the scheduler from all of my rules, so I can test deleting and creating a new scheduler.

Do you mean after the time period is removed? Did you hit Done for the app after removing the period?

Yes. I removed the period, clicked done, went back into scheduler, and clicked set temperatures. It used the temps from the period no longer displayed.

Further testing: deleted scheduler, created new one. Kept all default time periods and their names as is. Assigned each period everything. Clicked done. Went back into scheduler and clicked set temps and nothing. Clicked done. Opened scheduler again, setpoints on thermostat controller is still what was there before. The correct period is bold right now, but the current setpoints are not getting applied.

Yeah, there appears to be some problem with initialization. Will track down why.

I am not able to reproduce this now. Could you please provide a screenshot of what the app looks like just prior to hitting Set Scheduled Temperatures that does not work. A screenshot of the logs when you hit that button for the app would be useful as well.

I haven't forgotten about this.

I have a bunch of screenshots, but there is nothing in the logs. I have been concentrating on ensuring the Thermostat Controller reliably works as before the upgrade. As part of that, I deleted the thermostat controller. Recreating it didn't make it work. However, creating a second one WHILE the first one existed made a properly working controller with a new ID. Then deleted the old one. Maybe there is a clue for you in that bit of info?

Before "set scheduled temperature"

thermostat 4

Strange thing from above is that during some test, it's setting the setpoints to 74 and 76 based on manually set points from the scheduler created a few tries ago. When it does use values from the table, it's the wrong ones such as circled above. This was before the time sorting fix. After the fix, It just doesn't set anything at all as seen below.

Nothing is happening in the logs when the set scheduled temperatures button is pressed. Just the initialization when clicking the done button. Same behavior before and after the sorting fix and new scheduler child.
thermostat 6

Created a new schedule while the old one was still there to force a new app ID. Deleted old schedule.


Clicking set scheduled temp does nothing. The currently set temps of the controller remain the same. clicked done navigated to other screens, opened the scheduler app again, no change. This has been the same through the last few updates over the last couple of weeks.

AHA! I found the problem - using variables. I entered the setpoints without using variables, and the set scheduled temps works (at least for the current time period)!!

I have found that choosing the setpoints as variables a bit weird. Once I choose variable for a setpoint, all other setpoints choices are automatically variable. Convenient, but I don't think it's working quite right.

Converting each scheduled setpoint to variable, testing by changing the setpoint and clicking "set scheduled temperature", and repeating for all 6 setpoints, it appears to be sticking for now.

Does any of this help?

Update: Aaaaand it stopped working again. :frowning:

1 Like

Yeah, there's a bug with this. Will get it sorted out for the next release.

1 Like

Download the Hubitat app