How to Get Hanwha CCTV Online
App and Remote Access
What this guide covers
- What a healthy Wisenet Mobile handover should look like on a normal site
- How to bind the recorder or camera properly instead of only half-finishing the app setup
- Why push notifications fail even when live view appears to work
- Two worked examples showing the actual online setup path and what fixed the handover
What the app should do on a normal job
On a healthy Hanwha system, the app should do four basic things reliably: show live view, allow playback, stay linked to the correct device account, and deliver the notifications the client was promised. If one of those pieces is weak, the problem is usually not just the phone app by itself. It is normally a mix of recorder setup, platform access, phone permissions, event linkage, and account handover.
What to check before adding the device
- The recorder or camera is online locally and has the correct time and timezone.
- The platform or P2P setting is enabled and healthy on the device.
- The installer knows whether the client needs one master login or shared user access for multiple people.
- The site internet is stable enough that remote view and push events will not be blamed for an unrelated WAN problem.
- The phone has permission for notifications, background activity, mobile data, and local network access where required.
If those items have not been checked, the phone handover is usually guesswork. A device that is offline locally or still on the wrong timezone will often look like an app fault when the real fault is still at the recorder.
Step-by-step online setup
Step 1: make sure the recorder is already healthy on the local network
Before opening the app, confirm that the recorder or camera is visible locally, the date and time are correct, and recording is already working. If the device is not healthy on the local network first, the app handover will only hide the underlying problem for a short time.
Step 2: create or confirm the correct user account path
Decide who should own the system. On a home, that is usually the main household owner account first, then shared access for other family members. On a business, it is usually a site owner or manager account first, then any additional operator access. The mistake we often see is leaving the whole site on one installer login, which becomes messy the moment a phone changes or access needs to be removed.
Step 3: enable the cloud or P2P service at device level
Go into the recorder or camera network or platform settings and confirm the cloud or P2P service is enabled and shows healthy status. If it shows offline, not connected, or an error state, solve that first. Scanning a QR code before the device is ready rarely fixes anything.
Step 4: add the recorder or camera using the correct identifier
On most ordinary sites, the recorder is the cleaner thing to add rather than each individual camera, because the user then gets one organised path for live view and playback. Use the QR code, serial number, or the brand's normal account-binding method. Name the device clearly inside the app so the user can recognise it later, especially if they may have a second property or a second site in future.
Step 5: confirm live view and playback before touching alerts
Once the device is added, confirm that live view opens normally and that playback works by date and time. This is where you find out whether the timezone is wrong, the main stream is too aggressive for the client's phone, or the recorder was never properly initialised.
Step 6: set up user sharing properly
If more than one person needs access, share the system deliberately. Give the right people the right level of access instead of passing around one password by text message. This matters because family members, reception staff, managers, and contractors often do not all need the same rights.
Step 7: configure notifications in the recorder and on the phone
Notifications are never just a phone setting. The event has to be enabled on the recorder or camera, the schedule has to be correct, the event must be linked to push, and the phone must allow notifications and background activity. If the client expects after-hours alerts only, test that exact condition rather than only forcing a daytime event while standing next to the installer.
Step 8: test the final real-world workflow
Press through one actual use case before leaving. That may mean walking through the rear gate, crossing the after-hours line, or triggering the specific scene the customer cares about. Confirm the phone receives the alert, the app opens, and playback can be found. This is the step that usually separates a clean handover from the later support call.
Why notifications usually fail
Most notification complaints are not caused by the app store version alone. They usually come from one of five causes: the smart event rule was never properly enabled, the schedule is wrong, the event was not linked to push at the recorder or camera, the phone is blocking background activity, or the device is bound to the wrong account. That is why the better handover tests push events deliberately rather than assuming they will work because live view is online.
Sharing access without creating confusion
For homes and small businesses, it is better when each user has the right level of access instead of everyone sharing one admin login. That keeps the handover cleaner and makes later support easier if a phone is replaced, a staff member leaves, or a family member only needs viewing access. If the site is larger, document which account is the owner account and which logins are ordinary operators.
Home system that recorded perfectly but never sent alerts
Situation: The client could see live video on the app, so they assumed the phone setup was finished. Two weeks later they realised no-one had received a single after-hours alert from the driveway or side gate.
Solution used: The recorder event schedule was corrected, push linkage was enabled on the correct camera rules, and the phone battery restrictions were turned off for the app.
Why this was chosen: The real problem was not remote view. It was that the handover never tested a push event end to end. Once the recorder logic and phone permissions were both fixed, the app behaved normally.
Installation notes: The client was shown how to trigger a test event and how to recognise the difference between a network problem and an event-linkage problem later.
Small business with a new manager and a replaced internet service
Situation: The original installer login was still the only working account, the site internet had recently changed, and the new manager could not get playback on the app even though the recorder was still recording on site.
Solution used: The platform status on the recorder was confirmed, the device was rebound into the correct user handover path, and the new manager received their own clean account access.
Why this was chosen: The goal was not just to get one phone working again. It was to leave the site with a proper owner account and a cleaner long-term support path.
Installation notes: Playback, live view, and one real event were all tested before the handover was signed off, and the manager was told what to check first if the site ever changes modem or ISP again.
Common mistakes
- Scanning the QR code before platform access is actually enabled and healthy.
- Using one installer login forever instead of handing over proper user access.
- Assuming live view means alerts are already configured.
- Ignoring phone-level notification restrictions.
- Replacing the app before checking recorder time, event linkage, or account binding.
When to ask for help
If the device shows offline, the QR handover is unclear, playback is unreliable, or notifications still do not work after basic phone-permission checks, take photos of the recorder network screen and the app error state before changing more settings. That usually saves time and prevents the original fault from being buried.
Relevant SecurityWholesalers pages
Frequently Asked Questions
-
What is the first thing to check before adding a Hanwha recorder to Wisenet Mobile?
Make sure the recorder is recording locally, has the right time and timezone, and has the remote or QR-connect service path ready before the phone is involved.
-
Is Wisenet Mobile enough on every Hanwha site?
No. It is a useful phone handover path, but some sites will still need a stronger viewer or VMS client path as part of the final system design.
-
Why might Hanwha live view work while playback still feels wrong?
Because time settings, user permissions, or the way the recorder is handed over can affect playback even when the app connection itself is working.
-
Should each manager or operator share one phone login?
Usually no. A cleaner multi-user handover avoids confusion when staff change or one user only needs limited access.
-
Can notification complaints be caused by the phone rather than the recorder?
Yes. Battery restrictions, background limits, and notification permissions can all block alert delivery even when the recorder is correctly configured.
-
What should be proven before calling the app handover complete?
Live view, playback, one real event if alerts were promised, and confirmation that the correct end users can sign in reliably.
Related Pages
Hanwha WAVE vs Standard NVR Path
Use this if the real issue is the whole client workflow, not just the mobile app.
How to Install Hanwha CCTV Systems
Go back here if the recorder and network path are not stable enough yet.
How to Choose a Hanwha NVR
Make sure the recorder branch itself fits the job you are handing over.