Indoor Siren 6 and Doorbell 6 ZW164 from Aeotec still difficulties to set to work

Based on the information documented for Z-Wave Bindings I acquired almost a year ago an Indoor Siren (and doorbell) from Aeotec as a good and effective signaling system. I was a bit surprised that after installing it, I could only read the status of several channels, but I’m not able (with my limited knowledge) to control the siren which is obviously the main task of an Siren / doorbell.

During last year I’ve seen some discussions on the Siren and one member trying to solve the control with a local update but not integrated (yet) in the standard solution. I could not get this in a working state (which has purely to do with my limited knowledge).

Also in the discussions was mentioned that we are missing an important command (COMMAND_CLASS_SOUND_SWITCH) and that when we have added this the siren could be used.

I’m currently using Openhab 3.1 with compatible bindings but still I do not see any handle to operate (control) the siren.

What I would expect when the siren is included in the openhab system:

  • the siren 6 is a collection of 8 (9) nodes

  • which can be controlled and configured separately (sound, timing, licht).

    • with an internal control (‘hardware’) that only the most important signal is sounded.(when more than one ‘alarm’ is initiated at the same time).
  • Per node, the siren can select a sound (out of 30) from an internal table which can (also) be selected by the z-wave commands

However I do see only one node in the current (and previous) openhab implementation (however I did see 9 nodes on a certain moment in between upgrades, but perhaps I had a bad dream :slight_smile: ) and as far as I understand all channels are read only.

As I can control the siren via ‘z-wave PC-controler’ software on my PC (where you can see the channels as sub channels), which does show me and proves loudly that my siren is in perfect working condition, however not controllable via openhab (I do hope that I’m wrong, please correct me if so).

Hopefully above message can help to add the siren 6 as a fully operational node(s),

Kind regards

Rudi Tholen

Known Issue. you may want to subscribe to this Issue.

In the same boat - $60 bucks wasting away for the past 8 months. I assume COMMAND_CLASS_SOUND_SWITCH is part of the ZWave spec so I’ll scratch my head. The biggest issue I have is the ZWave binding database still claims this device is fully supported - no effort made to clean up the DB to warn any others that they will be throwing $$ away.

I agree, it’s disappointing that the people who own ZW164 devices and are familiar with this issue haven’t contributed updates to the volunteer-curated database to note this problem. Feel free to change that. :wink:

