Device controls delayed response

Home Assistant Android version: 2021.3.1-full Android version: 11 Phone model: Google Pixel 4 Home Assistant version: 2021.3.4 Last working Home Assistant release (if known): Probably never Description of problem: When I add a light (a ToggleRange) to the device controls (https://developer.android.com/guide/topics/ui/device-control) and then slide the brightness, it, most of the time, right after I release the slider goes back to the original state, and then after usually some 1/10s of a second it goes back to the new state.

I have done some digging and testing in the source code an I believe that the problem is around line 150 in HaControlsProviderService.kt (https://github.com/home-assistant/android/blob/eba8f155300b0b0bd0b7c6844ca2e47a653a4fe4/app/src/main/java/io/homeassistant/companion/android/controls/HaControlsProviderService.kt#L150), but as I’m not a kotlin developer (I’m only used to Java) and not familiar with the structure of the project I’m not sure how to fix it. Google Home doesn’t have this problem, but I’m not sure how they do it. I was thinking that it might be possible to just keep the value and not change it until the new value has arrived from the server. Also, when turning on a light that’s off, if keeping the value when updating to a new brightness, the app doesn’t know what brightness to select. Google Home has solved this by setting the brightness to 1% when it doesn’t know the brightness, and locally (only when the panel is open) remember the brightness when turning off the light. This approach gives, according to me, the best experience most of the time, but when it doesn’t know the brightness, it’s a bit annoying that it’s set to 1%. Maybe it could wait for response from the server only then, or set it to 100% instead of 1%.

Traceback (if applicable, to get the logs you may refer to: https://companion.home-assistant.io/docs/troubleshooting/faqs/#android-crash-logs):

Screenshot of problem: This is the bug: This is how Google Home has solved the problem by setting the brightness to 1%

Additional information:

[dshokouhi]

Would it be possible to check if the newly received state is the same as the old one and if so skip that update and let the 5-second timer update it if it turn out that the light SHOULD still be in the old state? I think that waiting max 5 seconds for it to update when the user set (by sliding) value isn’t the one it should be, but not have the slider jump back for no apparent (for the user) reason, is better than what it currently is. Would this be possible to implement? (Please let me know if you think than my questions are annoying)

So we need to provide an update. What you are asking us to do is to skip the first 2 checks that are done for entity data however that skips all the checks that we do before we send the positive result back to device control. I think the issue here is that the entity is not updating its state as fast as you would expect. I imagine the HA frontend also has a similar issue with the same entity? It has to because we query for it and we display things as real as we can from the server. For your issue you should focus on solving the issue at the server rather than the app. The app has been updated in a way to make the states stick. Now imagine you perform a control and it never took at all, maybe the device went offline when it got the command or just failed. Then we are keeping the incorrect state a lot longer just to satisfy an entity that is not updating immediately. The current checks we have in place are meant to keep things as up to date as possible with HA.

[dshokouhi]

Where does the old state come from when the slider goes back to the old state? Is it an old local state or is it from the server, but the server haven’t had time to handle the action and thus respond with the, for it, current data?

its from the server see line 147 in the file you linked to, and some devices do indeed respond back with the proper state after first refresh like my hue devices but my zwave ones are a bit slower and update on the second or third state refresh.