[Release] Reolink Integration - Cameras, Doorbells, NVRs & Home Hubs

Custom Apps and Drivers Custom Apps
83

I can handle testing. I'm mostly at this property on weekends, so it may take a few weeks to get it worked out depending on your availability and mine. I'm pretty clear on how it would go with the Hubitat rule. Thanks.

84

Returned, and have now created a doorbell device that seems to be working fine! Not sure what was up, but suspect "operator error"!! Many thanks for your work on this integration.

85

Spoke too soon!

After upgrading to Reolink Integration v1.4.2, my standalone Reolink doorbell no longer provides a Snapshot URL.

The device itself is working normally: motion/AI states update, the cached token is valid, and the Device Bridge connection reports healthy. However:

  • No snapshotUrl attribute appears under Current States.

  • Pressing Take Snapshot produces no snapshot-related log entry.

  • Normal GetAiState / GetMdState polling continues successfully.

The doorbell is configured as a standalone device rather than through an NVR.

It appears the standalone-device parent/bridge path may not be forwarding componentTakeSnapshot() through to the main Reolink Integration app in v1.4.2.

Could you please check whether snapshot/component command passthrough for standalone devices has been omitted or broken in the recent update?

Happy to provide additional logs if useful.

86

Release: Reolink Integration v1.4.3

Hotfix for manual commands silently doing nothing on standalone (non-Hub/NVR) cameras and doorbells.

Problem:
Standalone camera or doorbell bug - Commands like Take Snapshot, Refresh, PTZ, spotlight, night vision, siren, PIR, and battery/ability checks did nothing at all, with no error or log entry to explain why. Motion and AI detection kept working normally, which made this easy to miss.

The Fix:
A standalone device's real Hubitat parent is the "Reolink Standalone Devices" group device, not the app directly. That group device was only forwarding logging calls up to the app, not the actual commands themselves, so every one of those commands failed silently one step before it ever reached the app. This has been broken since the 1.3.8 bridge restructuring, not something 1.4.2 introduced. Fixed by adding the full set of command forwarding the group device was missing.

Action needed: Update to 1.4.3 in HPM.
No device deletion or re-discovery needed.

Thanks @Mclass for reporting it

87

Release: Reolink Integration v1.4.4

Hotfix for event connections that report "connected" indefinitely while actually dead, silently dropping motion/AI events.

Problem:
A production install test went several days without a single motion event from a doorbell, despite motion genuinely occurring (confirmed independently through an other means).
The bridge device's Connection Status still showed "connected" the entire time with no error, no warning, nothing in the logs pointing at it.

The Fix:
The existing keepalive was sending a packet every 25 seconds but never checking whether anything came back. :frowning:
Fixed by tracking the timestamp of the last genuinely received message and checking it on every keepalive cycle: if nothing real has come in for 90 seconds despite regular keepalives, the bridge now forces a reconnect itself instead of waiting indefinitely on a socket error that may never arrive.

If you've had a camera or doorbell that quietly stopped delivering events with no obvious cause, this is very likely why.

Action needed: Update to 1.4.4 via HPM.
No device deletion or re-discovery needed.

88

Release: Reolink Integration v1.4.5

Hotfix for event connections not recovering after a hub reboot.

Problem:
After a hub reboot, a source's event connection could come back showing "connected" while actually being completely dead with no motion, no AI detection, nothing delivered, with no error anywhere to explain it. The only way to recover was manually stopping and restarting the event subscription by hand.

The Fix:
This is a different bug from the one fixed in 1.4.4. That fix watches for a connection going silently dead while it's running. This one is upstream of that: after a reboot, the app never re-started the connection in the first place, because it trusted its own saved "connected" status from before the reboot.
Hubitat preserved that data, even though the real network connection can't survive a restart. With no connection ever re-established, 1.4.4's watchdog had nothing to watch. That saved status is now cleared automatically on every hub restart, so a fresh connection is always attempted.

Action needed: Update the app to 1.4.5
No device deletion or re-discovery needed

89

Reolink Standalone Devices Error – Wired Doorbell

I’m getting a recurring error from the Reolink Standalone Devices driver associated with my Reolink wired doorbell.

The doorbell is configured through the Reolink Device Bridge (Doorbell) and otherwise appears to be communicating normally, but the following error is being logged:

2026-09-01 12:46:09.432 pm

error

org.codehaus.groovy.runtime.metaclass.MissingMethodExceptionNoStack:
No signature of method:
user_driver_jdthomas24_Reolink_Standalone_Devices_2261.componentEventChannelUpdate()
is applicable for argument types:
(user_driver_jdthomas24_Reolink_Device_Bridge_2260,
java.lang.Integer, java.lang.Integer, java.lang.String, java.lang.String)
values: [Reolink Device Bridge (Doorbell), 3, 0, none, none]

I have run HPM Check for Updates/Repair and confirmed the Reolink integration is current, but the error continues.

It looks as though something being reported by the wired doorbell is not being handled correctly by the Standalone Devices driver.

Could you please have a look?

90

Release: Reolink Integration v1.4.6 @Mclass

Fixes a recurring error on standalone (non-Hub/NVR) cameras and doorbells where every real-time motion, AI, and visitor event push failed silently.

Problem:
A standalone camera or doorbell's event connection is parented under the "Reolink Standalone Devices" group device, not the app directly. That group device forwards a fixed set of commands up to the app on the device's behalf. componentEventChannelUpdate(), the method that delivers every real-time motion, AI, and visitor event, was added to the integration after that forwarding set was last built out, so it was never included. The result was a MissingMethodException logged against the Reolink Device Bridge device itself for every single event push on a standalone source. Motion and AI polling were unaffected since they don't use this path, but the event-driven update path relies on it entirely. Hub and NVR sources were never affected, since their bridges parent directly off the app.

The Fix:
Added the missing passthrough method to the standalone group device driver, matching the same pattern already used for every other command it forwards.

Action needed:
Update via HPM as normal.

91

Many thanks for your prompt response!

mclass