Openhab not sending Z-Wave commands to ZEN31

Nick_Wilkinson · October 28, 2023, 4:55am

Run into a strange issue with the Z-Wave binding seemingly not sending commands to the ZEN31

My Setup:
OpenHAB Version: Was running on 4.0.0.M3 (may have been M2). I have upgraded to 4.1.0.M2. Same issue on both versions.
HW: Pi 3B
OS: openHABian

Issue
I have used the ZEN31 in the past on a openHAB 3.x and it worked well. I included the ZEN31 in the ZWave network today and noticed that it wasn’t controlling the light strip. After some digging I found that when I would change the switch_dimmer2 (Red) channel the logs would show that it received a command and what looks to be an error “Command class SWITCH_MULTILEVEL not found when processing command on endpoint 2”. I tried putting the log into the Online Zwave log reader but Node 52 didn’t even register to filter on. Below are the Log File - it is Node 52

2023-10-27 21:14:53.118 [TRACE] [ng.zwave.internal.protocol.ZWaveNode] - NODE 35: listening == false, frequentlyListening == false, awake == false
2023-10-27 21:14:53.118 [TRACE] [nal.protocol.ZWaveTransactionManager] - NODE 35: Node not awake!
2023-10-27 21:14:53.119 [TRACE] [ng.zwave.internal.protocol.ZWaveNode] - NODE 34: listening == false, frequentlyListening == false, awake == false
2023-10-27 21:14:53.119 [TRACE] [nal.protocol.ZWaveTransactionManager] - NODE 34: Node not awake!
2023-10-27 21:14:53.120 [TRACE] [ng.zwave.internal.protocol.ZWaveNode] - NODE 33: listening == false, frequentlyListening == false, awake == false
2023-10-27 21:14:53.121 [TRACE] [nal.protocol.ZWaveTransactionManager] - NODE 33: Node not awake!
2023-10-27 21:14:53.121 [TRACE] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage nothing
2023-10-27 21:14:53.201 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 52: Command received zwave:device:d4ce5fee03:node52:switch_dimmer2 --> 60 [PercentType]
2023-10-27 21:14:53.203 [DEBUG] [erter.ZWaveMultiLevelSwitchConverter] - NODE 52: Command class SWITCH_MULTILEVEL not found when processing command on endpoint 2
2023-10-27 21:14:53.204 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 52: No messages returned from converter
2023-10-27 21:14:53.301 [TRACE] [WaveSerialHandler$ZWaveReceiveThread] - Received SOF
2023-10-27 21:14:53.303 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 10 00 04 10 31 0A 32 02 21 74 00 00 00 00 00 00 A5 
2023-10-27 21:14:53.304 [TRACE] [wave.internal.protocol.SerialMessage] - NODE 255: Creating new SerialMessage from buffer = 01 10 00 04 10 31 0A 32 02 21 74 00 00 00 00 00 00 A5 
2023-10-27 21:14:53.305 [TRACE] [wave.internal.protocol.SerialMessage] - Calculated checksum = -91
2023-10-27 21:14:53.306 [TRACE] [wave.internal.protocol.SerialMessage] - NODE 255: Checksum matched
2023-10-27 21:14:53.307 [TRACE] [wave.internal.protocol.SerialMessage] - NODE 49: Message payload = 10 31 0A 32 02 21 74 00 00 00 00 00 00 
2023-10-27 21:14:53.308 [TRACE] [WaveSerialHandler$ZWaveReceiveThread] - Message is valid, sending ACK
2023-10-27 21:14:53.309 [TRACE] [WaveSerialHandler$ZWaveReceiveThread] - Response SENT 6

When I would change the color_color1 channel - nothing seems to be in the logs past the command being received.

2023-10-27 21:12:53.615 [TRACE] [nal.protocol.ZWaveTransactionManager] - NODE 33: Node not awake!
2023-10-27 21:12:53.615 [TRACE] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage nothing
2023-10-27 21:13:03.466 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 52: Command received zwave:device:d4ce5fee03:node52:color_color1 --> 354,0,100 [HSBType]
2023-10-27 21:13:03.649 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 52: Command received zwave:device:d4ce5fee03:node52:color_color1 --> 340,0,100 [HSBType]
2023-10-27 21:13:03.849 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 52: Command received zwave:device:d4ce5fee03:node52:color_color1 --> 326,0,100 [HSBType]
2023-10-27 21:13:04.052 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 52: Command received zwave:device:d4ce5fee03:node52:color_color1 --> 315,0,100 [HSBType]
2023-10-27 21:13:04.208 [TRACE] [WaveSerialHandler$ZWaveReceiveThread] - Received SOF
2023-10-27 21:13:04.211 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 10 00 04 10 35 0A 32 02 21 74 00 00 C1 35 00 00 55 
2023-10-27 21:13:04.213 [TRACE] [wave.internal.protocol.SerialMessage] - NODE 255: Creating new SerialMessage from buffer = 01 10 00 04 10 35 0A 32 02 21 74 00 00 C1 35 00 00 55 
2023-10-27 21:13:04.214 [TRACE] [wave.internal.protocol.SerialMessage] - Calculated checksum = 85

