Core: Major Z-Wave bug since 0.33

[jsg4]

I am seeing Z-Wave states reporting improperly for all types of devices since 0.33. Additionally, when HA tries to turn on a light switch for instance as part of a scene, that state is not even reflected in the front-end sometimes. And if I manually turn on a light switch or lock, the state does not change sometimes.

As soon as I installed back to 0.32.3 this issue is 100% fixed.

Home Assistant release (hass --version):

0.33

Component/platform:

Z-wave

[arsaboo]

I think your issue was resolved in 0.33.1. Try updating to the most recent release and see if the issue persists.

[jsg4]

Thanks, it was not fixed. I have tried the latest release and had to downgrade. Here are other reports of this same Z-Wave problem.

https://community.home-assistant.io/t/z-wave-devices-stop-reporting-to-hass/6636/4

[jsg4]

Not fixed in 0.34.5 either.

[Cinntax]

I'm also seeing this- it looks like we see an event in the log for calling the turn_on service, but we see no subsequent state change event. So in the UI it looks like the switch turns on momentarily (the light correctly turns on too), and then the switch reverts back. I'll try to get some logs later tonight. I'm running the latest current version 0.34.5

[mikenolet]

I am having the same issue. Seems to be an issue with only light entities and not switches. Works okay in 32.4 but any revision higher is a no go for me. It also appears that it is happening with various manufacturer switches. Seems like I have to turn a light on then off then back on for the state to properly reflect.

[Cinntax]

Oh good observation. I have both switches and lights- so I'll try both also

[Cinntax]

Yeah i just tried this too- i tend to agree that the light controls definitely seem to be part of the problem. If i just touch the zwave switches, they seem solid. For lights, however, we get in this "limbo" state, where the light controls is not updating. Also, when in this state, it does seem to impact the switches as well. It's almost like the zwave updates get queued up, and the switches don't update until the light gets synched up again too.

[jsg4]

One thing I see though it that states don't update even outside of the UI. So if I turn on a switch or lock a lock, after being polled, they sometimes do not reflect that state in HA.

[mikenolet]

Is everybody using the Aeotec controller? Wondering why this is not wide spread. Maybe isolated to the controller.

[jsg4]

Yes Aeotec ZStick for me.

[happyleavesaoc]

I'm also experiencing this, but I need to quantify further which actions result in this behavior. I also have an Aeotec Z-Stick Gen 5.

[Cinntax]

I also have an aeotec zstick gen 5

[robbiet480]

I'm also having this problem now. Haven't tried a restart yet. @turbokongen can you take a look when you have time?

[keatontaylor]

This is almost certainly related to async changes and the z-wave polling interval.

[Cinntax]

Ok- so taking a closer look at how the z-wave library + hass works, it's very, very similar to what I did with the envisalink component. In that case, i had a polling mechanism built within the pyenvisalink library, and used pydispatch to update hass on a poll timer + any live events.

When the async switch happened, i had to update component states using the following:
self.hass.async_add_job(self.async_update_ha_state()), instead of just self.update_ha_state (which zwave is still using). This caused the update of the states to be properly scheduled on the event loop.

In the zwave case, it still looks like it's using sub-threads, so we have this weird updating of states through the event loop AND in a subthread....

Looks like there's a new helper method called schedule_update_ha_state which is very similar to the command i referenced above. Perhaps that is what the zwave component needs to use...

[kirichkov]

I think I have the same issue. I set up a generic_thermostat and the switch is Z-Wave. The UI doesn't change when the switch is turned on by the thermostat.
I'm also using the Aeotec Z-stick Gen 5.

[kirichkov]

What I also noticed is that after some time, one of the hass threads starts using 100% from one my RPi2 cores, and it looks as if it's hung. I attached using gdb and I saw that the executed code is different between breaks, so probably it's not stuck but the 100% usage never drops unless I restart. At one point the thread was calling the open z-wave library.

[happyleavesaoc]

I'm on the latest dev version. I think the z-wave issues are getting worse. Sometimes I'll flip switches and nothing will happen. Then, when I turn off HASS, suddenly all those actions will happen at once and I get a bunch of async+zwave stacktraces. Unfortunately I don't know enough about async, or zwave, to properly fix this.

