Controlling the schedules "offset" no matter where in any schedule you're in or when creates a central control problem that's fixable. It'd be a lot easier to manage the "EcoMode Offset if it could have the option to be set by a variable. The only other issue is to allow the schedules to self update if the offset changes.
One last issue... doing an update to the offset using another app only updates the first schedule in the list rather than the active schedule, even if the others are restricted.
For peak rates, why do an offset at all? Why not simply schedule your temperatures? Peak rate times don't change. To fix missed schedule changes due to away mode being active, force schedule refresh after mode changes.
I don't use modes at all, not useful in my situation and doesn't solve the stated problems. These are genuine bugs in the software, not issues that warrant workarounds. I don't actually use the offset for rate changes, sometimes I just want to offset the whole active schedule temporarily w/o having to edit all the time periods, One of my schedules includes 8 time periods for a more gradual change throughout the day, very useful in a climate like Phoenix. With the offset turned off, the feature obviously becomes useless, but on I can have it at 0 for normal or offset +/- whatever to change the temps in all the period settings. On the personal side, it stops my better half from fidgeting with the temp override on the thermostat, which goes back to schedule upon the next time period and gets her upset.
Yes a have, in fact that's how I use virtual buttons and a variable to set the offset. This worked fine until I had more than one schedule. I currently use three for different times of the year according to rate changes, that's when I ran into my current situation. The offset even use to stutter it's changes this way, but some update settled that down. Each time the offset would change, the rule would have to initiate a manual schedule update and set schedule.
I know these kind's of variable changes can make a difference in how the rules machine works and how apps respond to them. See this previous discussion about sunrise/sunset offsets - https://community.hubitat.com/t/feature-request/104415
Apologies but just to be 100% sure do you mean more than one Thermostat Scheduler instance for the same thermostats ? I think of "schedule" as one entry in the scheduling table of one Thermostat Scheduler.
See also what I posted this morning, in case it is relevant to your use-case:
I currently use 3 different Schedules for different "seasonal" times of the year, but only with one thermostat. I set a restriction for which one is "active" based on virtual switches that are set by a rule, otherwise they'll override each other (another bug, but workaround works). All schedules should respond to an EcoMode Offset change via rule control, but it seems to only set the first schedule's offset, and not the others, even though it's not the active schedule. What would work better is if all the schedules' offset can be changed by a single variable that's set by a rule. The other issue is set an offset doesn't automatically update and set the schedule... see my previous post.
DG
Technically my rule is setting the offset by variable, but from the image it gets complicated, which might point to why it's having problems. As I said better to have the scheduler allow offset by variable and to automatically update and set schedule when a change occurs.
In rule machine, did you set up just one action to set the EcoMode offset, or three? I think you might want to try three distinct actions, in each action selecting one specific Scheduler by app name rather than the default, which is by thermostat. If you select the Scheduler in the default manner (by thermostat), it may just pick whichever Scheduler it thinks is "first in the list":
Yes, I did set one action for the Offset. I notice you've recreated the scenario I'm in. I suppose three actions, one for each schedule, plus the set refresh for each might be a good work- around. I also think the default behavior you're describing is probably right on, though that still begs the question of why it picks the first one, rather than the active one?
I'll give a test on your idea and see how it behaves over the next few days. I'll do some schedule switching to see how it behaves. Still hope for a better solution, or is this intended to track down the bug and produce a long-term fix?
Ok, I've tested it and so far it behaves, though the offset gets a little jumpy when setting it, another old bug. Anyway here's my rule changes and it was less fidgety if I add the Schedule Setpoints refresh as a conditional rather than setting all 3 at once.
Correct - making sure to select the Thermostat Scheduler by app name and not by thermostat.
I am not sure Rule Machine has any awareness of which Thermostat Scheduler instances are restricted, it would have to query the Schedulers (which ones?) to find out. Plus, in theory, nothing currently stops one from having more than one "active" Scheduler for a given thermostat, so this type of selection for Thermostat Scheduler actions remains, in my mind, ambiguous (and to be avoided IMHO).
Consider another workaround: add an action (one per Thermostat Scheduler) to turn EcoMode OFF prior to setting the offset. Does that make the offset setting less "jumpy" ? (works for me).
I summarized the findings in a bug report here and tagged the support team for attention. I don't use EcoMode the way you do but I do use it as well as restrictions so I am exposed to these issues myself.
Tried the EcoMode on/off 3 different ways in the rule and if anything, it got worse. For whatever reason, whether it's add or subtract a degree, it tends (about 2 out 3 times) to jump 2 steps and then back to the right value.
