-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
extend optimistic state timeout to 10 seconds #10735
extend optimistic state timeout to 10 seconds #10735
Conversation
prevents "flip flopping" for slow integrations/devices
10 seconds is too long to "lie". We should explore some indicator that it's pending. |
The pending indicator is even better approach.
Easiest approach for first version would be to tie disabled state of the control to the pending state. AND/OR have an entity attribute with the update delay, defaulting to 2 seconds and can be overridden at entity-level. |
The downside with disabling is that is what we do when the entity is unavailable. |
Hmmm, yeah you are right. So some kind of "loading indicator" would be better perhaps. |
We don't have something like this for toggles. For buttons we have a "spinner on button" although I am not sure if we still use it? We should let @matthiasdebaat take a look too. |
The UX pattern of a This is my suggestion: When the users click the switch, it toggles like we do now. When the integration doesn’t report back after 2 seconds, we replace the switch with a spinner. I want to keep the UI as clean as possible for the 80% most common situation. |
That sounds like a very good solution @matthiasdebaat. I'm not sure about numbers but I think we're talking about a small amount of integrations/devices that do not report back within 2 seconds. Anyways this issue gets reported many times on the forums and issue trackers so would be nice to fix. |
That video is an example from the docs about what not to do 😝 |
Yeah, I was just referencing that small spinner icon/animation :-) |
src/components/ha-circular-progress.ts |
This approach works for people who are watching the UI. It doesn't solve the problem for those using voice commands (e.g. Alexa) though. |
What do you mean? Does the voice assistant give feedback that setting the new value failed ? EDIT: Confirmed by reading the forum post. The voice assistant responds that the command failed while the light actually turned on/off. So the voice assistant (or any other listener for the command) should also retrieve a temporary optimistic state. |
Converted to draft as this needs more discussion |
Given the response of @kpine that this also has impact to the voice assistants this needs more thought and can't be handled in the UI entirely. Idea:
Or something like that. |
BTW: Do we have any idea which integrations actually have this issue ? |
Hello, I started an issue related to this PR a few months ago home-assistant/core#59379 and wondering if the change in 2022.2 home-assistant/core#64621 is related to or resolves this? Thanks! |
It would be nice to have this fixed. What needs to be worked out RE the voice assistants? |
Imo the only way to fix this is at core level (for all integrations):
This is an architecture decision. Speaking of making things easier and reorganizing stuff in HA I think this fits there exactly. This is a good example where the user experience differs completely from the technical one. A user doesn't care at all if a state update was retrieved for a device/light. All they see is "why the heck did my command not work ?" Created an issue for this in the architecture repo: |
The Simple Thermostat card shows this in a nice way: when changing the setpoint the color of the setpoint numbers turn red. Once the same value comes back from the climate entity then the color of the numbers goes back to normal. |
The Plugwise integration has this issue after fully implementing use of the DUC, see home-assistant/core#67687 |
There hasn't been any activity on this pull request recently. This pull request has been automatically marked as stale because of that and will be closed if no further activity occurs within 7 days. |
Gonna close this, there is currently a architecture discussion going to fix this on a larger scale. |
Proposed change
Discussed many times already in forums, discord etc.
Some integrations and/or devices are just a bit slow to update, for example some Z-Wave devices.
You send a call service to turn on a light but the new state only arrives seconds later.
This causes a weird "flip flop" in the UI. You turn on the toggle, 2 seconds later it turns off again and a few seconds later it will turn on again. For most people this will mean they will probably go wild toggling the entity as they do not understand why it toggled back in the UI.
Some attempts have been made to try to fix this in the integrations but that just feels hacky.
Not to say that this approach is better but it is way more simpler and works for all integrations at once.
This extends the optimistic timeout from the current 2 seconds to 10 seconds.
In other words: This will give the integration up to 10 seconds to report back the actual/updated state.
Type of change
Additional information
Checklist
If user exposed functionality or configuration variables are added/changed: