I’m using two Zooz Zen77 Dimmer Switches. One controls the ligting load, and the other is just a line-powered zwave device intended to recreate the function of a 3-way switch (and 3-way dimmer).
Since one of the 2 dimmers has literally no control of the light, the 3-way behavior must either be created with rules in Openhab or via direct group association in Z-Wave (bypassing Openhab completely). I think the latter is better because it’s deterministic and lower latency.
When trying to make the group association, I look in the Thing Definition in Openhab and found no association group 3. Naturally, I went to OpenSmartHouse DB for the Zooz Zen77 Dimmer Switch), under Associations, and I don’t see an entry for the Association Group 3 (Multilevel) there either.
I’m confused because this is in fact supported in firmware.
Group 3 multilevel allows two or more dimmer switches to control the dimmer state of a single dimmed fixture. Instead of the remote dimmer only being able to directly send a simple on-off control via group 2 (status).
If the OpenSmartHouse DB for the Zooz Zen77 Dimmer had this group association defined, could this group association be configured by the native openahb Z-Wave add-on, without needing to (for example) create the group association outside of openhab (i.e. in Z-Wave PC-Controller or Z-Wave JS)? If so, what can I do to help update the entry? I’ve never done it before, but I am willing to help if I can.
Yes, the problem is that the database is incorrect (assuming that you’re right). You can edit it, but you must first sign up (and I think the signup link is “hidden” because of spambots, search this forum and I think you’ll find how to access it), and then request write access. This will usually take some days, and after the database has been updated, it won’t make it back into your OH installation until there’s a new release.
It’s a slow process, but it carried out, it makes it work for everybody. You can “hack it” by modifying the XML file inside the JAR file of the Z-Wave binding, you’ll find explanations for that on this forum as well, but long-term it’s much better to correct the database.
Excellent. Thanks for your input. I will do both. I’ll temporarily modify my local XML file to confirm it’s functioning properly, then make the identical change at opensmarthome.
I keep threatening (myself with) changeover over to Z-Wave.js but it’s a non-trivial time commitment in my not-small not-simple installation. With the exception of edge cases like this, and bleeding-edge z-wave devices not in the database, the native add-on is simple and works well enough.
The add-on doesn’t seem to work for everybody, but I think I might have found the reason and will issue a “fixed” version soon, that hopefully will take care of that.
The add-on can’t “override” definitions that are already in the binding, so it only really works for devices that aren’t present at all.
The format of the XML document isn’t exactly easy to figure out, so it remains somewhat “unreachable” for many.
edit: I’ve updated the add-on on the marketplace, so the problem with the add-on not working for everybody should hopefully be solved.
I may end up using your plugin because there are several Zooz ZWave device not currently in the DB that I would like to start using namely the itty-bitty ZEN57 (for when the shelly wave-mini’s are just too damned big) and the ZEN53 DC motor controller. After they work for me, I’ll submit them.
I’ve never created one from scratch. Hopefully not too difficult