node-red-contrib-ring-intercom 0.2.0

Node-RED nodes for a Ring Intercom (unlock + ding events), message-compatible with NRCHKB.

npm install node-red-contrib-ring-intercom

node-red-contrib-ring-intercom

Node-RED nodes for a Ring Intercom: unlock control and ding events, shaped to plug straight into NRCHKB nodes for HomeKit exposure. No video (see project docs for why).

Nodes

• ring-account (config): holds a Ring refresh token and the shared API client. Generate a dedicated token once with npx -p ring-client-api ring-auth-cli (do not reuse the token from homebridge or any other install -- see Troubleshooting).
• ring-intercom (in+out): one per physical intercom.
  • Input: { payload: { LockTargetState: 0 } } triggers unlock (same shape as NRCHKB's Lock Mechanism node output -- wire it directly).
  • Output: { payload: { LockCurrentState } } (msg.event: 'lock') and { payload: { ProgrammableSwitchEvent: 0 } } (msg.event: 'ding').

How dings are delivered

Dings arrive in realtime via Ring's push notification channel (FCM), the same mechanism the Ring app and homebridge-ring use: the account node's shared RingApi registers one push receiver, and ring-intercom subscribes to the device's onDing stream.

A 15-second event-history poll runs behind push purely as a watchdog: any ding that push already delivered is recognised (by event timestamp) and suppressed; a ding that push missed is still emitted -- at most 15s late, never lost -- together with a loud warning that push is unhealthy.

Troubleshooting realtime push

If dings only ever arrive via the fallback (yellow node status, "push missed a ding" warnings), work through these in order:

1. Use a dedicated refresh token. A token copied from another install (e.g. homebridge-ring) is a base64 "wrapped" token embedding that install's hardware id and FCM push credentials; two installs sharing it invalidate each other's sessions and steal each other's push registration. This package strips the wrapper defensively, but the underlying OAuth token is still shared -- generate a fresh one with npx -p ring-client-api ring-auth-cli.
2. Avoid duplicate push receivers. The account node keeps one RingApi alive across redeploys precisely so only one FCM socket exists per account. Restart Node-RED fully after upgrading this package so no receiver from an old version lingers (ring-client-api never closes its push socket, so a full deploy on the old version leaks one per deploy).
3. Enable "Verbose Ring logging" on the ring-account node and redeploy. Push-subsystem failures then show in the Node-RED log prefixed [ring]:
   • PHONE_REGISTRATION_ERROR -- FCM registration is failing. It is retried 5 times, then the library gives up until the next restart. If it persists, delete <userDir>/node-red-contrib-ring-intercom/ring-<node-id>.token and re-paste your token so a fresh push identity is registered.
   • Connection to the push notification server has failed -- outbound TCP/5228 to mtalk.google.com is blocked (firewall/IDS/DNS adblock). Allow it; push cannot work without it.
4. Check the device subscription. ring-intercom re-asserts the server-side ding subscription on every deploy; a warning Failed to subscribe to ding events means Ring rejected it -- check the account has full access to the intercom (shared users can lack event access).

Public key is not valid for specified curve in the log

Harmless, and handled since 0.1.1. @eneris/push-receiver drops a notification it cannot decrypt only for three specific failures; anything else it rethrows from a TLS socket handler, where nothing can catch it -- so a notification whose crypto-key header is not the dh=<base64> shape its decryptor assumes used to surface as an uncaught ERR_CRYPTO_ECDH_INVALID_PUBLIC_KEY exception (upstream 4.3.1 still behaves this way). The account node now wraps that decryptor so such a notification is dropped like any other undecryptable one, logging

[ring] Dropped an undecryptable Ring push notification (ERR_CRYPTO_ECDH_INVALID_PUBLIC_KEY); appData keys: [...], crypto-key prefix: "..."

A dropped payload carries nothing actionable, and a ding lost this way still arrives via the event-history watchdog poll (which flags push as unhealthy). If you see these together with "push missed a ding" warnings, work through the list above -- the drops are then a symptom of a push-identity conflict, not the cause.

Testing

• npm test -- unit + node-load tests, no network.
• npm run smoke:ring -- env-gated, read-only live check (RING_REFRESH_TOKEN or a gitignored test/.token file). Never calls unlock.