Light Switch for Ring Spotlight Cam does not stay active (“On” in Home app) to reflect the ACTUAL state of the camera’s light

[ohhmyjawwsh]

Is there an existing issue for this?

• I have searched the existing issues

Describe The Bug

When turning the Spotlight Cam light on with the Light switch provided by the plugin, the light will stay on for however long it’s been setup to stay on for, but the switch will revert back to OFF within a few second regardless of the light’s actual state.

To Reproduce

Simply trigger the cam light using the switch & watch it reset to OFF within a couple seconds while you can see the light on the camera is still actively ON either by live streaming or by looking at the device in person.

Expected behavior

Reflect the ACTUAL state of the light using the same polling interval setup inside the plugin & to only revert to OFF when the physical light is actually off. Everything else works fine with the current polling interval & functionality of the plugin, but I cannot automate a trigger of the light to turn back on again when it actually turns off because the status of the switch does not match the actual state & therefore will trigger an endless loop every 2-5 seconds of flipping the switch back on when the switch turns off, not when the light actually turns off. This bogs down HB resources & the plugin responsiveness since it’s a constant re-trigger of the switch that keeps turning off.

Relevant log output

No response

Screenshots

No response

Homebridge Ring Config

{
            "refreshToken": "XXXXXXXXXXXXXX",
            "unbridgeCameras": true,
            "beamDurationSeconds": 600,
            "debug": true,
            "cameraStatusPollingSeconds": 2,
            "locationModePollingSeconds": 5,
            "_bridge": {
                "username": "XXXXXXXXXXXXX",
                "port": 49014,
                "name": "Ring Camera"
            },
            "platform": "Ring"
        }

Additional context

No response

OS

iOS by use of Homebridge installed on a RaspberryPi

Node.js Version

v18.17.0

NPM Version

v9.8.1

Homebridge/HOOBs Version

v1.6.1

Homebridge Ring Plugin Version

v11.8.0

Operating System

iOS by use of Homebridge installed on a RaspberryPi

[tsightler]

I actually wonder if your settings are making this worse with the super frequent status polling interval. The Ring API takes some time to update to the actual status, and I know there is already some code in ring-homebridge to attempt to mitigate this somewhat, by delaying status updates for I think 5 seconds after a local state change, however, I have to deal with this in ring-mqtt as well, and I've found that 5 seconds often is not enough time for the Ring API to reflect actual state. I've actually increased the time to 30 seconds before finally reflecting the API reported state vs the local state.

However, with such frequent (2 seconds) polling, I'd be somewhat surprised if you don't get an out-of-date status almost immediately after the 5 second standoff time for updates.

I don't know anything about Homekit, but I'm surprised there's not some way to deal with this there, as this isn't all that uncommon, I've seen it across many devices over the years. Does Homekit not have some condition that lets a rule be skipped/ignored if there's been a recent state change? I mean, effectively that's all the ring-homebridge/ring-mqtt code is doing anyway, just ignoring any state reported by the Ring API for X amount of seconds.

[ohhmyjawwsh]

@tsightler unfortunately, I have tried it with different poll settings and that doesn’t seem to fix anything. It seems to be the fact that the switch is not a static state switch which makes it automatically revert back to the off position instead of holding the current state no matter what state the actual lights characteristic is registering to the Home app. In theory, the faster the poll rate, the quicker it would tell the Home app to remain in the ON position if the light is registering as ON, but even with extended poll rates, the switch still reverts back to its original position of OFF. It should be a simple fix, if the switch could be a static state switch but I can’t quite tell so that’s why I submitted this issue.

[tsightler]

It seems to be the fact that the switch is not a static state switch which makes it automatically revert back to the off position instead

I'm not sure what you mean by static state switch, but it is certainly not a momentary switch, if that is what you mean.

In theory, the faster the poll rate, the quicker it would tell the Home app to remain in the ON position if the light is registering as ON

