How to Get Dahua CCTV Online with DMSS
App and Remote Access

What this guide covers
- What a healthy DMSS 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 Dahua 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 do I need before scanning a Dahua recorder into DMSS?
The recorder should already be online locally, have the correct time and timezone, and have platform access or P2P enabled and healthy.
-
Why can I see live view but not get notifications in DMSS?
Because live view and push events are different parts of the setup. The event rule, push linkage, phone permissions, and background activity settings all need to line up.
-
Should every user share one DMSS login?
Usually no. A cleaner handover gives the site an owner account and then shares access properly instead of leaving everyone on the installer login.
-
What often breaks DMSS after an internet change?
Device binding confusion, platform status issues, or recorder network settings that no longer match the new modem or DNS path.
-
Can a phone replacement stop DMSS alerts even if the recorder is fine?
Yes. The new phone may not have notification permission, background access, or the correct device account linked properly.
-
What is the first thing to test after adding a device to DMSS?
Live view first, then playback, then one real push event so the whole chain is proven before handover.
Related Pages
Dahua DMSS Setup and Troubleshooting
Go deeper on the faults that appear after the first DMSS handover.
Dahua Notifications Not Working
Use a narrower checklist if the main problem is missing push alerts.
How to Install Dahua CCTV Systems
Start here if the local recorder setup is not stable yet.
















