Issue reading states of Z-Wave switches

Here is what I have, works perfectly and I can see the polling data in OZW_log.txt every 30 seconds only for the nodes requested. Not sure if this matters or not, but I am running 0.49

zwave:
  usb_path: /dev/ttyACM0
  config_path: /srv/homeassistant/src/open-zwave-control-panel/config
  network_key: "*******************************"
  new_entity_ids: true
  polling_interval: 30000
  device_config:
    switch.porch_light_switch:
      polling_intensity: 1
    switch.garage_light_switch:
      polling_intensity: 1
1 Like

Thanks for the suggestion, I did not have polling_intensitity set in the configuration.yamal file, rather I was setting in via the ZWave control panel in the GUI I’ll give this a try and see if it makes a difference.

@christheradioguy The Leviton switches should support instant status (even the non ZWP ones) without polling. I have some ancient ones that have support for it (Leviton calls it “hail”). Maybe one of the configuration values in the switch got inadvertently set to a different mode?

where would you check for these values, on HA zwave control panel or OZW?

It gets passed from ozw to HA so both control panels should be able to detect it. There is a parameter section in HA that allows you to configure the parameters.

This is all assuming that OZW has a fully detailed XML file for your device. If there is no detailed XML file, neither will know what parameter does what.

I’ll have a look through the switch’s manual for anything called ‘hail’ but it doesn’t ring a bell.

OZW is passing status on a manual switch event. It’s not getting handled by HA.

DEBUG:libopenzwave:notif_callback : new notification
DEBUG:libopenzwave:notif_callback : Notification type : 26, nodeId : 2
DEBUG:libopenzwave:notif_callback : call callback context
DEBUG:openzwave:zwcallback args=[{‘notificationType’: ‘Notification’, ‘notificationCode’: 1, ‘homeId’: 25503801, ‘nodeId’: 2}]
DEBUG:openzwave:Z-Wave Notification : {‘notificationType’: ‘Notification’, ‘notificationCode’: 1, ‘homeId’: 25503801, ‘nodeId’: 2}
DEBUG:libopenzwave:notif_callback : end
DEBUG:libopenzwave:notif_callback : new notification
DEBUG:libopenzwave:notif_callback : Notification type : 22, nodeId : 2
DEBUG:libopenzwave:notif_callback : call callback context
DEBUG:openzwave:zwcallback args=[{‘notificationType’: ‘NodeQueriesComplete’, ‘homeId’: 25503801, ‘nodeId’: 2}]
DEBUG:openzwave:Z-Wave Notification NodeQueriesComplete : {‘notificationType’: ‘NodeQueriesComplete’, ‘homeId’: 25503801, ‘nodeId’: 2}
DEBUG:openzwave:Z-Wave Notification Node : home_id: [0x01852839] id: [2] name: [] model: [Unknown: type=1c02, id=0334]
DEBUG:libopenzwave:notif_callback : end

I made some slight progress. I added the following XML file to OZW config.

Now I am getting info from HA Core on an event but still no state change.

