Closed jjross closed 3 years ago
Just here to comment that I'm noticing this behavior, as well. Still an issue on Home Assistant 2021.1.5 (Official Docker Container)
In case anyone stumbles in here trying to figure this issue out, I have a simple work around that I like until this gets fixed. My main use case is "Scene Buttons" on a dashboard that set the desired scene in a room. Rather than just having the buttons set the scene, I have them call an automation that sets the scene, waits for 0.5 seconds, and then calls the update_entity for the switches that are applicable to the scene. This results in Home Assistant taking a consistent 1-2 seconds to know the state of the switches.
Confirming that I also have the issue, It was definitely not there in earlier versions, yet cannot confirm when it got broken. For now, I'm looking to manually update the status of the switches until it gets fixed.
Just here to comment that I'm noticing this behavior, as well. Still an issue on Home Assistant 2021.1.5 (Official Docker Container)
In case anyone stumbles in here trying to figure this issue out, I have a simple work around that I like until this gets fixed. My main use case is "Scene Buttons" on a dashboard that set the desired scene in a room. Rather than just having the buttons set the scene, I have them call an automation that sets the scene, waits for 0.5 seconds, and then calls the update_entity for the switches that are applicable to the scene. This results in Home Assistant taking a consistent 1-2 seconds to know the state of the switches.
@cvsickle Mind sharing your automation on this? I have the exact use case and I'm trying to call homeassistant.update_entity from the automation against my tplink entities however this does not appear to change the delay I see in the UI. Thanks!
@akeslo, if you're interested in a different approach: I made it working just fine with NodeRed (I use it exclusively for all my automations). I'm using a 1s "pulse" node to call the update_entity for each of my TP-Link devices, works like a charm.
@akeslo, if you're interested in a different approach: I made it working just fine with NodeRed (I use it exclusively for all my automatons). I'm using a 1s "pulse" node to call the update_entity for each of my TP-Link devices, works like a charm.
@wzaatar thank you, taking a look now! I'm thinking I need to call the update_entity service every x seconds as I'm seeing delays in the UI beyond automations. For example, I have an auto entites card that shows all lights that are on, when I switch on a light this takes >~30s to update
Sounds like 1s "pulse" node to update_entity will fix this :)
Yes, I tried more than 1s, response was sluggish.
This works really well with node, thank you. I ended up using an inject node setup on repeat for 1s, is this what you are using? I couldn't find a "pulse" node.
Yes, it's the inject node configured to send an "on" pulse every second. I think the refresh rate for all my TP-Link devices now is very acceptable (I have around 15 of them in my setup).
@akeslo It seems like you have your solution, but if you still wanted to see my automation solution that I'm using for two switches, here you go:
service: homeassistant.update_entity data: {} entity_id: >- switch.living_room_main_light, switch.dining_room_light
After the automation sets the scene, it delays for 0.5 seconds, and then calls the service above.
Edit: of course, the drawback to this is that Home Assistant is not updated right away when one of the switches is manually toggled.
@cvsickle thanks for sharing! This likely has a lot less overhead than the node solution running every 1s as well :).
Maybe this is related to recent changes to retry handling? Ping @TheGardenMonkey
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.
The problem
I am using the TP-Link Kasa integration with a Kasa switch (HS200(US)) and Home Assistant is taking a very long time (up to 30 seconds) to reflect the status of the switch when it is activated manually (pressing the switch).
In reviewing the documentation Platform Options I can see that the default polling period appears to be 30 seconds so I believe that this integration is using the default period.
In older Home Assistant releases it was possible to define the "scan_interval" for a platform but this is not possible for a GUI configured integration. Also, though I have not experienced this (I only recently purchased this switch) forum posts appear to indicate that the integration did not used to behave in this fashion. Details from the forum are located in this thread
I understand that this is a local polling style integration and not a local push integration but I am not seeing this slow of a response from other local polling integrations (Phillips Hue for instance) so I still feel this can be addressed by code.
As you can see from the forum post people are using workarounds to address this issue (automations that call homeassistant.update_entity every three seconds for example) and I would think this would be better served as either a configuration for the integration itself or a new default value (3 seconds?) that would make this behave similarly to the Hue integration.
Environment
Problem-relevant
configuration.yaml
This is configured via the GUI integration page and does not have a YAML configuration.
Traceback/Error logs
Additional information