This is my first post here. I’m a new user to OpenHab as I’m switching away from a VeraPlus (previously Veralite). I’ve successfully moved most of my z-wave devices from my VeraPlus to my Aeotech Z-Stick Gen 5 and added all the devices as Things/Items to my OpenHab 2.4 installation (aptitude install on a Raspberry Pi 3). I’m having an issue with some Enerwave ZW15RM devices; they are showing as ZW20RM (ZW20RM In-wall Smart Meter Duplex Receptacle). For the most part this should be fine as the ZW20RM is a binary switch identical to the ZW15RM, except it’s a 20 amp receptacle. The problem seems to be that it shows with a dimmer channel instead of a Switch channel.
I have ZW15R receptacles that showed as ZW20R which work even though they show as the 20 amp device, so I’m guessing that if the ZW20RM’s Dimmer channel was changed to a Switch channel, all should work as well. I did try to flip the Dimmer ON/OFF switch in Openhab, but it does not turn on the device as I’m guessing it sends the wrong codes to the receptacle. I had a look at the xml file to see if it was an easy fix, but I’m not sure what to change, and if I should even be changing that since it’s getting the bindings from a database.
Yes, it is a switch channel, you need to link it to a switch itemtype in openHAB.
To be honest, I can’t get the problem from your first post, what exactly does not work?
The device is a switch and does not have a dimmer function.
I did read your post again and think I understand now (sorry, no native English speaker):
You are saying the device channel is showing up as a dimmer channel, right?
I have no idea how that can happen as the channel is not defined like that:
I’m not sure how this is possible - as you say, there is no dimmer channel defined in the database, and the device doesn’t support the multilevel switch command class in any case. I don’t know how the binding can just make that up
I note that this is a 2.4 installation, so maybe it’s possible that in 2.4 it was incorrectly defined as a dimmer - if so, migrating to 2.5 would resolve that.
When you say “migrating to 2.5 would resolve that”, are you referring to the zwave bindings version, as I have migrated to the latest 2.5 snapshot, or do I have to actually update my OpenHab install to the OpenHab 2.5.0.M2 version? I didn’t update my OpenHab 2.4 install to 2.5.0.M1 as I wasn’t sure how stable it is compared to 2.4, and didn’t want to ruin my first experience using OpenHab with a non-stable release. If I need to, I will update my OpenHab to the 2.5.0.M1, let me know if that is necessary.
After moving to the latest zwave bindings snapshot, I excluded the devices, even verifying they were removed from the Z-Stick using the zensys-tools ZWaveController application. After including them back, they are still showing with the dimmer as can be seen in the below screenshot.
As @sihui pointed out, it does show it has a Dimmer channel in the documentation, but list their classes as binary in the database on your site. I’m not sure what to do at this point. Correct me if I’m wrong, but I’m guessing when a device is scanned and added that it does a query to your online database on your site so should be correct. If not, is there something I have to do to get the latest database link/info for my install?
I’m still new to the configurations, but my ZW15R (bindings finds as ZW20R) is working and is the same as ZW20RM except the RM has the power meter, so I compared the database entries. As you can see in the first screenshot below, the classes do say SWITCH_BINARY, but the Endpoints still says SWITCH_MULTILEVEL. I get the SENSOR_MULTILEVEL, but should it really be a SWITCH_MULTILEVEL under Endpoints in the database (screenshot 2 below), or should it be the same as the ZW20R Endpoint and specify SWITCH_BINARY? I’m assuming SWITCH_MULTILEVEL signifies that it’s a varying current switch.
Yes - sorry, I didn’t see that you’d already done this.
Yes, but it’s not listed in the database, and that is what matters. The fact that the docs shows something else further indicates that previously the channels were different, but if you run the latest binding, it should show the channels in the database. I really can’t see how it can be different than the database if everything is up to date.
This doesn’t matter as this information is not used by the binding or database.
A multilevel switch is a dimmer - a binary switch is just a switch
Not sure if this helps, but something I noticed is the Device Type is showing 273 (0x111) for the ZW20RM which is the same device type for my ZW500RM (In Wall Dimmer Toggle with Meter). Does this matter? It won’t let me set this in the XML because every time I change it and restart OpenHab, it resets it, so I’m guessing it’s pulling from somewhere, not sure where. Is there something else I can try?
Is there something I can check what is causing? I looked at the logs after including and adding the Thing, but nothing stands out. Where can I look to see why it’s associating the dimmer channel? Is there something I can delete/clear after excluding, and before including to make sure it’s not using old settings?
As a side note, after updating to the 2.5 zwave binding snapshot, it is taking a minute or 2 for the inbox items found go from unknown to it finding out shaft the device is. Before the update, I never seen items show up as unknown.
Hi Chris, I just updated to the latest binding (2.5.0.201907090433), excluded, waited, included it back, and it’s still showing as a dimmer. Should it have been part of the snapshot?
Hi Chris, I’m currently on snapshot 20190711, and it’s still showing as a dimmer even after exclude/include. How often does the database get updated to the snapshot, and is there a way for me to do it? Is it customizable to where we can create our own xml spec files or other config file? I understand that it’s tightly controlled, but figured since most other things are controlled with config files, was hoping the devices could be too in case they aren’t in the database, or like in this case
it needs to be modified.
It’s not (easily) possible to create your own database files since they are embedded in the JAR. This is a limitation (or design feature) of OH itself. You can edit the JAR if you want of course, but that can be messy.
If you’ve deleted the thing and added it back, it should pick up the latest definition. I note though that the binding has not been built since the database was updated, so any recent changes will not be included.
Thanks for the follow-up. It seems to now recognize it as a “Switch”, but the switch isn’t working; however, the meter is reporting accurately. When I hit the switch it doesn’t do anything. I’ve tried doing a heal, I’ve reinitialized it, I’ve excluded and included a few times, rebooted the server, and even gave it over night to start working as I’ve noticed sometimes it takes a bit for the switches to start working sometimes.
Looking at the database there are some differences that stand out between the ZW20RM and ZW20R other than the power meter, but I don’t really know what all parameters mean. The ZW20RM says it’s a Library Type LIB_CONTROLLER_BRIDGE and and the ZW20R is a LIB_SLAVE_ROUTING Library Type. Then under endpoints the ZW20RM still is listing “SWITCH_MULTILEVEL” with checkboxes under Basic, NIF, UnSec where as the ZW20R lists it as a “SWITCH_BINARY” with Basic and UnSec checked. Not sure if that helps, but it’s the only thing I can see that is different. If you don’t see the issue, is there a way I can play with the settings/config to test to get it working?
