Ring Device integration via MQTT w/ Video Streaming

how do you “start” the script? i downloaded it from git, ran the npm install and configured my ring account/mqtt, but where do you start it?

From terminal- ./ring-alarm-mqtt.js

Would there be any way to get battery levels, like from the first alerts?

I do plan to add battery level and tamper status in the future, but it will probably be at least a few weeks before I get to work on that. I think it should be easy to return that data as extra attributes using json attributes topic, but I’ve not even attempted it yet.

1 Like

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.

1 Like

I don’t have the listener, I do have a dome flood sensor. Haven’t imported it into ring yet, not sure if it work with the ring system. I’ll give it a try and try your development code.

One more update pushed to development branch for today. This update adds support for battery and tamper status reporting on each device. These values are reported via a JSON attribute topic and appear automatically in the UI when you click on the device.

For now I’m not adding any sensors for these attributes, but it should be easy enough to build some automations using these if you want to build alerts, or you can easily use a template to build your own sensors. I’m open to suggestions on how to handle this better, but for now just surfacing the data seemed like a good start. If anyone is interested in testing battery/tamper status, let me know how it works.

1 Like

I definitely wouldn’t expect the Dome flood sensor to work as the code has no support for generic Z-wave devices at this time.

I do have a Ring flood/freeze sensor on order that should be in next week so when it comes in I’ll add support for it, although it seems the API doesn’t even have support for it right now so it might take a little while.

is this supposed to be started after a home-assistant reboot? i rebooted my home-assistant and it did not trigger anything, also my motion sensors don’t appear to be showing movement

current feature:

  • Monitors websocket connection to each alarm and sets reachability status of socket is unavailable, resends device state when connection is established

No, the websocket monitor feature watches the connection to Ring servers and, if it goes down for any reason (internet connection, Ring servers, etc), reports the status as UNAVAILABLE to all devices associated with that socket so you get indication in Home Assistant when devices aren’t getting state, you can even setup alerts for this event.

The script does have the ability to monitor for home-assistant restarts, however, only if you followed the instructions in the readme to configure MQTT birth messages for Home Assistant (just adding a few lines to your configuration.yaml). If you don’t follow these instructions and perform this extra config then there’s no way for the script to know that Home Assistant restarted, so you’ll have to manualyl restart the script, but with birth messages configured, Home Assistant will send an “online” message via MQTT. The script monitors for this messages, and re-sends the config/state data 60 seconds after it sees Home Assistant come online (it waits 60 seconds because I’ve seen issues with sending config/state too quickly that HA isn’t ready for it).

Regarding motion sensors, if you’re seeing the state change in the Ring app, but not in Home Assistant, that’s pretty weird and it’s difficult for me to see how this might happen as motion sensor support has been in the script for quite a while now and I’ve never had any reports of issues with them and I use them for a lot of light automations around my house and they’ve been rock solid. I’d suggest running the script in debug mode and seeing if you get any output on state changes.

BTW, what do you mean by “reboot Home Assistant”, did you reboot the entire system, or are you just restarting Home Assistant? More details of your setup would help.

I am attempting to use the add on by @rajansub, and following how @tsightler said he got it working. MQTT is set up already, and working with other devices. @rajansub add on installs and starts fine. I see all my Ring devices in the log, however they are not showing in the UI. However in home-assistant.log there is this line:

9-03-17 18:34:13 WARNING (MainThread) [homeassistant.components.mqtt] Data in your config entry is going to override your configuration.yaml: {'broker': 'core-mosquitto', 'discovery': False, 'password': 'PsjgP5zNHJrw3Tmfl0uFByZbH1_EndIm', 'port': 1883, 'protocol': '3.1.1', 'username': 'homeassistant'}

I have no idea where this info is, nor how to fix it.

Thoughts?

I really don’t know a lot about Hass.io, but those settings look to me like they are from the embedded HBMQTT broker (the protocol 3.1.1 is a givaway). Are you attempting to use the mosquitto broker from the addon store or the embedded broker? Do you have any lines with “embedded” in your configration.yaml? My install of Hass.io above way brand new and I just outlined the steps I took. Hopefully somebody that knows more about Hass.io will provide some suggestions.

1 Like

I am using the Mosquitto broker from the addon store: https://www.home-assistant.io/addons/mosquitto/

No lines with embedded: anywhere, as far as I know.

This is a fairly new install. Migrating from a RPi to a NUC. I am not even aware of the embedded broker. Anyone know how to disable this?

I figured it out. I removed the mqtt integration from my Configuration - Integration, then I rentered my MQTT info under ‘Set up a new integration’ - MQTT. Removed the configuration.yaml entry and restarted making sure Enable Discovery was ticked. Upon restart, the Ring devices appeared in the MQTT section in Configuration - Integration. After a few moments, they also appeared in Unused entities.

It does seem that after a restart of hass.io I have to manually restart the Ring integration add on before the devices show again.

I think it’s because you used the GUI to setup MQTT rather than just deleting it and manually adding the required MQTT lines to the configuration.yaml file. The GUI settings for MQTT don’t provide an option for configuring the MQTT birth message, and without the MQTT birth message the script has no way to know that it needs to resend the data.

I suppose I could do something hackish like send the data twice on initial startup, once immediately and again after 60 seconds, but, without the birth message configuration, it would still lose the devices if you restart Home Assistant without rebooting.

What I did in my example above was simply not use the “Setup a new integration” setting at all, but rather left it unconfigured there, and manually added the mqtt lines to configuration.yaml. This seemed to work just fine and devices will show up on restart because birth messages are configured. I do wonder if you can add “additional” options to configuraiton.yaml as long as you don’t try to duplicate existing options.

I’ll try to play more with Hass.io when I get a chance, I just don’t use it so it’s hard for me to understand.

I removed the GUI integration, and added directly to configuration.yaml, and that does not work at all for me. None of my mqtt devices are seen, including Ring. The logs for the Ring add on indicate it’s working, and has discovered the devices, but they do not show in HA. Also, this error message in the logs:
homeassistant.exceptions.HomeAssistantError: Error talking to MQTT: The client is not currently connected.

I also tried just adding the birth message section in configuration.yaml, but that also broke it.

It seems hass.io needs to have that integration…I really don’t know why that worked for you. I copied what you did exactly.

Odd.

Like I said, I’ll play around with it. I literally just stood up Hass.io and performed the steps as outlined above, that’s it. As a guy that’s been using Unix/Linux systems for a few decades, I find Hass.io to be confusing because, instead of having a single place to do things (configuration.yaml), you end up with two places to do everything (web ui and configuraiton.yaml for stuff you can’t do in the web UI). I really don’t understand the interaction between the two configs right now, but I’m sure it’s not that complex. It’s just difficult for me to assist as I only understand the operation of my script, which seems to be working just fine.

I understand. I was just giving you an update. I am playing around with it as well. I don’t understand the reasoning for the gui vs. yaml config. I assume to make it simpler for the less technical to use.

I am attempting what this thread suggests, and it’s still not working correctly. I will continue to investigate as well.