The components which are directly relevant to my problem:
HA v. 0.114.4
AppDaemon
wall RF433 switches
… which signals are caught by a Sonoff RF Bridge
… that sends an MQTT message
… handled by AppDaemon
… to switch on/off Sonoff Basic switches via HA
I totally understand that such a complex setup can induce some lag between the moment I press the wall switch and the moment the light is on or off.
I have not witnessed serious lags (they are there, but seem to be ~500ms, completely bearable) - when pressing the wall switch that handles a single entity (a single switch).
What I see, though, is that when a have a quick series of messages sent to HA from AppDaemon, they seem to be throttled (for a lack of better word: the time between the switches of the several devices is different and the more switches I go though, the slower to react the last ones are.
To be more precise: I have a group of switches (not lights) and to toggle them, I have to iterate over the components of the group, calling the entity one by one. This means that if group.room has 10 entities, I have to call the “switch off” service on each of them one by one. I cannot toggle group.room.
The effect I see, generally speaking, is that the time of reaction between device n and n+1 increases as n increase. It really feels as if the calls were throttled.
This is still acceptable, but I would like to understand whether this effect is expected because of some design
I am an amateur developer and I understand that the lag can come from various places (the messages could be sent with a delay by AppDaemon for instance (which is not the case, but that’s an example of possible cause)). What I probably mean to is to understand whether HA has some limiting capacities built-in (and if so - whether they are tunable))
Note: I know that I could turn my switches into lights via the switch platform (and have the ability to toggle a whole group - which may or may not help) but I want to keep that setup to be able to consistently edit devices and entities though the Lovelace UI.
@tom_l: you modified the question to make it an AppDaemon one but this is not specifically an AppDaemon question (I just mentioned the whole stack for completeness).
I would say that it is rather a pure HA one - but there is no explicit category for that (besides “Configuration”)
Yes, because this is where the events are sourced from - but the essence of my question is
What I probably mean to is to understand whether HA has some limiting capacities built-in (and if so - whether they are tunable))
I should have probably made it clearer in my question but never mind - I will see what comes from that (especially that AppDeamon users may have witnessed something similar). Thanks for following-up.
I believe the only limiting factor attributable to Home Assistant is the one second resolution of the event loop, and it is not adjustable. This limits how quickly a Home Assistant event listener can react to an event (up to one second delay). I am not sure if this is applicable to your iteration.
It could very well be, thank you. I will be looking at the precise timings of the fired events on HA side.
Do you know whether homeassistant.turn_on (or off) is synchronous? That is, does it return immediately to the caller and runs in a thread of its own, or does it wait for the action to be finished to hand back?
It may indeed be this. Per my previous message, I timed the calls to a group of four entities in this piece of code:
def toggle_group(self, group):
state = self.hass.get_state(entity_id=group, attribute='all')
operation = self.hass.turn_on if state['state'] == 'off' else self.hass.turn_off
for entity in state['attributes']['entity_id']:
operation(entity)
This means that the four entities are iterated over and homeassistant.turn_on (or off) is called. I measured the time between each of the calls. The results are (in seconds):
For the toggle ‘on’ (which means calling homeassistant.turn_on on each of them):
0.962460
0.185220
0.952443
For the toggle ‘off’ (which means calling homeassistant.turn_of on each of them):
0.101885
1.907397
0.142208
there is clearly a split between the ones that are instantaneous (~0.1s) and the ones that take ~1-2s. Since the resolution time on HA side is 1 second that could explain it (maybe there are other reasons, such as the resolution on AppDaemon side).
I will switch back the classification you applied to that question to get AppDeamon users more involded.
Why do you need to iterate over the entities when you set them all to the same state? Just use “operation(group)” instead of looping through the entities.
Oh yes, this is a very good point - I missed that (obvious) solution, thanks.
The delay is still there but the code is cleaner.
This (and the fact that there is the same delay when switching the group through Lovelace) means that there is something weird in the way the group entities are switched.
When clicking on any single light the switch is instantaneous, but when they are switched at once as a group the delays between the lights are very noticeable.
I would like to hold on with that question for a moment - while I investigate. I do appreciate very, very much your help so far.
The reason is that I realized I have another group of switches (twice the number of devices) made of ESPHome devices and this group, when switched the same way as the lagging one - switches instantaneously.
OTOH all four lights in the slow setup are connected to a MEROSS strip, which is integrated though the MEROSS cloud. I do not see any noticeable lag when switching a single port of that strip (I am actually quite surprised by that, I expected lags) and maybe there is a throttling mechanism (either in the component, or on the API endpoint).
As for the network, I have a Wi-Fi built upon Ubiquity Unifi APs, a MQTT broker running in a docker container and plenty, plenty of services (internal and external) that rely on this network. While of course everything is possible, I have doubts about congestion or MQTT - looking at all the other services.
This single device integrated via an external could (and the throttling which can derive form there) really seems to be the core issue.
Please bear with me while I investigate that part - again I do appreciate enormously your help.
I assume this is the problem. I could imagine that it queues the requests if multiple ones (switch light x, y and z on )are sent as one. This would also explain why it works when you press one switch after the other, because then you are always only sending one command at a time.
Yes, I am digging into the code to check for throttling client-side, and timing a tcpdump session to see whether a server-side throttling is not present either (or as well).