Ring Device integration via MQTT w/ Video Streaming

InstigatorX · March 9, 2019, 7:59pm

Line 82 - commented out deviceClass: ‘None’,
Line 124 - changed to if (component === ‘alarm_control_panel’ || component === ‘lock’) {

Auto-Discovery works for locks.

I can get locks to appear by manually configure them. Getting tracebacks in log when trying to auto discover.

Traceback (most recent call last):
File “/usr/local/lib/python3.7/site-packages/homeassistant/components/mqtt/lock.py”, line 62, in async_discover
config = PLATFORM_SCHEMA(discovery_payload)
File “/usr/local/lib/python3.7/site-packages/homeassistant/helpers/config_validation.py”, line 655, in call
validated = super().call(data)
File “/usr/local/lib/python3.7/site-packages/voluptuous/schema_builder.py”, line 267, in call
return self._compiled([], data)
File “/usr/local/lib/python3.7/site-packages/voluptuous/schema_builder.py”, line 589, in validate_dict
return base_validate(path, iteritems(data), out)
File “/usr/local/lib/python3.7/site-packages/voluptuous/schema_builder.py”, line 427, in validate_mapping
raise er.MultipleInvalid(errors)
voluptuous.error.MultipleInvalid: required key not provided @ data[‘command_topic’]

Traceback (most recent call last):
File “/usr/local/lib/python3.7/site-packages/homeassistant/helpers/config_validation.py”, line 643, in call
return super().call(data)
File “/usr/local/lib/python3.7/site-packages/voluptuous/schema_builder.py”, line 267, in call
return self._compiled([], data)
File “/usr/local/lib/python3.7/site-packages/voluptuous/schema_builder.py”, line 589, in validate_dict
return base_validate(path, iteritems(data), out)
File “/usr/local/lib/python3.7/site-packages/voluptuous/schema_builder.py”, line 427, in validate_mapping
raise er.MultipleInvalid(errors)
voluptuous.error.MultipleInvalid: extra keys not allowed @ data[‘device_class’]

tsightler · March 9, 2019, 9:06pm

Are you on .89 by chance? The device_class stuff is really only needed for binary_sensors but was previously ignored if you used it on components that didn’t need it. However, in .88 they started warning about it and said they would be rejected in future versions so I’m thinking that might be it. I’ll look at it later tonight.

To be clear, are you saying that with manual configuration the locks show up and you get proper state?

tsightler · March 9, 2019, 10:15pm

I see the issue, the command topic is a required parameter for the MQTT lock component, but I haven’t actually implemented a command topic for locks yet so of course that failed. Somehow I missed that this was a required parameter and assumed it would be possible to just monitor lock state with a state topic. Your quick changes basically give it a state topic that won’t actually do anything, but that’s OK, at least it proves the overall concept seem sounds and device detection is working.

I’ve got some other cleanups I’ve been working on so I’ll try to fix this and maybe code up something to attempt to actually set the lock state.

tsightler · March 10, 2019, 12:38am

For anyone wanting to test lock support I have pushed a new version to the lock_support branch on github. It makes some changes to how supported devices are handled which should address the device_class issue and it also adds a command topic for locks so hopefully auto discovery of locks will work correctly.

I’ve also attempted to implement the ability to control locks. Since I don’t actually have a lock this is a complete and total stab in the dark based on the code that dgreif uses in his homebridge code. He’s obviously a far more skilled coder than I am, so I’m not at all sure I used this code correctly, but it seemed pretty straightforward. I simulated calls to the function but without a lock I have no idea if Ring actually did anything with the commands I sent. It seemed to work, at least, I didn’t get errors, but if someone could give it a spin and let me know what behavior they see I would appreciate it.

These changes should also make it easier for me to add new devices so, assuming I didn’t break anything too horribly, I’m going to try to add fire/co2/listener support in the next few days.

perryw · March 10, 2019, 1:52am

I installed this a little bit ago and it’s working fine so far.

motoolfan · March 10, 2019, 3:15am

.51 is working great, thanks for the addon.

dambrosioj · March 10, 2019, 4:20am

The locked showed up great! and unlock/lock work. Amazing!

tsightler · March 10, 2019, 4:41am

Thanks a lot for testing the lock capability, I’m pretty amazed that it worked! I’ll probably let all of these changes settle for a few days to make sure I don’t get any critical issues, then merge the code into the main branch and work on adding flood/smoke/co2 device support, those should be pretty easy with the new changes.

I appreciate the suggestion to include lock support, I didn’t even know it was possible to integrate locks with the Ring alarm before you brought it up.

tsightler · March 10, 2019, 3:44pm

I have pushed additional code to the lock_support branch that attempts to detect and report status for the First Alert Z-wave Smoke/CO2 sensor. I don’t actually have one of these yet, but my understanding is that it shows up as two separate devices (one for smoke & CO2 respectively) so I’ve added code to detect these devices and provide alarm status. If someone happens to have one of these I’d be appreciative of any reports of success/failure, especially if you can test the alarm state.

The next devices I plan to add will be the smoke/CO2 listener and the flood/freeze sensor. These will each take a little longer because they both have some specific challenges.

The smoke/CO2 listener appears to present both alarms via a single Ring “device”, which I never anticipated in my code. I could fairly easily represent it as a single, generic device in HA, perhaps a “safety” class that simply tripped to “unsafe” status if it was either smoke or co2, but I think the ideal case would be to represent both alarm conditions independently. I have an idea on how to handle that fairly simply in my code, but it might be a few weeks before I have time to work it out and test it.

The flood/freeze device is potentially even further out because it does not appear to be supported in the current ring-alarm API code, although my guess is that adding that support should be fairly easy overall.

Please let me know if you have other things you’d like to see supported. I’ve been really thinking about including, at least optionally, the ability to control lights on ring cameras like the ring spotlight/floodlight cams. You can add that to HA today via a custom component, but it feels like something about that breaks on every HA update and I also do a lot of things with MQTT outside of HA.

motoolfan · March 10, 2019, 4:40pm

I have three of First Alert Z-wave Smoke/CO2 sensors and just loaded your lock config, the showed up and appear to be functional. Eventually I’ll get locks, Thanks again! I’m testing this in a virtualized Debian(proxmox). When the lock support branch gets merged into the main branch, I’ll switch back to the addon.

motoolfan · March 10, 2019, 5:36pm

I just tested one of my First Alert Sensors and the status never change in HASS. Just checked the Ring App to see if the test would show up in events and it didn’t, Not sure if it’s supposed to.

tsightler · March 10, 2019, 6:01pm

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.

motoolfan · March 10, 2019, 6:14pm

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.

seasideCT · March 11, 2019, 1:11am

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!

tsightler · March 11, 2019, 3:02pm

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.

seasideCT · March 12, 2019, 4:08am

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.

tsightler · March 12, 2019, 10:18pm

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

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"
}

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>"
}

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.

tsightler · March 12, 2019, 10:27pm

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.

perryw · March 12, 2019, 10:49pm

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

seasideCT · March 13, 2019, 4:19am

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