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.

The basic online setup order

Create or confirm the correct EZView account path for the end user.
Enable the cloud or P2P service on the recorder or camera before scanning anything.
Add the device by QR code, serial, or the correct account-binding method for that brand.
Confirm live view works first.
Turn on notifications only after the event logic on the recorder or camera has been tested.
Share or hand over access to the actual users rather than leaving everyone on one installer login.

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.