Adding RTSP Cameras to eZLO Plus controller

Amcrest Cameras:

rtsp://[username]:password@IPaddress:554/cam/realmonitor?channel=1&subtype=0

You said you had your cams working in other apps right? Like VLC so then you have your RTSP URLs correct. But to add that into the Vera app in the Advanced settings area you would do the following:

Camera IP - 192.168.1.136:2020
Username - yourusername
Password - yourpassword
Camera RTSP URL Path - /cam/realmonitor?channel=1&subtype=01

I see you are using port 2020 however, maybe the Vera app doesn’t like that maybe?

Why are you using port 2020 ? On the internal LAN IP of the camera? I assume you changed the port number on your camera settings yes ?

I have several cameras, one was set to mjpeg just to test the stubstream URL but the rest are h.264.

I have modified some of the ports for forwarding through my firewall but even 554 standard didnt work.

I changed one substream to test but thanks for noticing.

Not sure then. I fixed my issue with my Hikvision cameras by not using streams that were using MJPEG as the video decoding and using H.264 instead.

And I was also able to add another Ezviz brand camera OK first time into the Vera mobile app.

I did not use any port forwarding stuff however, do you actually need to do that for the Vera mobile app?

Because your Ezlo controller is on your LAN and your cameras are on your LAN presumably, so they can talk to each other directly on the local LAN IPs and internal standard ports of the cameras etc.

I just tested this by turning off wifi on my phone (simulating remote access via 4G) opening the Vera mobile app and playing my 3rd party Generic IP Cameras and they did play OK.

Its the Vera / Ezlo cloud relay servers that get you that internal access when you are outside of the home.

Now if you were using an app like TinyCam Pro for remote access to the cameras then yes, you would need to do port forwarding from the Internet to the LAN.

So in that case you might have port 2020 on your router / port fowarding rules list and use your static ISP Internet IP address (or DDNS domain name) and that then gets NAT translated into port 554 and the actual internal LAN IP of the camera. That’s what I do anyways.

But if you are unable to even play your cameras in the Vera mobile app whilst that phone is on the local WIFI then you still have a lower problem than thinking about remote access from the Internet and port forwarding. Get it working on the LAN first if you can then try remote access.

Post a screen shot of your cameras settings in the Vera mobile app, under Advanced settings area / the connection settings. Thanks.

Thanks for the testing, I see you got hikvision working very similar. Im using this on a local network with the hub and cameras, the ports forward and are customized but for now I can not add anything. I left it alone all day to let support attempt to add using iOS.

I will try to add it again and post a pic. I also have a video of it working on that google drive link, it was well documented with support when I finally got it working, I had to have their help since the app wasnt working to add it and finally I got it working. I will post an update once I hear back from them.

thanks again.

I added an older Amcrest PTZ camera using the same RTSP URL and it shows in the app not on the web dashboard. Support also added the ADC2W and it shows in the mobile app not the dashboard. I think the subtype should be 01 but 00 is showing here but they are testing with that so Im going to stay out of the controller.

here is a few screenshots.



In the RTSP URL field I would of removed everything before the /cam part of it.

Perhaps it doesnt matter ?

According to that Amcrest support page they said the subtype=0

But maybe that doesnt matter either. Which subtype is working?

That is an idea worth trying, I wondered about it being redundant that way
UPDATE-
I wondered about the URL stream field since you said use everthing after “/cam”

I tried it and it works both ways I created 3 cameras and all work in the dashboard despite the URL stream showing different paths. thats curious !!!



Noted, I will wait until I hear from the technicians because that is the camera they are testing.
I added that other older model as listed.

(ADC2W note- I like that wide angle 133 degrees)
UPdate from support saying this ADC2W cam is giving this information

I asked about the other camera still same brand older model. Both on h.264 for primary and substreams.

Support contacted me to discuss this, I slept on it and today, checked the substream encoding, it WAS MJPEG. I changed it to h.264 and it is working! I dont know how that changed to MJPEG or maybe I am just old and got confused testing both ways! I am sure it is h.264 out of the box and I reset it and power loss tested it to be certain.

Sure enough that newer AMCREST MODEL: ADC2W works using

/cam/realmonitor?channel=1&subtype=01 (only 0 for substream doesnt and I see per my original support notes I shared this exact stream url noting the 0 problem)

Im stoked I couldnt have done this without the great help from B~ at support! We addressed multiple issues in apps etc to get this going and now the work begins!

I hope this helps others using the new controllers/interfaces.

4 Likes

So you got the camera working with the sub stream and h.264 ?

Or it only works with the main stream ?

I believe I am pulling the substream and its h.264.
Im using

/cam/realmonitor?channel=1&subtype=01

I want to post another “close encounter” situation for you IP RTSP camera enthusiasts.

My Amcrest branded cameras mentioned in this thread did something shocking.
My cams are on wifi, using a linksys router all DHCP. All created using this thread. All working! IT just works!

Now today, im back on site adjusting the DHCP network, reserved IPs for all the cameras and the EzLO Plus Controller. All the IP Addresses were manually Reserved in the router configuration page. My router gets a NATTED WAN IP so I created a subnet 10.10.10.1 with DHCP range at 100 up.

My cams got new IPs. I routed them in sequential order from 101 to 105 and the Ezlo Controller at 106.

I did this Just in case the local IP stream listed in the MiOS dashboard is itself or loopback as old guys say.

The Dynamic Dashboard on the Ezlo Plus Controller found ALL the cameras at the “new” IP addresses. How did this happen? Something I will need to sleep on.

I am amazed, I have never seen a URL relocated without using a name service perhaps…it used the name of the device to locate the new IP??

Either way it is “dynamic” and saved me a ton of work! It took longer to write up than to login to the router and arrange the IPs in sequence reserved via DHCP control.

This Dashboard just “adapted” to the new IPs and played video! Bravo! :astonished:
alot of other zwave controllers could never pull this off.

2 Likes

The original unit that “lost” the live view repeated the same behavior. I redeployed it to another site with different cameras using this thread specific URL.

Worked for 24 hours. then back to failed.

I think Ezlo were having some issues with the playback of the ip cams in the dashboard recently, not sure if its fully resolved yet? Know my dashboard has been struggling to play all my cams lately.

This unit in particular has several logic problems included but no limited to showing playback. I have a few others that are not having this issue. Its just this one. In fact, they cameras worked fine when I was on site setting them up they played immediately but just magically when I drive back home and check, they are just buffering.

Mine have looked like this for days