…if it is not fast enough will it actually record all state changes?
Let me expand on what in the face of it might sound like a stupid question.
I have a wait_template that waits for a state change. Sometimes that state change can be within a second or two and allowing for the integration to do it’s stuff and report the change it seems to me that they get can lost.
Specifically (and I’ve left this until last because Sonos is probably a minority integration and I didn’t want the best brains to think it didn’t apply to them - I believe it is a universal issue) my Sonos TTS system waits for state changes to playing and then paused to know it has finished.
Recently (I suspect since 0.99 but wouldn’t even know where to begin looking) this has not always worked because sometimes the state never changes to playing and the wait_template never evaluates to True. And it is definitely ‘random’ behaviour but appears to only happen with very short TTS events.
What I want to know is, do state changes get queued and applied eventually or, if the engine can’t keep up do they just get lost?
If the former then I can probably start by assuming the Sonos Integration isn’t always working properly. and if as I suspect, the latter then I will have to think of another way to know when the TTS has started. (Suggestions appreciated!)
I don’t think its a problem with the speed, a pi3 can handle a million events in a few seconds from recent benchmark runs.
If HA can see a door switch trigger and have the light on before I open the door I think its plenty fast.
Can you go to the states page and see if it actually sees the state change? Are you sure that the change is coming to HA? Is the change a push or a pull to HA, what is the polling interval is pull?
Unless you are running an absolutely massive and very chatty system on a potato I doubt the event bus or the listeners are your problem.
Even when an addon went haywire and hogged the majority of my system resources I was still seeing events trigger automations, all be it delayed by 5 to 10 seconds (when usually they were ‘instant’).
There is a similar issue with the GPIO binary sensor. Very short events will trigger an on event but more often than not the off event will be missed. This is down to the way the integration is implemented not the event bus.
Well, I’m glad I got some responses because on the face of it I absolutely agree with this
and it has taken me a good few days of watching this behaviour to pluck up the courage to ask a patently ridiculous question. Especially as I don’t have a massive system and it is not running on a potato (I run a currently over-powered NUC.)
However…
I know (as much as these things can ever be ‘known’) that my Sonos media players do not always change state from paused to playing despite the fact that they do ‘play’.
I know this from:
the fact that my wait_template (sometimes) never evaluates to True, leaving scripts on despite hearing the TTS play.
from looking at the trail of states in the Logbook
and using Occam’s razor I will have to assume that the Sonos integration doesn’t work properly efficiently enough to use wait_templates the way I am using them.
Clearly not that short!!
But my alarm pending warning beep is just under a second (the script that plays it loops for a set duration).
And the announcement that tells me alarm is deactivated when I come home is two words long so probably less than two seconds.
But yes both of those are long time in computer time…
I could get around this if I could find a way to base the wait_template on the state of an attribute changing because there is one (media_position_updated_at) which I think always gets updated (eventually).
No one needs to guess if a state change has or has not happened. Just set homeassistant.core to debug in the logger, run your system, then look in home-assistant.log for state_changed events. No guessing required, only searching skills and patience.
@tom_l Will that work? I thought wait_template would only see state changes rather than attribute changes.
Anther day, another thing to learn about HA…
A wait_template will be evaluated and if it evaluates to true the script will go on immediately to the next step. If it evaluates to false, then it will listen for state_changed events for the referenced entities, and whenever one happens the template will be re-evaluated. A state_changed event will happen when any part of an entity’s state changes, even if only an attribute changes.
Everything in Home Assistant happens simultaneously (out of sync/asynchronously). It could happen that you only reach “wait for playing” after Sonos has already played and is back to paused.
But solving this by guessing is hard. I agree with other posters that the first step is to check whether the states changes are actually recorded. The Logbook should work for that.
looking in the logbook, when it works as expected all state changes I expect to see including playing and paused are shown but when it doesn’t work as expected no state change to ‘playing’ is recorded there.
So then I started wondering if the Logbook couldn’t keep up either!
The state machine and thus the Logbook will not drop state changes.
The Sonos integration can work in push as well as poll mode. You should verify that it is working in push mode. You can test this by pressing play/pause on a speaker a few times. If Home Assistant updates almost immediately, you are in push mode. If it takes a random 0-10 seconds to update, that is poll mode and state changes can be missed.