Is there an existing issue for this? <li class="

<a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/us

See attached a screenshot from my phone: <a target="_blank" rel="noopener noreferr

<a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/us

1 out of 2 camera's do not send events,about dgreif/ring

Comments (15)

danielvand commented on September 21, 2024 1

@tsightler thanks again, I completely understand you need to do something with the Refresh Token Updated event, was just an experiment (that failed). Thanks for explaining the length difference with those tokens.
I think I found the problem. It looks like I reached a certain amount of authorized user devices, I removed them all via account.ring.com and now it all seems to work!
Thanks again for your help.

from ring.

tsightler commented on September 21, 2024

Can you please run Data Discovery and provide the output of both cameras?

Also, are you definitely getting notifications from the second device on your Ring app? Note that I don't mean events. If you could catch a screenshot of a notification from said camera on your phone but not from ring-client-api, that would be interesting.

from ring.

danielvand commented on September 21, 2024

Yes I do get notifications on my ring app (and alexa echo)
What kind of screenshot do you want from Ring? From the history of events or from the notification in the notificationbar?

from ring.

tsightler commented on September 21, 2024

Notification bar itself would be useful. Events in history don't always produce a notificaiton so it's hard to know anything from that. But I'd like to just see a notification on the phone that wasn't received at all by ring-client-api to see if there's any possible clues about why such a notification would not arrive to ring-client-api.

The problem we have here is that the overall code path isn't rocket science, rather it is quite basic. When started, ring-client-api registers as a device that can receive Firebase push notifications using a token. That token is sent to Ring via the API so that Ring services can send notifications to the token ID associated with that specific client. The client is either subscribed to events or not. If you are receiving some notifications, but not others, then it can only be that Ring is not sending notifications for that device, or perhaps it is sending a different notification type, but no idea why.

from ring.

tsightler commented on September 21, 2024

There is some interesting information in the discovery data. For the older cameras the detection mode for motion/human/package_delivery is "cloud", while for the newer camera it is "edge". This makes me think that Ring has implemented such detection in the camera itself, which is fine, but I wonder if this type of detection actually produces a different notification message type.

Out of curiosity, do you definitely not get notifications of doorbell dings on the new doorbell? Or is there any chance that it's only motion events that are being missed?

from ring.

danielvand commented on September 21, 2024

See attached a screenshot from my phone:

While trying to reproduce the issue, now I don't get any notification via the ring-api. It looks like it is able to connect to Ring, but while listing it doesn't get any notification. Any clue how to debug?

I'm running this example: https://github.com/dgreif/ring-client-example/blob/main/example.ts

from ring.

qreeves commented on September 21, 2024

@danielvand Out of curiosity, did you delete and re-create the motion zone on the camera that is no longer working? I recently did this on all of my devices (Stick Up Cams, and Video Doorbell Pro) and have not been able to get motion events through ring-mqtt since. Came here looking for info on how to debug and can't even get the Data Discovery node packages to work.

from ring.

tsightler commented on September 21, 2024

@qreeves I think it is unlikely that deleting and recreating motion zones are the cause of your issue, although I know it might seem that way if they happened at a similar time. As long as you are receiving notification on the Ring app, then notifications should work here as the methods used are identical and are completely unaware of any motion zone settings. It's based 100% on whether Ring sends a notification to the correct FCM token for the associated device or not.

If you are having issues with ring-mqtt I would suggest opening an issue on that project, but first make sure you have followed the steps outlined in the ring-mqtt v5.3.0 release notes to reset notifications. If you've done that, feel free to open an issue on the ring-mqtt project and we can look into it.

@danielvand I think I have an idea of what is happening in your case, at least why camera notifications stopped completely. I'm guessing (although I don't know this) that you generated a refresh token via the command line and are just re-using that token rather than monitoring for onRefreshTokenUpdate and saving the updated token when it arrives.

This is more critical now than in the past because the initially generated token contains just the refresh token needed to make the very first connection to the Ring API, however, during that initial connection the session is established, system ID is generated, and device registration with GCM is preformed and FCM token is generated and pushed to Ring to send the notifications. All of this is then re-encoded into the updated token so that the same GCM registration/FCM token will be used in the future.

However, if you don't save this updated refresh token, and just keep using the cli generated token over and over, ring-client-api will generate a new GCM registration/FCM token every type you reconnect. This will keep notificaitons from working during future restarts.

Can you verify if you are re-using the initial token or if you are monitoring onRefreshTokenUpdate and saving a new token?

