Ring Device integration via MQTT w/ Video Streaming

Yeah, I’m not sure if test events will register or not honestly. I’m guessing if it doesn’t show up as an event in the Ring app it’s not going to get sent as an event in my code either. I was thinking I’d have to actually trip one of them with actual smoke and then hope the fire dept doesn’t show up, well, once I get one that is.

I’m pretty sure, although I guess not 100% sure, that the state code should work. To perform the testing on that part of the code I did a little hack to make it think a motion sensor was a fire alarm and the status code worked, but without having a actual device it’s very difficult to test for real. I should have a device within the next few weeks.

Since I’m not really getting any negative feedback I’ll probably merge the code in another day or two.

I’m sure the wife wouldn’t like for the Fire Dept to show up… lol. Since I’m not getting errors and it’s visible in HASS, I’d say it’s good to go.

Hi –

Thanks for putting this together. I am a total newbie admittedly in HASSIO. I installed your add-on, based on the logs, it appears to be working as it is pulling in the names of my Ring sensors.

Unfortunately, I have no idea how to use MQTT — I left the user/pass blank per your default config. There are no additional entities related to the Ring in my system even after restarting.

I did add the following in my yaml file:

mqtt:
broker: 127.0.0.1
discovery: true
discovery_prefix: homeassistant
birth_message:
topic: ‘hass/status’
payload: ‘online’
qos: 0
retain: false

Any help / assistance greatly appreciated, this add-on is great!

I’m afraid I don’t know anything about HASSIO so hopefully someone else can chime in on the specifics for it. I personally just run mosquitto installed locally and configure the HA MQTT component and the script to connect to it.

No worries, thanks very much for responding. I’m excited to get this working, in HASSIO the plugin appears to be pulling the correct data, I have an MQTT service installed, what is a little confusing to me is the configuration / tie-in between the two.

In my ring plugin configuration I have the following:

{
“host”: “localhost”,
“port”: 1883,
“ring_topic”: “ring”,
“hass_topic”: “hass/status”,
“mqtt_user”: “my-mqtt-username”,
“mqtt_pass”: “my-mqtt-pass”,
“ring_user”: “my-ring-login”,
“ring_pass”: “my-ring-password”
}

I have seen various help docs that say you should use ‘localhost’,‘192.168.1.X’ (my actual Pi IP), ‘127.0.0.1’ … unclear to me what is correct.

In my configuration.yaml I have the following:

mqtt:
broker: 127.0.0.1
port: 1883
discovery: true
username: my-mqtt-username
password: my-mqtt-pass

I’ve tried a few combinations of the IP/broker variables, can’t seem to get them to tie together, probably something obvious. Each on their own based on the logs they appear to be working, but, nothing is showing up as entities.

Thanks again, I hope that helps clarify my question.

I did a quick install of HASSIO in a VM today and this is what I did to get it working:

  1. Install Mosquitto broker from official add-on store, modified the config with a username/password like so:
{
  "logins": [
    {
      "username": "mqttuser",
      "password": "mqttpw"
    }
  ],
  "anonymous": false,
  "customize": {
    "active": false,
    "folder": "mosquitto"
  },
  "certfile": "fullchain.pem",
  "keyfile": "privkey.pem"
}
  1. Installed the Ring alarm hassio integration from @rajansub above. Used the following configuration (for IP address I used the actual ethernet IP):
{
  "host": "<ethernet_ip_address>",
  "port": 1883,
  "ring_topic": "ring",
  "hass_topic": "hass/status",
  "mqtt_user": "mqttuser",
  "mqtt_pass": "mqttpw",
  "ring_user": "<ring_email>",
  "ring_pass": "<ring_password>"
} 
  1. Edited the configuration.yaml and added the following:
mqtt:
  broker: 127.0.0.1
  username: mqttuser
  password: mqttpw
  discovery: true
  discovery_prefix: homeassistant
  birth_message:
    topic: 'hass/status'
    payload: 'online'
    qos: 0
    retain: false

That’s it, with that, entities showed up automatically.

1 Like

Also, I have merged the lock_support branch into the master branch so support for locks and First Alert Smoke/CO detector is live for all.

1 Like

Sweet. I just rebuilt the HASSIO plungin and the two smokes showed right up.

You sir, are awesome. Followed this and managed to get it working. Thanks very much!

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.