Ring Glass Break (without ring integration) Not Triggering Automation

Configuration Z-Wave
,
#1

Goal: send Twilio SMS message when Ring glass break sensor (without base station) detects broken glass.

Install: Home Assistant 2022.9.7, Supervisor 2022.09.1, Operating System 9.0, Frontend 20220907.2 - latest. Installed on VMWare Workstation VM.

Similar topics: Ring Glass Break Sensor (without ring integration)

Hardware:
Z-Wave: Running the Aeotech Z-Stick 7 with the latest firmware.
Ring glass break sensor. Battery level 100%.

triggerAction
triggerAction2198×792 68.1 KB

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.

1 Like
#2

Post the automation in YAML format.

Reference: FAQ guideline 11.

#3

automations.yaml

- id: "1664849155844"
  alias: Ring Glass Break Alarm
  description: ""
  trigger:
    - type: unsafe
      platform: device
      device_id: c91094ed372bcf37076513d36f9c953e
      entity_id: binary_sensor.node_4_home_security_intrusion
      domain: binary_sensor
  condition: []
  action:
    - service: shell_command.twilio_sms
      data:
        recipient_number: +##########
        body: Ring glass break in basement went off.
        twilio_number: +##########
  mode: single

Relevant Section of configuration.yaml

shell_command:
  twilio_sms: "/config/helpers/send-sms '{{ recipient_number }}' '{{ body }}' 'twilio_number:{{ twilio_number }}'"

helpers/send-sms:

#!/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}"

I modified this from How to Receive Alerts from Home Assistant with Twilio SMS

#4

Change the Device Trigger to a State Trigger.

  trigger:
    - platform: state
      entity_id: binary_sensor.node_4_home_security_intrusion
      from: 'off'
      to: 'on'

Repeat your current procedure for activating the binary_sensor. Alternately you can force its state to on using Developer Tools > States.

#5

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.

#6

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.

Ring Glass Break Sensor (without ring integration)
#7

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.

#8

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

#9

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.

1 Like
#10

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?

#11

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. :slight_smile:

@unique384 are you following this? You can fix your problem this way.

#12

Im having trouble with this because when I go into the device configuration, all the parameters are greyed out and I can’t change them. Why?

#13

For anyone else suffering from being unable to set the parameter – you can’t do it yet using the base zwave integration has this issue still open: Missing device configuration: <Ring Glass Break Sensor > · Issue #5145 · zwave-js/node-zwave-js · GitHub.

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.

#14

You can use the zwave_js.invoke_cc_api service from HA to manually set configuration parameters that are not known by the driver (Z-Wave JS):

service: zwave_js.invoke_cc_api
data:
  command_class: "112"
  method_name: set
  parameters:
    - parameter: 11
      value: 1
      valueSize: 1

If you are already using Z-Wave JS UI though, it’s arguably easier to manually set config parameters from its control panel UI.

For future reference, you do not need to uninstall the integration (if that’s what you did) nor re-pair your devices when switching from the official Z-Wave JS add-on to the Z-Wave JS UI add-on. The network information is stored on the controller. See the integration docs for instructions on switching: https://www.home-assistant.io/integrations/zwave_js/#how-do-i-switch-between-the-official-z-wave-js-add-on-and-the-z-wave-js-ui-add-on

#15

Great, thanks for this. I should be able to save some battery on this with an automation now.