You can use the same method above to set your tamper volume to 0. Just get the volume switch ID of switch 2.
1 Like
I have a binary sensor that meets that description also… 
binary_sensor.zw162_doorbell_6_tampering_siren_active
However when the tamper alert is triggered (when i slam the frontdoor a bit door hard) it only triggers the overall binary sensor
binary_sensor.zw162_doorbell_6_browse_siren_active
@freshcoast
Don’t get me wrong i love what the OZW integration is doing already. What for me is the big unknown is how to integrate this with automation. For now i only have sensors and i’m retrieving info.
My usecase for the doorbell 6 is to have a physical alarm sound from my ‘alarm panel’ automation.
There is no ‘device’ that i can set to ‘siren.alarm.active’ so i am guessing i need to dump some kind of action on the MQTT bus, and i am having a hard time getting into that.
Thankfully adamoutler is jumping in with some interesting pointers, so i am diving into that as we speak… 
Trigger the service as mentioned above. Just do it in an automation instead of developer tools.
lol… just playing around with it… and it works like a charm.
If you want digital switches in Hassio you can use this, BTW. Node Red Momentary Switch
I’m using this to create 10 switches for various sounds and set volumes.
While playing around i was looking through the ozw.log and i found a warning that might explain why the tamper alert is not recognized.
I’ve been thinking about this and I believe I came up with a good methodology. If we look at the overall layout I think this is what it looks like… Please examine this graphic.
So we have a tamper tone which is special because it is triggered by a specific condition. The rest (3-9) appear to be pretty much equivalent, regardless of what the OEM intended. Some are labeled doorbell, environmental, or warning… but they’re all just sound switches.
I believe the best way to approach the ZW162 device is to set volume for switch 2 at an appropriate level for tampering warning. Then volumes 3-9 incrementally, so 3 is a low volume tone, and 9 is a high volume tone. Then we play the tone we want through the appropriately volumed switch.
eg. We always set the following volumes upon initialization of routines.
Switch 3 volume=10
Switch 4 volume=20
Switch 5 volume=30
switch 6 volume = 40
switch 7 volume = 60
switch 8 volume = 80
switch 9 volume=100
Now we can simply trigger the tone we choose at an appropriate volume. EG.
Automation routes doorbell to Switch 5
Automation routes notification to switch 3
Automation routes alarm to switch 9
What are your thoughts on this?
In my particular setup, I’m observing binary_sensor.sound_switch_doorbell_1_siren_active changing within lovelace when the tamper alert is triggered.
I see what you are getting at. It is more or less use / abusing the sound switch virtual devices to manage the sound and sound level from HA.
I might do the same once i trust my instance of HA a bit more to always work effectively…
For now my doorbell button and chime work natively without HA to be there. I’m already very happy with the ability to trigger an alarm myself, and for now i am fine to configure from ozw the sound level and push from automation an mqtt sound.
So I made this nice automation here, but apparently if you send “inactive” message 0 to a node which is already inactive, the device won’t respond. The whole system stops working while it waits for a response that never comes. I think the problem is in OZW Beta. I’d like a button or switch to shut the whole darn thing up, but it just wont work because the device wont respond if its already going. I think we need to be able to isolate which one is currently operating and turn it off.
This is how to turn off sounds.
This is my flow and appears to be fully ready for automation as a set of Switches within Home Assistant.
If you want to use it, you can simply configure the Pink node with your username, password, and IP to your MQTT server. Then configure yellow nodes with a proper ValueKeyID, and select a sound for the top group, and set volumes for the bottom right group. Here’s Node Red code. It’s too large to fit in a single post here, so link: https://pastebin.adamoutler.com/ZQEu
Note: This requires OZW and Node Red. and shows up in Home Assistant like this
1 Like
Thanks to the great info in this thread, I was able to finally get my siren (sitting here for over a year) to work. It’s a bit cumbersome to implement the zwave stuff (but implemented it as a subnode in node-red).
I also added the calculation of the config for light / tone duration / tone interval / play count, but that doesn’t seem to work (it’s correctly applying the hex => int conversion, but for example not cutting off the duration). I think these settings will only be used when there is an actual button (associated device) activating the siren?
I haven’t switched to OZW beta yet…
I have two doorbell buttons paired to one doorbell. when either is pressed it plays the same tone and sends the same message to HA so right now it’s impossible to tell which button rang the doorbell.
Once I switch over I’d like to split those tones & messages to be specific to the button pressed.
I assume I can do that by setting different tones in doorbell 1 & doorbell 2 settings?
And do you know how I would go about having the doorbell send different events to HA depending on which doorbell button was pressed?
@finity Yes in the config you can set a different default tone and volume level for three different doorbell devices. So far in the ‘chime’ notification i did not see a distinction between alarm, doorbell or tamper notification.
But maybe when you try it out you will see it… (keeping fingers crossed)
Just a quick and dirty screenshot from the OZW config menu
Thanks for that info.
If I ever get it figured out i’ll report back here.
Hi all.
I have this same device, and whenever I change the configuration values in the OZW beta GUI, it doesn’t actually update.
Sometimes, it appears that the command worked (i.e. I set Tampering Default Tone to “Inactive”) and the device appears to respect the setting, but checking the OZW gui and I still see the previous configuration value.
Refreshing the node does not help.
I try to avoid using Node RED, but I’ll be taking a look at the setup graciously provided to see if we can get it translated into native HA automations.
Thanks all!!
Make sure that you have all the virtual devices installed as well. You can check this by viewing the system values in OZW admin:
I had to exclude / include it a few times before it actually started showing all the (sub)devices. Then you need to check instance 3 (which is doorbell 1) via MQTT and you can start sending commands. I’ve created sub-flows in node-red, but 2 separate calls are needed:
- Set volume
- Play tones
Thanks!
I do have all the sub devices recognized properly.
Poking around in MQTT explorer for the different COMMAND_CLASS_SOUND_SWITCH ClassIDs, it appears that the values aren’t consumed by OZW unless explicitly asked to read it:
{
"Label": "Doorbell 1 Volume",
"Value": 25,
"Units": "",
"ValueSet": true,
"ValuePolled": false,
"ChangeVerified": false,
"Min": 0,
"Max": 255,
"Type": "Byte",
"Instance": 3,
"CommandClass": "COMMAND_CLASS_SOUND_SWITCH",
"Index": 2,
"Node": 12,
"Genre": "Config",
"Help": "The Volume to play the tone at",
"ValueIDKey": 562950165119025,
"ReadOnly": false,
"WriteOnly": false,
"Event": "valueRefreshed",
"TimeStamp": 1601038507
}
So it seems whatever I implement should set the values, say, on start up, so they are in a known state and can be tracked.
But I can clearly now why we need to implement a new device class in Home Assistant to handle these types of devices.
New platform for siren/chime devices · Issue #375 · home-assistant/architecture (github.com)
My current plan is to implement Home Assistant entities for the controls I need, and configure automations to fire either the correct zwave service call or MQTT command to trigger OpenZWave 1.6 beta to set the desired configuration.
The next step is to figure out how to fire the Zwave Events to trigger the siren to make a sound, but I think that must be done with MQTT and not the hass zwave service, since I don’t believe it supports that.
To trigger the sounds please check the message of adamoutler of 11 days back. He added many screenshots of Mqtt messages, and they actually work.