Schedule usage

[agile glacier]

I’m trying to think about using the schedule helper, where I have tasks that run one after another in inconsistent blocks

If I have two blocks next to each other in the same schedule (ie one block ends at 7 am and the other starts at 7 am)), but they have different additional data attributes, does the schedule trigger off/on at the transition block? If so then how do I check when it’s truly off? If I check for an off state and do something then immediately override it with the on trigger of the next block are there any race conditions?

Similarly if I make separate schedules instead of different data attributes is there a race between the “off” of one schedule and the “on” of another? How do I deal with that beyond setting tasks a minute or so apart and hoping they finish? Do I have to keep state somewhere? Even then you presumably need a delay so you know which one triggers the mutex first.

This all seems confusingly complicated for just wanting to detect a state transition so I feel like I’m missing something

Basically I need to be able to see what the new state is in the off trigger which leaves race condition questions, or, if I can’t, I need to somehow ensure the off condition finishes running before the next on condition at the same time triggers (whether it’s in the same schedule helper or a different one)

This should be relatively fundamental to any usage of back to back different scheduling of things

[agile glacier]

oooo I see it fills the “next_event” field. Is there a canonical way to use this? So i need to check if the next_event is within 5 seconds or so of the current time?

My use case is relatively simple:
a schedule for thermostat for when I’m sleeping, then setting whatever the regular thermostat thing is when I’m not sleeping

But then also set a different thermostat value for the 30 minutes when I’m waking up -> but this has a race condition with setting the regular thermostat from above. Because sleep is ending. But if I track waking as a separate data attribute I still have off/on triggering at the schedule boundary creating a race condition on setting the thermostat again

And maybe the answer is just the schedule helper (even utilizing multiple schedules) isn’t the right tool for schedules needing to set items with more than 2 states

[agile glacier]

So all I want to do is have a schedule where I set a thermostat to one of three states based on time of the week, but unless I’m missing something the schedule helper isn’t suitable?

[west current]

I think a way to do this with schedule helpers would be to have separate schedule entities for each state, e.g. a sleep schedule that only has times when it should use the sleep setting, and a waking up schedule that only has times when it should use the waking up setting.

Then in the automation, you could check for state changes on all of the schedule entities, and write up a choose statement - "if sleep schedule is on, set temperature X, otherwise if waking up schedule is on, set temperature Y, otherwise set temperature Z"

[agile glacier]

I assume one automation can’t run twice at the same time, so it solves any race, but not necessarily the ordering I guess? like imagine waking is after sleep, I don’t see why in principle sleep off triggers before awake on, so you could have unexpected behavior if they’re set at the same time. but I guess you set them one minute apart and then the lack of race guaranteed by being the same automation saves you?

does the state continue to change in the background? can I just put a one second sleep at the start of it and check the current state

[west current]

if you always check the current state of the entities in the automation, then I think it should work? i.e. if you get triggered by the sleep schedule ending, then when you do a check to see if the wake up schedule is on, it will already be on.

[agile glacier]

I can accept that as a solution but I’m curious if that works because the logic is correct, or because python is slow

because it would seem to me the concurrency logic is wrong 🙂

[west current]

I … think it should work, because the "schedule" helper is calculated, so it should always be returning the exact current state when you check, but if you're worried about it you could make the states overlap a bit.

i.e. make it so that by the time sleep ends, wake up has already started, so there's no chance of a gap.

[agile glacier]

right, but there’s a different sleep ending transition without a wakeup on weekends so I want to actually do something there

[west current]

I don't see how that's a problem? you can have different schedules on different days, and not having a wake up time set on one day won't cause a problem.

[agile glacier]

if you trigger “off” to set a state, and awake “on” to set a state, and awake “on” triggers first, then it will get immediately disabled by the sleep “off”

oh, but you’re checking the current state

I see what you mean@!

I think the overlap is a good solution then

[west current]

the reason this works is that in your automation, the triggers are only used to run the automation - you don't need to check which trigger caused the automation to run, or what the trigger data is. Instead inside the automation, check the current state of the different schedules to decide which temperature to set.

[agile glacier]

I mean it’s a bit silly you’re triggering everything twice at transition points, but that’s basically harmless

[west current]

yeah, the worst it will do is set the same temperature twice.

[agile glacier]

right

this seems like such a basic problem though I’m somewhat surprised I couldn’t find anything about it when googling about schedule, so I wonder if the schedule helper isn’t really a very canonical solution to this problem…

maybe most people just have a bunch of time/day based triggers

[west current]

yeah, I guess having schedules which are directly adjacent to each-other isn't that common.

since it's mostly used for "on/off" controls, rather than changing something over the course of a day.

[agile glacier]

yeah if there was two states there’s no problem. They added the ‘data’ attribute anticipating more but it doesn’t seem to me particularly useful with the types of triggering available for transitions

(for all the reasons discussed)(

[west current]

actually… since the additional data works by setting entity attributes, maybe using an entity attribute changing trigger on a specific attribute would work for this?

[agile glacier]

🤔

Assuming that trigger works I don’t see any logical problem with that

[west current]

I'm not sure how that will handle the case when no schedule is active (which means the attribute isn't defined).

could be worth testing out to see what it does

[agile glacier]

hopefully it would return None

if it left the attribute value as it was that would suck

but you could fill the schedule solid as a workaround maybe

actually maybe you do want it to leave attributes so it’s not zeroing it out during the off trigger

[west current]

i'll be able to let you know what it does in a couple minutes when my test schedule triggers :)

[agile glacier]

🙂

[west current]

Works perfectly. you get one trigger when the schedule turns on (attribute goes from missing to present), one trigger when it switches from one scheduled event to the next (as long as the attribute changes - if the attribute is the same there is no trigger), and one trigger when the schedule turns off (attribute goes from present to missing).

[agile glacier]

That’s the ideal behavior!

Nice!!!

I was expecting perhaps it would turn off and then on when it went unchanged but that’s much better

[agile glacier]

@west current just getting to trying this!

🤞

[agile glacier]

Seems to work so far

Now to set it up fully when I’m awake tomorrow

[agile glacier]

lol everything is working I just need to figure out how to set both the upper and lower temperature without it being one of the ecobee climate modes lmao

Got it the UI configure was just hiding the high and low sets lol

[agile glacier]

Oh god there’s a race between the clear hold button on ecobee thermostats and setting the new comfort setting preset fuck me

Hmmm not sure there’s a trigger I can use for that

[agile glacier]

Lmao the downstairs thermostat was just in some sort of bugged state and rebooting fixed it

[agile glacier]

@west current my alpstugas just came, did yours stabilize co2? I’m about to try putting them outside to see how that works

Ope I need to find some usb c cables

[west current]

it got better, but it's still reading a ~100ppm lower than my other sensors. i'm keeping an eye on it to see how much drift it has.

blue line is the ALPSTUGA, yellow line is a zyAura ZGm053U (dual-beam NDIR), red line is a Sensiron SCD4x (photoacoustic) via ESPHOME that I just set up. Interestingly, the SCD4x appears to have rather good out of the box calibration.