Ring Contact Sensor Gen 2 - Arm/Disarm and LED Settings?

Good day! I recently acquired a Ring Contact Sensor, Gen 2, and successfully paired it to my Z-Wave network and integrated it into HA. The intrusion sensor is working fine, changing from safe to unsafe and vice-versa when it should, very responsively. I cobbled up a test automation and it triggers just fine.

What I can’t figure out is how to actually set the thing armed vs. disarmed via HA, if it’s even possible. For now, mine is always active. Does anyone know if there is a Z-Wave value that controls this? Some other method? I’d like to create some automations to arm it automatically under certain circumstances, etc.

It would also be nice to have some visual representation of whether it’s armed or not. If anyone has done so, is it possible to tweak the indicator Z-Wave settings, or any other way, to have the LED blink periodically when the sensor is armed?

Thank you for reading, and for any guidance you can provide.

What do you mean exactly? “armed” and “unarmed” are usually a function of the security system (e.g. an alarm panel) and not a sensor. The sensor just reports open and closed.

If you don’t have a real alarm system, you can create one manually in HA and use the armed/not armed status as a condition in your automations. There’s an example at https://www.home-assistant.io/integrations/manual. Or just use an input_boolean.

According to the device DB, the LED Indicator config parameter already defaults to the LED being on when the sensor is active. There is no “arming” capability. You could manually automate that by setting the config param to 0 for off, and 2 for always on. However, note that battery devices don’t respond to commands in a timely manner. It could be hours or days depending on how it’s configured (wake up interval).

I’m sorry, I’m misusing terminology. Perhaps “enabled/disabled” or “active/inactive” would be a better way of putting it. For example, I have some Ring glass break sensors, and for those, I can set config parameter 11 (Enable Detection) to Enable, and the devices will trigger normally upon the sound of glass breaking, or set it to Disable, in which case they won’t. I guess I assumed the contact sensor would have some similar parameter, but I really shouldn’t assume that sort of thing…

I don’t have a real alarm system. That manual alarm control panel page looks pretty daunting, but I could monkey with it sometime when I have some time and frustration threshold to burn. If you feel up to elaborating at all on how the input_boolean could be implemented in this case, I would certainly appreciate it.

Thanks for your insights!

That glass break sensor is a special battery device. It is always listening for commands (at a frequency of 250ms or 1s), so it has the ability to handle configuration changes more quickly. It’s the same as Z-Wave locks. So that probably explains why they implemented such a feature in the glass break sensor, but not the contact sensor.

Just a note: the LED indicator parameter you mentioned, based on my experiments, works by flashing the LED when the sensor changes from safe to unsafe (1, the default), flashing it when the sensor changes from safe to unsafe or from unsafe to safe (2), or neither (0). It doesn’t do an “always on” kind of thing.

Ah, I see. Good to know, thanks.

Probably lots of ways to do this. If you don’t need to disable individual contact sensors, just create a single input_boolean and in the automation check if the boolean is enabled or not. When you want to “arm” them, turn it on. If you need to disable/enable individual devices, I might use labels to indicate which ones are armed.

The manual alarm panel integration allows you to define all of the sensors you want to trigger an alarm. If the panel is armed, then any sensor going on will trigger the alarm. If the alarm is unarmed, then any sensors going on will not trigger anything.

1 Like

Now I get your meaning, and I got a test automation working with the input_boolean as an “if” condition for whether the automation triggers when the sensor is tripped, toggling the input_boolean with another test automation, etc. That should be enough to work with for whatever purposes I need. Thank you very much!

As for the LED, I think it may simply be impossible to get it to do what I’d like it to. C’est la vie.

1 Like