[justinglow]

Also having this problem. Running 0.35.2 on RP3 AIO and Aeotec Z-stick 5. HASS not showing state changes for GE z-wave dimmer switches. If an automation or some external controller (like Alexa) changes the state, HASS dashboard does not reflect the changes. If I change the state manually from the dashboard, HASS dashboard reflects proper state as expected.

[markcarline]

Just some feedback from me....

I'm not seeing any issues like this reported here but I do have the fibaro dimmer 2 and the everspring an157/an158 that I use with the aeotec zstick gen 5.

I guess this issue is related to the type of devices being used.

[turbokongen]

Someone should test with latest dev code to see if this is resolved.
If not, follow instructions here: https://github.com/home-assistant/home-assistant/pull/5143
And see if value did change, and compare it to OZW_log.txt

[happyleavesaoc]

I tested it. I have a HomeSeer WD100 switch.
If I toggle via UI: perfect and instant toggle of physical switch
If I turn off via switch: UI usually updates
If I turn on via switch: UI never updates

The more I toggle a given physical switch, the less likely the UI actually updates.

[Cinntax]

I'll give it a try later tonight- but in terms of the ui not updating when physically changing the switch, I know on my dimmers there was a special config setting I had to set on the dimmer to advertise all changes to the controller- by default it would just sync up with the switches in the immediate group (the accessory dimmer).

[Cinntax]

Okay- i just re-pulled dev and tried again. It didn't seem to solve the issue. HOWEVER, In my case, the more i look at it, the more I think perhaps it's just my zwave controller getting behind.
1- any physical change seems to represent just fine in the UI (including on/off/dim).
2- If i make rapid changes in hass, my zwave network seems to "lag" behind (with the UI also lagging).

I've attached a snippet from both hass log and openzwave log.
In this scenario, my lights were already ON, and I turned them OFF using the hass UI. The lights went off immediately, but the UI was incorrect temporarily.
I think i'm just seeing a delay in reports back from the network. Both logs show a good 10 second delay between the service being called, and the confirmation.

is it at all possible that older versions "assumed" the state of the switch until told otherwise?

ozwlog.txt
hasslog.txt

[partofthething]

My report: on latest dev branch, z-wave devices are acting more responsively than ever. GUI updates when I toggle my GE switches physically and the lights switch immediately when I toggle them in the GUI. Happy so far. I have Aeotech Z-stick on a Raspberry Pi 2.

[turbokongen]

@Cinntax Timeouts are problems on the zwave network, and not a problem in HA.
Help can be the following:
Delete the zwcfg_[home_id].xml file and let all devices be rediscovered by the network.
This is helpful if the config for a device has changed, or other settings.

You can tweak the openzwave settings, by adjusting timings at the file options.xml in the openzwave config dir.
Also have a look here on how to troubleshoot the zwave network.
http://www.openzwave.com/knowledge-base/

Also when everything is rediscovered, use the network heal, and look for timeouts or errors during the heal, That will give you a hint on what nodes are problematic.

Before the UI waited 0.5sec before it assumed failed command, but now it is waiting 2 secs, so that should just make it better. 10 seconds delay is alot on the zwave network. A healthy network should give callback in 1-4secs depending on size.

If somebody needs help decoding the ozw log, Pm me and I will have a look at it, and give some hints and try to explain.

[turbokongen]

Some more tips:
If it is only light.xxxxx devices you have problem with, do the following in the config:

zwave:
  usb_path: /dev/ttyACM0
  config_path: /srv/hass/src/python-openzwave/openzwave/config
  polling_interval: 30000
  customize:
    light.dragon_tech_in_wall_dimmer_level_31_0:
      refresh_value: true
    light.dragon_tech_in_wall_dimmer_level_32_0:
      refresh_value: true
.....

If that does not do the trick, or just nearly, add:

zwave:
  usb_path: /dev/ttyACM0
  config_path: /srv/hass/src/python-openzwave/openzwave/config
  polling_interval: 30000
  customize:
    light.dragon_tech_in_wall_dimmer_level_31_0:
      refresh_value: true
      delay: 5
    light.dragon_tech_in_wall_dimmer_level_32_0:
      refresh_value: true
      delay: 5