Any help would be greatly appreciated here.

Sebastian_Bacher · October 28, 2023, 6:44am

I have a similar problem with OH 4.0.0 and Eurotronics Spirit Zwave thermostats. It is possible to send this command to switch to Eco-Mode

ThKiZiR_Mode.sendCommand(11)

but i cannot change the temperature of the thermostats by using

ThKiZiR_Heiz_Temperatur.sendCommand(22)

Within the second command, there is even no reaction from the zWave-Controller (RazBerry 2), which means, no green light when sending commands.

Other data like current temperature ist working fine. Everything worked well with OH 3.4.

apella12 · October 28, 2023, 5:26pm

First welcome to the forum. Second when in doubt it is best to create a new thread. Nothing attracts more interest than a new community member with no responses. Also I’m 99% sure this is not a similar problem. You are probably missing the units. Mode is a number. Temp is a number:temperature. Is your item setup as number:temperature? If yes, try something like
ThKiZiR_Heiz_Temperatur.sendCommand(22|°C)

This is not a strong zwave area for me (I have no device like this), but reading the manual, how many and to what ports do you have switches? I’m wondering if there is no switch on IN1 (red) that channel may not work? Also what is parameter 150? Lastly you really only need to set the binding to Debug. Also Zooz support is pretty good at least to run by your connections and parameters. Also wondering if “Reinitialize Device” might help.

Nick_Wilkinson · October 28, 2023, 10:15pm

Thank You Bob for the pointers. Zooz does have good support. A few answers to your questions.

I have no switches attached. The only thing I have connected is the Light Strip and the Power. I have used the ZEN31 before with OpenHAB 3.x and it worked in this wiring configuration. Based on this question I did attach a set of switches and can control the Light Strip with the switches showing the ZEN31 is working (at least locally)
Parameter 150 is the default - Zero → I don’t fully understand this parameter but it seems to be the level to send commands via association groups not incoming commands from the hub(OpenHAB)
I have done an exclude / reincude as well as factory reset on the ZEN31

When I went to debug this I was expecting something that looks like the following screen shot in the zwave logs which shows (1) Command Received [by the binding I think] (2) Command Sent out “Tx” (3) Ack from the device “Rx” (4) Then a GET to see the state of the device.

I did try to change the configuration parameters - They were successfully updated (Communication to/from the ZEN31 seems to work for this). You can see this in the logs below. The reason I think this is an OpenHAB issue is because it seems like the Binding receives the command to update Color or Red/Green/White/Blue Levels (i tested all of them) but then doesn’t actually do the “Tx” out the ZWave Radio.

In the raw logs I find the following which seems to point to a bug / configuration issue / database issue as it seems to be saying it can’t process the command but I haven’t been able to debug further.

2023-10-27 21:14:53.203 [DEBUG] [erter.ZWaveMultiLevelSwitchConverter] - NODE 52: Command class SWITCH_MULTILEVEL not found when processing command on endpoint 2
2023-10-27 21:14:53.204 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 52: No messages returned from converter

apella12 · October 28, 2023, 11:03pm

I agree the node47 is exactly what is supposed to happen and that with the param 21 change there is reasonable communication.

The only thing that led me to param 150 was the RGBW / HSB Wall Switch Mode title and “0” is the RGBW option and the commands not going out are HSBType. I’m going to have to do some research.

Random thoughts

I recall another posting with a similar problem and I thought the answer was to add raw_color to one of the endpoints
I thought I read that HSB had been depreciated, but that doesn’t mean it would work. But I’m not sure.
what bothers me about the debug message is the multiswitch CC is clearly listed in the DB.

Edit: After some review I do not think param 150 is involved. Also found this thread and I think it is a very similar device. Seems to suggest the color_raw control might help. Lastly checked the binding and the last color change was Dec 2021 and the last device changes were August 2022. Sorry no real answer as I don’t see changes in 2023.

Sebastian_Bacher · October 29, 2023, 6:53pm

Thank you very much, this worked for me. I changed the declaration in my .items-file from

Number ThKiZiR_Heiz_Temperatur <temperature_hot> {channel=“zwave:device:89b464e0:node46:thermostat_setpoint_heating”}

(which worked fine in OH 3.4.4)

to

Number:Temperature ThKiZiR_Heiz_Temperatur <temperature_hot> {channel=“zwave:device:89b464e0:node46:thermostat_setpoint_heating”}

By the way, this (ThKiZiR_Heiz_Temperatur.sendCommand(22|°C)) did not work.

Next time i’ll start a new thread.