DEBUG:libopenzwave:notif_callback : new notification
DEBUG:libopenzwave:notif_callback : Notification type : 26, nodeId : 2
DEBUG:libopenzwave:notif_callback : call callback context
DEBUG:openzwave:zwcallback args=[{‘notificationType’: ‘Notification’, ‘notificationCode’: 1, ‘nodeId’: 2, ‘homeId’: 25503801}]
DEBUG:openzwave:Z-Wave Notification : {‘notificationType’: ‘Notification’, ‘notificationCode’: 1, ‘nodeId’: 2, ‘homeId’: 25503801}
DEBUG:libopenzwave:notif_callback : end
DEBUG:libopenzwave:notif_callback : new notification
DEBUG:libopenzwave:notif_callback : Notification type : 22, nodeId : 2
DEBUG:libopenzwave:notif_callback : call callback context
DEBUG:openzwave:zwcallback args=[{‘notificationType’: ‘NodeQueriesComplete’, ‘nodeId’: 2, ‘homeId’: 25503801}]
DEBUG:openzwave:Z-Wave Notification NodeQueriesComplete : {‘notificationType’: ‘NodeQueriesComplete’, ‘nodeId’: 2, ‘homeId’: 25503801}
DEBUG:openzwave:Z-Wave Notification Node : home_id: [0x01852839] id: [2] name: [] model: [Unknown: type=1c02, id=0334]
DEBUG:libopenzwave:notif_callback : end
INFO:homeassistant.core:Bus:Handling <Event state_changed[L]: entity_id=zwave.leviton_unknown_type1c02_id0334, new_state=<state zwave.leviton_unknown_type1c02_id0334=Ready; lastResponseRTT=24, averageRequestRTT=17, receivedCnt=9, manufacturer_name=Leviton, averageResponseRTT=24, friendly_name=Leviton Unknown: type=1c02, id=0334, product_name=Unknown: type=1c02, id=0334, new_entity_id=zwave.leviton_unknown_type1c02_id0334, node_id=2, is_ready=True, is_failed=False, receivedDups=0, retries=0, neighbors={1, 3}, query_stage=Complete, lastRequestRTT=17, receivedTS=2017-09-07 13:12:16:205 , node_name=Leviton Unknown: type=1c02, id=0334, sentTS=2017-09-07 13:12:16:180 , sentCnt=13, sentFailed=0, max_baud_rate=40000, is_info_received=True, is_awake=True, is_zwave_plus=False, old_entity_id=zwave.leviton_unknown_type1c02_id0334_2, receivedUnsolicited=0, capabilities={‘listening’, ‘routing’, ‘beaming’} @ 2017-09-07T13:06:51.641287-04:00>, old_state=<state zwave.leviton_unknown_type1c02_id0334=Ready; lastResponseRTT=25, averageRequestRTT=18, receivedCnt=8, manufacturer_name=Leviton, averageResponseRTT=25, friendly_name=Leviton Unknown: type=1c02, id=0334, product_name=Unknown: type=1c02, id=0334, new_entity_id=zwave.leviton_unknown_type1c02_id0334, node_id=2, is_ready=True, is_failed=False, receivedDups=0, retries=0, neighbors={1, 3}, query_stage=Complete, lastRequestRTT=18, receivedTS=2017-09-07 13:08:08:744 , node_name=Leviton Unknown: type=1c02, id=0334, sentTS=2017-09-07 13:08:08:719 , sentCnt=12, sentFailed=0, max_baud_rate=40000, is_info_received=True, is_awake=True, is_zwave_plus=False, old_entity_id=zwave.leviton_unknown_type1c02_id0334_2, receivedUnsolicited=0, capabilities={‘listening’, ‘routing’, ‘beaming’} @ 2017-09-07T13:06:51.641287-04:00>>
DEBUG:homeassistant.components.websocket_api:WS 1713408080: Sending {‘type’: ‘event’, ‘id’: 2, ‘event’: {‘time_fired’: datetime.datetime(2017, 9, 7, 17, 12, 26, 291645, tzinfo=), ‘event_type’: ‘state_changed’, ‘origin’: ‘LOCAL’, ‘data’: {‘entity_id’: ‘zwave.leviton_unknown_type1c02_id0334’, ‘old_state’: <state zwave.leviton_unknown_type1c02_id0334=Ready; lastResponseRTT=25, averageRequestRTT=18, receivedCnt=8, manufacturer_name=Leviton, averageResponseRTT=25, friendly_name=Leviton Unknown: type=1c02, id=0334, product_name=Unknown: type=1c02, id=0334, new_entity_id=zwave.leviton_unknown_type1c02_id0334, node_id=2, is_ready=True, is_failed=False, receivedDups=0, retries=0, neighbors={1, 3}, query_stage=Complete, lastRequestRTT=18, receivedTS=2017-09-07 13:08:08:744 , node_name=Leviton Unknown: type=1c02, id=0334, sentTS=2017-09-07 13:08:08:719 , sentCnt=12, sentFailed=0, max_baud_rate=40000, is_info_received=True, is_awake=True, is_zwave_plus=False, old_entity_id=zwave.leviton_unknown_type1c02_id0334_2, receivedUnsolicited=0, capabilities={‘listening’, ‘routing’, ‘beaming’} @ 2017-09-07T13:06:51.641287-04:00>, ‘new_state’: <state zwave.leviton_unknown_type1c02_id0334=Ready; lastResponseRTT=24, averageRequestRTT=17, receivedCnt=9, manufacturer_name=Leviton, averageResponseRTT=24, friendly_name=Leviton Unknown: type=1c02, id=0334, product_name=Unknown: type=1c02, id=0334, new_entity_id=zwave.leviton_unknown_type1c02_id0334, node_id=2, is_ready=True, is_failed=False, receivedDups=0, retries=0, neighbors={1, 3}, query_stage=Complete, lastRequestRTT=17, receivedTS=2017-09-07 13:12:16:205 , node_name=Leviton Unknown: type=1c02, id=0334, sentTS=2017-09-07 13:12:16:180 , sentCnt=13, sentFailed=0, max_baud_rate=40000, is_info_received=True, is_awake=True, is_zwave_plus=False, old_entity_id=zwave.leviton_unknown_type1c02_id0334_2, receivedUnsolicited=0, capabilities={‘listening’, ‘routing’, ‘beaming’} @ 2017-09-07T13:06:51.641287-04:00>}}}

I finally gave up trying to get polling to work by setting things in the zwave: settings - I solved things using the solution @lmamakos provided. Feels really, really hacky. But it works. :man_shrugging:

Anything obvious I’m not doing right here?

zwave:
  usb_path: /dev/ttyACM0
  network_key: !secret ZWAVE_KEY
  polling_interval: 60000
  # polling to fix the 3/4-way lights not refreshing
  # correctly when operated from their remotes
  device_config:
    light.tv_room_light:
      polling_intensity: 1
      refresh_value: true
    light.stairway_light:
      polling_intensity: 1
      refresh_value: true

