I’ve got some ZWave light switches configured that are working great… but the UI doesn’t want to cooperate.
I activate the switch - it physically turns on instantly - and the toggle slides over. The icon doesn’t update to reflect that it’s updated however - and after a moment the toggle slides back to the previous (now wrong) state. If I hit the refresh button it will then catch up to itself and show the correct state.
I have streaming updates turned on - and the log is not giving me any errors related to that. I also tried in multiple browsers, but it’s the same way on Safari, Chrome, and Firefox.
My equipment is:
Aeon Labs Z-Stick, Gen5
GE 45604 Outdoor Module
and a few GE 12722 in-wall switches
It’s the same issue on the outdoor module and the in-wall switches.
But again… I hit refresh and everything is fine. I’m not sure why streaming updates are not coming through. Unless refreshing causes HASS to poll… which it doesn’t seem like it is.
Yes - if I switch them from the UI they react instantly. The toggle switch will toggle off, hesitate for a moment, then jump back. If I leave the screen as is, nothing will ever update. As soon as I hit refresh (in the UI or in the browser) it will reflect the correct state.
I’m seeing this exact same problem with 0.32.2 after a manual refresh of the UI it is allways back in sync with the physical switch. This is with platform: command_line and Switches: for me, it does exactly what the video shows above.
I’m looking more closely at my OZW_Log.txt file, and while I am relatively new to debugging this system, here’s my assessment:
At the initial time of interacting with the switch, it goes to “off” in the UI, two zwave commands are immediately enqueued, one SwitchMultilevelCmd_Set and one SwitchMultilevelCmd_Get
Immediately after the SwitchMultilevelCmd_Set command completes, the _Get command is sent. Because only fractions of a second have passed since flipping the switch, my dimmer is at this moment in the very early stages of a “fade-out” operation. As such the real-time dimmer value it sees is very much not “off”, in fact it’s only had time to get from its initial value of 99 down to a new value of 98. 2016-11-10 22:05:26.706 Detail, Node006, Refreshed Value: old value=99, new value=98, type=byte
As the slow fade-out proceeds, a ValueChanged notification fires, which is picked up and triggers a refresh, meaning another SwitchMultilevelCmd_Get happens. At this point we’re about a third of the way through fading out. 2016-11-10 22:05:27.664 Detail, Node006, Refreshed Value: old value=98, new value=66, type=byte
Step 3 repeats a few times during the fadeout, once at new value=33 and once at 0. For whatever reason, the arrival at 0 does not cause the switch in the UI to flip to off.
The entire exchange ends with a ValueChanged notification that doesn’t appear to get handled by HA, unless the log is sort of non-sequential in a way that I’m not accounting for Edit: I see now that the ValueChanged event that was confusing me was reflecting a confirmation of the change event from zwave, and its subsequent passage long to HA. Why this event is not being reflected back in the UI is still unclear to me.
A bunch of work on a zwave issue that turned out to be unrelated to this led me to discover that most, of not all, of this issue (the UI toggles not responding well to interaction, and seeming failures in the streaming updates) were related to some misconfiguration of my nginx reverse proxy.
I haven’t yet tracked down precisely which element of my prior config was responsible for interfering, but anyone having this issue who also happens to be using an nginx reverse proxy might want to turn their attention in that direction first.
That was indeed one of the changes I made! So probably that was the one causing the main part of the misbehavior.
I’ve noticed that if I visit hass within my home network, I will not see the “Push notifications” slider (I do not have that component configured)… but from outside via the nginx proxy it does appear and is “off”. This doesn’t cause issues but it signifies to me that there’s still some info being passed differently through the proxy than via a direct connection.