Fibaro Wall Plug driver shows "off" after switching on from the hub under Z-Wave JS (BasicReport value 99 treated as off)

I have just migrated my Hubitat C-8 to Z-Wave JS tonight and the built-in Fibaro Wall Plug driver shows the wrong switch state when the plug is turned on from Hubitat. The plug turns on (the load is powered), but a few hundred milliseconds later the device state flips to "off" and stays there until “Refresh” is pressed. All my Dashboards show the same wrong state.

Environment

  • Hub model: C-8
  • Platform version: 2.5.2.127
  • Z-Wave stack: Z-Wave JS (recently migrated from legacy)
  • Z-Wave firmware: 7.18.1
  • ZWave-JS version: 15.29.0
  • Device: Fibaro Wall Plug Type G (UK) - FGWPG-11
  • Driver: Built-in "Fibaro Wall Plug

Issue

  • Fibaro Wall Plug is off.
  • Turn it on from the device page or a dashboard.
  • The load powers on, but the device state ends up as "off".
  • Expected behaviour is switch = on
  • Actual behaviour switch = on, then immediately off (twice)

Debug Log (Switching on from Hubitat)

on()

SwitchBinaryReport: SwitchBinaryReport(value:255)

Office Lights switch is on

BasicReport(value:99) B

asicReport(value:99)

Office Lights switch is off

Office Lights switch is off

executeBasicGetCmd()...

Analysis

The plug correctly reports "on" with SwitchBinaryReport(value:255). It then sends BasicReport(value:99), which is also "on" (per the Z-Wave spec, 1–99 and 255 = on, 0 = off), but the driver records it as "off". It looks like the driver treats only 255 as on. Under the legacy stack this didn't happen, so Z-Wave JS appears to be delivering the Basic "on" value as 99 where the driver expects 255.

Pressing the physical button on the plug reports correctly (single SwitchBinaryReport(value:255), state = on).

Configure and a hub power-cycle did not change the behaviour.

Possible Fix

In the Fibaro Wall Plug driver's BasicReport/BasicSet handling, treat any non-zero value as "on" (value > 0), rather than only 255. I have ~49 of these plugs, so a fix in the built-in driver would be much appreciated.

:up_arrow:
@bcopeland

Very strange... Investigating

Oh... I see..

Looks like this device did something a bit non-standard and the driver was making use of that quirk and ZWave-JS normalized the value..

Fix coming..

Dang that was quick @bcopeland. What you tryna do? Give us slackers a bad name?!!! :laughing:

Perfect timing.. A build was already in the works when I submitted the fix..

Thanks for sorting this out so quickly - much appreciated.