Is your refresh actually working? I have one Z-Wave bulb that I need to use refresh on but as far as I can tell it never refreshes. It’s a Linear LB60Z-1 Dimmable LED Light Bulb and claims to be Z-Wave Plus compliant.

Yes, I’m doing exactly what @lmamakos did and it’s working for my lights:

Hi.

I also have the issue with DZS15 switches.
However, I came up with a solution that doesn’t involve polling, or refreshing things every couple of minutes.

I am just starting to play with HASS, so I have no idea if this is the best way to do that, or if it can be simplified.
At the moment, for each switch I need an automation entry:

- id: '1526157257464'
  alias: Update_Office_Switch
  trigger:
  - entity_id: zwave.leviton_dzs151lz_switch
    platform: state
  condition: []
  action:
  - data:
      entity_id: automation.update_office_switch
    service: automation.turn_off
  - data:
      entity_id: switch.switch_2
    service: zwave.refresh_entity
  - delay: 00:00:05
  - data:
      entity_id: automation.update_office_switch
    service: automation.turn_on

I noticed that every time when I manually press the switch, after 10 seconds, there is a state_changed event on that node, that doesn’t actually change anything. But it’s still there. When that happens, I refresh the relevant entity.
Which also triggers the state change. To avoid refreshing it all the time, this rule disables itself and re-enables itself after a couple of seconds.

Is that a good idea?

And I managed to improve the original script.
Instead of turning the automation off and back on after a delay, I added a condition that prevents it from running too often:

alias: 'Update Corridor Light'
trigger:
  - platform: state
    entity_id: zwave.leviton_dzs151lz_switch_3
condition:
  condition: or
  conditions:
    - condition: template
      value_template: '{% if states.automation.update_corridor_light.attributes.last_triggered == none %}True{% else %}False{% endif %}'
    - condition: template
      value_template: '{{ as_timestamp(now()) - as_timestamp(states.automation.update_corridor_light.attributes.last_triggered) | int > 5 }}'
action:
  - service: zwave.refresh_entity
    data:
      entity_id: switch.switch_3

I’m having the same issue with 2x Aoetec dual micro switches I had installed yesterday. The refresh in the HA UI is inconsistent at best. I’ve tried changing between ‘hail’ and ‘basic’ in the reporting options, and some of the time the switches are updating state when I use the physical switches or the HA UI, but it can be slow. Often if I switch from off to on the state will change to on for a moment and the light(s) turn on, but in the UI the switch reverts back to off for a few seconds before getting a state update and then showing on. Sometimes it doesn’t seem to update at all.

But if I go into the z-wave config and ‘refresh’ the node, the states (and other sensor data) all instantly update correctly.

1 Like

Did you work out how to make the Aeotec Dual Nano switches behave? I’m having exactly the same problem :frowning:

I’ve had them in ‘basic’ reporting mode for a while now and they seem OK at updating the switches, but not any of the other status like power usage. I still seem to need to ‘refresh’ the node to get that updated.
It still does the thing where if I change the state in the HA UI, it flips back to the previous state for a second before updating. Say the light is off and I switch on, the switch moves to on (and the light turns on), then the switch flips back to off for a second or two (actual light stays on), then the switch updates back to on and stays there.

1 Like

Hi,
have same issue but only with my Fibaro Roller Shutter, they don’t report the cover level anymore. They were installed few years ago, when i started to learn Home Assistant, and never had update problems. I think is related to the latest Home Assistant releases (0.70 and over?), but I haven’t the time to revert to old releases and give a try.
Other zwave powered devices i have (only smart sockets) seems to update, but they send autonomous report to measure the power at every variation … other battery powered devices seems to be ok too.

Here’s what Aeotec Support told me today. Sounds like there is room to improve OpenZWAVE or Home Assistant.

"It may be related to how OpenZWave requests an update from the device when it is controlled from the interface which may cause the device to report OFF and then again to the actual state of the device.

Setting:

Parameter 80 [1 byte] = 2 to report Basic SET may help with speeding up the transition to the real state when controlling form the interface.

If you can stop the interface from issuing a BINARY SWITCH GET command when controlling from the interface, this will help avoid the issue that you are seeing.

When i’ve seen this issue in the past, controlling from the UI itself, the UI from OpenZWave issues a Binary Switch GET to request an update, but it is better to rely on the device updating on its own.

Typically this should be the flow of communication:

  1. Controller issues ON command UI
  2. Switch turns ON
  3. Switch issues update to Controller that it is ON.

But this is the control that I have seen with others using OpenZWave type softwares:

  1. Controller issues ON command from UI (interface changes to ON state)
  2. Controller issues State Request from UI
  3. Switch reports OFF state before turning ON to controller (interface changes to OFF state)
  4. Switch turns ON
  5. Switch issues update to Controller that it is ON (interface changes to ON state)

In this case, keeping your controller from requesting an update should resolve the issue that you are seeing."

I have the same issue and worked around this by setting up an automation that refreshes the zwave device after is was used by triggering when electric power consuption drops. in this way I will get an update even when the device was used with the physical buttons. I do not need to poll the device. I have created this blueprint. Maybe give it try.