I’ve updated to the latest version and the ‘unavailable’ status hasn’t been occur since then. Thanks @tsightler!
I was trying to handle it better in node-red but it is not straightforward. It has to consider ‘unavailable’ then ignore the next ‘off’ in a few seconds.
Looks good here @tsightler was able to upgrade no problem though was expecting the problem I had was a one time issue with initial install. Long shot question - is it possible with the Ring API to capture the user that disarmed the alarm like the Ring app does? For example you can have the ring app notify that the alarm was disabled by user X because they used PIN Y. Would be great to be able to capture this data to HA so that I could trigger alerts based on who disarmed the alarm (thinking about kids etc).
First, thank you tsightler for this great work, it’s working perfectly since the first installation.
I’ve no update but a second instance of the Ring add-on showing up in the add-ons store page.
Also, an unavailable state is occuring every 4 hours for about 5 to 6 seconds and then back to normal status. For my own use it’s not bothering but wondering what might cause this unavalability.
Thank again
I believe that the reason there are two addons showing up is that I had to change the slug (basically how Hassio identifies the addon) from ring-mqtt to ring_mqtt because, for some reason, dashes are not properly supported for slug names. I believe that this will be a one-time event, but to fix it you may need to remove the repository/plugin and and re-add it.
I apologize for this, I did not realize that the original slug name was not valid (it worked after all) but another user reported that they could not perform certain functions (such as automating a restart of the addon) because the slug name was considered invalid (with a link to the unresolved issue in Home Assistant). This left me with little option but to change the slug name, but I did not realize the impact this would cause with upgrades. I’ll try to take care of it going forward.
Regarding the disconnect/reconnect issue, it should be resolved in 3.1.0. I don’t understand why this is happening suddenly as the script has had monitoring for the websocket since the early versions. I can only think that perhaps as part of the move to 2FA that Ring has also added some type of timeout for the session where the API has to re-authenticate and re-establish the websocket connection (the fact that multiple users have reported 4 hours makes me think it is not a coincidence). In 3.1.0 the websocket is still monitored, but it must remain down for at least 60 seconds before actually setting the devices as unavailable, as long as the API reconnects within that time I simply ignore it the disconnect.
Thanks. When I removed and re-added as you suggested, it only gave me the choice of a single addon, which was 3.1.0.
Sorry for the basic question but how do I install this Hassio add-on ? I looked on the GitHub page but I don’t see any installation instructions.
In home assistant, go to Supervisor > Add-on Store > and add a new repository URL of https://github.com/tsightler/ring-mqtt-hassio-addon
Then scroll down and you should see the add-on to install
Thank you !!
Since updating Hassio, my Ring devices are showing as not available. I get the following error in Hassio:
20-03-31 11:10:31 ERROR (SyncWorker_10) [supervisor.docker] Can't create container from addon_fdb328a7_ring_mqtt: 404 Client Error: Not Found ("No such image: fdb328a7/aarch64-addon-ring_mqtt:3.1.0")
Not sure what the issue is. I uninstalled both the plugin and the respository. I also reflashed Hassio and recovered my configs from a snapshot. I have uninstalled the plugin a couple times.
I am on the 64bit RPi 3B+ version, with HassOS 3.12 and Supervisor 214. Any idea what is wrong?
Thanks,
Rick
I don’t know if Ring change its 2fa auth but now everytime I reboot or shutdown, I need to get a new token.
I have the same problem as Bruno unfortunately.
Seems to work beautifully whilst server is running but as soon as it restarts I have to remove the key and redo the process
3.1.0
Same issue as Bruno7 and D_Sx. Doing a clean reinstall of my HA setup and have to go back and forth between the new one and the old one. Each time I boot one up, I have to get a new token to get the ring integration to work. Not a major issue since I don’t usually shut down HA but could be an issue if it reboots after a power failure.
Issue mysteriously disappeared and addon back to normal behaviour, tried after shutdown and restart.
Might be related to Ring servers.
Yes, seems to be working again (for now).
I notice all the ring-mqtt integrations show up as “Entities without devices” is there an easy way to fix that on the ring-mqtt side? Ideally each device would come in as one item with the items like light/sensor/etc. as items belonging to a device.
Thanks,
Right now the ring-mqtt code does not support sending all of the required autoconfig data to register a “device” in Home Assistant. The enhancement to support this is technically on my to-do list but, if I were to be completely honest, it’s not a very high priority for me compared to many other things on that list that seem far more useful.
Perhaps more importantly, I just don’t have much time to put into enhancing the code base right now and what little time I do have has been spent fighting to just keep the stupid thing working due to various issue with Ring, mainly around the switch to require 2FA and the complications that has brought with it.
BTW great tool, and really appreciate the work. Is there anyway to manually bring these in as devices? IE don’t use the auto gen stuff? If not no worries, it gives me a great base to work with.
I don’t think there’s any way to add “devices” manually. You can technically disable MQTT discovery on the HA side and add all entities manually, but, the HA MQTT documentation says:
device
(map)(Optional)
Only works through MQTT discovery and whenunique_idis set.
So that makes me think it’s not possible to manually add entities to devices via the config file.
Out of curiosity, what do you see as the benefit do you get from having the entities associated with devices? I mean, I see your screenshots above, but I don’t really see how it’s negatively impacting usability. Is it just the simplicity of adding a device to the UI vs individual entities or am I completely missing something? At one point I thought it might be a better way for me to show things like battery level and tamper status (I could make each value an MQTT sensor entity associated with the device). Maybe if you can help me better understand the usefulness of this capability it might raise the priority of this feature for me as it’s always easier to motivate yourself to work on something that you can find useful yourself! 
Mainly it is the right way 
If you look at the changes to HA over the last while, it is really moving to a device context. So all devices are linked in UI for automation/scripts/etc. So first it makes things easier. It also simplifies device management. If I rename a device HA auto renames all Entities for that device.
In addition it gives you one spot to see everything about a device. Here is an example from a tasmota smart outlet. Notice how you can go to one place to see everything associated with that. Automations/Scenes/Scripts and all sensors/switches/attributes.
I have 8 ring device, but what those produce is a miss match of sensors/lights/etc. that aren’t grouped so it makes management of things more difficult. For most that might not be a big deal, but with 78 ZWave devices, 25+ MQTT devices, and 15-20 other integrations simplifying system management is the only thing that keeps it sane
With that said, what you have produced is very usable, and I really appreciate it, the ring-mqtt is actually fairly fast at reports of motion/lights/etc. and supports the widest range of ring devices. Way better than the native ring integration. Plus I am working on moving everything I can to MQTT. So I will make it work Thanks for all the work you have done already.
Sample of Tasmota device:
Thanks again for a great mqtt add on!
Thanks for the additional detail, it helps me understand a little more what the benefits my be. Maybe I’m an old-school HA user, but I have a bunch of MQTT devices configured via manual method so they don’t support devices concept anyway, as far as I can tell (maybe it works if I manually set unique_id, I guess I’ll have to try it).
But, realistically, when I first created ring-mqtt (originally ring-alarm-mqtt) it wasn’t intended to be something primarily used with HA (I wasn’t even using HA at the time). But, when I started using HA I was lazy, and wanted to use MQTT auto-discovery, so I coded up the basic support for it in the script, but I expected that there would be native support for Ring alarm fairly quickly and didn’t spend a lot of time on anything other than what I needed.
I think your request is pretty reasonable and, looking at the overall device concept, it looks like it would be pretty easy to implement and have some nice advantages for devices with mulitple sensors (like smoke/co2 and flood/freeze) so maybe I’ll give it a shot when I get more time.
