No local communications, everything goes to the cloud and back for both the native camera integration and the alarm. Basically, these tools are using the same API used by the Ring app as that’s the only way to talk to any Ring devices at all.
I think I know what it is. I have my router set to reboot at 4am every Thursday. I think it is here when the problem manifests. Its obviously trying to reach the api and can’t because internet is temporarily down whilst its rebooting. But it never recovers. I have it now where all devices are in an unavailable state and they all show unavailable in the device history from this same time at 4.01:53am. I have my router set to reboot here. In my logs I see everything complaining of course (as whole network goes down including internet as my rPi is wired to the router directly and wifi). Is there some limit on how long it tries to connect before its giving up?
I still have lots of the active dings error though, which I assume is the Ring addon not this one. But I also have this (which looks like your addons type of message maybe?) in my home assistant log which was appearing a lot all night and morning before everything went unavailable with my router reboot:
2021-03-25 00:29:22 WARNING (SyncWorker_4) [homeassistant.components.ring] Error fetching Ring history data for device a8108724096a: ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response'))
How do I relate that device number to an actual physical device? Thanks 
Edit: just restarted the addon and immediately the devices all spring back to life again. I did just try rebooting router again and it didn’t cause the problem though. I’m just unplugging the rPi from the network for a few minutes longer to test, maybe it is time dependent (how long it is without connection).
There’s no timeout, it should basically retry the connection forever. However, as I mentioned above, there seems to be a bug in the latest Node v12 that causes it to sometimes just stop trying to connect. I can generally reproduce it by blocking the network for around 5-10 minutes although every now and then it still works and reconnects. However, with Node 14, it seems to work fine every time, even if I block the connection for hours it will come back within 60 seconds of unblocking the connection.
All of this connection/reconnection logic is actually handled in the ring-client-api and socket.io layers below my code, so I assume it is just some bug that was introduced recently (I did tons of testing with this back when I first developed this code because my expectation of automations is that they have to work nearly 100%). If I had to place a guess it has something to do with ring-client-api switching to the use of HTTP2 for some operations (required by changes on the Ring side). This seemed to cause a lot of grief with older node versions as the author of the ring-client-api also saw some reports of similar issues in his project (Ring Homebridge addon) and had users upgrade to Node v14 for the problem to go away. (Example: https://github.com/dgreif/ring/issues/560)
When I push the next version I’m going to base it on an updated image that includes Node v14 so hopefully the problem will go away.
1 Like
Appologies, hadn’t picked up on your previous reference to connection loss triggering it. Definitely sounds like you found it as thats exactly whats happening here. I’ll wait for your next release and give it a whirl. Thanks for your patience and work on keeping this addon going
Just getting started with ring-mqtt and apologies for the basic question, but really not sure how to get started.
I’ve installed via the HA addon route and this is working. I’m guessing now that I need to create some MQTT sensors to start getting info from my cameras.
However, one of the main reasons for using this was to be able to set the mode of my cameras (I’m not using an alarm).
On startup I noticed that an alarm config was displayed so tried to use the ‘state’ topic listed in that with the commands arm_home and arm_away, this did nothing. Also tried one of the cameras and still nothing.
Some pointers would be greatly appreciated.
Assuming you set “enable_modes”, which it sounds like you did since you did get a alarm control panel, then you should just be able to use the alarm control panel to arm/disarm the “modes”.
One thing I would point out, unlike with the alarm, which displays status changes in the app immediately, when you set modes via ring-mqtt, the status in the app will not display correctly until you kill the app and restart it, so it may not be obvious if it is working or not in some cases (this has bit quite a few users that reported it not working).
However, I’m also concerned that Ring may have made changes that broke the underlying ring-client-api because the Homebridge project also has a current open issue reporting this same behavior.
Unfortunately, I don’t use modes at all, I pretty much developed the feature blind based on the Homebridge addon, and thus it’s not something I test regularly. I know that it worked in the past, and it’s a very simple component (basically a fake switch that reads the status from polled operations and calls the functions to enable/disable various modes), but I’d like to hear from someone else that was using modes if it’s still working for them or not. There have been no other reports of it not working to this point.
1 Like
I also noticed you indicated you sent “arm_home” and “arm_away”, but it should be “ARM_HOME” and “ARM_AWAY”. The code for modes is very strict regarding case and, for whatever reason, the default for the HA alarm control panel is upper case. I’ll relax the case restrictions for modes in the next release so that it matches the normal alarm which already ignores case. You should at least see the attempts to arm/disarm in the logs if you send the correct command, even if it’s not somehow working on the backend.
I’ve pushed 4.5.0 which bumps the Node v14 and I can’t reproduce this issue on that version so I’m hopeful it might address your issue. Please feel free to open an issue on Github if you continue to experience issues after upgrading to that version.
Just wanted to let you know that I’ve pushed 4.5.0 which should now allow bypass of retrofit zones. Untested since I don’t have any but it was a simple change so hopefully I did it right.
Seems to have resolved it here. Nice job
Been running plugin now for quit a while here and a happy camper.
Originally did a manual install of the plugin and was running HA in docker (from a few years back) on an intel mini pc. Switched over to HASSIO on a Intel i3 and it is doing well and much easier to work with than the old HA in Docker.
Currently using version: 4.5.2 on latest version of HA in HASSIO running on an i3 here in Ubuntu 20.04.
I am running MQTT broker on another computer here. Tried using the HA MQTT broker and it never did work right.
A few months ago enabled TTS to Alexa devices via the HA Alexa Media plugin.
It is working well except that:
I use Alexa TTS when the alarm is enabled in night mode. It works fine except that it triggers in the middle of the night sometimes 2-3 times. Middle of the night is 2-3 AM. That and I have chosen one Alexa device in two homes to do the TTS for the Ring Alarm. Well and it has become low on the WAF when TTS triggers at 2 AM …waking up wife and house #2 folks.
So for my automation in HA using MQTT trigger type:
Topic: ring/xxxyyyzzz/alarm/state
Payload: armed_home
and
Trigger Type: state
Entity: alarm control panel
From Disarmed
To Armed
Only that this triggers hours after initial state is changed X2 or X 3 times in the middle of the night.
I am not seeing any disconnects to the ISP or switching over to the sim card stuff on the hub.
I have had to disable the automation to Alexa TTS for time bean as it was low on the WAF.
I am managing two alarm panels here with HA. Primary alarm panel is a Leviton Omni Pro 2 panel using the Omnilinkbridge which works well and then secondary alarm panel which is the Ring in House #2.
New TTS is via multiple Alexa devices. Old TTS is still using Micrsoft SAPI and audio distribution via a Russound. Much talking going on…
Can you suggest an automation script which triggers only once when Ring alarm is armed or disarmed?
Why are you triggering on MQTT payload? I think I would personally just trigger on a device state vs the entity state and certainly not the MQTT payload which might be duplicated (MQTT will resend state for multitude of reasons).
That being said, you really need to examine the states and figure out what is triggering it before it’s possible to determine how to fix it.
Im embarrassed to post this, but I dont seem to be able get this launched. I’m running Home Assistant from a docker container and numerous other plugins (includiing eclispe/mosquitto) from docker as well.
I’ve been able to get a token with this:
docker run -it --rm --entrypoint /app/ring-mqtt/node_modules/ring-client-api/ring-auth-cli.js tsightler/ring-mqtt
but when i run the actual docker-run script… either in terminal, or portainer, or docker-compose (which i try to convert everything too) i just get this in logs:
Running ring-mqtt…,
Running ring-mqtt…
Maybe this is working as designed and i’m just going to the wrong address, which i thought was http://<ip_of_server>:55123
Running this docker-compse:
ring-mqtt:
container_name: RingMQTT
environment:
- RINGTOKEN=[STRIPPED OUT]
- MQTTHOST=localhost
- MQTTPORT=1883
volumes:
- /home/ringmqtt:/data
restart: unless-stopped
image: tsightler/ring-mqtt
If you are not getting any errors then it is probably working. The default behavior of the script is to produce no output. If you want to see some output you’ll need to set DEBUG environment variable so try adding DEBUG=ring-mqtt and it should be much more verbose.
Also, the web interface doesn’t run in the Docker container since it’s used only to get the initial token and with the Docker version that’s done via command line.
1 Like
Awesome… Debug showed me that the MQTT host didn’t like http. Changed that and BOOM! All good. Great app man. Im a bit of a novice to MQTT – use Zwave2MQTT and it works great… but been a while… will be fun to brush off the rust.
Thanks again.
1 Like
Hi, I think maybe not an addon issue, but did something change in how the arm service should be called? I used to pass:
“code”: xxxx
and in last few days its giving an api error that it doesn’t like this:
Call-service API error. Error Message: extra keys not allowed @ data['code']
if I remove passing a code get:
Call-service API error. Error Message: extra keys not allowed @ data['entity_id']
I’ve had this setup for a while now in nodered with no issues. The only thing I can think of is HA / Addon updates (I update everything immediately), but I also added some new contact sensors and also a second keypad.
I don’t have any idea but perhaps you can use the Services UI in the developer screen to troubleshoot. I had no issues arming and disarming the alarm via services with the latest versions. As far as I can tell entity ID needs to be part of ‘target’ not ‘data’ and, unless you have a code set in the frontend, I don’t think you need ‘code’ at all. Definitely does not appear to be addon related.
Turns out my message to alexa previous in the flow had payload set in output location and that was adding to my service call for arming. Must have miss-clicked it recently. Still no disconnects on the ring devices though so that issue is definitely fixed. Still getting that active dings error though for the doorbell. Think will try removing that plugin and using yours with it.
While I’m confident the reconnection issues for alarms are fixed, there are definitely still issues with cameras, which use a completely different interface. Unfortunately, the issues is somewhat complex and not really related to ring-mqtt but rather to underlying changes in ring-client-api to use HTTP2 which were required due to some changes in the Ring servers. HTTP2 support seems quite unstable in Node at the moment and this has introduced a number of issues one of which is the reconnect problem. I’ve been investigating with the authors of the underlying components but it may take a while before there is a full fix available for cameras losing connection.
So sorry! We have a newborn in the house and I have been distracted! Just saw this message and went to try it out. Seems to work. I will probably do some more experiments to see the extent of the bypass. (i.e. if I have bypass on and a window is open and I arm the house, THEN I open a door that is on a different circuit in the retrofit mode, will that still go off?)
Thank you again!