Hi all. I’ve pushed a new version to the development branch that includes the first cut at support for the Ring Smoke & CO Listener. I don’t have one of these devices yet (should be here next week, along with my flood/freeze sensor), but if anyone out there does, and especially if you have some way to test the alarm state (either don’t have professional monitoring or willing to turn it off) it would be much appreciated.
For now this new feature lives only in the development branch as implementing this required significant changes to the core alarm/device setup code and, while I’m pretty confident the changes would have no impact on existing devices as it’s working fine with my setup, I would still feel better to get some results from people that actually have the device and are willing to test. If that doesn’t happen then I’ll test once I get my device next week and merge after that.
The Smoke/CO listener is a single device from a Ring perspective, but it will show up as two separate devices in Home Assistant, one “smoke” and one “gas” class device. To make this work, and so they would still have unique device IDs, I had to make a few changes to the device ID and topic creation logic for these devices. This should have zero impact on HA users and changes nothing about devices that were previously supported, but might be important to understand for those attempting to monitor devices via other MQTT tools, like Node Red, since topics for the listener will have a slightly different format.
Normally, the script creates state/command topics with the following format:
<ring_topic>/alarm/<location_id>/<mqtt_component>/<device_id>/state
<ring_topic>/alarm/<location_id>/<mqtt_component>/<device_id>/command
It uses the ZID from the Ring API as the device_id, which is also leveraged as the unique_id in the HA configuration. Because the listener device has a single ZID with two sensors, I used the sensor class as a suffix to the device_id and also as a subtopic for the sensor state topics, so for example, if the listener has device ID “abcdef” then the device_id for the sensors would be “abcdef_smoke” and “abcdef_gas” and you’d get something like this for your topics:
<ring_topic>/alarm/<location_id>/<mqtt_component>/abcdef/smoke/state
<ring_topic>/alarm/<location_id>/<mqtt_component>/abcdef/gas/state
Once I start adding support for device level attributes, like battery/tamper status, they can still apply at the device topic level while individual sensor state is in the subtopic for the specific sensor.
This seems logical to me, and easy to consume (and code), so I’m hopeful that’s OK, but I’m open to feedback on this.