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.
I’ve not looked at your issue, but discussing it here will not help and just confuses this issue! I will take a look at yours when I get some time a bit later.
Sorry for the stupid question but is it replacing only or is it also OK to add the new version to the addons directory?
The reason for the question is that I did the latter and also see that 3.4.0 binding is loaded. Directly before it loadsd still 3.3.0 (which is somewhat expected). Is that an issue?
Because now my thing configuration UI looks broken. It has weird field layout and misses options at the bottom.
Especially I was looking for “Reinitialse the device” which I used before.
Are those changes expected?
As mentioned before I’m currently running 3.3.0 release (but typically I’m on the “milestone” train) and just dropped the openHAB-ZWave #253 [Jenkins] into the addon directory and restarted openhab.
It seems you have answered your own question. first uninstall the Zwave binding from OH. Then go into the openhab-cli and feature:install openhab-transport-serial
(This is part of the UI installation, but not when putting a zwave binding in addons)
Then add the snapshot binding to the addons.
Lastly delete the device (not exclude) and then rescan to pick up the changes.
).