Thanks for the reply! Yeah, I had looked at this a bit earlier, but was unclear on how this database and OpenHAB interact. Does OpenHAB hit this database in real time when it is adding a Thing through the zwave binding, or is the database stored somewhere internally to OpenHAB?
Another question is kind of about the nature of the device itself. Am I to assume that these are largely the same device, just with different IDs/model numbers? The linked blog post says in this case that I should try to “just add the extra references into the existing device.” Are these the same device? Sure the plug design is different because of the different regions, but are they functionally the same enough to warrant being treated the same in the database?
No, the changes to the database are not available in real time. The database is statically stored in the z-wave binding. The database maintainers work hard to get the database exported and a new version of the binding compiled regularly and do a great job keeping that delay down to usually less than a week between an approved change to the database and being able to get the functionality into OH. Of course, this does require that you update your binding to the newest version via your preferred method; it will not be updated automatically for you when the binding is rebuilt.
Okay now I’m all set up to add a device to the database, but I’m getting a very un-descriptive error when i try to submit the form. Just a little popup saying “Error”. Here is the xml i pulled out of openhab: network_c410d0dd__node_21.xml (28.0 KB)
Don’t know if I should create a new thread, but will try here first.
I have one of these devices and using my zniffer found 2 things;
Not all the configuration parameters in the manual are shown in the UI. I did edit the XML file in the binding and recompiled a .jar locally and the file below did pick up the missing parameters. Not sure of next steps. Here is the file zwa023_0_0-edited.xml (18.4 KB)
Also am not sure if this can be fixed, but the device is hardwired to send a CLOCK update hourly (per Aeotec support). From the zniffer this seems to come from Endpoint 1.
However, per the manual (and Aeotec), there is no Clock command class on Endpoint 1, so the Clock offset:1 channel does not work (I believe it is designed to send a Clock SET when the clock is off by 60 seconds). The CLOCK offset on EP 0 does not show a value, however, using the PC Controller I was able to do a “one time” SET on EP 0. What needs to happen for this to work is to take the Endpoint 1 Clock Report and send the Clock SET back on EP 0.
I do not really need an accurate clock on this plug, just in case someone else may need it in the future, I thought I would point it out. The XML above a eliminated the Clock Offset:1 channel as I hoped it would magically know what to do (did not work )