Btw your doco still mentions using the Generic Camera component: ring-mqtt/CAMERAS.md at 3943159123e685547a673a751faf927f53bbf210 · tsightler/ring-mqtt · GitHub
@tsightler Just updated to 5.0.0 and it is phenomenal! I love the move to persistent volumes. Way easier to update settings 
Thanks @IceBotYT. Using the config.json file with Docker is somewhat controversial, and I’m sure some users will prefer it while others aren’t going to like it, but, for me, it’s about maintainability. Having all install methods use the identical configuration method and state engine will significantly reduce the testing overhead for me going forward.
While I’ve done a ton of testing during the 5.0.0 development cycle, I know that you can’t have over 300 commits, not to mention the significant changes to the underlying ring-client-api, and not have some regressions, but hopefully it will stabilize over the next few months and at least most of the risk for issues is limited to camera features.
3 Likes
I just updated my docker container (haven’t done that in a while). Everything still works, which is absolutely great.
I don’t really get what’s phenomenal, and don’t get me wrong, i absolutely love this plugin/docker. But is there a change list going to 5.0.0? The changelog-hist file doesn’t mention 5.0.0.
I can see the installation procedure had changed, but the old ring-token environment value still works. Is it expected to deprecate this anytime soon?
@tsightler Dear Developer! Thx for such great update, addon for HA is work better than previous one. Snap is taken faster, just upon move and taken again after another move detected (like is native RING application), that is really big advantage in new version. No bugs found for the moment.
Regards
Alex
The changelog-hist file is for historical versions, the current version is in current changelog or on the project page you can always view the releases which include detailed changelog as well.
1 Like
I get this error on startup of 5.0.1. Doesn’t seem to cause an issue, so not raised a ticket on GitHub, but can do if needed.
2022-05-12T19:25:16.955Z ring-mqtt New location: The Mews (111111122222233333-redacted)
Register request has failed with Error=PHONE_REGISTRATION_ERROR
Retry... 1
It’s a spurious message that comes from a new, underlying dependency in ring-client-api and I can’t figure out any way to suppress it so far. Unless it continues to repeat it is completely safe to ignore since, as you can see from the next line in the log, it just automatically retries the registration until it succeeds. It my experience it never fails more than 2-3x during initial startup.
UPDATE – I think I’ve figured out a safe way to suppress these messages so hopefully they will be gone in the next release.
1 Like
5.x version not show up on mqtt broker. I just updated to 5.x version on ringmqtt log it show it have successfully login but on mqtt broker side all the entries shown unavailable. I also used Mqtt Explorer to listen to the port but nothing on Ring-Mqtt item show up.
Everything in your screenshots looks correct and working, no idea why MQTT messages would not be making it to the broker, but you didn’t post anything from the Mosquitto logs or configs, which would give some additional clues. If prior versions were working it’s even more difficult to understand as, other than using mqtt_url vs separate mqtt parameters, nothing significant has changed, and that part clearly appears to be working since it’s believes it’s connected to some broker.
Ideally you should open a support issue on the Github project page vs trying to troubleshoot in this thread, but, at a minimum you should post Mosquitto addon config and the logs showing the connections being established from Home Assistant and ring-mqtt.
nvm i found the issue. Just notice the new 5.x auto login name listed as user “addons”. I never added this as an user on my mqtt accesscontrollist file. After i added it everything worked. 
Interesting that you had to do this as the Mosquitto addon should create this user automatically, at least, the script for it is supposed to.
Is it possible to get the definitive snapshot for a given motion event? You say with the new version, you now get the UUID of the snapshot with the notification into ring2mqtt, but I don’t see where that is presented in a single place in HA (but then I haven’t looked at any events you may be emitting from the addon).
Previously I have detected a change on the motion or ding sensor and then wait for a change in timestamp and url on the snapshot camera, but I’m hoping with the new push notifications there is a better way than this.
I don’t really understand the query, the UUID is just used so that ring-mqtt can get the notification snapshot directly from the Ring API, it’s sent to the snapshot camera like any other snapshot, it’s simply sent as quickly as it can be retrieved after a motion event is detected (usually <200ms but can vary based on bandwidth, Ring API response time, etc).
Previously I have detected a change on the motion or ding sensor and then wait for a change in timestamp and url on the snapshot camera, but I’m hoping with the new push notifications there is a better way than this.
It’s difficult for me to understand what way could possibly be better than this. Since all other snapshot types are blocked when motion events are detected, you can be sure that any update after a motion event is the best snapshot that ring-mqtt could retrieve for the event, whether via UUID or forced snapshot request (valid for high-power cameras only). I feel like this logic is exactly the correct thing to do.
I suppose I could possibly include the UUID as an attribute of both the motion event and the snapshot, but this seems unnecessarily complicated, especially since there are weird corner cases where a UUID isn’t available so automations would have to deal with that case.
I think the challenge is that I’m rely on HA entities and those take time to process. To give what I see as a sequence of changes to states and attributes on the binary_sensor.motion_sensor and the camera.snapshot sensors
- BS - State change to On
- Cam - timestamp is changed (600ms)
- Cam - access token is changed (76000ms)
I’ve added at the end of each line the time (approx) from the first event indicating a motion. So it takes over a minute for the HA entity to be updated with the snapshot picture. However the timestamp on the camera entity and lastMotion on the snapshot are only 1ms apart.
It therefore becomes difficult to identify which snapshot relates to the motion since you have to wait over a minute to have it presented in HA (or maybe my problem is it takes that long to reach NodeRed, but I haven’t had that long to wait before).
It could be I’m misinterpreting what the access token represents. I thought it was a link to an individual image, but I’m sure during my testing that I’ve seen two different tokens link to same image, and I’ve seen the image change against a single token.
So I’m not sure if I can act on the binary_sensor state change, wait 5-10 seconds and then process the snapshot camera image, or whether it is more complex than that.
Edit: I note that the state on the snapshot camera never changes from Idle, so it isn’t possible to automate based on that, it has to be done on attributes of the camera.
Just configured my flow back like this, and this causes it to download the previous snapshot, not the current one.
I’m going to look and see if I can just work off the MQTT updates, because it looks like the snapshot is in there, so it would remove the delays in HA.
Edit: And this is fallible, because there is nothing that links the motion event to the snapshot. It could be it is doing its occasional snapshot, just before the one that would shown in the notification. As just happened to me the next snapshot I processed from MQTT was a few seconds before the one shown in my Ring app notification.
So yes, I think it would be useful to have the UUID of the snapshot in both motion sensor and snapshot, so it can be tied up.
It could be I’m misinterpreting what the access token represents
The access token is a temporary authentication token, it changes every 10 minutes or so when the old one expires, it’s not tied to any image and should not be used as a trigger for anything.
It’s difficult for me to understand how a UUID is really useful. When a motion event is detected all other snapshots are paused (interval snapshots don’t update while motion = ON) so you can be assured that the next image received after a motion event is the best image, regardless of UUID. Honestly, it’s very, very rare that this update takes longer than 200ms, so just pausing a single second should work reliably enough in the vast majority of cases, unless there’s something HA that’s causing additional delay. The logs show how long it takes from motion notification to snapshot update so you can see if you are seeing delays much longer than this.
Thanks for coming back and I really appreciate the enormous amount of effort you put in.
I do my automation in Node-Red, and that was showing at least 600ms for the image update to come through. I can’t tell if it is quicker in HA native automation because I don’t use it and I think the automation I’m trying to do (as ever) is too complex for it.
From what you said, and from looking at it again I think the MQTT feed into Node-Red is working fine, a little time will tell. I know HA is driven by MQTT, but it seems that getting the snapshot from the MQTT message is quicker than waiting for HA to update. I’m running this on a VM on a Mac Mini M1 so I know I’m not short on compute power.
I’m a little surprised at 600ms, feels longer than almost any time I’ve seen in nearly 1000 events that I’ve monitored (I’ve seen a few cases where Ring API response was slow). The logs should clearly show how long ring-mqtt itself took to push on the motion event and then the image, here’s what an event from one of my cameras looks like:
2022-05-16T17:48:06.573Z ring-mqtt [Front Garage Side] Received motion push notification, expires in 180 seconds
2022-05-16T17:48:06.573Z ring-mqtt [Front Garage Side] Requesting motion snapshot using notification image UUID: 8e42969a-3fee-4468-938a-7b8aba1afb5a:18308579
2022-05-16T17:48:06.573Z ring-mqtt [Front Garage Side] ring/a9ce28cb-fafb-421c-4508-29d54f48cbd3/camera/3045113e46e4/motion/state ON
2022-05-16T17:48:06.574Z ring-attr [Front Garage Side] ring/a9ce28cb-fafb-421c-4508-29d54f48cbd3/camera/3045113e46e4/motion/attributes {"lastMotion":1652723286,"lastMotionTime":"2022-05-16T17:48:06Z","personDetected":false,"motionDetectionEnabled":true}
2022-05-16T17:48:06.709Z ring-mqtt [Front Garage Side] Successfully retrieved updated snapshot
2022-05-16T17:48:06.709Z ring-mqtt [Front Garage Side] ring/a9ce28cb-fafb-421c-4508-29d54f48cbd3/camera/3045113e46e4/snapshot/image <binary_image_data>
2022-05-16T17:48:06.710Z ring-attr [Front Garage Side] ring/a9ce28cb-fafb-421c-4508-29d54f48cbd3/camera/3045113e46e4/snapshot/attributes {"timestamp":1652723287}
So you can see that, from the time the notification is received, until the time the snapshot image is sent, is actually only 137ms. This example uses rich notifications with UUID to retrieve the snapshot.
It would be interesting to see if the delay in your logs is significantly higher because I personally think <200ms is pretty good.
These are the timestamps for MQTT feed into Node-Red, and me pushing the log info to a file. It’s about 600ms which to be honest I’m reasonably happy with.
{"time":"2022-05-18T11:42:23.485Z","topic":"ring/17e5f81c-2128-4f1c-9baa-de18de0202d5/camera/54e01981fb8c/motion/state","payload":"ON"}
{"time":"2022-05-18T11:42:23.490Z","topic":"ring/17e5f81c-2128-4f1c-9baa-de18de0202d5/camera/54e01981fb8c/motion/attributes","payload":"{\"lastMotion\":1652874143,\"lastMotionTime\":\"2022-05-18T11:42:23Z\",\"personDetected\":true,\"motionDetectionEnabled\":true}"}
{"time":"2022-05-18T11:42:24.105Z","topic":"ring/17e5f81c-2128-4f1c-9baa-de18de0202d5/camera/54e01981fb8c/snapshot/image","payload":{"type":"Buffer","data":}}
{"time":"2022-05-18T11:42:24.116Z","topic":"ring/17e5f81c-2128-4f1c-9baa-de18de0202d5/camera/54e01981fb8c/snapshot/attributes","payload":"{\"timestamp\":1652874144}"}
These are (I think) the matching HA state changes, which are also about 600ms apart:
{"time":"2022-05-18T11:42:23.495Z","topic":"binary_sensor.front_door_motion_2","payload":"on","data":{"entity_id":"binary_sensor.front_door_motion_2","old_state":{"entity_id":"binary_sensor.front_door_motion_2","state":"off","attributes":{"lastMotion":1652873400,"lastMotionTime":"2022-05-18T11:30:00Z","personDetected":true,"motionDetectionEnabled":true,"device_class":"motion","friendly_name":"Front Door Motion"},"last_changed":"2022-05-18T11:33:01.349282+00:00","last_updated":"2022-05-18T11:33:01.349282+00:00","context":{"id":"0180d6f153255315ab552490ad1773e2","parent_id":null,"user_id":null},"original_state":"off"},"new_state":{"entity_id":"binary_sensor.front_door_motion_2","state":"on","attributes":{"lastMotion":1652873400,"lastMotionTime":"2022-05-18T11:30:00Z","personDetected":true,"motionDetectionEnabled":true,"device_class":"motion","friendly_name":"Front Door Motion"},"last_changed":"2022-05-18T11:42:23.487427+00:00","last_updated":"2022-05-18T11:42:23.487427+00:00","context":{"id":"0180d6f9e6ff894b9d471ba50a6c32f7","parent_id":null,"user_id":null},"original_state":"on","timeSinceChangedMs":5}}}
{"time":"2022-05-18T11:42:23.502Z","topic":"binary_sensor.front_door_motion_2","payload":"on","data":{"entity_id":"binary_sensor.front_door_motion_2","old_state":{"entity_id":"binary_sensor.front_door_motion_2","state":"on","attributes":{"lastMotion":1652873400,"lastMotionTime":"2022-05-18T11:30:00Z","personDetected":true,"motionDetectionEnabled":true,"device_class":"motion","friendly_name":"Front Door Motion"},"last_changed":"2022-05-18T11:42:23.487427+00:00","last_updated":"2022-05-18T11:42:23.487427+00:00","context":{"id":"0180d6f9e6ff894b9d471ba50a6c32f7","parent_id":null,"user_id":null},"original_state":"on"},"new_state":{"entity_id":"binary_sensor.front_door_motion_2","state":"on","attributes":{"lastMotion":1652874143,"lastMotionTime":"2022-05-18T11:42:23Z","personDetected":true,"motionDetectionEnabled":true,"device_class":"motion","friendly_name":"Front Door Motion"},"last_changed":"2022-05-18T11:42:23.487427+00:00","last_updated":"2022-05-18T11:42:23.491472+00:00","context":{"id":"0180d6f9e70359093ee512fef9bc34c7","parent_id":null,"user_id":null},"original_state":"on","timeSinceChangedMs":14}}}
{"time":"2022-05-18T11:42:24.121Z","topic":"camera.front_door_snapshot","payload":"idle","data":{"entity_id":"camera.front_door_snapshot","old_state":{"entity_id":"camera.front_door_snapshot","state":"idle","attributes":{"access_token":"3af04d953c635bb94fc682b580b6494ab579833878d4b4cc5b58e11905d809e3","timestamp":1652874134,"entity_picture":"/api/camera_proxy/camera.front_door_snapshot?token=3af04d953c635bb94fc682b580b6494ab579833878d4b4cc5b58e11905d809e3","friendly_name":"Front Door Snapshot","supported_features":0},"last_changed":"2022-05-17T18:31:16.974880+00:00","last_updated":"2022-05-18T11:42:13.638782+00:00","context":{"id":"0180d6f9c086d3ca21ceba357f893e83","parent_id":null,"user_id":null},"original_state":"idle"},"new_state":{"entity_id":"camera.front_door_snapshot","state":"idle","attributes":{"access_token":"3af04d953c635bb94fc682b580b6494ab579833878d4b4cc5b58e11905d809e3","timestamp":1652874144,"entity_picture":"/api/camera_proxy/camera.front_door_snapshot?token=3af04d953c635bb94fc682b580b6494ab579833878d4b4cc5b58e11905d809e3","friendly_name":"Front Door Snapshot","supported_features":0},"last_changed":"2022-05-17T18:31:16.974880+00:00","last_updated":"2022-05-18T11:42:24.105544+00:00","context":{"id":"0180d6f9e9694ab7a3581977a06de930","parent_id":null,"user_id":null},"original_state":"idle","timeSinceChangedMs":61867146}}}
That said, it looks like capturing the image either way (via MQTT or HA events) is working fine. I had a method which was clearly wrong (and was providing unreliable results) based on HA events which was confusing things. A simple motion, wait a few seconds, capture image from HA api url seems to work.
Edit: I’ll run in parallel for a couple of days to see if I get reliable results. HA method is simpler, but MQTT has the actual image in the message, so you know you have it.