What works: 1. When I run the automation manually (Actions > Ellipsis Menu > Run) I received a text message with the alert. I.e. the Twilio side works. 2. In the device LogBook I see tamper notifications when I open the device cover. 3. When I press the button on the device, I get a heartbeat notification in the log book.
What doesn’t work: 1. I placed the glass break sensor on a shelf next to my metal trash can, put some glass bottles in the bottom and threw another bottle in the bottom creating a loud crash. Nothing happens on Home Assistant. No entries show up in the Logbook. The automation is not triggered. 2. I played youtube videos of glass breaking with the sensor directly next to the speakers. No affect. 3. Dropping the sensor about 6 inches onto my desk as the youtube videos play.
#!/usr/bin/env bash
#
# Send a message using Twilio SMS
#
# Use curl and bash so we don't have to install any extra
# python libraries into our Home Assistant server.
# First, load our Twilio credentials. Change /config to
# the path to your installation's configuration directory.
conf_d=${conf_d:-/config}
credentials_file=${secrets_f:-$conf_d/twilio-credentials.sh}
# Now we load TWILIO_ACCOUNT_SID and TWILIO_AUTH_TOKEN from $credentials_file
source "$credentials_file"
recipient_number=$1
message_body=$2
exec curl -X POST -d "Body=$message_body" \
-d "From=${TWILIO_NUMBER}" -d "To=${recipient_number}" \
"https://api.twilio.com/2010-04-01/Accounts/${TWILIO_ACCOUNT_SID}/Messages" \
-u "${TWILIO_ACCOUNT_SID}:${TWILIO_AUTH_TOKEN}"
With your change, I get the text when I trigger it manually, through Developer Tools > States, however the alarm doesn’t go off. I am thinking it has to do with the Z-Wave JS Device parameters being incorrect as there is no entry for the glass break sensor listed in the device database. The Ring website says it has to be in “armed” mode in order to sound off, but I am not sure how to set the mode without the app.
The alarm won’t activate because forcing the binary_sensor to on doesn’t influence the physical alarm. However, you have confirmed that the suggested State Trigger is working properly, it triggers the automation and sends a text message.
So now we know the automation is functional and what’s left is to confirm the binary_sensor is receiving information from the physical glass break sensor.
Your testing of the glass break sensor suggests the glass break sensor is either ignoring the sounds you created or it does hear them but the Z-Wave integration doesn’t receive anything from the sensor.
That makes sense. Thanks for your help. I find it hard to believe the break sensor is ignoring all the sounds I am making (breaking physical glass inches away from the device). There could always be something wrong with the device itself but that seems unlikely given that it’s brand new. I guess I don’t know where to go with your second suggestion. HA does receive tamper alarms when I open the device and it also receives a battery status so if the Z-Wave integration is at fault then it would seem to only be for the most essential command (alarm), which could be intentional by Ring.
Glass break sensors listen for very specific frequencies produced by shattered glass. For my old-school glass break sensors (hard-wired to an alarm panel) I can trigger them with a loud, sharp hand-clap (clapping hard enough to sting a bit). The sensor’s three “intensity” LEDs light up and the alarm panel reports the zone is violated (alarm system jargon that the sensor was activated).
For your device, it suggests it’s far more particular about what it wants to hear. (Or something, somewhere, is wrong.)
I just got two of these and am also trying to set them up. I have discovered that these sensors are in a power save mode which tells it to ignore Glass break unless it is armed. Because we are using this with HA… I don’t think alarmo (which is what I am using) tells the sensor that it is armed.
We either have to find a way to change the sensor to turn off power save mode, or to set it to an armed state… Otherwise it doesn’t seem like this will do anything at all.
I don’t have a solution so I’m hoping someone here does.
The ZWA DB shows the device and has a list of config parameters without any documentation as to the possible values. Perhaps parameter 11, “Enable detection”, set to 1 (default 0) will turn on detection?
Hey Freshcoast fancy meeting you here hahaha. I was just dropping by to tell these guys that you solved the problem for me.
Correct, parameter 11 needs to be set to 1 or the sensor is useless. This normally is what gets done on the ring hub when you arm the system or take it out of power save mode. Having it always enabled may kill the battery faster but atleast its working now.
I suppose something could be rigged up, and automation, that changes the parameter from 0 to 1 and then back again when arming or disarming alarmo. That sounds easy enough using that script you showed me… I’ll give it a try.
Only issue is that the sensor doesn’t reflect the value when you look under config… After running the script it still says zero instead of 1…however, unlike before, I’m able to trigger the sensor consistently using a big knife slapping against a frying pan up close to it.
@unique384 are you following this? You can fix your problem this way.
Seems there’s no way that I can tell to override the lack of support in the zwave db used by this lib and just set it to what you want. Trying to do that by manually calling the service just gives you an error.
I had to uninstall zwavejs, install zwave js UI, re-pair the devices with that, edit the config param in the zwave js UI web interface, then I could install zwavejs again but without the supervisor and link it to zwave js UI over websocket. That means my devices are managed by zwave js UI which lets you change params of unknown devices. (previously called zwave2mqtt). All working now.
For anyone with this issue, my solution was what others said, I had to go into the Configuration and Parameter 11, change to ENABLE (this is different from others where they had a value, this must be a newer config option, mine is in words and clear to understand).
The Parameter 11 is designed to save battery life when disabled, so typically in standard Ring Alarm setup with native App, it disables detection when system is not Armed to save battery.
I’m still using the Native Ring App and I have a protection plan. But I’ve constant issues with my Ring Glass Break sensors showing a tamper randomly and constantly, which is ONLY a issue for me when it happens at night and sets off my alarm and I didn’t see a way to disable that feature to not set off alarm if tampered was detected. I’ve even had both my sensors replaced by warranty by Ring, and even the new ones are doing it. Part of me thinks maybe installing them on Ceilings is the issue and somehow gravity is working against it and SOMEhow it slightly lifts off the tamper button to cause a tamper.
So what I did was REMOVE my Glass break sensors from Ring, then include them with Home Assistant. This gave me the control to ONLY trigger my alarm siren for Glass break.
So my setup is when my Ring System (through ring native) but added to HA with Ring to MQTT goes Armed Home or Away, it sets parameter 11 to ENABLE. Then when my System Disarms it sets it to DISABLE to save battery life. I also have both the Glassbreak sensors through HA set to siren my system if Glass break is detected. SO now I have everything I need that will Siren my system if glass break is detected, but not when a Tamper occurs, and I can control the sound detection parameter to save battery when system is not armed.
IF YOU DO NOT HAVE Parameter 11 enabled, it will not detect ANYTHING.
