Linear/Utilitech Glassbreak Sensor Setup

Configuration Z-Wave
1

I am moving to HA from Smartthings as I am tired of dealing with Samsungs issues. I realize I am stepping into a different arena of issues but at least they are issues I can have some sort of control over. That being said, After some hassles with a door lock that are now resolved and location services(still cant get google location to function) I am down to my last few sensors which are Utilitech/Linear Glass Break Sensors. https://products.z-wavealliance.org/products/1094 They work great with ST and very rarely had any false positives but test out fine and actually worked well when i broke a photo…so I added one to HA tonight. It shows up in the Zwave List as "Linear Unknown: type=4742, id=3030 and says it is sleeping. Aside from that I get 4 additional bubbles at the top that all report 0. They are

Linear Unknown: type=4742, id=3030 Alarm Level
Linear Unknown: type=4742, id=3030 Alarm Type
Linear Unknown: type=4742, id=3030 General
Linear Unknown: type=4742, id=3030 Indicator

These items never update but if i test the alarm so it trips as though in a real situation I see the below entries in the logs relating to the device.

2018-10-26 18:53:44.807 Detail, Node037, Received: 0x01, 0x0d, 0x00, 0x04, 0x00, 0x25, 0x07, 0x9c, 0x02, 0x25, 0x00, 0xff, 0x00, 0x00, 0x90
2018-10-26 18:53:44.807 Detail,
2018-10-26 18:53:44.807 Detail, Node037, Refreshed Value: old value=0, new value=255, type=byte
2018-10-26 18:53:44.807 Detail, Node037, Changes to this value are not verified
2018-10-26 18:53:44.807 Info, Node037, Received alarm state report from node 37: General = 255
2018-10-26 18:53:44.807 Detail, Node037, Notification: ValueChanged
2018-10-26 18:53:44.868 Detail, Node037, Received: 0x01, 0x0d, 0x00, 0x04, 0x00, 0x25, 0x07, 0x9c, 0x02, 0x25, 0x00, 0x00, 0x00, 0x00, 0x6f
2018-10-26 18:53:44.868 Detail,
2018-10-26 18:53:44.868 Detail, Node037, Refreshed Value: old value=255, new value=0, type=byte
2018-10-26 18:53:44.868 Detail, Node037, Changes to this value are not verified
2018-10-26 18:53:44.868 Info, Node037, Received alarm state report from node 37: General = 0
2018-10-26 18:53:44.869 Detail, Node037, Notification: ValueChanged

Can anyone advise me on how I might get these values to update properly in the interface so I can use the data to trigger an alarm when Im finished setting them up?

Thanks in advance!

2

Those “bubbles” will relate to entities starting sensor. that you’ll find in the <> menu under Developer tools.

One of those will be updating when you test the alarm.

3

it looks like the “general” sensor should be switching between 0 & 255 when the device is triggered.

Look in the states page under the dev-tools section in the sidebar for that sensor as instructed above and see if you find that sensor and see if the value changes.

It also looks like from your zwave log that the sensor doesn’t send the signal for very long so that might be causing some scan time issues on receiving the data correctly or being able to see the state change even if HA actually gets the change in state.

If that’s the case then set up an automation using that sensor that turns on an input_boolean when the value of that sensor equals 255. That might help you catch the change in state.

4

Thanks for the reply @finity you are correct - it was my understanding from the log that that sensor should be updating but alas it does not. If I follow it in the states section the result is the same - never appears to adjust from 0. The device is very quick with reporting the state changes - when triggered its at 255 for about 1 second and then reverts to 0. I tried setting up an input boolean as you suggested but it doesnt seem to catch it either.

In my configuration.yaml:
#Glass Break Dining Room
input_boolean:
glassbreakdr:
name: Notify when glass has broken in the dining room
initial: off
icon: mdi:skull-outline

In my automations.yaml:
#GLASS BREAK DR
- id: Glass Break Dining Room
alias: Glass Break Dining Room
trigger:
platform: state
entity_id: sensor.linear_unknown_type4742_id3030_general_2
to: ‘255’
action:
- service: input_boolean.turn_on
data:
entity_id: input_boolean.glassbreakdr

Im not using input booleans for anything else so maybe I jacked up a setting there as I was piecing that together from what i found online? Any thoughts/guidance are appreciated. Thanks!

5

The only other thing I can think of is that sometimes there is a setting in the zwave config section that changes the report type to send. Maybe look around in there and see if you can modify that setting to maybe send a binary report or something. You will need to look in the specification manual to see what the different options are to change.

6

Did you ever find a solution to this? I am trying to set these up as well.

7

I got these working. When the test button is pressed they will send an update but the state value doesn’t change. If actual glass breaks they update to 255. They were tricky to test. I ended up using some videos of actual glass being poured onto the ground and also gently flicking the unit at the same time to get it to trigger and find the actual reported value.

To improve the experience, I ended up creating binary sensor facades as template sensors like so…

    my_glass_break:
      friendly_name: "My Glass Break"
      value_template: >-
        {% if is_state('sensor.my_glass_break', 255)
           and not is_state('alarm_control_panel.security', 'disarmed') %}
          on
        {% else  %}
          off
        {% endif %}
      device_class: sound
8

Thanks for the info! I am still unable to get these to work. I have been testing by banging a drinking glass with a knife with the sensor right next to it. The red light flashes as if it detected a glass break, but the sensor’s value never changes in HA.

When I look at the z-wave logs, I can see that the value is changing to 255, but it is for less than a second and HA never seems to pick up the change. Are you using OZW-beta or the z-wave integration?

9

I was on the OZW-beta. I’m switching over this week to zwavejs2mqtt or zwavejs (not sure which yet). I’ll let you know how it goes. The sensor value change happens in a split-second. To detect it I suggest creating an automation or something to flip the value of an input_boolean on and leave it that way so you can see it.

1 Like