from ring.

qreeves commented on September 21, 2024

Yeah sorry, didn't mean to hijack here. As a FOSS dev myself, I hate opening issues until I've exhausted my ability to collect information. I will follow the correct procedure if I don't end up figuring it out. Thanks for the pointers.

from ring.

tsightler commented on September 21, 2024

@qreeves Sure, it's no problem, just like to avoid confusion. I'm the maintainer for ring-mqtt but also spent a ton of time tracking down the notifications issues when Ring changes the behavior back a few months ago. A lot of users that either don't upgrade regularly, or don't restart often only recently started having notificaitons issues due to Ring huge outage about a week ago that forced restarts. If users had never followed the steps required in v5.3.0 and later, then they will lose notifications after that restart, even if they had continues to work up until that point.

There's also still the possibility that there are corner cases or some other behavior we haven't uncovered yet, but, so far, no user that has followed the instructions after upgrading to v5.3.0 or later have reported having the problem come back, and it's been months.

from ring.

danielvand commented on September 21, 2024

@tsightler thanks for you answer and help! I'm following this example: https://github.com/dgreif/ring-client-example/blob/main/example.ts
This used to work in the past nicely. (Using this example I build some custom stuff, but I thought I start here again till it works) So I generate a token the first time from cli, I save that in .env file and as soon as I start it, it gets a onRefreshTokenUpdated and rewrites a new token into the .env file. But the actual token I get on the event is the same as I already got via the cli. I don't get a onRefreshTokenUpdated event (or any notifications or events) since then.

Just a thought, if it was something with the token shouldn't it work in the beginning till it expires? Also without a valid token from the beginning it shouldn’t be able to connect and/or show me the devices?

from ring.

danielvand commented on September 21, 2024

It's getting more strange by the minute. While playing around, I see the following behaviour:

create token via cli --> new token of 1117 chars
run script, gets Refresh Token Updated --> same 1117 chars token as via the cli
within seconds 2nd Refresh Token Updated --> token of 2265 chars long, which has been identical for the last days (weeks?)

So my thinking was, what if I take the Refresh Token Updated out on purpose, because with that cli generated token I can connect to the api, but no luck, same result.
I'm not sure if it's around the update of the token?

from ring.

tsightler commented on September 21, 2024

@danielvand I tried to explain above why this is critical now when it perhaps wasn't in the past, but I guess it was not clear.

Just a thought, if it was something with the token shouldn't it work in the beginning till it expires? Also without a valid token from the beginning it shouldn’t be able to connect and/or show me the devices?

No, because again, as of a few months ago, the refresh token now contains more than just the refresh token. If you just keep using the CLI generated refresh token over and over you will never save the persistent hardware ID, GCM credentials and FCM token, as those are not generated until the first time the token is used, but after that point are stored along with the refresh token in the encoded string. It is now absolutely critical that the updated refresh token be saved and used for future restarts or notifiations will abolutely not work.

from ring.

tsightler commented on September 21, 2024

It's getting more strange by the minute. While playing around, I see the following behaviour:

create token via cli --> new token of 1117 chars

run script, gets Refresh Token Updated --> same 1117 chars token as via the cli

within seconds 2nd Refresh Token Updated --> token of 2265 chars long, which has been identical for the last days (weeks?)

Not strange, looks exactly as expected, the second updated token includes the additional persistent credentials which are used to receive push notifications, generated specifically for that registered client. In previous versions this was just generated new each time the connection to the Ring API was made, but Ring stopped allowing this some months ago, so now you must save this information, and it's now wrapped into the token.

This is why saving the refresh token is critical every single time. If you don't save that initial longer refresh token, notifications will not work on subsequent restarts of the API. If you save it at some later point, without first removing the registered device from Ring Control Center, it also will not work.

from ring.

tsightler commented on September 21, 2024

Awesome! Glad it is working for you now!

I certainly think that there is some room for improvement here, perhaps we should generate the full credential during initial token generation via the CLI, then it would be somewhat less of an issue, but, in general, it was already important to store the tokens and most project did monitor onRefreshTokenUpdated anyway, so it was a way to address this new Ring API change without requiring a new method to be implemented for every project using this library. It just became pretty much non-optional to store them with 11.8.0 and newer since, if you don't, camera notifications will only work the very first time you use the token.

from ring.

1 out of 2 camera's do not send events about ring HOT 15 CLOSED

Comments (15)

Related Issues (20)

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent