Anyone have experience with this and node red? I’d like to buy it and use it for various purposes (doorbell, chime, etc…) through node red automatons. Not sure how to set it up and select different chimes/tones through node red.
Hi,
OZW 1.4 and this doorbell do not play well with each other. Especially if added Securely. Aeotec adopted some parts of the z-wave spec that were optional previously and OZW 1.4 doesn’t support it.
Plus things like the SoundSwitch CommandClass etc are not supported in 1.4. I would suspect your going to have troubles with this device till HASS can upgrade to 1.6.
1 Like
What kind of troubles?
I paired it a week ago and it seems to be working ok using the event generated on a button press in an automation.
I haven’t tried to do anything more than that yet.
I also managed to get Siren6 somewhat working, though in a manner that’s wholly unsatisfactory.
I don’t have the Aeotec doorbell button, just Siren6. I’ve put it in an association group that gets a basic report from an Ecolink door/window sensor monitoring a classic electro-mechnical doorbell button.
As I understand it (and I don’t), either the basic report is being mapped to trigger a SOUND_SWITCH_TONE_PLAY_REPORT command internally or the report is tickling the siren’s notification behavior (per sections 4.4 or 4.9.3 in Aeotec’s engineering docs, respectively). In my case, it happens to play a doorbell-esque sound.
However, this is a hack. I don’t know how (and, from what I can tell, assume it’s not possible) to have the ecolink sensor send arbitrary values to play different tones. I also haven’t been able to figure out how to change the tone that gets played or the volume for the various endpoints without proper support for COMMAND_CLASS_SOUND_SWITCH in homeassistant_pyozw and HA’s zwave platform. I can’t list the available tones or configure which tone is used for each endpoint without that support, at least directly from HA. Most importantly, I can’t disable the tone for endpoint 2 (tampering) so I can’t even handle the device for testing without earplugs.
I would like for HA to have support for “sound switch” devices similar to zwave.switch so one can send arbitrary “Sound Switch Tone Play Set” commands with full tone ID and volume parameters at will to the device from HA per section 4.95 in the zwave application command class spec. This support should extend HA’s config/discovery to be aware of the available tones, and expose sound switch endpoints as momentary or toggle switch entities in HA as appropriate.
I don’t think it’s reasonable to make dramatic feature requests of an open-source project without offering to help implement them. I’m a competent developer in python, C, and C++ so I pulled @fishwaldo’s OZW 1.6, pyozw and homeassistant_pyozw, and started digging into HA itself to see
- what (if anything) is missing in OZW 1.6 (which already supports
COMMAND_CLASS_SOUND_SWITCHand this siren’s specific AV device type - what needs to be done to support
OZW 1.6in HA (major parts of which are already underway- I’m on the verge of setting up another zwave network with just the siren and a couple nodes I’m no-longer using on it to test this python_openzwave PR outside of HA) - and how difficult it would be to add a
zwave.media_player/zwave.sound/zwave.sound_switchplatform or extendzwave.switchto support sound switches.
However, I’m very new to working with zwave at such a low level and do not yet comfortably understand the HA zwave platform code. I also don’t have a lot of free time to work on this. There are a lot of contributors to the zwave component in HA and it’s not yet clear to me if there is a lead point-of-contact, who all the home-assistant/z-wave codeowners are, and what issues are already being worked on. So without some initial guidance and new open dialogs with active developers, it will be some time before I’ll be able to make any headway on my own.
3 Likes
Hi, there.
Great first post!
Thanks for all of the information and the willingness to help.
issues you will encounter on 1.4:
- Not all commandclasses on each endpoint are exposed when included securely.
- No way to identify From which endpoint a notification (Alarm) came from. (so you cant see if its doorbell 1, 2 etc etc
- No way to trigger/configure the soundswitch, which selects what tones to play on what events etc.
@matterhorn OZW 1.6 should fully support this natively. You can test with OZWCP (native or via the docker image). The Python Wrapper is in progress with changes to support 1.6, and I don’t think anything has happened on the HASS side for 1.6 yet as its dependent on the python wrapper being updated.
2 Likes
FWIW I made a video fo how I kind of got it working. It has limitations but it works for me.
1 Like
It’s a nice video but I think that doing all of the calculations with time and last changed is more complicated than simply using the zwave event generated when the button is pushed.
Is there some reason I’m missing that you don’t want to use the example automation that I posted above?
Also, how many doorbells do you have?
I’m going to assume you only have one and if that’s true then you somehow have a whole bunch of entities that erroneously got created.
You said that the alarm_level entity you are using is the “sensor.aeotec_limited_zw162_doorbell_6_alarm_level_9”? If so then that means that it created eight other entities before that one from the same device. And it looks like it did the same for all of the other entities usually associated with the device (sensor.aeotec_limited_zw162_doorbell_6_alarm_type, sensor.aeotec_limited_zw162_doorbell_6_burglar, sensor.aeotec_limited_zw162_doorbell_6_power_management, sensor.aeotec_limited_zw162_doorbell_6_sourcenodeid, etc). So now you have over 45 entities existing for the same device.
By contrast, I only have seven entities in total from my one doorbell device.
I think it is safe to say that you can safely remove all of those extraneous entities by deleting them from the entity registry.
Worked a treat thank you, I added more automation when basic_level is 0 to turn the Boolean off again.
I just need to work out why the siren unit is now flashing white every 5or6 seconds?
Edit: reseat the button battery stopped the flash.
yeah, the periodic flashing usually means a battery “fault” on the pushbutton.
I’ve had to replace my battery already. Hopefully it was just because the battery from the factory was crap and it’s not an indication of typical battery life. I’ve only had it for a few months now.
Didn’t like the double trigger on this, ok so in your case nodered can handle it but the basic_level as shown by finity above gets a notification for doorbell on (basic_level =255) and off (basic_level =0) and you can act on one or both as desired. Thanks anyway.
Has any of the functionality of this doorbell improved with the 0.100.x updates?
no. and it likely won’t for a while.
the version of Open Zwave needs to be updated in HA first. But that entails that an updated version of Python-openzwave needs to be available to even start on implementing it in HA.
The last I looked python-openzwave wasn’t completed yet.
1 Like
Ok. Thanks!
The functionality of my SmartThings multi sensor improved with this update, and I swore the changelog said something about improving sirens, and just kinda hoped, but I guess I’ll go back to waiting. (Or kludge a different solution together entirely. 
)
this is all I could find about sirens in the change log and it’s for ZHA (Zigbee):
is that what you saw?
Yup… and I now just realized… that’s ZHA, not ZWave. 
I need a few more cups of coffee or something… 
1 Like
Have anyone managed to disable the tampering alarm and/or picked which tone and volume the button is supposed to trigger?
I’m no expert but I think that won’t be possible until OZW 1.6.
I got the doorbell 6 on Wednesday and I have not been able to configure it through HA. I contacted Aeotec who also said that it can’t be done in HA until OZW 1.6 is available. There is some Windows software that they suggested I use but I run HA on a Raspberry Pi 4 so I currently have no way of configuring the doorbell.
It is sat in the box not being used as the default volume is enough to cause a local earthquake! Not great from Aeotec in my opinion - why make a consumer product that the consumer cannot easily configure?!
Not really Aeotecs fault really. The new zwave integration (with ozw 1.6) is in development and since one of the devs have a doorbell I expect it to be testable pretty soon.