Could not agree more given issue 1245 (Add support for COMMAND_CLASS_SOUND_SWITCH · Issue #1245 · openhab/org.openhab.binding.zwave · GitHub) was opened in October 2019 and people - including myself 8 months ago - are still buying the product based on that db.

So, does that mean you’re going to submit a database update?

1 Like

In that GitHub issue, there is a user-customized version referenced that apparently implements the missing functionality.

One other alternative that I’ve gone to is to actually switch from the built-in Z-Wave binding to using zwave2mqtt instead. This takes the Z-Wave integration completely out of OpenHAB into a separate service. It takes a lot more manual configuration on the OpenHAB side (have to setup the MQTT binding and all the things and their channels). However I’ve found that in general it’s been nice to have the Z-Wave handling abstracted out of OpenHAB as it’s afforded me some other benefits like being able to run OpenHAB 2 and OpenHAB 3 in parallel with the same Z-Wave network using a single Z-Wave USB stick.

zwave2mqtt uses OpenZWave, and I have to note that even on that side the ZW164 handling is not perfect (there is some bug with some of the tone names becoming corrupted when using encryption). I think even they only recently got support for the sound switch command class too (within the last year or so only), so overall the open source Z-Wave community has not had support for this device until recently.

Nevertheless, zwave2mqtt is a working alternative that I’ve found if you are not comfortable building your own custom version of the OpenHAB Z-Wave binding with the interim sound switch support (I suppose there is still no word when official support will come).

Edit: Below is a sample MQTT Binding thing and channel configuration for using the ZW164 through zwave2mqtt to give an idea of what type of configuration is required to create a switch in OpenHAB that will toggle the door bell sound through zwave2mqtt:

Bridge mqtt:broker:eclipse-mosquitto [ host="mqtt-host", secure=false, username="MyUserName", password="MyPassword" ] {
  Thing topic zwave2mqtt_Siren "zwave2mqtt Aeotec Siren" @ "My Home" {
      Type switch: BrowseChannel_DoorBell [
        on="01 Ding Dong (5 sec)",
        transformationOutPattern="JSONPATH:$.value"  ]

Hi rpwong, sorry if I did something wrong. As when I read in your link (above mentioned) in the last line of the database guide:

  • “If you have problems, or want to discuss something about the device, please open a thread on the openHAB community forum.”

So what can we do next to expedite a next step in a solution?
And I’m really willing to help if possible.

Kind Regard
Rudi Tholen

The issue is not the database, but changes that need to be made in the binding. This happens to be my first entry in the database and it was a BIG one.

Chris has been extremely busy and, I do not believe, he has a device for testing any binding changes.

Ashley, this is an intriguing alternative. As I’m also considering upgrading to OH 3.0 in the near future, it does appear to offer other flexibilities.

Do you have examples of any of the other nine channels - especially being able to control the volume of the alarm and separate tones? Could you possibly post them, if so? Would like to get a feel for what’s still needed to be done to configure them and then I could be of additional help for those other channels as my experimentation continues.

@jczuprynski , most of the configuration can be done through zwave2mqtt’s web interface. Configuration works very similar to how the OpenHAB Z-Wave binding works - once the interview of the device has been completed, zwave2mqtt matches it up to its own database of Z-Wave devices so that you can perform configuration from its web interface. Each configuration parameter also has a topic string next to it that you could use from an MQTT client if you wanted.

Here is the screenshot from the volume configuration for the Siren6 in zwave2mqtt, for example:

As I alluded to before, not everything is perfect. There is some kind of off-by-one error with the channels so the names don’t match up. In my setup you’ll see that “Doorbell 1” has a volume of 0, but that is actually the “Tampering” volume. I had tried to understand the ZW164 channels, and it seems that there is a slight difference in the offset of the channels vs group associations (I’m not sure if I’m using the right term).

The numbers you see in parentheses, (e.g. 8-121-1-2) matches with what the MQTT topic would be for that value. You would use that as the basis for setting up a channel in the OpenHAB MQTT Binding (referring to the zwave2mqtt documentation to understand how to construct the specific topic). I’ve found that one easy way to find out the topics is to subscribe to everything in the MQTT Broker and making changes or toggling devices and observing what topic zwave2mqtt used to publish each method. I then copied the ones I wanted to use as the basis for my MQTT binding setup.

You also have to figure out how to transform the values to the correct OpenHAB states, so it takes some testing/trial and error.

Recently I’ve also been migrating to zwavejs2mqtt, which I think may be the author’s successor to zwave2mqtt; it uses yet another Z-Wave library, which is JavaScript-based… through all this I’ve come to appreciate how complex and difficult it is for developers working on open source Z-Wave stacks - there’s definitely pros/cons of each library and neither are perfect!

The topics in zwavejs2mqtt are slightly different than zwave2mqtt, and I haven’t tested getting the Siren6 up and running there yet, but I think the idea is the same.

Right, I just meant that if someone is going to be annoyed that the database entry doesn’t have a note about the binding issues, they are more than welcome to add one to the database description. :wink:

1 Like

@acee, how did you install ZWave2MQTT - using a Docker container, or other method? I presume you are running on a Raspberry Pi configuration, so it’d be helpful if you could point us in the right direction for easiest / most reliable installation method. Of course I’ve already looked at the github for this, (GitHub - OpenZWave/Zwave2Mqtt: Fully configurable Zwave to MQTT gateway and Control Panel using NodeJS and Vue), but interested what method you chose.

I am using Docker, inside a Hyper-V Linux virtual machine. Originally I ran it directly in the Linux VM because I couldn’t figure out how to share the Z-Wave USB stick with a Docker container due to my setup being inside Hyper-V, but once I figured that out I switched to using Docker. I’m now also looking to run OpenHAB itself in Docker as I’ve found it’s a lot easier to upgrade versions without worrying about software dependencies (I had some issues in the past with Java versions getting messed up).

So in my opinion, Docker is the easiest way to get it up and running.

If you are using a Raspberry PI (or otherwise running the docker host directly on your hardware), you should be able to use the docker compose file the author provided more-or-less directly assuming your Z-Wave USB device is at /dev/ttyACM0

You will also need to setup your own mqtt broker, which I am also using Docker for.

You can switch between the regular OpenHAB Z-Wave binding and some other Z-Wave software like zwave2mqtt easily - just record your Z-Wave network key if you are using encryption and enter it into the other software’s configuration. You can only have one software accessing the Z-Wave stick at the same time, so with OpenHAB you can temporarily stop the Z-Wave binding or shutdown OpenHAB altogether. The new software will need to complete its own interview of the devices stored in your Z-Wave stick, which would require you to wake up all your battery devices.

As I have initiated this discussion to create awareness and hoping for a solution to get the siren operational in OpenHab I have entered it also as a request for change on the database. This request was however directly closed with the remark that it is not the database but the binding and that the database is also used by other apps,

However (with my limited knowledge) I can not see nor understand how the siren is working based on the entries in the database, as it appears to me as a read only device (except for the configuration). A Siren is an Item that should be able to be controlled of course. Also I’m missing the ‘sub’ devices in the database as mentioned in the manual and visualized (and operational) in the ‘Z-Wave PC Controller’ software.

In recap:

  1. That the Binding does not support this also, seems to me clear as in the database, no ports to write to the device are defined to start the sound or alarm (but who am I to judge and really I’m still hoping I’m wrong!)

  2. What I’m missing also a bit, in The Z-Wave Binding is an option where one can set,:send or read (and perhaps as a temporary solution) different z-wave codes. This could be an opening for all new z-wave codes / items. And when these codes are well tested they could be an integral part of (a new version of) the Binding.

As my memory card (the third already) from my Pi is showing problems, I’m not sure, if at this moment I’m on the correct path.

It has been real fun to work with OpenHab and the Pi, it did give me a lot of pleasure and learnings and being extremely impressed by all the work done by all members!

However I have really to rethink my options

Discussion closed?

Kind Regard

Rudi Tholen

This is correct. The binding does not support this function at the moment. Until this is implemented, the database simply cannot have the features added since it must first be implemented in the binding.

Hi Chris,Thank you for you answer,

It’s a pity we are not yet closer to a solution yet. I do understand that you are very busy, as the topic is over a year old, Please consider the solution, I suggested above (to add an interface that we can ‘program’/send the ‘Z-Wave’ commands). In that way even we can help you to come closer to a correct solution.

As an example I like to point us to the Homey Community ( board as this shows that someone called Ragnar (Ragnar Ekker) could temporarily solve this with adding straight Z-Wave commands before official implementation. Perhaps we can learn from it, so we all can be more diligent after the introduction of new and perhaps more complicated z-wave items and perhaps we can then stop complaining over missing functionality but adding solutions to the project even if we are no programmers :slight_smile:

Kind Regards
Rudi Tholen

This is quite a lot of work, and is IMHO not a very usable idea. Sure - it’s fine to allow technical people to hack something together, but it isn’t really something the masses can use. To add this would just take away more time, and really isn’t something that is used very often.

I’m not sure I understand? So this option would provide you a system to code new features - but you make out like that is not available now? You have full access to the source code, so you can also do this right now.

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.