[SOLVED] Zwave devices not updating item states after upgrade to OH 3

This is somewhat related to my other post: OpenHAB 3 zwave items/channels only updating after saving the item

After the upgrade to OH 3 most of my Zwave items/channels are not updated when switched manually in the hardware. Using OH sitemaps to trigger an update works fine, but when using the actual hardware switch nothing happens;

My setup:
Hardware: Raspi 4, 4GB
Zwave device: Oomi Switch FT116, http://manuals-backend.z-wave.info/make.php?lang=en&sku=FT116-C&cert=ZC10-17035527 , zwave:oomi_ft116_00_000
Openhab: 3.1.0-SNAPSHOT - Build #2115

In openHAB 2.5.11 everything works fine (verified using my backup installation), but I get no values in OH 3 for any state changes.

Actions trying to fix:

  • deleting and re-adding the items
  • deleting and re-adding the thing
  • re-initialization of the thing
  • restart OH 3
  • clean cache and restart OH 3
  • update to latest snapshot

When using the hardware switch(turning the light on) the following message is sent:

2021-01-04 21:47:30.754 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 70: Application Command Request (ALIVE:DONE)
2021-01-04 21:47:30.755 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 70: resetResendCount initComplete=true isDead=false
2021-01-04 21:47:30.757 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 70: Incoming command class COMMAND_CLASS_HAIL, endpoint 0
2021-01-04 21:47:30.758 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 70: SECURITY not supported
2021-01-04 21:47:30.760 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 70: Received COMMAND_CLASS_HAIL V1 HAIL
2021-01-04 21:47:30.761 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 70: Got an event from Z-Wave network: ZWaveDelayedPollEvent
2021-01-04 21:47:30.763 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 70: Polling initialised at 43200 seconds - start in 75 milliseconds.
2021-01-04 21:47:30.765 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 70: Commands processed 1.
2021-01-04 21:47:30.766 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 70: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@fbafe7.
2021-01-04 21:47:30.767 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2021-01-04 21:47:30.769 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2021-01-04 21:47:30.770 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2021-01-04 21:47:30.772 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2021-01-04 21:47:30.838 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 70: Polling...

What I am missing (no matter if I turn the device on or off) is a message like this, actually sending the command details to the item:

2021-01-04 22:02:20.323 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 84: Got an event from Z-Wave network: ZWaveMeterValueEvent
2021-01-04 22:02:20.324 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 84: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_METER, value=0E+1
2021-01-04 22:02:20.325 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 84: Updating channel state zwave:device:512:node84:meter_current to 0 [DecimalType]
2021-01-04 22:02:20.327 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 84: Commands processed 1.

Zwave Debug log of adding the thing back to OH 3 after deleting:
openhab.log (738.7 KB)

I am a bit lost here. This also does not happen only to these devices but to quite some others - not all however)

Thank you for any hints!

  1. Do not expect early snapshots to be fully functional.
  2. Filtered DEBUG logs are useless for troubleshooting.
  3. The zwave log viewer may be of assistance.


  1. That is understandable - however, this did not work since the stable release…
  2. I did not filter anything, I only removed all entries before and after the re-adding of the thing.
  3. yes, I loaded the file into the log viewer but I cannot see anything there that would help me…

Even the entries related to the right channel (zwave:device:512:node70:switch_binary) look good to me.
Still, nothing is updated

What I notice is that I only get a HAIL from the failing devices. While the others send “SWITCH_BINARY_REPORTS”.

Is HAIL not “supported” anymore?
I tried to switch the device from HAIL to “Basic Report CC” but this also does not help…

I had the same problem, my light switches and outlets failed to generate any events in OH. Flipping things from any UI worked without issue (and things worked in the 2.x series).

I created everything in the new UI and imported my zwave items in the Dev tools; where I believe I went wrong was by not setting a profile on the link item page. After this all the outlets and light switches worked like before.
What I can’t figure out is that all of my door sensors continued to work the same and didn’t have the issue, which makes me think its something with my hardware.
Outlets - Leviton DZR15
Light switches - GE / Jasco 12722 (couple of other models for dimmers, but mainly those)

1 Like

I also converted my text files to OH 3, but all of them have profiles.

Even created new items directly in OH 3 and even they don’t work

