Qubino ZMNHHD mini dimmer cannot be controlled (anymore)

  • Platform information:
    • Hardware: Raspberry Pi with RaZberry
    • OS: Raspbian Buster
    • Java Runtime Environment: OpenJDK Runtime Environment Zulu11.52+13-CA (build 11.0.13+8-LTS)
    • openHAB version: 3.3.0
  • Issue of the topic:

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?

You mean my items I assume? Yes, did that.

I still have logs from the inclusion. Attached here filtered for “NODE 46”. I could provide full log if required.

Do you see anything from there?
node46.txt (284.7 KB)


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.

Here is the full 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

So the basic problem is this -:

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. I’ll update the database to force this command class to be added. It’s strange that this has just started though…

Thanks @chris ,
I’ve read a bit more also in the manual and not sure if I get it right.
It says
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?

1 Like

Thanks - interesting.

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 :slight_smile: ).

Sounds like a theory but I don’t know how to not send dimmer commands:
This is my item:

Switch garage_lights "Garagenlicht" <outdoorlight> (Switches, gEingang, gLampen) ["Lightbulb"] {alexa="Switchable" [category="LIGHT"], channel = "zwave:device:5a95239b:node46:switch_dimmer"}

So any hint what makes openhab send a switch command instead of multilevel would be interesting.

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.

I assume it is this one: Database update (#1790) · openhab/org.openhab.binding.zwave@b763597 · GitHub

Can I do anything to apply this w/o waiting for a snapshot?

Well, snapshots are normally generated a few minutes after the merge into the main branch, so you shouldn’t really need to wait very long :slight_smile:.


Hmm, so I could replace the zwave bundle of my 3.3.0 installation with that one? I’m slightly scared.


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…

Is it possible, that its the same problem with Fibaro Dimmer 2 (FDG212)? And when yes, its also solved in the actual snapshot?

This issue is specific to this device when it is included without the dimmer channel, so it will not be related to other devices.

But when you look on the other post, then I have the exact same issue (Command class SWITCH_MULTILEVEL not found). Maybe it needs also the same fix.
See Zwave Fibaro Dimmer 2 (FGD212) not able to set Dimmer-Value

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.