Support

Hanwha Notifications and Event Rules Setup

Hanwha notification problems are usually not app problems on their own. The clean path is to prove the detection rule, the schedule and the recipient logic first, then test push notifications or email only after the event works locally.

Hanwha Analytics Support

Summary

Use this guide when a Hanwha site needs cleaner alert setup for motion, analytics or event-driven notifications through the recorder or broader Hanwha workflow.

Applies to

Hanwha recorders and Wisenet workflows
Sites using motion or analytics-triggered events
App, email or operator alert handover

Difficulty and time

Difficulty: Moderate

Estimated time: 20 to 45 minutes

What you will need

Recorder or VMS admin access
Working owner or operator app account
One camera with the target detection rule
Time to run a real walk test

What this guide covers

Detection before notifications
Schedules and recipients
Analytics versus basic motion
False-alert reduction

On Hanwha systems, the wrong commissioning order creates noisy apps and unhappy users. If you turn on push alerts before the analytics rule is proven, every later phone complaint becomes harder to diagnose because you do not know whether the issue is detection, recording, schedule, recipient setup or the phone itself.

Before you start

Check that the camera or recorder already records correctly.
Confirm the owner account is the one receiving the first test alerts.
Choose one camera and one event type to prove first.
Make sure the time zone and clock are correct before using schedules.

Step 1: Decide whether you are using basic motion or analytics

Do not mix these together in your head. A site using object analytics should usually be tuned around that logic, not broad untargeted motion.

Use basic motion only where scene noise is low and the customer accepts broader triggers.
Use analytics where the site wants more targeted human, vehicle or rules-based events.
Keep one rule active first instead of enabling every possible alert type at once.

Step 2: Prove the event on the recorder or VMS before you touch the phone

The event should be visible locally first. If the recorder never sees the event properly, the phone cannot fix that.

Confirm the event counter or event list changes when a real test walk happens.
Check the detection area, sensitivity and object filtering.
Run one real test under the same lighting and angle the site normally sees.
Confirm the resulting clip is recorded where expected.

Step 3: Apply schedule logic carefully

Many notification complaints turn out to be schedule complaints. The customer thought alerts were set for after hours only, but the rule was live all day or never armed at all.

Set the arming or event schedule before adding users and recipients.
Keep the first test schedule simple.
Check whether weekends, holidays or overnight spans need special handling.
Repeat the event test after the schedule is saved.

Step 4: Add recipients and test only one notification path at first

Choose the cleanest first alert path, usually the real owner or responsible site user.

Confirm the phone is logged into the correct Wisenet Mobile account.
Turn on phone notification permissions before calling the notification broken.
Use one recipient first, then expand to other users only after the base path works.
If email or broader notification paths are used, test them separately rather than all at once.

Step 5: Reduce false alerts before wider rollout

A notification path that technically works but annoys everyone is still a bad setup.

Reduce scene noise, tighten the detection area and review thresholds.
Keep trees, flags, moving reflections and public footpath noise out of the active rule if possible.
Review night behaviour separately if the customer mainly cares about after-hours alerts.

Worked example

After-hours office alerts only

Situation: An office only wanted night alerts from the rear car-park entry, not daytime alerts from staff movement.

Solution used: One analytics rule was created for the rear entry, the schedule was limited to after hours, and the owner account was tested before staff access was added.

Why this was chosen: It proved the event chain cleanly before other users were introduced.

Installation notes: False triggers from headlights were tuned down after the first night test.

Related support guides

Relevant product categories

Still stuck?

Need help choosing or setting up a system? Contact SecurityWholesalers support with your order number, product model and a clear description of the issue.

Frequently asked questions

Should I turn on notifications before I test the event locally?
No. Prove the event and recording path first, then add the phone notification layer.
What is the usual cause of Hanwha alerts being too noisy?
Usually the detection area, schedule or object logic was too broad for the real scene.
Should every user receive the same alerts?
Not always. It is often better to prove the owner path first, then add other recipients only if they genuinely need the same event stream.