....

It is important that these are set under the zwave section in customize, NOT the homeassistant section.
If these tips fixes your problems, please report back. :)

[Cinntax]

Thank you very much! I'll give it a shot and let you know! I definitely understand that the real problem, at least in my case, resides outside of hass, but it looks like these may help at least make it less noticeable.

[Cinntax]

So I went ahead and deleted my xml zwcfg_*_.xml file within the .homeassistant folder, and yes that did seem to make everything FAR more robust. I know over the last few months I've added a few switches, change OZW versions, etc. so I suppose in my case the network was just not operating as efficiently as it should have been.

I can see how your other fixes would also help in the event that we're not getting timely callbacks, but I'll hold off on those changes unless I feel they're needed. Thank you!

[nriley]

@turbokongen since it seems you haven't gotten much direct feedback:

I tried refresh_value: true and delay: 5 but nothing updated in home-assistant after turning on my dimmer (Linear/GoControl/Nortek WD500Z-1) from the switch. When I added polling_intensity: 1 it did update but only after ~30 seconds. The other changes definitely did help with responding to dimming requests; much less frequently does Home Assistant insist that the old/stale value is actually correct, and I see several brightness updates while the light ramps back to 0 when you turn it off at the dimmer.

After some further research I discovered that I indeed do need to poll this switch — it doesn't support sending updates (or associations, despite the printed documentation provided with the switch). What a mess; will get another dimmer next time!

[adamup928]

I can confirm the problem since 0.33 and the above suggestions (polling_interval) do not help. Rolling back to 0.32.3 and everything works fine. OZW always logs events correctly. Running on Ubuntu 16.04 in a virtual environment. ZWave controller is an Aeotec Gen 5.

[ih8gates]

I've been having this issue with the last several versions of HASS (I have not yet upgraded to .38 - I'm at .37): A light will be off, but HASS will report it's state as "on", both in the switches' UI and in the states dev tool. This is the behavior when HASS turns the light off (ie: not a polling issue).

The switch itself has a status LED that shows that it is off. And if I query the switch in Open Zwave Control Center, the correct status is reflected. When I make changes to the on/off status via OZWC, no errors are displayed/generated in the console.

Update: it appears that when I restart HASS, the correct state is noted.

I consistently have this issue with two switches, both are GE (one is a 12724 and one is a 45606). My Zwave controller is an Aeotec gen5.

[adamup928]

I just upgraded to the dev branch to see if these merged fixes would help, but the same issue still exists.

[jsg4]

Seeing same thing.

[mikenolet]

Have you tried adding the customize entry in your zwave config (example below):

zwave:
  usb_path: /dev/ttyACM0
  config_path: /srv/hass/src/python-openzwave/openzwave/config
  customize:
    light.dragon_tech_in_wall_dimmer_level_31_0:
      refresh_value: true
    light.dragon_tech_in_wall_dimmer_level_32_0:
      refresh_value: true
    light.linear_lb60z1_dimmable_led_light_bulb_level_33_0:
      refresh_value: true
    light.dragon_tech_in_wall_dimmer_level_9_0:
      refresh_value: true
    light.unknown_id000c_unknown_type4447_id3034_level_28_0:
      refresh_value: true
    light.unknown_id000c_unknown_type4447_id3034_level_10_0:      
      refresh_value: true
    light.aeotec_unknown_type0003_id0019_level_30_0:
      refresh_value: true    
    light.unknown_id000c_unknown_type4447_id3034_level_27_0:  
      refresh_value: true
    light.linear_lb60z1_dimmable_led_light_bulb_level_21_0:
      refresh_value: true

[adamup928]

@mikenolet - adding 'customize' as an entry below zwave gives me the following error (on the dev branch):

ERROR:homeassistant.bootstrap:Invalid config for [zwave]: [customize] is an invalid option for [zwave]. Check: zwave->zwave->customize. (See /home/homeassistant/.homeassistant/configuration.yaml, line 126). Please check the docs at https://home-assistant.io/components/zwave/

Adding "refresh_value: true" under the global customize entry (homeassistant->customize->[switch name]->refresh_value:true) within configuration.yaml doesn't generate any errors but still does not result in any UI response to switch changes.

