01Create a rule and select cameras
Open Rules → Add new rule, choose object detection or hardhat detection, then select devices and cameras. Once saved and enabled, the assigned processor executes the rule; the website can be closed.
Choose objects and confidence in rules. Rules on the same camera share inference. Search labels come from observations meeting the corresponding rule object threshold, not a separate history setting.
02Choose a scope for each camera
Presence/staying rules can use the whole frame or a separate region on each camera. Whole frame needs no drawing. A multi-camera rule shares conditions and recipients, not region coordinates.
Crossing requires a tripwire and direction on each camera. A region or mask cannot be selected as a tripwire. Fix invalid scopes before use; they do not silently become whole-frame rules.
Regions, crossing and exclusions ↗03Set conditions and repeat interval
Multi-observation confirmation always applies. Duration starts after the same object meets confidence and scope; a score drop resets unfinished duration, not its ID. This is separate from notification cooldown.
New rules default to a 60-second cooldown per camera within the rule. Camera 1 does not block camera 2. A continuously true presence condition does not alert every 60 seconds: it must trigger again. Existing rules retain their configured interval.
04Enable delivery and choose recipients
Configure Telegram, SMTP or MQTT under Push, then enable the delivery method and choose recipients or destinations in the rule. Telegram is recommended; email uses configured SMTP.
Saving a rule does not turn on notifications by itself. With delivery off or no valid destination, events may still appear without any message being sent. Check the delivery summary on the rule card.
Notification setup guides ↗05Test, review and duplicate
Test with a real target and check the source camera, snapshot, matched conditions and delivery result in Events. A YOLO label in a historical frame does not prove that scope, duration and cooldown passed.
View-level detection settings have been removed. Configure objects and confidence in rules.
06Read upload status and historical diagnostics
Unlimited rule events · 30-day cloud retention. Rule events and historical keyframes have no hourly count or aggregate image-byte quota. Keyframe uploads require no paid plan. Image size, API request rates, sampling, local cache and retention remain bounded; semantic search still depends on your plan. This is not unlimited video storage or guaranteed delivery.
Historical diagnostics on the processor page stays collapsed. Invalid records, such as events for deleted rules, are quarantined without retrying or blocking other uploads. Default local retention is up to 7 days from capture, subject to capacity; the next report after cleanup updates the count. Collapsing diagnostics does not delete evidence. Investigate if the count keeps growing.
Missing recent processor reports mean counts may be incomplete. Available quota does not prove delivery to recipients. Pending data retries after recovery; events older than 10 minutes at upload are archived without automatic catch-up notifications.
Common questions
Must a couch and bed appear together?
No. Multiple selected classes match any selected type. Car and truck are separate classes too.
Why is there a historical frame but no rule event?
Searchable observations do not necessarily trigger an event: scope, activity, duration and notification cooldown are evaluated separately.
How do I clear a persistent quarantine warning?
Historical quarantine no longer acts as a current overview alert. Expand Historical diagnostics on the processor when needed. Retention cleanup removes cached records; evidence need not be deleted just to hide a notice.