Fix SmartMotionHuman/Vehicle not triggered with CrossLine/CrossRegion events - #557
Merged
rroller merged 1 commit intoMar 21, 2026
Merged
Conversation
… events are subscribed When both CrossLineDetection/CrossRegionDetection and SmartMotionHuman are in the events list, translate_event_code() should prioritize translating to SmartMotionHuman/SmartMotionVehicle when the ObjectType matches and a listener exists for the SmartMotion event. Previously, the `is None` check on the CrossLineDetection listener always failed (returned False) when both events were subscribed, because the listener for CrossLineDetection was registered. This meant CrossLineDetection events with ObjectType=Human were never translated to SmartMotionHuman, leaving those binary_sensors permanently off. The fix adds a priority check: if a SmartMotionHuman or SmartMotionVehicle listener exists, translate to it first. The original fallback (translate when no CrossLine listener exists) is preserved for backward compatibility.
Owner
Contributor
Author
|
Thanks. |
Owner
|
Seems this is causing issues and I'll need to revert it #560 |
MicheleMercuri
added a commit
to MicheleMercuri/dahua
that referenced
this pull request
Mar 23, 2026
…teners Fixes rroller#560. The previous implementation (rroller#557) returned a single event code, which meant CrossLineDetection was silently dropped when a SmartMotion* listener also existed. This change makes translate_event_code() return a list of codes so both the original CrossLine/CrossRegion sensor AND the SmartMotion* sensor fire on the same raw event. Three touch points: 1. translate_event_code() → returns list[str] instead of str 2. on_receive_vto_event() → iterates over the list 3. on_receive() → iterates over the list Behavior matrix: | Config | CrossLine + Human | Result | |----------------------------|-------------------|-------------------------------------| | Only CrossLine subscribed | ✓ | [CrossLineDetection] | | Only SmartMotion subscribed| ✓ | [SmartMotionHuman] | | Both subscribed | ✓ | [CrossLineDetection, SmartMotionHuman] | | Neither subscribed | ✓ | [SmartMotionHuman] (fallback) |
5 tasks
rroller
pushed a commit
that referenced
this pull request
Mar 23, 2026
…teners (#561) Fixes #560. The previous implementation (#557) returned a single event code, which meant CrossLineDetection was silently dropped when a SmartMotion* listener also existed. This change makes translate_event_code() return a list of codes so both the original CrossLine/CrossRegion sensor AND the SmartMotion* sensor fire on the same raw event. Three touch points: 1. translate_event_code() → returns list[str] instead of str 2. on_receive_vto_event() → iterates over the list 3. on_receive() → iterates over the list Behavior matrix: | Config | CrossLine + Human | Result | |----------------------------|-------------------|-------------------------------------| | Only CrossLine subscribed | ✓ | [CrossLineDetection] | | Only SmartMotion subscribed| ✓ | [SmartMotionHuman] | | Both subscribed | ✓ | [CrossLineDetection, SmartMotionHuman] | | Neither subscribed | ✓ | [SmartMotionHuman] (fallback) |
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
When both
CrossLineDetection/CrossRegionDetectionandSmartMotionHumanare included in the configured events list,translate_event_code()fails to translate CrossLine/CrossRegion events withObjectType=HumanintoSmartMotionHuman. This leaves theSmartMotionHumanbinary sensor permanently off, even though the camera correctly detects humans.Root cause
In
translate_event_code(), the existing logic at line 597:checks whether the listener for the CrossLineDetection event key is
None. But when bothCrossLineDetectionandSmartMotionHumanare in the events list, the CrossLineDetection listener is registered, soget()returns the listener (notNone), and the condition always evaluates toFalse. The translation never happens.This affects users who have both IVS (CrossLineDetection/CrossRegionDetection) and SmartMotion events enabled — a common setup with WizSense cameras (e.g. IPC-HDW3441TM-AS) connected through an NVR.
Fix
Added a priority check before the existing fallback: if a
SmartMotionHumanorSmartMotionVehiclelistener exists, translate to it directly when theObjectTypematches. The original fallback logic is preserved for backward compatibility (translates to SmartMotionHuman when no CrossLine listener exists).Testing
CrossRegionDetectionandSmartMotionHumanin the events listSmartMotionHumanbinary sensors never turned onSmartMotionHumancorrectly triggers on human detection events