I know you already have an answer that works for you but, in the interest of being complete, i wanted to add some context.
These are not really “phantom events”, and it’s not about “sensitivity” they are simply the events detected by the camera. The native Ring integration polls for all events, so any event that shows up on the camera event history creates a state chage . On the other hand, ring-mqtt depends on notifications, which are much faster, but if you enable smart notifications, only events that get through this smart notifications filter (for example, person detection) will get through. If you have notifications enabled for all events then ring-mqtt and native Ring integration is identical.
ON state duration is just one possible trigger. However, ring-mqtt does send an updated “ON” for every event, and you can use something like “lastMotionTime” for the trigger instead, as that will trigger for every motion event even if state is already “ON”.
No because this would be technically incorrect, this field shows the status of the last detected motion event (as identified by the “lastMotionTime” attribute) and is independent of the existion ON/OFF state of the sensor.
ON state in ring-mqtt has always followed the expiration time for the event which is a property of the event, and is 180 seconds. This also matches the behavior of 1st generation Ring motion sensors which were the only motion sensors available at the time, so behavior was consistent between camera and alarm motion detection. In the current dev version, you can override this on a per-camera basis down to as low as 10 seconds since so many people don’t seem to understand that you can still just trigger on something other than “ON” state, if you want to get every motion event for some reason.
Thanks for this update. While I have a way of resolving this, its always nice to be able to do within the integration. Plus some nice additions as well. Thanks for investing in, and keeping this integration updated. Much appreciated!
@tsightler Thank you for the new release. The new features are appreciated. From the release notes that appeared in the update (I am struggling to find them online now I have updated), you seemed to indicate that Gen2 motion sensors have a different (much shorter) cooldown time of 20 seconds, as opposed to 180 seconds (3 minutes) for Gen1 sensors. Have I understood this correctly, as that in itself is a major reason for me to upgrade most of my Gen1 motion sensors to Gen2. They are simply not reactive enough when trying to use them for lighting automations, and it should save me having an additional (different brand) motion sensor for lighting in each room where I need that reactivity.
Well, I guess I can’t be 100% sure but, until recently, I only owned 1st gen motion sensors so that was the only behavior I had ever seen from Ring devices. A few months ago I purchased a 2nd gen motion sensor to cover a different area in the house and it seems to stay activated for only 20 seconds. Personally, I dislike this, but to each their own, and I can live with it.
By far the biggest thing I dislike about the 2nd Gen motion sensor is that it seems far less sensitive than either of the 1st Gen sensors, even on the most sensitive setting. It actually wasn’t sensitive enough for the use case for which I purchased it and I ended up purchasing a 1st Gen sensor from eBay.
Thanks for the insight. Pity the Gen2 ones are less sensitive. I have heard others say that about them as well, but it is the first I have heard that the cooldown period is quicker, which I would definitely appreciate for lighting automations. I guess I will need to purchase a single sensor to test with and then weigh up the pros and cons.
So this is mostly just me being nosey, but I’m super curious why does this matter for lighting automations? I use quite a number of motion sensors with 2-3 minute cooldown for lighting functions and I’ve never really perceived it as an issue, but I’m guessing it’s just some use case that I don’t have.
@tsightler It’s only if you want lighting to switch off faster than three minutes, which I do in a few cases. “Follow-me” lighting also requires fast cooldown, which is something I want to setup e.g. for Hallway, Landing and Stair lights. Another good lighting example is for rooms like the Garage. In my case I am usually in and out in a minute as all I am doing is getting something from the second fridge. So the lights come on when motion sensor in there detects motion. They go off automatically after 10 minutes, but sometimes I hit the light switch to turn them off. If I then realise I need something else withing three minutes and go back in the light doesn’t come on, as the motion sensor is still detecting motion from the previous entry and hasn’t switched off (cooled down) ready to detect the next event.
I also have another use case whereby I have any Alexa “Welcome Home” announcement, which although it has multiple triggers for different motion and door sensors (after the person has changed from away to home), it sometimes fails to work if someone was in the house and has just walked past all the sensors before they entered, as they are all then on for three minutes before turning off i.e. they need to be off to be tripped by the new person entering.
Also for room presence in e.g. a toilet, whereby I want to have very quick updates to know if someone is in there after the door has closed i.e. has someone just entered or exited the toilet. If the sensor doesn’t detect motion within 20 seconds of the door closing, it’s a pretty good bet that the toilet is now vacant and someone was in there and has just left rather than someone just entering. If you have a fast cooldown period you can also use the order of activation to see which direction someone is moving in for room presence as well. 3 minutes is just too long for that sort of thing.
I’m sure there are more use cases where a fast cooldown period is useful, but that’s just a few.
The Philips Hue (Zigbee) motion sensors have a very quick cooldown of 10 seconds and work brilliantly for these scenarios, and I believe the newer Aqara ones (T1 I think) have a configurable cooldown too (which I think goes down to 30 seconds), but I don’t have any of them and they weren’t easy to find when I last looked about 6 months ago. Basically, wherever possible I would like to prevent sensor duplication and only have one motion sensor in the room.
Thanks for the details. I guess I don’t try to do anything that fancy. I don’t rely on motion sensors for primary triggers for most areas, only as supplemental information, and I’m not trying to turn on lights in toilets! I don’t believe I would ever rely on Ring sensors for such advanced automations honestly, that’s the kind of thing for local sensors, IMO.
I have a question. When deactivating via an automation, I give a 4-digit code so that Ring Alarm knows who is deactivating the alarm. But the code doesn’t seem to get through to Ring Alarm The Ring Alarm push message doesn’t contain the correct name that triggered the automation.
I believe that’s because the code is internal to Home Assistant. As far as Ring is concerned it just sees it as the account that the integration is using.
I don’t believe so. @tsightler may correct me if I am wrong. When Home Assistant disarms the alarm the Ring app pushes a notification to say Alarm disarmed by Robert Wigley from app, or something to that effect, as it’s my account that is being used by the integration. I keep meaning to setup another account called Home Assistant and swap the integration over to using that so it would say Alarm disarmed by Home Assistant from app, but I haven’t got round to it and it’s not really an issue anyway, as I know it’s Home Assistant that’s done it if I haven’t.
No, this isn’t possible via an automation because ring-mqtt is connected to the API as a specific Ring user (the user you used when you authenticated via the web or cli tool), so all actions from ring-mqtt are performed by that user.
To think about it another way, if you login to the Ring app, then you can arm/disarm the alarm from the app as the user you’ve logged in as, no code needed. That’s exactly what ring-mqtt is doing. If you wanted a different user to disarm the alarm, you’d have to log out of the Ring app and log back into the app as the different user.
The actual physical keypad is completely different, it talks locally via Z-wave to the base station, so the base station knows what code has been entered, and the disarm is happening locally (you can arm/disarm even if the internet connection is down).
Does anyone know if there is a way to disable motion dection for a camera? I’d like to add a button on a dashboard that I can use to toggle motion detection for my doorbell on/off, rather than having to go into the app, selecting the doorbell/camera settings and toggling it there.
@tsightler Hi, have you come across, or have any idea as to why some of my camera’s are now reporting this in the log?
[Camera Name] Camera lost subscription to ding events, attempting to resubscribe… …?
I have made no changes to my home assitant at all or the ring mqtt configuration. (Or changes via my ring account/app)
I noticed this morning where I was still getting notifications for person events however the image was a stale one from about 8 hours earlier. From that point on the messages about lost subscriptions to ding events has followed. The mqtt event dings are not being updated with the latest details and specifically the snapshot id.
Do you think this could be something with the home assistant ring add-on? I dont see anyone else here detailing a similar error so must be local to me. Would removing/reinstalling the ring HA add-on make any difference? I cant recall if your add on requires it or not and whether that is causing these issues.
I guess im just looking for your opinion on maybe some best next steps.
My suggestion would be to ignore it, it’s a mostly harmless message. Ring seems to have made some minor changes to their API that are triggering this for non-doorbell cameras. These messages will be suppressed in the next release but they are harmless.
it seems that wile the binary sensors still work, whatever it is, its causing issues with snapshots not updating. Occasionally I see the generic cameras that are set to the rtsp://*…napshot.attributes.entity_picture are not getting updated.
If I restart the ring mqtt service, the log shows everything loads ok , all subscriptions are confirmed and it logs a snapshot refresh OK. This si when all the cameras update correctly. After that one load, I start to see logs as follows.
2023-03-29T10:06:35.796Z ring-mqtt [**CAM1**] Previous Person 1 URL has expired, updating the recording URL
2023-03-29T10:06:35.811Z ring-mqtt [**CAM2**] Previous Person 1 URL has expired, updating the recording URL
2023-03-29T10:06:35.820Z ring-mqtt [**CAM3**] Camera lost subscription to ding events, attempting to resubscribe...
2023-03-29T10:06:35.828Z ring-mqtt [**CAM4**] Camera lost subscription to ding events, attempting to resubscribe...
and while the binary sensors will update that a motion event occurred, the snapshots are not taken/captured. The URL for entity picture does not seem to change. Going back tot he HA ring integration, I am running this as well but started to use mostly the ring mqtt components. Im not sure if there is any dependency on the HA integration but could it be worth removing/re-adding that ?
Snapshots on motion are broken right now due to the fact that Ring changed the API behavior with an update a few days ago and I haven’t had time to push out an update with a fix for this. It has nothing at all to do with the messages you are asking about or the log lines you posted. The “lost subscription” message is spurrious and not important.
I don’t believe I would ever rely on Ring sensors for such advanced automations honestly, that’s the kind of thing for local sensors, IMO.