What url did you use for the BI request? Scramble the password of course.
Local web request
Robin
#33
Very odd… you’re right, if that works the other one should???
Take it you tested your URL with the port included via a browser?
jrfarrar
#34
Yes with port…of course after I hit enter the browser removes it. It really is port 80 NOT 81 like my screen cap above…I fixed it. That was holdover from when I tested the BI server as that port is 81. Maybe I should see if I can force the camera’s http port to 81… i’m stretching at this point. And I can take that URL in my browser and make this camera go back and forth to presets all day long
jrfarrar
#35
Ok so it looks like there is a large delay trying to make that request… the 10:58:30 is when I hit the test button.
Robin
#36
As long as you are quoting the correct port, it shouldn’t matter so changing the port (if possible which is unlikely) will achieve nothing.
As Ian said, webCoRE defaults to port 80 if not told otherwise so for port 80 you don’t even need to state the port at all.
Robin
#37
I’d say that delay is just in the reponse… not the sending.
Response shouldn’t matter for this type of command anyway.
jrfarrar
#38
This is actual URL I’m sending (except password) using GET and JSON. Copied right out of webcore. I even eliminated the variables…
ipaterson
#39
Looks like that particular request may have timed out… I don’t really know where to go from here since you’ve already confirmed that both the camera and hub are on the same subnet. It is possible to block host-to-host communication on your network but you would know if you had done it.
Robin
#40
His requests to Blue Iris went through ok so host-to-host most be ok
I’d be interested to know if using a WAN IP works, just as a test? You could disable port forwarding after.
jrfarrar
#41
Well I’m on a path…seems that the local computer I was using here was already authenticated to that camera. As a tried the link on my phone to see if another device would trigger. I immediately got prompted for username/password. So I apologize. It seems that passing the username/password via variables isn’t going to work for this camera. Explains why the BI test worked and now I know webcore doesn’t support http://username:password@.
Robin
#42
Maybe try the authentication header method instead… instructions are on the BI FAQ I posted above.
ipaterson
#44
I think you’re looking for Basic YWRtaW46cGFzc3dvcmQ= in the Authorization header where the encoded part is just base64 encoding of username:password (you can generate the value here if necessary since webCoRE doesn’t have a base64 encode function)
jrfarrar
#45
Thank you, I tried that and it didn’t work.
Digging through camera’s API documentation now. I see reference to supporting both basic and digest…but no luck yet and this camera’s documentation (Dahua) is not necessarily ever up to date or easy to read in English 
jrfarrar
#46
Found this in the code for BlueIris fusion…can this help? Fusion can move a camera to a preset. I’m assuming through the BlueIris server connection.
httpPostJson(uri: parent.host + ‘:’ + parent.port, path: ‘/json’, body: [“cmd”:“ptz”,“camera”:shortName,“button”:presetNumber, “session”:session]) { response4 ->
and found this finally on a forum:
“I think Dahua switched to digest authentication which may be your problem.”
so Fusion is my last hope
jrfarrar
#47
@ipaterson @Robin I found an answer!! BlueIris does accept commands to move to a ptz point and it doesn’t seem to even require authentication. Tested in webcore locally and ran fine.
http://{BI_server_IP}:81/cam/{CAM SHORT NAME}/preset=2
Hope this helps someone else.
Robin
#48
There is a option (settings > web server > advanced) where you can turn off authentication on LAN, must be off for you hence no need to authenticate (I have mine setup the same).
I’ll add your URL format to my FAQ and give you credit… well found!!
jrfarrar
#49
Don’t credit me(lol)…I found it on IPCAMTALK forum. Working like a champ in webcore! I see a few more PTZs in my future now…this functionality in webcore makes them very useful. BTW, Thanks all. Webcore and this forum are seriously the best.
pnbruckner
#50
Hi all. I’ve been dealing with the same issues (reading this and other topics for clues as to how to make it work.) I’m trying to send exactly the same kind of PTZ command (as well as some others) to an Amcrest IP2M-841 IP camera I have. What I found is:
- This camera does not accept username and password as part of the query string (i.e., &user=…&pw=…) like Blue Iris does.
- This camera (with the latest version of firmware) does not accept basic authentication. It only accepts digest authentication.
- This camera has an option for an anonymous user, but in that case it only allows viewing the video stream (i.e., you can’t use PTZ commands, etc. that way.)
- When using a webCoRE web request with http://username:password@address…, where the address is external (i.e., not on the LAN with the hub), it will work, because under the hood WC/ST is recognizing the camera requires digest authentication and automatically resends the request with the proper headers.
- Doing the same with an internal address (e.g., 192.168.x.x) does not work because WC/ST does not automatically support digest authentication in this case.
FYI, I’ve added a feature request:
Bottom line, given all these constraints, the way to make it work (i.e., directly from webCoRE to the camera) is to use an external address, and set up port forwarding as necessary on your Internet router.
One last tidbit: I tried to use https instead of http (with the proper port numbers and forwarding), but that didn’t work either because the certificate the camera generates for HTTPS causes the following error:
Hope this helps.