Are you missing a push(button) method in doorbell code?
What model ? Stand alone or NVR?
Also, periodic snapshots don’t seem to be running. The URL works fine.
Release: Reolink Integration v1.3.1
Fixed a missing doorbell command and a light-detection gap.
Problem:
The doorbell driver declares the PushableButton capability (needed for the pushed/numberOfButtons attributes so Rule Machine can trigger on a doorbell press), but never implemented the actual push() command the capability requires clicking Push on the Commands tab (or any app/rule calling it) threw a MissingMethodException. Separately, the new supportedFeatures attribute from v1.3.0 under-reported a doorbell's light, since doorbells report it under a different ability key (supportDoorbellLight) than cameras do (supportFLswitch).The Fix:
Added push(buttonNumber) to the doorbell driver and routed the real doorbell-press event through it. Updated supportedFeatures detection to check both light keys. Also confirmed supportAiPackage as the real package-detection field name against real doorbell hardware.Action needed:
None. Existing doorbells will show the correct light capability the next time supportedFeatures is refreshed (Check Abilities command, or next discovery run).
Well Crap: Fix one thing- break another.
Release: Reolink Integration v1.3.2
Fixed a false negative in PTZ Calibration detection.
Problem:
The supportedFeatures attribute's PTZ Calibration detection was gated on the field supportPtzCalibration but that field incorrectly reported "unsupported" on at least one camera confirmed to actually support calibration through the Reolink app. The original reasoning for trusting that field turned out to be built on a case where it happened to agree with a different, more reliable field, and that agreement didn't hold up against real-world testing.The Fix:
Switched the primary signal to supportPtzCheck (the ability flag tied to the actual API endpoint calibration status checks use), which matched real calibration availability on every camera tested. supportPtzCalibration is now checked as a secondary fallback only.Action needed:
None. Existing devices will show the correct calibration capability the next time supportedFeatures is refreshed (Check Abilities command, or next discovery run).
Looks good. Had to use “image” tile to get auto refresh.
That’s the correct path. Image
Refresh settings are in the device page itself.
Release: Reolink Integration v1.3.3
Known older-firmware bug causing false "asleep" reports.
Problem:
Some cameras on ~2021-era firmware have a documented bug (confirmed independently via Reddit and Reolink's own support docs) where the camera's web server intermittently returns corrupted/garbled data instead of a real response and not encryption, not a real connectivity issue, just bad data back from the camera. The app couldn't tell that apart from the device being genuinely unreachable, so it got reported as asleep.The Fix:
The app now detects this specific failure (a JSON parse failure on an otherwise-successful HTTP call) and retries once immediately with the same session before giving up, since a second attempt right after a failed one often succeeds. Also added a Tips page section explaining the bug, how to recognize it in your logs, and remediation steps in order of effort . Toggling HTTP/HTTPS off/on and rebooting the camera first, then a firmware update via Reolink's Download Center or a support request if that doesn't help.Action needed:
None. If you're on affected firmware, check the new Tips page section for the recommended fix steps.
Release: Reolink Integration v1.3.4
Fixed connectivity-failure log spam.
Problem:
A single source going unreachable (host down, network issue) previously logged 2-3 separate warnings every poll cycle with both a raw connection failure and confusing secondary "Cannot invoke getAt() on null" from trying to parse a response that never arrived, and "no token available." This repeated in full for as long as the outage lasted, producing dozens of near-identical warnings for one ongoing problem.The Fix:
Only the transition into or out of "unreachable" now logs a warning. The first failure logs once and says further identical warnings are suppressed until it recovers, and reconnecting logs a single "connection restored" line. Full-tier logging still shows every individual attempt for anyone actively troubleshooting. Also added a Help & Support section to the main page with links to the community thread and a way to support the project.Action needed:
Update via HPM
Release: Reolink Integration v1.3.5
Capability-detection corrections, cross-checked against Reolink's own library.
Problem:
v1.3.1 incorrectly grouped a doorbell's status/ring indicator light in with the Spotlight feature, based on real hardware showing that ability field nonzero on a doorbell that only has IR night vision and a button light or no true spotlight. Separately, we'd never had a field mapped for IR/night-vision capability at all, and our ability-lookup logic only checked one of the two data fields Reolink's API actually provides per capability, leaving room for a field to be misread if the two ever disagreed.The Fix:
Split the doorbell light into its own "Status LED" feature and added a proper "Night Vision" feature. Added floodLight back as a defensive fallback for spotlight detection. Ability lookups now check both data fields Reolink provides instead of just one. Confirmed the battery percentage field name directly rather than guessing. All of this was cross-checked against Reolink's own officially-backed reolink_aio library, which a community member kindly pointed us to.Action needed:
None. Existing devices will show the corrected feature list the next time supportedFeatures is refreshed (Check Abilities command, or next discovery run).
Release: Reolink Integration v1.3.6
Fixes a discovery-page bug where unchecking a device would not actually remove it, plus some clarity improvements to that page.
Problem:
On a standalone (single-channel) source, unchecking an existing device in the discovery list never removed it. The auto-apply logic only fired when a box was checked, not when it was unchecked, so the removal path never ran. Multi-channel sources already worked correctly in both directions, but the toggle that applies changes was labeled in a way that only described adding devices, not removing them.The Fix:
Single-channel sources now apply changes in either direction, checking or unchecking. The multi-channel apply toggle is relabeled to make clear it both creates checked devices and removes unchecked ones. Every device row now says outright whether it is an existing or new device. The source-removal toggle is reworded to make clear it deletes the entire source, unrelated to the per-device checkboxes above it.UI Update:
Added visual improvements in the Integrations page for each device with important notes.No action needed, update through HPM.
Roadmap: Exploring event-driven updates instead of polling
A heads up on something I'm exploring, separate from the current release.
The problem:
Right now (default), every device gets polled, on a timer every few seconds, for wired cameras, and 30s for battery. That works, but it means there can be a delay between something happening and Hubitat finding out. For most things, that's fine. For a doorbell where you want a light to turn on the instant a person is detected at night, a few seconds of lag is noticeable.What I'm looking at:
Reolink cameras, NVRs, and Hub products support persistent connections that can push events such as motion, AI detection, and doorbell presses the moment they happen, instead of waiting to be polled. The exact capabilities, and event pushes, vary by device and firmware. The goal is to use event-driven updates wherever the device supports them, with polling as an automatic fallback.The plan:
Event-driven updates would be the default, with the integration automatically falling back to polling if the connection drops or event-driven updates aren't supported by a particular device. This ensures that no device is worse off if this makes it to production integration.If this proof of concept is successful, it will require a new driver and bridge. As a result, existing rules and dashboards will be affected, and the devices will need to be fully rebuilt within HE.
While that would be a minor setback, the potential benefits would outweigh the inconvenience if this works as expected.
Where this stands:
Internal testing only, on a separate build, and not touching the production app or drivers.I may open this up to a small group of testers once I'm confident in it. That's a genuine maybe, not a promise or a timeline. Reolink's firmware varies enough across models and generations that I want this proven on more than just my own hardware after initial testing.
Updates to follow as things develop.
No action needed at this time, just staying transparent about what's in progress.
Anyway you can include a "PIR Enabled" boolean in the next release? It'd be great to have so we can enable/disable battery-powered cameras from recording.
I have looked into this and will add once I am done with the internal testing for events-driven updates. Check you DM
Revised: No further updates will be introduced until 1.3.7 BETA testing is complete on my end, which has gone well so far. As stated previously, the eventual release will break existing rules and dashboards, since a new parent driver structure changes how child devices are created (meaning new device IDs). This will benefit the integration going forward.
I have both Home Assistant and the current release of the Hubitat Reolink Integration. They are both syncing with my Home Hub (which has 2 wired cameras and 2 battery cameras).
When the Hubitat integration is active, it causes continuous state polling and synchronization loops that conflict with Home Assistant's event subscription handling for the Reolink Home Hub. Specifically, this rapid polling triggers a cascade where battery powered camera channels on the hub continuously toggle between active and standby states. This continuous state thrashing overwhelms the persistent Baichuan TCP push connection on port 9000, causing the event subscription to drop and fail to re-establish after roughly 3 to 10 seconds. Disabling the Hubitat integration immediately stops the state flooding and stabilizes the socket connection.
Hope this snippet of information helps.
Can you DM me the logs of this when it happens so i can use them for reference?
This actually lines up directly with why I've been testing event-driven updates instead of polling. The whole motivation was cutting down on exactly this kind of constant polling traffic hitting the Hub, in favor of one lightweight persistent connection instead. Your report is a good concrete example of the problem that's meant to solve, not just the notification-lag angle I'd been focused on.
Still mid-testing on that, found and fixed a few real bugs already, some more still open. No promises on timeline, but this is genuinely useful context for that work, so thank you for taking the time to write it up.
Is this stand alone or behind a NVR or Hub?
Do you have other cameras ?
What make and model doorbell ?
