Okay, thanks. Sorry. I just figured if the PTZ and other commands work remotely, then the snapshots and mjpeg video would too.
Is it possible to have the camera send you photos? I seem able to be able to trigger it but I have no idea how to see the photos.
You can have the camera email you photos based on motion alerts, if that is what you are asking.
Searching the thread for the resolution with the port/IP configuration issue. I am experiencing the same thing and am confident I am using the correct IP. In addition I am using port of 80 or 554.
Thanks!
Did you turn on debug mode? Does the camera work with the Amcrest Web View tool? Are you asking the camera with WiFi enabled if using a local IP?
Greetings,
I acquired three Amcrest IP2M-841 cameras on Amazon Prime day. I’ve connected one of the cameras to my WiFi network and it works fine using the Amcrest Web View app. I’ve installed Belgarion’s SmartThings device type for the 841. I’m able to control the camera using SmartThings (up, down, left right) AND I see captured photos from a security event in the device screen in SmartThings, but the live video feed in SmartThings fails - either “spins” and does not connect OR errors with “Camera cannot be found. We are trying to connect.”.
With Debug turned on, I see the following logging:
e9209e4f-a5fd-43b0-9f68-68d21558bfc7 8:49:55 PM: debug ipIsLocal -> Host IP ‘10.0.0.169’ is Local
e9209e4f-a5fd-43b0-9f68-68d21558bfc7 8:49:55 PM: debug ipIsLocal -> Found = 00001010
e9209e4f-a5fd-43b0-9f68-68d21558bfc7 8:49:55 PM: debug convertIPtoBinary -> IP address passed in is 10.0.0.169 and the converted binary is 00001010000000000000000010101001
e9209e4f-a5fd-43b0-9f68-68d21558bfc7 8:49:55 PM: debug videoStart -> Streaming MJPEG video; apiCommand = /cgi-bin/mjpg/video.cgi?channel=0&subtype=0, IP = 10.0.0.169, Port = 80
e9209e4f-a5fd-43b0-9f68-68d21558bfc7 8:49:55 PM: info videoStart -> Turning Video Streaming ON
I’ve also tried RTSP:
e9209e4f-a5fd-43b0-9f68-68d21558bfc7 8:51:04 PM: debug ipIsLocal -> Host IP ‘10.0.0.169’ is Local
e9209e4f-a5fd-43b0-9f68-68d21558bfc7 8:51:04 PM: debug ipIsLocal -> Found = 00001010
e9209e4f-a5fd-43b0-9f68-68d21558bfc7 8:51:04 PM: debug convertIPtoBinary -> IP address passed in is 10.0.0.169 and the converted binary is 00001010000000000000000010101001
e9209e4f-a5fd-43b0-9f68-68d21558bfc7 8:51:04 PM: debug videoStart -> Streaming RTSP video; apiCommand = /cam/realmonitor?channel=1&subtype=0, IP = 10.0.0.169, Port = 554
e9209e4f-a5fd-43b0-9f68-68d21558bfc7 8:51:04 PM: info videoStart -> Turning Video Streaming ON
e9209e4f-a5fd-43b0-9f68-68d21558bfc7 8:50:46 PM: info toggleStreamType -> Image Streaming Mode Now ‘RTSP’
Any suggestions to troubleshoot this issue?
Thanks.
–Dave
I seem to be having the same issues as user @franklin, and potentially @retrop as well.
It’s 3:28AM, so I’ll post logs tomorrow at some point, but here’s what’s going on for me:
I’ve added the presets in the web view tool. They work there (as well as all PTZ functions), but do not work from the ST App. In fact, when I try to use any of the PTZ or Preset commands, the stream crashes and I have to try and reload it.
A web URL command does produce the preset desired.
I’m streaming H.264H over public IP on http port(s) 18333 and 18334 (two Amcrest cameras). I’m experiencing the same issues on both cameras… Actually, I just went back into the web view tool, and the stream (automatically?) changed from H.264H to MJPEG. I have no idea why.
Frankly, I’m too tired for this right now. I’ll post some more tests & logs tomorrow, but wanted to ping the users above in case they’d figured out a solution since June 12.
Cheers! This is an incredible implementation and I’m so excited. I’ve had these cameras living outside of SmartThings because I hadn’t seen this thread, and I immediately set to work getting them set up when I saw this thread — public IPs through my own domain, etc. — really pumped to get it working.
The streams are hard-coded to use port 554 in the current version of the DTH.
Hi Dave,
Can you confirm that your video stream configuration is set to use port 554 in the Amcrest Web View app?
David,
Thanks. Web View shows 80 at the HTTP port and 554 as the RTSP port. I’ve tried connecting using both protocols with little success. The cameras are setup in SmartThings with Port 80
I spent some time last night trying a few things:
- The camera was setup for a WiFi connection. I connected it with an ethernet cable to the same switch as the SmartThings hub and it had no impact.
- I rebooted the camera a couple of times and it worked for a while using RTSP. It is not working this morning.
- I got around to the creation of a non-DHCP range on my router and did a hard assignment of an IP address to the camera. No impact but I’m now confident that there will be no IP address conflicts or unexpected changes address changes.
- I did notice a couple of instances where the camera “locked up” and then rebooted when I tried to stream to SmartThings. Only did it a couple of times, but I did see this behavior when I first installed.
- I monitored Live Logging in ST and only saw what you’d expect - no errors or unexpected results.
I have three of these cameras setup today. One is WiFI and the other two are wired. None of them stream but all three seem to work for all other purposes (like up/down/zoom/left/right/reset).
–Dave
This has been my experience as well. I have played around with switching between RTSP and MJPEG with mixed results. As best as I can tell this has to do with the undocumented video support in ST’s, as I can not see anything wrong with the way I am making the function calls.
That’s where I landed. There really isn’t much to the function calls. I’ll reach out to SmartThings support and see what they say.
To echo others, nice implementation with the handlers. Thanks much for your work.
–Dave
That’s the RTSP port, correct? I’ve modified the HTTP port(s) on the cameras and forwarded them on the router because I’ve already got an application at prefix.mydomain.com:80 — so now the webview interface is accessible at prefix.mydomain.com:18333 (and 18334 for my second camera), each pointing to the respective local IP addresses of the cameras.
I’m probably just an idiot — if I’m using a public domain, do I need to set up port forwarding for the RTSP port as well? Is the HTTP gateway(s) not enough?
Thanks for your patience with me — definitely learning here!
I suppose I don’t quite understand how, if the RTSP port is a default, I can have multiple cameras addressed from the same public domain (prefix.mydomain.com).
Cheers 
You are correct in that the “hard coded” port 554 is for the RTSP streams only. If you use MJPEG as the stream protocol then it will use the same port that you defined for the camera.
The RTSP port being hard coded is a huge deficiency in the DTH and you are correct in that you can only use RTSP for 1 camera per IP.
I plan on writing a SmartApp for this driver when I find the time and I will address this hard coded port limitation then… but I have been very busy as of late.
So this is probably a dumb question, but here goes…
I have a couple of existing Dlink cameras (5222L) and wanted to add additional cameras to my setup. I acquired a few AmCrest 841 cameras and had issues with getting them to stream to the ST app on my IPhone. I opened a ticket with SmartThings support and the short answer is they won’t support the Amcrest cameras but will support the dLlink at this time. On Friday, all of the cameras would stream with no issue to my IPhone when wifi-connected, a wifi-connected IPad and a wifi-connected Android tablet. If I took the IPhone off of my wifi network (no longer local to the ST hub), then the dlink camera would continue to stream but the Amcrest’s failed. I guess I assumed that the app talked to the hub and video stream was relayed but it seems that is not the case the Amcrest cameras but is for the dlink. I suspect I was just making an incorrect assumption - can someone confirm?
–Dave
Hi @RushDave,
If you have configured the Amcrest DTH to use a local IP, then you turn off your WiFi, your phone is now connected to the net and will not be able to resolve the IP correctly.
I assume the DLink cameras are still working be cause they are not configured to use a local IP?
Sorry, I was unclear. Both the dlinks and the Amcrests are configured to use a local IP. Wired or wireless didn’t seem to matter for the local IP - live streaming works intermittently at best. I guess my point was that even with the local IP, the dlinks work outside of my network meaning that the ST hub/server environment must be relaying the video to the apps. I was surprised it worked.
I did setup unique ports for each Amcrest camera, mapped the local IPs for each in the router to the port, and assigned a resolvable DNS entry to my network allowing me to connect using a non-local IP to the cameras (http://myhome.somewhere.com:9999 where 9999 is a unique port for each camera). This worked in all cases with a browser connection and intermittently with the ST app.
I suspect the intermittent nature for the live streaming is an issue with the ST service not handling connection performance issues - whether on my end or on their end.
For my situation, I’m OK with how this is - not a show stopper for me. But I did find it interesting that that DLink’s worked with a local IP address externally. I’ve asked ST support that same question but haven’t gotten a response.
–Dave
1 Like
This is what I did as well. I am equally surprised that the DLinks worked while outside of the network… interesting! Please let me know what you here back from ST support. 
ST support confirmed that the ST app leverages the dlink cloud to stream the live video. They believe the intermittent issues that I see with both the cameras and ST app is tied to performance issues with my internet connection. I’ve disagreed with them on that assessment as I notice no performance issues AND the cameras work fine with the associated cloud service from the camera vendor (mydlink.com OR amcrestview.com). That’s what I know.
Thanks.
–Dave
Email from ST Support:
Victor (SmartThings)
Jul 26, 12:52 PM MST
Hey Dave
The functionality of your cameras with SmartThings is highly dependent on the speed of your internet connection, so at times, depending on your speeds, the streaming may be limited.
Also, the SmartThings Hub will pull the video from the D-Link camera’s cloud so that you can view the clip within the SmartThings mobile application, so yes, it does relay the video stream so that you can view it externally.
Let me know if you have any other questions or concerns, and have a great week!
Regards,
Victor
SmartThings Support