Browser Push Notifications

[sjonez]

I noticed on the web portal that you can access at ring.com it now has browser push notifications available for dings/motion. Is this something you can make use of so that dings are event driven rather than polled?

[sjonez]

I think that notifications (to chrome at least) use firebase messaging, so I don't know if something like this would help https://github.com/MatthieuLemoine/push-receiver

[dgreif]

Hey @sjonez, thanks for pointing this out! I also noticed this feature a few weeks ago and did some digging into fcm to see if we could leverage it here. I didn't find push-receiver in my research, but that definitely looks like a promising option. I'm currently working on camera streaming in the beta branch, but will probably look into this once streaming is stable. Would make a huge difference if we could get push notifications instead of polling the API!

[dgreif]

Success 😁. Figuring out the senderId for the android app was the trickiest part, but I have my ways 😏. I've got everything integrated and working reliably on my end. Released version 10.0.0-beta.4 if you care to give it a try. Thanks again for all your help and encouragement to push forward with this approach, I have been wanting to solve this problem for years!

[sjonez]

Just tested, it works great! Not only do we now get push notifications but I can now make use of smart notification types too, amazing!

Thanks for the super quick turnaround time from idea to code in just a few days :)

Just a quick question, there is still some polling required to get the camera status right? In order to retrieve battery level and siren/alarm state and such - I assume that polling hasn't been removed?

[dgreif]

Yep, that polling is still in place, defaulting to every 20 seconds. It can be increased with the settings if you're not using camera accessories for automations. I've been keeping a close eye on how Ring fetches that data and they still use polling from the web and the Android app. Hopefully someday they migrate that to websockets like the alarm system

[sjonez]

FYI I left the new example.ts running all night and while it is certainly picking up events I did notice this in the output:

(node:6801) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 ON_READY listeners added to [PushReceiver]. Use emitter.setMaxListeners() to increase limit
(Use `node --trace-warnings ...` to show where the warning was created)

Any idea why I would have 11 listeners setup?

There were also quite a few of these, but not sure if that's just normal connections being dropped and re-established:

Error: read ECONNRESET
    at TLSWrap.onStreamRead (node:internal/stream_base_commons:217:20) {
  errno: -104,
  code: 'ECONNRESET',
  syscall: 'read'
}

[dgreif]

Thanks for pointing these out. I think the MaxListeners warning is just going to happen because of how PushReceiver handles reconnects: https://github.com/Eneris/push-receiver/blob/master/src/client.ts#L159-L170. It shouldn't be an issue.

The ECONNRESET are similar, it's just an error trying to read from the stream, likely due to a network blip of some kind. I see a number of these in my logs as well.

Fixing these would probably require a PR to Push Receiver. I'll keep it in mind, but both seem harmless so far