I’ve got a Qubino ZMNHHD since a year and it has been working fine until recently. I cannot tell when it exactly stopped working and I thought it might be some “usual” disconnect but it still does not work after resetting the device and reinclude it into openhab. That worked fine but I cannot control the lights.
The only log messages I can find are:
2022-07-22 15:59:47.054 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 46: Command received zwave:device:5a95239b:node46:switch_dimmer --> ON [OnOffType]
2022-07-22 15:59:47.056 [DEBUG] [erter.ZWaveMultiLevelSwitchConverter] - NODE 46: Command class SWITCH_MULTILEVEL not found when processing command on endpoint 0
2022-07-22 15:59:47.057 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 46: No messages returned from converter
2022-07-22 15:59:56.591 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 46: Command received zwave:device:5a95239b:node46:switch_dimmer --> OFF [OnOffType]
2022-07-22 15:59:56.594 [DEBUG] [erter.ZWaveMultiLevelSwitchConverter] - NODE 46: Command class SWITCH_MULTILEVEL not found when processing command on endpoint 0
2022-07-22 15:59:56.596 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 46: No messages returned from converter
Any ideas? Or any additional information I can provide?
Probably the device is not communicating, or not initialised in the network or something like that. The error Command class SWITCH_MULTILEVEL not found when processing command means that the binding couldn’t find this command class in the device info it holds after the interview, so probably the interview, which normally happens during inclusion, hasn’t happened.
I assume you updated all your things to use the new node ID after the re-inclusion?
Well, it’s the “thing” that has the node ID being set - this is the important part.
Unfortunately filtering the logs means you’ve removed the information I really need to see, however I don’t see that the SWITCH_MULTILEVEL command class seems to be active, but again it’s very hard to tell without seeing the fully log.
And I usually don’t have things defined via config but just within the UI. So after inclusion it should be fine. But just verified in the code tab that it has node_id: 46
Here is where the device reports what command classes it supports, and as multilevel_switch is not in the list, it’s missed.
I would first suggest to try a reinitialisation - there is an option in the thing configuration and setting this to true will redo this, but slightly differently since it requests this data specifically rather than relying on it from the inclusion.
If that doesn’t work, then we will need to do a database update to force this command class to be recognised.
I’ve clicked “Reinitialise the device” and a lot of stuff happened in the log.
But I haven’t found any log entry containing NODE 46 and MULTILEVEL and there are no commands working.
Is that sufficient or should I post the full log again?
Thanks @chris ,
I’ve read a bit more also in the manual and not sure if I get it right.
It says
GENERIC_TYPE_SWITCH_MULTILEVEL (in Switch mode it changes to GENERIC_TYPE_SWITCH_BINARY)
COMMAND_CLASS_SWITCH_MULTILEVEL_V3 [S0]* [S2]* (only present in Dimmer mode)
And since I run the device in switch mode (instead of dimmer) I’m wondering if the detection is actually correct?
But in that case I wouldn’t know why openhab tries to do something with MULTILEVEL. What would give openhab the indication it actually is a dimmer and not a switch?
It does then sound like the database was previously correct.
The channels are defined in the database, so the binding doesn’t change based on what the device sends. This was a limitation in openHAB when the ZWave binding was written - all channels had to be defined statically. This has not changed, and other bindings I’ve written such as Zigbee use this, but rewriting the ZWave binding to do this is a huge task.
So, probably the best thing for you is simply not to send dimmer commands to the device - I think that probably would solve the problem (I think ).
I got mixed up with the way the zigbee and zwave binding converters work. So it’s not possible to do this - what you’re doing is fine, but it will always result in the multilevel switch commands.
We will need to add another channel to this device - I’ll do that now.
Well, you asked for a way to not wait for the next release. If you want to wait for the next milestone, that’s probably a week or two away - or the next stable release is about 5 months. Otherwise you need to use the snapshot.
The binding is the same as the last release - just the database has been updated, but it’s up to you. I appreciate many people like to wait for the next release, but that is some time off…
The issue here is that the device does not support the dimmer channel at all. It is included without the dimmer enabled so cannot send a dimmer command. That sounds completely different to the other issue where you are actually trying to send a dimmer command as I understand it. It seems therefore completely different.
).