What should I check before adding a Uniview recorder to EZView?

Check that the recorder is online locally, has the correct time and timezone, and has the cloud or P2P service ready before you try to bind it to the phone.

Does EZView guarantee that notifications will already work?

No. Push events still depend on the recorder or camera event rules, the alert linkage, and the phone permission settings.

Should the whole site share one EZView login?

Usually no. A cleaner owner-account and shared-user path makes later support easier when phones change or staff change.

Why can live view work while playback or alerts still feel wrong?

Because those parts of the handover depend on more than the connection itself. Time, event logic, and account binding all matter.

What if the site has changed internet provider?

Recheck the recorder network settings, cloud state, and account binding rather than assuming the cameras themselves are the fault.

What should I prove before leaving the site?

Live view, playback, one real event if alerts were promised, and clean user access for the people who will actually run the site.

Commercial

How to Get Uniview CCTV Online with EZView

EZView is most useful when the recorder and camera setup are already healthy on site. If the device is not recording properly, the time is wrong, or the event rules were never finished, the app handover will look worse than the underlying system deserves.

App and Remote Access

Uniview network video recorder — A Uniview recorder needs to be set up cleanly on site before EZView is treated as the solution to every remote-viewing question.

What this guide covers

What a healthy EZView 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 Uniview 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.

Worked Example

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.

Worked Example

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 should I check before adding a Uniview recorder to EZView?
Check that the recorder is online locally, has the correct time and timezone, and has the cloud or P2P service ready before you try to bind it to the phone.
Does EZView guarantee that notifications will already work?
No. Push events still depend on the recorder or camera event rules, the alert linkage, and the phone permission settings.
Should the whole site share one EZView login?
Usually no. A cleaner owner-account and shared-user path makes later support easier when phones change or staff change.
Why can live view work while playback or alerts still feel wrong?
Because those parts of the handover depend on more than the connection itself. Time, event logic, and account binding all matter.
What if the site has changed internet provider?
Recheck the recorder network settings, cloud state, and account binding rather than assuming the cameras themselves are the fault.
What should I prove before leaving the site?
Live view, playback, one real event if alerts were promised, and clean user access for the people who will actually run the site.