Many devices work flawless (door sensors, motions sensors, Neo Coolcam plugs, some Neo light switches…), but not the mentioned hardware.

E.g. node 33 works just fine, sending a switch value (on/off). Node 70, one of my problematic devices, does not work)

1 Like

An update/commit from digitaldan solved the issue.
I updated to the latest snapshot version of the Zwave binding and the switches are working again:


Well this is good news, I also went ahead and updated to the same zwave snapshot will do some testing after work.

For anyone else looking to grab the new snapshot I ran this command from Karaf:

update org.openhab.binding.zwave https://ci.openhab.org/job/openHAB-ZWave/31/artifact/target/org.openhab.binding.zwave-3.1.0-SNAPSHOT.jar

1 Like

I am having a similar issue with Fibaro FGD212 Dimmer 2 modules not updating when pressing the physical switch on the wall. I am running the latest zwave snapshot as suggested. The normal switches work fine, only dimmers seem to be affected.

openhab> bundle:list -s | grep zwave
263 x Active x  80 x      x org.openhab.binding.zwave

When an unsolicited “SWITCH_MULTILEVEL_REPORT” is received from pressing the dimmer switch there is no “STATE UPDATE” for the “switch_dimmer1” channel. Other channels like “sensor_power” are being updated as expected.

When the Dimmer module is polled the “switch_dimmer1” channel is updated.

Any advice would be hugely appreciated.

Just for grins, remove your FGD212 items from the UI and create them in a .items file. I ended up putting all of my zwave into OH this way and haven’t had a problem since.

Last I was aware, there is an issue with items linking to channels done through the GUI.

Just remember that you cannot configure devices if you do this. You will need to use other software in this case (sorry).

No - this has never been a problem. The issue was related to channel linking and it makes no difference if it is done through the UI or files (the binding has no knowledge of how an item is configured).

This is the definition for the Dimmer channel and a Switch channel in my .items file.

Switch Study_Nook "Study Nook Light" <light> (Dining_Room) ["Control","Light"] {channel="zwave:device:85a23c30:node10:switch_binary1"}
Dimmer Dining_Room_Light "Dining Room Light" <light> (Dining_Room) ["Control","Light"] {channel="zwave:device:85a23c30:node12:switch_dimmer1"}

@chris, do you think this is a bug in the zwave code? When receiving an unsolicited “SWITCH_MULTILEVEL_REPORT” a “STATE UPDATE” is not being called.

I think that’s pretty unlikely to be honest.

That’s because the command is not encapsulated for the correct endpoint.

Thanks for your response.

I see what you mean about the unsolicited command sent from the Fibaro FGD212 dimmer device not containing the EP-1 context.

Unsolicited command from FGD212 dimmer device

vs this for the polled response

I noticed the sensor power unsolicited command from the dimmer also does not contain the EP-1 context (guess it’s related to the device itself), but the STATE_UPDATE is still called.

I did some more testing with other devices and the Fibaro Switch FGS223 devices do send the EP-1 (or EP-2) context in unsolicited commands

The Fibaro Switch devices contain two individual switches, the EP context would be required to distinguish between EP-1 and EP-2.

Given the Fibaro FGD212 dimmer device only has one physical dimmer, would the dimmer device be required to send the EP context? or should the zwave binding use a default of EP-1 if there is no context in the received command?

This was working with my previous OH2.5 installation.

I get a 404 error with that URL…should it still be working?

Nevermind, figured out it should be https://ci.openhab.org/job/openHAB-ZWave/lastSuccessfulBuild/artifact/target/org.openhab.binding.zwave-3.1.0-SNAPSHOT.jar

I had a similar problem with OH 3.0.1 - Release Build
I could only turn on the Z-Wave plug from UI, but not off.
The log showed events for on, but dead silent for off.
Upgrading to 3.1.0-SNAPSHOT - Build #2308 solved it.
Unfortunately I don’t have the log any more.

Do you use the web based UI for configuration? Once I updated to 3.1.0 using openhab-cli, openhab-cli will show the binding at 3.1.0 but the web based UI still shows 3.0.1 (even after reboot).

I used openhabian-config to switch to the latest version, not the console.
I try to use the UI for as much as possible.

And my UI - About looks like this: