Fix hybrid/thermal cameras misdetected as doorbells, dropping IVS events - #587
Open
jaaneo wants to merge 1 commit into
Open
Fix hybrid/thermal cameras misdetected as doorbells, dropping IVS events#587jaaneo wants to merge 1 commit into
jaaneo wants to merge 1 commit into
Conversation
is_doorbell() treated any model starting with "DHI-" (and not containing "NVR") as a VTO doorbell. This misclassifies regular cameras whose model just happens to use the common "DHI-" prefix, e.g. the DHI-TPC-BF1241 hybrid thermal camera. Once misclassified, the integration tried to open a VTO connection on port 5000 instead of the normal camera event stream, so the device never received any events at all (not even VideoMotion). is_doorbell() now only matches on the "VTO" substring, matching real Dahua doorbell model names like DHI-VTO2211G-P. Separately, once events do arrive, on_receive() discarded any event whose channel index didn't match the entry's configured channel. That filter exists to handle NVRs/DVRs, where several config entries (one per channel) share a single event stream and must ignore events meant for other channels. Hybrid cameras report IVS events (CrossLineDetection, CrossRegionDetection) on an internal sub-channel that differs from the video channel, so this filter was silently dropping them too, even after the device is correctly detected as a camera. The filter is now only applied when more than one config entry shares the same device address, which is the actual condition that requires per-channel filtering - a standalone camera isn't sharing its stream with anything else. Tested against an IPC-HFW3849T1-AS-PV (unaffected, still filters correctly) and a DHI-TPC-BF1241 added both as a single entry and split into two entries (visual + thermal channel), confirming cross-line and cross-region events now reach the correct entry's sensors.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
I have a DHI-TPC-BF1241 (hybrid visual+thermal camera) alongside several regular IPC-HFW3849T1-AS-PV cameras. The regular cameras receive line-crossing/region events fine, but the hybrid camera never received any events at all, not even
VideoMotion.Root cause 1:
is_doorbell()false positiveAny model starting with
DHI-(and not containingNVR) is treated as a doorbell (VTO). That's too broad - it's meant to catch doorbell models likeDHI-VTO2211G-P, but it also matches regular cameras that happen to use the commonDHI-prefix, likeDHI-TPC-BF1241. Once misclassified, the integration opens a VTO connection on port 5000 instead of the normal event stream, which the camera doesn't support, so it silently never receives any events.Fix: match on the
VTOsubstring instead, which still catchesVTO...,DH-VTO...,DHI-VTO..., without matching unrelatedDHI-prefixed models.Root cause 2: channel filter drops IVS events on hybrid cameras
After fixing
is_doorbell(), the camera started connecting normally, but cross-line/cross-region events were still silently dropped:This filter exists so NVRs/DVRs - where multiple config entries (one per channel) share one event stream - can discard events meant for other channels. But the DHI-TPC-BF1241 reports
CrossLineDetection/CrossRegionDetectionon an internal sub-channel index (index: 1) that differs from its configured video channel (channel: 0), so this filter dropped them too, even for a single standalone entry with no channel-sharing going on.Fix: only apply the filter when it's actually needed - i.e. when more than one config entry points at the same device address. A standalone camera (including a hybrid one with only one entry) isn't sharing its event stream with anything else, so there's nothing to filter out.
Testing
is_doorbell()now returnsFalse, event stream connects normally, andCrossRegionDetection/CrossLineDetectionevents arrive in the debug log withindex: 1.