Support for Aeotec ZWA023 Smart Switch 7

Based on this page, it seems like some other model of the Aeotec Smart Switch 7 is supported (ZWave Thing | openHAB)

However, it seems like this is a different model (ZW175), and doesn’t support the US version (ZWA023). Is anyone working on getting this supported?


The binding uses a community maintained database. Feel free to add is following the guide or we cam assist as needed. Here is the database guide.

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?


Looking more closely between the two, the configuration parameters do look quite different…

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.

Thanks for the context. Is there anyway to hack something in on my end just to get off the ground while I wait for approval to add the device to the database → new zwave binding build?

I’ve never tried, but probably not without forking the repository and re-compiling it yourself.

The device database is part of the binding. It is usually exported to GitHub about once a week and then picked up by the snapshot build process.

It is possible to unpack a binding jar file, add new xml, and repack it but most people just wait and download a snapshot with the database changes.

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)

Any ideas?

Ha! Nevermind, it did get added despite the error. Super confusing

1 Like

Yeah. That error is a pain.

Thanks @youngmit for updating the database. I thought I would give one of these a try. Not sure it is in the current Zwave snapshot, but should be soon. It does look approved. Anyway thanks.


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;

  1. 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)

  2. 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 :unamused:)