In theory yes, in practice no, because, as I noted above, the Ring API does not update the state immediately. In other words, it's the Ring API that doesn't reflect the actual state, which puts some challenges on tools like ring-homebridge and ring-mqtt to deal with. I guess this is because it has no reason to do so since the Ring apps themselves do not synchronize state in anything resembling real-time. This is visible in Ring apps, for example, if you go to the Ring web dashboard and turn on the light on with the app on your phone, the dashboard will not reflect the state until typically 20 seconds or so later. Every now and then it will be faster, I've seen as few as 4 seconds, but I've seen as long as almost 30 seconds.

Just by way of example, I wrote a simple piece of code that sends the command to turn the light on, then, every two seconds, spits out the state that the Ring API reports for that light. I used 2 second polling to match your case. Here are the results:

on <-- Light was turned on so ring-client-api manually updates state data to "on"
off <-- First poll of Ring API which still reports light as "off"
off <-- 4s
off <-- 6s
off <-- 8s
off <-- 10s
off <-- 12s
off <-- 14s
off <-- 16s
off <-- 18s
off <-- 20s
off <-- 22s
off <-- 24s
on <-- Finally, Ring API reports actual light state, ~26 seconds after light was turned on
on
on
on
on
on
on

So, as you can see, polling every 2 seconds does no good, because the Ring API itself doesn't have the correct state for >20 seconds and frequent polling is far more likely to get you throttled, which will actually delay updates even more. My guess is, if you wait 20-30 seconds, that the switch will eventually reflect the correct state in Homebridge/Homekit.

This is an annoying problem to deal with since it is the Ring API itself doesn't reflect the actual state, and the only viable workaround that I could think of was to ignore state updates from Ring API even longer after any local state change. Right now, if I understand the ring-homebridge code correctly, it is ignored for 5 seconds, but in ring-mqtt I opted to use 30 seconds, which doesn't really solve the problem, but effectively hides it from automations.

The other option is to ignore such phantom state changes in the automation itself, i.e. add a condition that ignores state changes if state was previously changed in the last 30 seconds. This is a common workaround for such issues in Home Assistant, but not sure if Homekit allows such conditions easily.

I'd suggest changing the current timeout value from 5000 to 30000 in homebridge-ring/camera.js. You can look for the line:

lightTargetTimer.setTarget(value, 5000)

Replace that value with something longer and see if it at least helps with your automations.

[tsightler]

@dgreif What do you think about increasing the setTarget value to 30 seconds instead of 5 seconds? I've verified that this mostly hides the behavior described here and it's what I've used for ring-mqtt for quite a while now for the very same reason.
I'm not sure why the Ring API now takes so long to update the light status, but I've only very rarely seen it take longer than 30 seconds. Without this it makes building automations a little more difficult in some cases because you have to ignore the phantom state change that happens.

I do sometimes wonder if this should be implemented in ring-client-api instead so that every project doesn't need to implement its own workaround for the behavior.

[dgreif]

@tsightler I'm game for changing that to 30s. I can get an update out this weekend with that change.

[ohhmyjawwsh]

@dgreif @tsightler I’m totally down for this change but I have a couple concerns I’d want to share.

1. this change in polling would not affect the polling for the camera status or motion detection in any way right? Also

2. I totally see how this could help. But what I’m experiencing is that the switch itself won’t stay “on” for even the 5 seconds the plugin is already (according to notes above) setup to ignore changes. So is this actually a polling issue or is it a code issue with the switch device exposed?

3. lastly, if the change to 30 second intervals doesn’t poll a new status until then, what happens when you turn the switch back off within those 30 seconds? Wouldn’t that prevent the switch from telling the Ring API to turn the light back off if it is told to ignore any changes made until that time?

Forgive me if any of these questions are naive, I’d just honestly rather deal with a switch that doesn’t reflect the current state than to add issues of less reliable motion detection/notifications for the camera itself or not being able to turn the light back off when it’s physically on on the device.

