TZ67 Switch Dimmer wont stay in OFF state

I have 2 of these dimmers, both are acting exactly the same, I can set the dimmer level but I cannot send an OFF command, the lamp never turns off and the state just turns back to ON instantly in the log.
These dimmers worked perfectly in openhab2.

Ip =
Release = Raspbian GNU/Linux 11 (bullseye)
Kernel = Linux 5.10.92-v7+
Platform = Raspberry Pi 3 Model B Rev 1.2
Uptime = 0 day(s). 20:29:14
CPU Usage = 0.77% avg over 4 cpu(s) (4 core(s) x 1 socket(s))
CPU Load = 1m: 0.67, 5m: 0.84, 15m: 0.82
Memory = Free: 0.05GB (6%), Used: 0.89GB (94%), Total: 0.94GB
Swap = Free: 2.31GB (99%), Used: 0.02GB (1%), Total: 2.33GB
Root = Free: 51.23GB (91%), Used: 4.65GB (9%), Total: 58.29GB
Updates = 5 apt updates available.
Sessions = 2 session(s)
Processes = 136 running processes of 32768 maximum processes

Here are my items:

Dimmer Left_Lamp "Left Lamp" {channel="zwave:device:42a260fdd1:node8:switch_dimmer"}
Switch Left_LampS "Left Lamp Sw" {channel="zwave:device:42a260fdd1:node8:switch_dimmer"}
Dimmer Right_Lamp "Right Lamp" {channel="zwave:device:42a260fdd1:node6:switch_dimmer"}
Switch Right_LampS "Right Lamp Sw" {channel="zwave:device:42a260fdd1:node6:switch_dimmer"}

Here is the log of what happens:

16:39:07.387 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'Left_LampS' received command OFF
16:39:07.409 [INFO ] [openhab.event.ItemStatePredictedEvent] - Item 'Left_LampS' predicted to become OFF
16:39:07.422 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'Left_LampS' changed from ON to OFF
16:39:08.975 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'Left_LampS' changed from OFF to ON

It’s worth pointing out that this also happens when I control the Switch directly from the control panel. I am a little concerned the switches (and the lamps) are always on drawing power.
Unfortunately I didn’t save my items files before upgrading so I have no point of reverse reference, however I am sure this plug had a switch_binary channel, now it just has switch_dimmer, not sure if this is relevant.
I am seriously considering reverting back to openhab2 until this new version gets all it’s kinks sorted out. This is not the only thing that doesn’t work properly in openhab3.

It’s clear if this is an imported legacy Thing or a newly discovered Thing.
If the former, make a note of UID, delete it, rediscover and assign the same UID.

It’s a Zwave Thing, so it’s stored in the controller and imported into the UI.
I tried deleting it and re-adding it, no effect.

Okay, that was to rule out binding device database changes to channels.

You could inspect the online database version to see if you should expect a switch channel?

@rossko57 Not sure where to find the database, google was no help either.
On the items property description within the control panel it says this about the Thing:

The brightness channel allows to control the brightness of a light. It is also possible to switch the light on and off.


I’m not sure what you searched for, but if you look in the zwave documentation, there is a link to the database in the main zwave binding doc. There is also a link directly to the database for every device at the bottom of the documentation page for the device in the OH docs. If I search “OH ZWAVE DATABASE” in google - it’s the top hit.

OK, found the plug, even had a photo of exactly wat it looks like, nice touch.
So, the classes listed in endpoints are:


Or… Maybe sending 0 to COMMAND_CLASS_SWITCH_MULTILEVEL_V1 turns the dimmer OFF and 255 turns it ON at last set level?
It’s been so long since I played around with command classes. I think I have them all somewhere in a .NET class file from OpenZwave.
I am trying to resist the urge to just hard reset my controller and include them all again from scratch.

Of note, the database entry for this has not been updated since OH2.5 / 2019-09-18 and it supports only the switch_dimmer channel.
It’s hard to see how it behaved differently in OH2.

Do they ramp down slowly, would a longer poll after command help?