Z-wave entity status incorrect in dashboard

Configuration Z-Wave
1

Home Assistant 2022.8.7
Supervisor 2022.08.5
Operating System 8.5
Frontend 20220802.0 - latest

Jwave-JS
Driver Version:10.0.3
Server Version:1.22.1

An odd issue has emerged in the last week where some of my z-wave switch and dimmer modules do not show the correct status in the dashboard, which making control a challenge. So far this seem to be related to some Fibaro Dimmer 2 and Double Switch 2 modules, but not all.

When I use an entity card I can turn the switch on, the toggle goes across to on and then a second or so later goes back to off yet the device does turn on. If I toggle it again the display goes to on and back to off again but the device stays on. If I toggle to on and back to off quickly it turns the device off. For modules affected in this way, controlling the module via a directly attached switch does not change the dashboard.

An automation with explicit on and off actions controls the module OK but the dashboard shows no change.

I have an Fibaro Dimmer 2 module running the same firmware revsion (3.5) where the status is correctly reflect in the dashboard. I have compared the config and while all the settings look similar, they are in a different order.

This seemed to start last week after some upgrades. The operating system went to to 8.5 and Z-wave JS

addon_core_zwave_js_0.1.67
addon_core_zwave_js_0.1.66

I restored to a backup prior to this and the issue remains although the operating system did not go back to the previous version. I have also run device and full network heals to no avail. Also re-interviewed an affected device.

Any ideas?

2

Sounds like a bug to me. I’d suggest capturing the zwavejs debug logs and posting them for one of the experts here to review.

Also, go into the zwavejs2mqtt ui (if you have it), find the device and see if refreshing (polling) it’s value corrects the state.

I had a similar problem with a fan switch. So I created this automation.


- id: "loft_fan_1 refresh switch state"
  alias: loft_fan_1 refresh switch state
  description: "Automation to refresh switch after state changes usually caused by switch control"
  mode: queued
  trigger:
    - platform: state
      entity_id: fan.loft_fan_1_level
  condition: "{{ trigger.to_state.state != trigger.from_state.state }}"
  action:
    - service: system_log.write
      data:
        level: info
        message: "Polling fan.loft_fan_1_level state change from {{ trigger.from_state.state }} to {{ trigger.to_state.state }}"
        logger: hvac
    - service: zwave_js.refresh_value
      data:
        entity_id: fan.loft_fan_1_level
    - delay: "00:00:01"
    - service: zwave_js.refresh_value
      data:
        entity_id: fan.loft_fan_1_level

Also just for good measure, i run this automation every 10 minutes.


- id: "loft_fan_1 poll switch state"
  alias: loft_fan_1 poll switch state
  description: "Automation to periodically poll switches"
  trigger:
    - platform: time_pattern
      minutes: "/10"
    - platform: homeassistant
      event: start
  action:
    - delay:
        seconds: "{{ range(0, 60)|random|int }}"
    - service: zwave_js.refresh_value
      data:
        entity_id: fan.loft_fan_1_level
3

Which entity specifically isn’t working?

I ask as Fibaro FGD-212 dimmers (Firmware: 3.5, older firmware just doesn’t work with dimming) present TWO switches as Fibaro are poor at sticking to standards (Home Assistant 2022.8.7 Supervisor 2022.08.5 Operating System 8.5, latest Z-Wave JS).

The first switch works, the second does nothing.

4

So I have done some more detective work to try and narrow this down.

Firstly, I have not had any issue with switching or dimming with the Fibaro modules until this last few days. Firmware 3.5 for the FGD-212 and 3.3 for the FGS-223 had been really stable. All my modules are on the same firmware.

Yesterday I did a re-interview of these some of the modules I could not control. This then allowed me to control them from the dashboard but the status was still wrong. Turn on and the indicator toggles back to off after a second or two but the switch was on. I try the same switches again today and voila, all working as they should?

Other modules I had not re-interviewed had the same issue where they could be controlled from the dashboard. I have re-interview these today and as per yesterday they can now be controlled but the status is wrong. Interestingly looking at the logs it said it was a new module and did a full interview? I’ll see if these work properly tomorrow.