What’s wild to me is that inside the official Ring app the changes are immediate (seen by physically standing in front of the camera & turning the light on & off by the switch) but the delay only happens when Homebridge/this plugin/HomeKit come into play. Maybe there’s another way to go about this? Like is there any way for the switch to just STAY in whatever state you have it set to, no matter what, but then keep sending the instructions to the API for it to update the device whenever the API finally registers the instructions being sent & not reflect anything other than what you tell it to do in the home app? I personally don’t use the light switch for any automations other than to just trigger it to turn on when motion is detected but no other issues have come from it since nothing else should be really automated if the light turns off (at least in my case), it’s just an annoyance & wondered if there was a fix which is why I searched the previously closed problems & posted this. BUT if this will affect anything else about the way the plugin polls for camera interactions, I’d say it’s probably safe to bet that anyone who cares about camera notification reliability & triggering, will likely care more about that than a simple annoyance of having a switch say one thing when it’s not the case in real life lol.

Thank you both again for taking time to look into this & consider options. If I can be of any help like with a screen record of the issue or anything else just let me know.

[tsightler]

I think you are significantly misunderstand the change. To you concerns:

1. No changes to polling at all, or to motion detection, which doesn't use polling at all anyway (motion/ding events are received via push notifications).

2. This is the only thing that concerns me, any chance you could record a video of the issue and share it here? I mean, I've tested this issue, and can reproduce it fairly easily. You said in the OP that it was a couple of seconds, but then said it caused a cycle every 2-5 seconds. That was close enough to 5-7 seconds for me, but if you are really seeing it in <5 seconds, then I'm not sure what you might be seeing. It could possibly be something slightly different for Spotlight Cam vs Floodlight Cam (I don't have access to a Spotligh Cam, but the API in use and state is the same).

3. Repeating point 1, it has nothing to do with polling intervals, it's just that, for 30 seconds after any local change, homebridge-ring would trust it's local state instead of the state reported by the Ring API, that is all. If you turn the light back off it will still send the command to turn the light off and start the 30 second timer to ignore state over again.

This is roughly what the Ring app does, if you locally change the state it just presents that local state, except it polls even less often, only every 60 seconds or so, or if you manually refresh. Functionally, this is very similar to what you describe as "another way to go about this".

[ohhmyjawwsh]

@tsightler Thank you sincerely for the clarification. I did misunderstand but I’m glad you explained. Totally makes sense. To explain a bit clearer, sometimes it will instantly turn back off. Other times it will take a few seconds, & then other times it catches up with the actual state of the light & matches that even after shutting off. I recorded a video & surprisingly was able to recreate all 3 instances in the same video. Hope this helps. I’m not a developer for this stuff so I do apologize again for misunderstanding but I trust whatever decision made will be to make things better. Thank you!

Since the video was too big to attach, you can use this iCloud link to view it. If you have any issues with that just let me know.
https://share.icloud.com/photos/077r37hCUqVfxTuFB2EmzWXmQ

[dgreif]

@ohhmyjawwsh thanks for the video, that's helpful! A couple questions:

1. Can you post the homebridge logs from a similar scenario, with an accompanying video? That would help us line up the timing to understand what's happening.
2. Try setting cameraStatusPollingSeconds to 0 (which means don't poll at all). I curious if this gets you into a state where it always waits 5 full seconds before showing you any incorrect values.
3. How did you get the light into it's own tile? Did you choose the "Show as Separate Tiles" option in the camera settings?

I'm very open to upping the timer from 5 to 30 seconds, but the video does make me think that the problem will persist, likely because your polling period is so short.

[tsightler]

This video is a little difficult to determine what is happening, but I think it will be 95% better with the 30 second timeout. I can reproduce most of this behavior easily enough. The one that is a little confusing is the near instant flip backs, I'm not sure about those.

I might be a little too optimistic because I used to get nearly identical issues opened on ring-mqtt and, after I went to 30 seconds, they disappeared. Admittedly, I don't even allow users to select the polling interval, ring-mqtt is locked to 20 second polling. I feel like giving people the option to set lower rates gives them the false impression that this will lead to quicker state update, which, as my example above shows, it does not, it just more quickly gives you the wrong state.

[dgreif]

I've released the 30 second bump in 12.0.0-beta.3. @ohhmyjawwsh would you mind giving that a try? If you still have issues, try setting cameraStatusPollingSeconds to 0

[ohhmyjawwsh]

@dgreif @tsightler Hay all. I’ve recorded a few more videos to help as well as tried the new beta.

To answer your question @dgreif, yes, the light switch is in its own tile by choosing “Show as Separate Tiles”. Also so you know, the “Steady Light” switch is a dummy switch I added in Homebridge for an automation I was trying to make work sort of as a lock to keep the light on while I’m in the unit working (ie: if the Light switch turns off while Steady Light is on, turn Light switch back on indefinitely until Steady Light is turned off).

Also, I tried setting cameraStatusPollingSeconds to 0 inside the plugin UI but it gives an error of needing to be 1 or more so I had to manually change this in the config file. I have attached a screenshot of the error message given by the plugin UI.

I recorded 4 videos with different settings in each one. I also did this on my iPad with the Homebridge Logs side-by-side with the Home app using only the mouse cursor so you can see my clicks & also to give highlights to things happening that shouldn’t, etc. I hope this is more clear & helpful.

To note: I have debug mode on & also checked the downloaded log file & it shows no more detailed logging than you see on the screen which I think is wild because it doesn’t show each switch action?? I can’t figure out how to show the verbose or detailed debug logging but I have all those options to show debug logs turned on. You may also notice I stopped all other log-heavy Child Bridges so that the activity log is more clearly just the Ring plugin’s logs.

So, here’s the breakdown:

1st video — made with the non-beta version of the plugin & with the 2 second polling I have had in the config for a long time now. No changes were made before this one (same settings as from the recording I’ve previously provided from on my phone):

https://share.icloud.com/photos/003PMjTY-IgrNpLYlNnaRBF7Q

2nd video — I manually changed the cameraStatusPollingSeconds to 0 in the config file, saved & restarted the Ring plugin’s child bridge to take affect:

https://share.icloud.com/photos/0bdiIg2Bm9SW9iZbaCnriFrAA

3rd video -- I updated to the new beta suggested to try, & changed the poll time back to the 2 seconds to try it:

https://share.icloud.com/photos/0a7tO_n85VheHF_gzTYUzQfmA

4th video -- I am still on the new beta & have now changed the poll time to 0 seconds as recommended to try it on the beta version too:

https://share.icloud.com/photos/049dDD6jb1WrEBc1mycGAKsUw

Key takeaways:
In every video I have at least one or more of the instant kickbacks from the switch immediately reverting to off. Then after that it typically didn't happen ever again the rest of the video. This is quite odd.

I also noticed even on the beta it did not fix much & I still saw the switch not reflecting the actual state. You can see this multiple times on the previous version & the beta version where I circle the camera snapshot & circle the switch showing 2 different states.

Where it gets interesting is that when you're in live view of the camera, the switch is instantly responsive & immediately commands the light with the switch being toggled, & also instantly updates/keeps set to whatever the state of the light is which is to be expected since it's a live connection but pointing this out because there is never any instant kickback to the off state, or any other lag in misreading the state of the light to match the state of the switch. It's the moment that you leave the live stream that the switch becomes unreliable, will not match the active state of the light & now on the beta version of the plugin also sometimes becomes completely unresponsive to clicks (seen at 2:20 on the 4th video) -- this was never an issue I experienced on v11.8.1.

I hope this all can be helpful & if there's anything else you need me to provide or reproduce to help, just let me know. I'm happy to provide the log file after editing out other irrelevant/private data but like I said earlier, it doesn't show anything more than what you can see in the videos on the left side so I'm not sure this would be too helpful but just let me know.

Thank you both so much again for your time & effort looking into this & for this awesome plugin to begin with. :)

[dgreif]

@ohhmyjawwsh Thank for all the additional research and detail. I have not been able to reproduce anything close to this behavior, and have not seen any other reports of this type of behavior. My best guess is that your HomeKit automations are the cause. You mentioned the "Steady Light" that you have set up, which is intentionally changing the state of this light. I recommend you disable all automations (even unrelated ones as you may have accidentally included this light elsewhere 😄) and then see if you can recreate the behavior. The fact that it is so often an instant change is a strong indicator that the polling and Ring side are not the problem, but instead HomeKit is seeing the change and immediately switching it to a different state.

[ohhmyjawwsh]

@dgreif Thank you for your response & suggestion. Unfortunately this could not be the case as that switch has been off this whole time & the only time it runs is if the switch is on (see screenshot) & the only other automation I've ever set up for the light is to trigger the switch when motion is detected by the camera. Since I'm not in the unit & the camera isn't detecting any motion, this would not come into play either unfortunately. Fun fact if it's ever helpful for you; when you view a device's detail & scroll down a little, it will show all related automations whether they are enabled or not so that can really help sometimes to see where you've included the device in stuff.

I will keep playing around with it & hope it just fixes itself with time but it's just very frustrating. Given that the switch works perfectly in live stream but only has the issues when live stream has ended & is utilizing polling with the API, it just keeps me thinking it has nothing to do with my setup since if it was a problem with that or HomeKit reacting based on rogue automations or anything else, the problem would remain very visible while using the switch in live stream but it doesn't & works exactly as it should. Just confusing... but I thank you so much for the plugin & for taking the time to further look into this issue. If you have any other suggestions to try I'm willing to give them a shot & I'll keep an eye out for any other users who mention a similar issue to try to compare our situations & see if there's some common ground.

Hope you have a wonderful rest of your weekend! :)

