Has anyone tried to use Zooz’s ZEN35 Dimmer Controller?
I’m using the regular ZWave binding in openHab 5 (not ZWAVE JS).
I hacked together an XML file because it’s not listed in the database on opensmarthouse.org
I took pieces from the ZEN32 (non-dimming scene controller) and pieces from the regular dimmers ZEN72.
I can control the dimmer remotely, but when I change the dimmer from the switch, or press one of the scene buttons, it doesn’t update it state in openHab.
Every other Zooz device I have is working great, so I assume it’s a configuration issue on my part.
It kind of defeats the “community” purpose to not add a new device into the ZW DB. No one else (less technically able) will be able to use the device until it is added. Also the entry gets uploaded without possible hand entered errors that you may have made. The ZEN32 had quite a bit of customization in the DB.
That said (without searching for those errors, you may want to add the COMMAND_CLASS_BASIC to the Switch dimmer. That is not normally necessary with zooz, but maybe it is needed here.
From what I read for adding a device to the database, it was necessary to start with a basic XML, then add properties using the web UI. It is unclear to me elements are needed in the XML to get started.
I will absolutely add the ZEN35 to the database once I figure out how it works. I will look at adding COMMAND_CLASS_BASIC, thanks for the tip.
The blog has the general process, but in summary there is an XML generated by the ZW binding when your device is first found (as an unknown device). Even unknown devices are interviewed for the properties of the device. That avoids most errors in creating an XML from scratch. That is the XML that gets uploaded to ZW DB. That’s all.
Next, you customize the DB entry with parameters, association groups and other information from the manual. Lastly, you can download an XML from the ZW DB to update your jar while waiting for a build.
Ok, thank you. I had read that before, but I didn’t know what location was meant by {userdata}/zwave and it only references OH2 and OH3. It turns out OH5 still makes the XML files in that location.
For anyone looking in the future “opehab-cli info” at the terminal will show the locations of the important OH directories.
I uploaded my basic XML and am working on copy-pasting the overview descriptions and such. I looked up all the parameters from the manual, so I have descriptions for those already.
To get the basic cc in the xml, click on the cc above the dimmer and check the box that says basic is part of this cc. If you want to control the parameters like the zen 32, add channels to the configuration cc. Look at the zen 32 for reference. Looks like a good start.
I did find it odd that the options carried over from one parameter to the next when I was making them. I thought it convenient, but it seems it was a bug.
And now they’re all gone. I tried to export the XML to try it and it broke the ZWave binding. I reverted back to my hacked XML and the ZWave binding is working again.
It is a fairly complicated device. What I see is that you have entered 19 parameters, but the manual has 41. Also, no association groups and the manual appears to identify 12. It could take a while. When you are done remember to mark for review.
Meanwhile as to your original issue, did the basic CC solve that problem?
I added a couple of configs from Zen32, seems to be okay. Are you hitting save?
Yeah, I paused at 19 parameters, because it was getting tedious and I was eager to try it. I will keep at it. My goal is to get the XML export from the website to match closely with my handmade version.
Adding the basic CC does not seem to have resolved the issue, but I wonder if the association groups is what I’m missing. When I grep’d the OH-INF/things/zooz folder, some devices had COMMAND_CLASS_BASIC for their dimmer or scenes, and others did not, so I think I’ll focus on association groups for now.
I hit save changes on the parameters dialog each time, not sure what happened. The options are being retained now. When I get to new parameters, I’ll check more closely.
08:12:00.776[WARN] [org.openhab.core.thing.internal.ThingManagerImpl] - Channel types or config descriptions for thing ‘zwave:device:aea46737fa:bedroom_dimmer’ are missing in the respective registry for more than 120s. In case it does not happen immediately after an upgrade, it should be fixed in the binding.
08:12:00.789[WARN] [org.openhab.core.thing.internal.ThingManagerImpl] - Failed to normalize configuration for thing ‘zwave:device:aea46737fa:bedroom_dimmer’: {thing/channel=Type description zwave:zooz_zen35_00_000_config_decimal_param3 for zwave:device:aea46737fa:bedroom_dimmer:config_decimal_param3 not found, although we checked the presence before.}
08:12:00.852[WARN] [org.openhab.core.thing.internal.ThingManagerImpl] - Failed to normalize configuration for new thing during update ‘zwave:device:aea46737fa:bedroom_dimmer’: {thing/channel=Type description zwave:zooz_zen35_00_000_config_decimal_param3 for zwave:device:aea46737fa:bedroom_dimmer:config_decimal_param3 not found, although we checked the presence before.}
When I started configuring the ZEN35 in the database, it only had 2 configuration endpoints, so config_decimal_param3 didn’t exist where as it did in my manual config. This made the whole ZWave binding not work.
Also, I’ve discovered that updating the bundle and rebooting takes 10-15 minutes before things function again, so I have to be patient when testing.
Using the XML exported from the database, I’m back to where I started. All my devices work except for the ZEN35 reporting it’s dimming value, and scene number. I marked the ZEN35 for review in the database as it’s pretty close.
When my wife is not sleeping later I will capture some debug logs with pushing buttons and changing the dimmer value. I did try updating parameter values through the OH UI and that seems to be working as well.
What the debug should show is the message sent by the device when you trigger remotely. Hopefully there is one, we can see why it is not getting matched up with a channel. The logs can get long, so initially I’d advise turning to debug, do the test and then go back to info.
Edit: also make sure parameters 19 and 33 are showing correctly
The messages showing node 1 are odd. Will take a look. I have a Zen73 (on-off only). With only manual operations. (my device doesn’t have the Basic CC, but has a parameter to use Binary Switch)
Ok, here is a manual log file. I pressed each button, and double tapped the dimmer button. Other than “unknown command class“ messages, there is no traffic from node 26.
I’m not sure if the bytes listed are raw received data or translated by the USB stick. I don’t have a copy of the ZWave spec anyway, so I can’t analyze further. According to an online resource, the “unknown” command classes don’t exist, so either the data is probably getting corrupted, or the ZWave binding isn’t parsing it properly.
I’ll look at the latest, but complicating the issue is the viewer. Long story short, but I have suggested to the developer to make changes for 700/800 series controllers, but they haven’t been made. I have a modified mine, so I can report there is nothing wrong.
This is the only thing I found odd in the first file. It appears the manual trigger is sending a restore last value command. Could that be possible? Maybe your latest will clear it up. There should be no TX from the controller. Note the log I posted, only RX for local control.
EDIT: Definitely no messages from Node 26. Thing to try. Delete the node from the thing page and rescan, if that doesn’t work, exclude the node via the controller and reinclude.
Yeah, I wondered if the “unknown command class” was reported by the binding or the viewer.
That’s not a manual trigger, that’s me changing it from the OH UI. The button on my page changed the state to “ON”, which I assume defaults to Restore Last Level.
If I push buttons on the ZEN35 directly, I see no traffic other than the “unknown” messages.