One Dimmer 2 module that did not have the issue has a slight difference in that it shows Highest Security: Unknown as opposed to the affected ones that all seemed to be Highest Security: S0 Legacy.

A Double Switch 2 module that did not have the issue shows Highest Security: None whereas one that did has Highest Security: S0 Legacy.

Given these observations, I am leaning towards this being to do with security now. J-Wave JS release notes for 10,x does have a few security items in there with the last one being for 10.0.3

  • For securely included nodes, attempt endpoint communication with S0, even if S0 is not listed in the endpoint capabilities (#4978)

Another update tomorrow.

5

I’ve not seen the differences probably due to my Z-Wave controller being a Aeotec Z-Stick Gen5. This has a 500 series chipset which I believe is unable to support secure inclusion (although listed as Z-Wave Plus Certified: Yes). My FGD-212 are therefore Highest Security: None, Z-Wave Plus: Version 1. Not sure if this is just S0 under a different name.

The v3.5 FGS-212 all work fine (apart from the second useless control channel - likely lazy Fibaro using one firmware for the single and dual channel devices).

I used a 500-series controller as at the time, there were lots of driver issues with 700-series, although they are supposed to support Z-Wave Plus V2. There’s going to be a lot of folk updating Z-Wave controllers when Yellow is released in volume so 700-series will get more field testing!

My guess your issues may be partly down to a 700-series controller, and as you suggest S0/ S2/ S? secure inclusion being not quite stable. My experience has mostly been on openHAB, but re-interviewing devices has worked for me in the past to pick up attributes. It appears secure inclusion has to be handled differently from the start to get a key exchange (even a PIN or QR code for v2) which could complicate matters.

Controller firmware updates are worth checking, but beyond that, it might be worth trying to exclude/ include a device as a test. It is hard to hit the internal button on a FGD-212 and navigate the LED colours but the cleanest test would be to exclude/ factory reset/ include.

6

Update this morning. Nothing mysteriously fixed itself overnight so I tried a full shutdown and power off of HA. Power on and now the modules I had issue with yesterday are controllable and the status reflected correctly in the dashboard. All seems to be working OK.

I am running an Aeotec stick Gen5 with firmware 1.1 plugged into a USB2 port on my Pi4 via a 1.5M USB extension lead. Not had any issue up until now. I really want to avoid an exclude/re-include as it causes a lot of work.

7

Surprised you have a Gen5 500-series - although v1.1 firmware is at least a version behind mine.

Confirming versions is tricky - think I had to “download support information” to get a JSON file with all of the component details in one place.

Aeotec firmware update via a PC perhaps?

8

James – I think the second control channel is setup so that if you have two physical switches connected you can use them both. E.g., toggling/dimming the second switch changes the second channel. (At least that is how I have used them.)

-David

9

Yes, you can use S2 as an additional or second S1. You can also setup for rocker switch mode. S1 for up and S2 for down. I use S2 with the scenes feature to control other devices. In one setup I have a normal outdoor PIR connected to S2. The PIR switches on when motion is detected and off again a configurable time after motion stops. I have scenes set so the ‘on’ acts like holding down the switch (scene 22) and off like release (scene 23). An automation picked up the scene ID and triggers another device.

10

Interesting @dbs - I’ve never connected anything to S2, and it didn’t appear under openHAB (likely different interview parsing code). My FGD-212 are mounted in enclosures above UK ceiling roses with only 2+CPC cable to switches.

My mental model of Z-Wave separates sensors from controls, so expected the second light.fgd212_2 not to appear as a controllable light, but as a button/ sensor/ other.

Perhaps there is an issue modelling not just “button” events, but “dimmer” percentage states as well, so the S2 switch state is exposed as a dimmable light?

@siwilson - using S2 as a PIR input channel is cunning!

11

Just confirmed my Aeotec Z-Stick Gen5 is v1.2 firmware suggesting you might benefit from an upgrade

  • Settings → Devices & Services → Z-Wave JS → x devices → Z‐Stick Gen5 USB Controller

Device info

ZW090
by AEON Labs
Firmware: 1.2

12

Looks like I am not the only one with this issue.

Zwave JS 0.1.66