[dgreif]

The fact that it works correctly during a live stream is definitely an interesting detail, but unfortunately I can't think of a great explanation for why that would make any difference. Maybe it's simply that Ring has an open line to the camera, so the light change is propagated throughout their system more quickly? @tsightler any other ideas?

[tsightler]

I haven't had time to go through all of the videos, but I've mostly focused on video 3, because that's the latest code and the one that is running in a way I would expect most users to configure things.

Unfortunately, there's not much debugging for the light on/off state in the logs, so it makes it a little bit difficult to make guesses. When I watch that video, it mostly works as expected, but there's a couple of cases where it gets out of sync. What would be really interesting is, if after 30-60 seconds, does it ever get back in sync.

@dgreif I don't know if you'd consider adding some additional debugging here, maybe log sets and both API and target state values on gets.

There are a few things in the video that may look like problems but are not, for example, in a couple of cases I see you highlighting that the snapshot image is out of sync vs the light state, but if you look at the log, you can see that the snapshot was updated from a cached snapshot, and the cached snapshot was taken before the light state was changed, so this isn't really an issue. I believe if you had waited one more snapshot cycle, the snapshot image would have been correct.

[dgreif]

I think some additional logging is a great idea. Not sure why I didn't put any in these lights to begin with 😄. Lets get that out and do another recording like the ones posted before.

[ohhmyjawwsh]

@dgreif Sounds good. I can do that & hopefully that can be helpful once we get the logs in there. I tried recording a video with the camera directly in front of me so you can see the physical light too but it was really rushed & very inconsistent so I'll have to try that again later on.

Also I see your point @tsightler, I must've missed that in the moment but honestly the snapshots are the least of my concerns since they do only refresh every 10 (or more) seconds & typically aren't a great reference but it was the best I could do at the time without doing a live stream because when live streaming, everything works absolutely flawlessly which is the confusing part for me. I agree if it had waited one more cycle it might have matched back up again. But yeah let's get those logs in there & I'd be happy to do another video & also can try to record the physical light again too. :)

You guys rock!

[tsightler]

I don't think there's anything more that can be done for this issue, Ring state updates for camera lights are simply not synchronous and can be delayed as much as 30 seconds, so we do the best we can with the logic now.