[mezz64]

Latest dev requires you to use 'device_config' rather than 'customize'.

[adamup928]

still no luck with the 'device_config' key under zwave rather than 'customize'.

zwave:
  usb_path: /dev/zwavestick
  config_path: /srv/homeassistant/src/python-openzwave/openzwave/config/
  device_config:
    light.homeseer_hswd100_wall_dimmer_level_9_0:
      refresh_value: true

Toggling within the UI results in a change at the switch - just not vice versa.

[adamup928]

0.39 resolves this issue for me. Polling will update the switch state in the UI, correctly.

[adamup928]

After watching this for awhile, the switches only trigger changes in the UI after a restart of HA and for a few hours after that. Then they all stop triggering UI changes. Toggling within the UI always results in an action at the device, though...

[ddykhoff]

Yeah, I'm definitely still having z-wave issues on 0.39 as well. In addition to the state not being updated when physically using the switch (which only stops working after HASS has been running for awhile), I am also seeing off behavior when using just the UI to control z-wave switches as well. The toggle switch will bounce back and forth a few times before settling on the original value (i.e. if it was off and I turn it on, it will send the correct command the light will turn on, but the switch will then bounce back and forth in the UI a couple of times before settling back on 'off', despite the light being on. Pressing it again then sends the turn on action again, doing nothing and I get stuck being unable to control the switch from the UI).

[mikenolet]

@ddykhoff I found adding the refresh true helped with the in app refreshing:

zwave:
usb_path: /dev/ttyACM0
config_path: /srv/hass/src/python-openzwave/openzwave/config
#polling_interval: 30000
device_config:
light.dragon_tech_in_wall_dimmer_level_31_0:
refresh_value: true
light.unknown_id000c_unknown_type4447_id3034_level_19_0:
refresh_value: true
light.aeotec_unknown_type0003_id0019_level_17_0:
refresh_value: true
light.dragon_tech_in_wall_dimmer_level_9_0:
refresh_value: true

[ddykhoff]

Yeah, I've had refresh_value in my device_config the entire time. I've tried every combination of delay, polling_interval and refresh_value to no avail.

[adamup928]

I've had the same experience, as ddykhoff and also have those values present.

@balloob - Can we reopen this issue to get it a little more visibility?

[CrossfireCurt]

Also seeing same issue as @ddykhoff with 0.39.3. Switched back to 0.38.4 and it works fine.

zwave:
  usb_path: /dev/ttyACM0
  polling_interval: 30000
  config_path: /srv/hass/lib/python3.5/site-packages/libopenzwave-0.3.1-py3.5-linux-x86_64.egg/config/
  customize: 
    light.ge_12724_3way_dimmer_switch_level_8_0:
      refresh_value: true
      delay: 3
      polling_intensity: 1

[ishults]

Same issue here, especially with the thermostat. Also have the Aeotec stick.

[mealan]

not sure if it helps, but same issue here with 0.39.3, what's really curious though, is that it's the same thing with my wemo switches. i can flip the status remotely and it'll update, but using HA to do the trigger it will move and show it switched for a second, and then move right back to where it was before hand.

it'll work for a certain amount of time, but then after night or a few hours i have to manually trigger the switch then it'll work again for a little bit.

[ih8gates]

I wanted to add that, while I see discussion about the state as it's displayed in the UI, the issue is tied to the actual states of zwave devices, not just the interface. I have zwave devices that, despite being off for hours (and HA turned them off), a test for their state still shows them as on.

[370gt]

i am having the same issue with an aeotec zstick gen 5. If i reboot the server, all the states of the lights in the house update, but if most in the house are manually switched it doesn't work. I have the odd light that will poll without issue....

[mikenolet]

Seems to be broken again in 0.40. The refresh_value: true
doesn't seem to work anymore.

[rofrantz]

