When turning on a light or switch, using the toggle in the frontend might “jump”.
This can happen when, e.g., the device didn’t respond or didn’t respond quickly enough or any other reason that caused the state to change back.
This “jump”-ing behavior is very annoying to me, as the state of the action I did, can be reverted a couple of seconds later. What is missing here, is feedback on “I’m busy” / progress.
I would love to see something like this implemented on all toggles in the UI:
This at least gives me feedback on the action being in progress vs. the state actually changed and is confirmed.
…/Frenck
(PS: The example video with the progress indicator is actually considered a bad example by Google/Material Design, but I think it fits the Home Assistant scope/context really well).
I have this issue with Zigbee where moving the brightness bar will move it as if it registered only to then move back halfway for a second first. I feel like this can resolve this feedback problem.
Yeah, this is a similar thing, but not exactly the same… What you are describing is probably caused by a “transition”. Some bulbs go from a → b in X time. During that time, you’ll see the brightness bar move (as it reflects the reality during the transition).
I had heard that before! Is this a transition that is hardcoded into the bulbs? I was using ZHA and checked my transition time and even setting that to 0 didn’t remove this lag.
I have recently switched over to zigbee2mqtt and I have to say that the lag is all but gone. Perhaps zigbee2mqtt masks that transition.
Depends on the bulb/brand. There is no “standard” for that
Most are configurable, some are not. Others only transition when no explicit transition is provided. For example, some work when sending transition 0 with the light.turn_on command (which is not something you’d do when using the UI directly).
this is very visible on the POE switches created by the Unifi integration. the jumping back and forth can take over a minute or more… and if you are not patient enough (or simply have no clue as to the real state) could toggle again, and have the opposite result.
depending on the toggled device, this can range from being uncomfortable to potentially dangerous…
Maybe the problem is the UI, desired state and actual state should be independent and display an icon when there’s an error or timeout. Clicking on the icon would retry.
The biggest difficulty is to know when the state is really updated especially for polling integration (e.g : Xiaomi miio fan).
And there is the same issue with cover position, light brightness, etc…
My Z-Wave shutters only send the position at the end of the movement because they don’t support opening/closing state. Adding a loader will “emulate” these transitions states. Don’t known if it’s a good idea to emulate that
tbh, the loader Frenck shows in his vid, is much clearer than the toggle jumping back, making you think it didn’t catch what you want, and making you toggle it again, while in fact it did get what you want, is in the process of doing so, and waiting to finally return to the projected state…
a loader would at least prevent the user from interacting again, while he/she shouldn’t and needs to wait a bit?
This is a really good suggestion. It’s comparable to using TCP instead of UDP; the first having an ACK/NAK scheme, while the second is like shouting out into a black hole
I’d like to elaborate a bit more on this request: It would be nice if it defaulted to a certain ‘state’, but also had the possibility to customize which state and value it should be trigged by. Let me give you an example of a situation I’d like to resolve:
I have an outdoor outlet to which I connect my car during winter. It provides power to an engine heater and a cabin heater. The outlet is powered by a Shelly 1PM DIN relay that then goes via a 16A RCBO. Humid and cold outdoor conditions sometimes triggers the RCB and then I end up in a situation where I (and HA) are under the impression that the car is heating up, while in fact it’s not.
In this specific scenario, I would like to use the ‘ENERGY Power’ sensor and a certain threshold value (>5W for instance), as feedback for the UI button. If it hasn’t reached the threshold within a certain (configurable) time, the icon should change into an exclamation mark, or similar warning symbol.
The jump actually helps you in this situation. Guessing the state based on the an assumption by the UI would hurt you. Right now, if you turn on a switch and it doesn’t actually turn on, the UI assumes it turned on, but then updates based on the actual state of the entity, which causes it to jump back off in all your situations.
If that’s not the case, then you need to figure out why your switch isn’t reporting the correct state.
