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.

[ghost]

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.