Smth went wrong with the latest update. Out all single and double switch relays that I have (all qubino) the single dimmer that I doesnt want to turn off. I tried from both physical switch and the ui and after a few seconds the light turns on again :(

[rofrantz]

And I think its from previous dev version. Tonight I've updated HA again and the dimmer issue its still there

[lessthanjoey]

I have the same issue and am using Aeotec Z stick too.

I had no issues on 0.38.4, but 0.40.0 and 0.40.1 are both a disaster with (apparently) both switches and dimmers (light.xyz) for me. All the products are homeseer in my case (ws-100+, wd-100+). I suspect that similarly the switches work fine until the dimmer gets backed up, and then the switches don't work well either.

Specifically, I also see the bug where commands seem to be queued to the dimmer, as when I go to manually turn it off it will often turn back on multiple times if that's what I'd tried in the gui.

[mealan]

for what it's worth my issue appears to be stable now with 0.40.0 and adding in a secure network key and re adding all the devices. (besides the wemo) so it appears to be a combination of ha as well as the secure network key for zwave

[mikenolet]

Can you provide more detail re the secure key for zwave? I am not aware of such a process. Thanks.

[mealan]

sure! i got it from here:

https://community.home-assistant.io/t/powered-zwave-devices-marked-as-dead/1827

which points to here:
https://github.com/OpenZWave/open-zwave/wiki/Adding-Security-Devices-to-OZW

however i didn't want to do the default secure key so i used the code from here:
https://home-assistant.io/docs/z-wave/

under adding security devices.

i did the secure devices for each light switch (now up to 4 of them, 6 total if you include the 3 way flips) and it's been very stable.

make sure you copy down your secure key somewhere else, just incase HA overwrites it.

hope that helps someone

[kirichkov]

I've always had all my devices added securely and still have this issue. I think it was something else that improved the experience for you.

[mealan]

in that case it might have been the disable self heal and additional switch i added. could be range was too far for the other one, but that still wouldn't explain the wemo not working

[kirichkov]

I started digging into the matter. Thanks to the new z-wave cards I realized my controller was in a terrible spot since only one of my switches had a direct connection to it. I moved it one meter and now all of my switches have direct connection to the controller. I'm suspecting the poor connectivity was causing the delayed UI reactions.

In case you haven't checked your z-wave connectivity do so first and try to improve it.

[rwa]

I still have very similar issues in 0.43.2.

Even using a Homeseer switch that has instant update capabilities, if I toggle the switch in the interface, the device responds, then the interface flips back. At this point I lose control of the switch from the interface altogether. Switching it manually has no effect on the interface either. So I get one use of the switch and then it's hosed until I restart.

[lessthanjoey]

The only time I had this issue it persisted no matter the home-assistant version. It resolved itself after I essentially "rebooted" the switches by flipping the circuit breaker off for 10 seconds, then back on. It had driven me nuts for at least a month so well worth a try! The key indicator was that whenever I went to toggle one of those switches in the UI, I'd get on OZW.log error about an unexpected or incorrect response from the switch.

So, for anyone having issues with non-responsive z-wave switches, try flipping the breaker!

[mikenolet]

Will give it a shot. I see in the UI when I toggle a switch. Goes off to on then off to back on. Learned to live with it.

---

From: lessthanjoey [e-mail]
Sent: Saturday, April 29, 2017 7:05:51 PM
To: home-assistant/home-assistant
Cc: Mike; Mention
Subject: Re: [home-assistant/home-assistant] Major Z-Wave bug since 0.33 (#4867)

The only time I had this issue it persisted no matter the home-assistant version. It resolved itself after I essentially "rebooted" the switches by flipping the circuit breaker off for 10 seconds, then back on. It had driven me nuts for at least a month so well worth a try! The key indicator was that whenever I went to toggle one of those switches in the UI, I'd get on OZW.log error about an unexpected or incorrect response from the switch.

So, for anyone having issues with non-responsive z-wave switches, try flipping the breaker!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/home-assistant/home-assistant/issues/4867#issuecomment-298199981, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AP7BbPZ1disUhHE338aUAvtkpd34E18Sks5r08JPgaJpZM4LKjSs.

[lessthanjoey]

That's exactly what happened for me and it was driving me crazy. Totally solved after a good power-cycle on the switches' breakers.

[parneli]

Just gone to set up a new Zwave plug, in particular the Aeon Labs Z-Wave Plus SmartSwitch

Looks like I am experiencing this issue whereby the UI does not update at all if using the manual switch (although will work after the HASS services are restarted), I started to think this is by design but I suspect not after reading further. I can see the following in the OZW.log which suggests the switch is annoucing the change.

Info, Node003, UPDATE_STATE_NODE_INFO_RECEIVED from node 3

I have tried the above suggestion to add a refresh value but I can't get the below config to work:

customize: switch.aeotec_zw096_smart_switch_6_switch_3_0: refresh_value: true delay: 5

Appreciate any guidance if anything I am doing is wrong, else may be related to this issue.

[lessthanjoey]

Did you try the suggestion with the breakers? I think the problem was when
you turned the breakers back on. I had brownout recently and half my
switches started doing this (once one did it, they all did until restart).
Flipping the breaker cleanly fixed it again.

On May 4, 2017 12:27:23 AM parneli [e-mail] wrote:

Just gone to set up a new Zwave plug, in particular the Aeon Labs Z-Wave
Plus SmartSwitch

Looks like I am experiencing this issue whereby the UI does not update at
all if using the manual switch (although will work after the HASS services
are restarted), I started to think this is by design but I suspect not
after reading further. I can see the following in the OZW.log which
suggests the switch is annoucing the change.

Info, Node003, UPDATE_STATE_NODE_INFO_RECEIVED from node 3

I have tried the above suggestion to add a refresh value but I can't get
the below config to work:

customize: switch.aeotec_zw096_smart_switch_6_switch_3_0: refresh_value: true delay: 5

Appreciate any guidance if anything I am doing is wrong, else may be
related to this issue.

--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/home-assistant/home-assistant/issues/4867#issuecomment-299114500

[dmourati]

Same issue for me on 0.44.1. It seems laggy/unresponsive from home assistant on my raspberry pi 3 and z stick to aoetec Z096 smart switches. I notice that after a few iterations, the switch connectivity "wakes up" and becomes more responsive.

[turbokongen]

So this issue is very random it seems. Let's try to find out where the problem is:
Let's start with the network itself.
Firstly: at start of HA the zwave network starts, and will not respond to much of any statechanges from HA.
Only after the event: zwave.network_ready has been fired, zwave will respond properly to commands. That is just how OZW is started.

Check the node entitiy states for the problematic devices.
Look at the RTT times:

The Aeotec switch node of mine has 46ms and 29ms for response times(Round-Trip-Time).
The Qubino who is not in direct contact with the controller and the node furthest away(14m outdoors) in my network still has 158ms and 78ms. That is a healthy network.
A note on RTT times: Devices can be slow internally. Though they will behave correctly.
Higher RTT means problems in communicating with the node, that may be RF interferrence, even device errors, and encryption errors. A guide to error findings in the OZW log can be found here: http://www.openzwave.com/knowledge-base/
Here you will find message ID's used in the log, and will explain what they are.
That is a start.

[jsg4]

The issue I see applies to every single Z-Wave light, switch, and lock so I am not sure what looking at the specific device information is going to solve. I have also tried every refresh_true setting from 1-5 and it does not fix the issue. The switches in front end keep flipping after I change the state, and then they update to the proper state after, not just light specific. Anything else to try?

[turbokongen]

Have a look at my post again. This is not specific to any type of device. RTT times are how much time it takes for the node to respond back to the controller after a command. So if it takes longer than 2 secs (2000ms)it will flip back. Check the RTT times.

[jsg4]

Why did this start happening with 0.33?

[turbokongen]

No idea. Reviewing the changes made to zwave from 0.32.4 to 0.33.4 there is minor changes, we added the possibility to configure delay of value refresh to lights, some refactoring of the climate component and a bugfix to cover component.
So if we are going to figure out why this only happens to some and not others, we need to look at the basics first.

[CrossfireCurt]

Prior to 0.33 I was using the delay-of-value-refresh with lights just
fine... how do you mean that it was just added? Why and how did this change?

On Sat, May 20, 2017 at 3:16 AM John Arild Berentsen <
[email protected]> wrote:

No idea. Reviewing the changes made to zwave from 0.32.4 to 0.33.4 there
is minor changes, we added the possibility to configure delay of value
refresh to lights, some refactoring of the climate component and a bugfix
to cover component.
So if we are going to figure out why this only happens to some and not
others, we need to look at the basics first.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/home-assistant/home-assistant/issues/4867#issuecomment-302856367,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABGTom_xJp9_ESMsH7_xEGXg-LNoHaEks5r7pNWgaJpZM4LKjSs
.

[turbokongen]

Prior to 0.33 it was at default 2secs for ALL devices except the workaround devices. Not configurable. The workaround devices had 5 sec refresh. This made problems with devices that support instant notifications, flooding logs with refresh values. So we added an opt-in for the refresh. Meaning ALL devices will not refresh values by default. If you opt-in with the config (refresh_value: true) then it is set for default 2 secs. If you also specify the delay option, it will delay by that amount of seconds.
This is option is only available for lights.

[jsg4]

Example with two problematic lights in the front end and also the lock. Please let me know what input to try so these don't flip back and forth. Thanks turbo

{ "is_info_received": true, "sentFailed": 0, "retries": 0, "capabilities": [ "beaming", "routing", "listening" ], "receivedUnsolicited": 0, "manufacturer_name": "Leviton", "max_baud_rate": 40000, "averageRequestRTT": 32, "sentTS": "2017-05-20 09:33:15:803 ", "lastRequestRTT": 24, "lastResponseRTT": 34, "receivedCnt": 13, "is_zwave_plus": false, "friendly_name": "Foyer Lights", "node_id": 3, "receivedTS": "2017-05-20 09:33:15:838 ", "is_awake": true, "neighbors": [ 1, 2, 129, 4, 5, 6, 7, 130, 9, 10, 131, 133, 134, 139, 140, 16, 17, 141, 19, 20, 21, 23, 24, 25, 26, 27, 29, 30, 32, 33, 35, 36, 37, 38, 39, 40, 41, 42, 56, 59, 60, 62, 64, 65, 69, 70, 74, 75, 76, 77, 78, 79, 81, 82, 83, 91, 94, 96, 99, 112, 113, 114, 116 ], "sentCnt": 23, "is_failed": false, "receivedDups": 0, "is_ready": true, "product_name": "Unknown: type=0401, id=0334", "averageResponseRTT": 34, "query_stage": "Complete" }

And

{ "is_info_received": true, "sentFailed": 0, "retries": 0, "capabilities": [ "beaming", "routing", "listening" ], "receivedUnsolicited": 0, "manufacturer_name": "Leviton", "max_baud_rate": 40000, "averageRequestRTT": 67, "sentTS": "2017-05-20 05:57:18:645 ", "lastRequestRTT": 27, "lastResponseRTT": 36, "receivedCnt": 16, "is_zwave_plus": false, "friendly_name": "Gate Lights", "node_id": 20, "receivedTS": "2017-05-20 05:57:18:682 ", "is_awake": true, "neighbors": [ 128, 1, 2, 3, 4, 5, 6, 7, 129, 9, 10, 130, 131, 133, 134, 139, 140, 141, 21, 23, 24, 25, 26, 27, 29, 30, 32, 33, 34, 35, 36, 37, 39, 40, 41, 42, 56, 59, 60, 65, 69, 74, 75, 76, 77, 78, 79, 81, 83, 91, 96, 99, 100, 112, 113, 114 ], "sentCnt": 25, "is_failed": false, "receivedDups": 3, "is_ready": true, "product_name": "VRMX1-1LZ Multilevel Scene Switch", "averageResponseRTT": 75, "query_stage": "Complete" }

{ "battery_level": 100, "is_info_received": true, "sentFailed": 13, "retries": 3, "capabilities": [ "beaming", "routing", "frequent" ], "receivedUnsolicited": 6, "manufacturer_name": "Assa Abloy", "max_baud_rate": 40000, "averageRequestRTT": 1887, "sentTS": "2017-05-20 09:35:10:847 ", "lastRequestRTT": 2141, "lastResponseRTT": 2233, "receivedCnt": 335, "is_zwave_plus": true, "friendly_name": "Mudroom Lock", "node_id": 119, "receivedTS": "2017-05-20 09:35:13:079 ", "is_awake": true, "neighbors": [ 128, 129, 2, 4, 5, 132, 133, 9, 10, 141, 16, 17, 19, 23, 24, 25, 27, 32, 37, 38, 39, 40, 41, 42, 59, 64, 75, 81, 82, 99 ], "sentCnt": 348, "is_failed": false, "receivedDups": 6, "is_ready": true, "product_name": "Unknown: type=8002, id=1600", "averageResponseRTT": 2252, "query_stage": "Complete" }

[turbokongen]

@jsg4 In your examples:
Foyer lights and Gate lights should be fixed by setting delay: 1 in config. Remember to use refresh_value: true first. They have low RTT times.
The Assa Abloy one is no cure for. It has an average RTT of more than 2 secs.
2 secs is the time HA waits for a confirmed state change before it resets to old state. This lock will always be flipping forth and back.

[jsg4]

Trying that now. My point though is that before 0.33 even the lock did not flip and back forth in the front end, this issue did not happen for however long Z-Wave has been in HA until 0.33.

[turbokongen]

I'm not sure when, but before the 2sec wait change we only had 1sec, so that would be even worse.

[jsg4]

Didn't work. Here's screenshot and video.

Light.zip

[turbokongen]

But the problem is only the back and forth flipping of switches? It will display correctly after a short period of time?

[jsg4]

Correct, it always shows the correct state after that, so it's just a visual front end thing. Makes it annoying when using something like Homebridge for instance as you receive alerts like door is unlocked and 5 seconds later door is locked.

[turbokongen]

cc @pvizeli @balloob @robbiet480 Any of you with suggestions?

[parneli]

My situation does not fix itself until a restart of the zwave services, it doesn't update in HASS until you send another command to the device and the state thinks it is still the last sent command. Power cycling the switch hasn't worked.

Trying to add refresh value .. delay 1 but saying invalid config ?

zwave:
  usb_path: /dev/ttyACM0
  polling_interval: 30000  
  config_path: /srv/homeassistant/src/python-openzwave/openzwave/config
  customize:
    switch.aeotec_zw096_smart_switch_6_3:
      refresh_value: true
      delay: 5  

Happy to try any suggestions, as stated above you can see the zwave log upating so its not the zwave network, my RTT is about 36 network looks fine.

[parneli]

I seemed to have resolved my issue/s, with a combination of upgrading to the latest HASS 45.1 and OZW OpenZwave Version 1.4.2508 but also changing the above code from customize to device_config :
device_config: switch.coffee_switch_4_0: refresh_value: true polling_intensity: 1 switch.aeotec_zw130_wallmote_quad_switch_2_0: refresh_value: true polling_intensity: 2

[emlove]

It looks like the big change from 0.32 to 0.33 was that we switched to asynchronously firing off the state change instead of blocking. https://github.com/home-assistant/home-assistant/compare/0.32.3...0.33#diff-758847d0dd4b50b523c035461d973f60R99

update_ha_state is no longer supported, but if someone wants to try replacing schedule_update_ha_state with the lines here https://github.com/home-assistant/home-assistant/blob/0.32.3/homeassistant/helpers/entity.py#L186-L188 we could see if that is what actually caused the problem. force_refresh isn't necessary. Note that this isn't a correct fix, since we don't want to block the zwave thread while waiting for hass core to update the state.

[nriley]

@armills Thanks for investigating — your description does seem to track pretty well with my observed behavior. Unfortunately, the Z-Wave set up I have access to is nowhere near me for months at a time, so I have limited ability to test this myself. I hope that some other folks who are experiencing this problem might be able to step up and help.

[balloobbot]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.

Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment :+1:

[nriley]

For anyone else who stumbles across this issue, it should be fixed by https://github.com/home-assistant/home-assistant/pull/9430 — which is currently blocked on https://github.com/OpenZWave/open-zwave/pull/1352. If it's still not updated by the end of the year I should at least be able to do some testing when I'm physically present at the house where I set up HA.

[lifeisafractal]

@nriley , I have tested out #9430 with the OpenZWave/open-zwave#1352 fix in pace as well and it does fix the issues described above (with a Home Seer HS-WD100+). Unfortunately, there hasn't been any feedback on the open-zwave PR, positive or negative, so it's hard to say when this will get merged. I'm try bumping the open-zwave PR to see if there is anyone in particular to talk to about it.