ZWave lightswitch not updating on 29.7 without manual refresh

Development
1

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.

Any ideas?

2

Dimmer’s or toggle switches?

3

These are all Toggles.

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.

4

Hmmm

If you switch them from the UI, do they respond?

5

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.

6

Update! 30.2 seems to have resolved this problem. Why? No clue. But it works!

7

Hmm, I’m still seeing this issue in 32.1 (it has been happening for a while but I haven’t had time to track anything down until just now).

To recap:

  • Flip a switch in the UI
  • UI switch responds instantly and physical light also responds instantly
  • ~1 second later, the UI switch reverts to its original state, making it inconsistent with the physical switch
  • Usually a manual refresh of the UI will bring the web based switch back into a consistent state with the physical switch, but not always.

Here is a video of this happening.

Happy to retrieve any additional details that might help in debugging this issue.

8

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.

9

If anyone else is following this thread, I think that this issue may be covered here.

10

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:

  1. 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

  2. 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

  3. 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

  4. 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.

  5. 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.

The detailed OZW logs are here if needed.

11

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.

12

I’m using nginx reverse proxy as well, would be great if you figure it out if you could post what you did here. Thanks!

…
After looking at my own nginx reverse proxy, adding the line
proxy_buffering off;
seems to have fixed the problem so far, I will keep an eye on it.

Thanks for the point in that direction.

13

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.