IpCamera binding and Amcrest camera

Hello @matt1

I am still seeing some strange behavior with the Amcrest IP3M-943B model. Please see the trace log below. I notice this particular message:

HTTP/1.1 401 Unauthorized

2018-12-22 11:53:12.320 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - Sending camera at IP:192.168.0.46,     URL:/cgi-bin/snapshot.cgi?channel=0
2018-12-22 11:53:12.332 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - CommonCameraHandler created.... 4 channels tracked (some of these may be closed).
2018-12-22 11:53:12.343 [TRACE] [ipcamera.internal.MyNettyAuthHandler] - MyNettyAuthHandler is now setup for    GET:/cgi-bin/snapshot.cgi?channel=0
2018-12-22 11:53:12.345 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - Have re-opened  the closed channel:0   GET:/cgi-bin/snapshot.cgi?channel=0
2018-12-22 11:53:12.369 [TRACE] [ipcamera.internal.MyNettyAuthHandler] - 401: Normal for DIGEST authorization.  URL:/cgi-bin/snapshot.cgi?channel=0
2018-12-22 11:53:12.371 [DEBUG] [ipcamera.internal.MyNettyAuthHandler] - 401: Mark as closing, the  channel:0   GET:/cgi-bin/snapshot.cgi?channel=0
2018-12-22 11:53:12.374 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - Resending using a fresh DIGEST     URL:/cgi-bin/snapshot.cgi?channel=0
2018-12-22 11:53:12.376 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - Sending camera at IP:192.168.0.46,     URL:/cgi-bin/snapshot.cgi?channel=0
2018-12-22 11:53:12.384 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - CommonCameraHandler created.... 4 channels tracked (some of these may be closed).
2018-12-22 11:53:12.398 [TRACE] [ipcamera.internal.MyNettyAuthHandler] - MyNettyAuthHandler is now setup for    GET:/cgi-bin/snapshot.cgi?channel=0
2018-12-22 11:53:12.401 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - Have re-opened  the closed channel:2   GET:/cgi-bin/snapshot.cgi?channel=0
2018-12-22 11:53:12.403 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - DefaultHttpResponse(decodeResult: success, version: HTTP/1.1)
HTTP/1.1 401 Unauthorized                                                       
WWW-Authenticate: Digest realm="Login to AMC01857529401DFB3",qop="auth",nonce="885970889",opaque="c030d02c0c128144ebfd5edcf11b54ffad75c010"
Connection: close                                                               
CONTENT-LENGTH: 0                                           
2018-12-22 11:53:12.406 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - Channel marked as closing, channel:0   URL:/cgi-bin/snapshot.cgi?channel=0
2018-12-22 11:53:12.407 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - EmptyLastHttpContent
2018-12-22 11:53:12.410 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - Camera has sent some kind of message.Bytes=0
2018-12-22 11:53:12.411 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - Camera has sent last part of the message.Bytes=0
2018-12-22 11:53:12.414 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - commonCameraHandler closed channel:0   URL:/cgi-bin/snapshot.cgi?channel=0
2018-12-22 11:53:12.415 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - Closing CommonCameraHandler.       URL:/cgi-bin/snapshot.cgi?channel=0
2018-12-22 11:53:12.423 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - commonCameraHandler closed channel:2   URL:/cgi-bin/snapshot.cgi?channel=0
2018-12-22 11:53:12.425 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - Closing CommonCameraHandler.       URL:/cgi-bin/snapshot.cgi?channel=0
2018-12-22 11:53:21.321 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - !!!! Channel was found idle for more than 15 seconds so closing it down
2018-12-22 11:53:21.325 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - EmptyLastHttpContent
2018-12-22 11:53:21.328 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - Camera has sent some kind of message.Bytes=0
2018-12-22 11:53:21.331 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - Camera has sent last part of the message.Bytes=0
2018-12-22 11:53:21.334 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - commonCameraHandler closed channel:3   URL:/cgi-bin/eventManager.cgi?action=attach&codes=[All]
2018-12-22 11:53:21.337 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - Closing CommonCameraHandler.       URL:/cgi-bin/eventManager.cgi?action=attach&codes=[All]

That log is printed out after I triggered the Update Image switch, and the image was not updated. The password is accurate, and the image was updated just fine 10 minutes ago. Could it be that they have some sort of speed control to black list the client for a while if they access the API to quick?

Thanks,

Unathuorised is completely normal for digest cameras. Every second response from the camera will be a 401 unauth message as that is how the secret handshake is done.

There is a black list but not sure what triggers it, you can it off in my cameras settings.

Also you can crash the web server in the camera if too much traffic is done with motion alerts turned on. Test by disabling all alarms and see if the feature works.

Lastly I found the cameras settings for quality, compression and key frame generation made a difference when wanting 1 second snapshots from the camera.

You will have to play and see what makes a difference. Just ignore the 401 unauthorised messages they are normal if you are also seeing working replies.

matt1,

Thanks for the hints. I lowered the resolution. However I still notice that sometimes the motion alarm is triggered very fast, and repeatedly, but other times nothing is triggered. I had an SD Card in the camera, and when looking in the Playback view, I did see the camera’s recorded motion alarms that weren’t fired by the binding.

This means that the camera’s motion detection is correct, but it either doesn’t always send it to the API listener, or somehow something interferes with the listener causing it to not receiving the event. I looked around the camera settings, and I see a setting for the # of connection, which is defaulted to 10. I increased it to 20 but it doesn’t help. Is the binding holding a keep-alive connection with the camera for the motion alarm? Sorry I haven’t had time to read the Amcrest APi spec yet. Is the motion alarm working reliably for your Amcrest cameras? I wonder if the connection might be gone somehow.

Thanks,

Set the camera up as Dahua and not amcrest and you then get the alarm keep alive you are after.

Matt1,

Mine is actually set up as Dahua.

ok it may be…

  1. the debounce/dejitter setting stopping it. Enter this into a browser to see. The moment you use the openhab controls to turn the alarm back on it will reset this value…
/cgi-bin/configManager.cgi?action=setConfig&MotionDetect[0].Enable=true&MotionDetect[0].EventHandler.Dejitter=0
  1. or it may be when the stream is restarted it misses alarms, watch the logs to see if it happens when the log tells you the stream was stopped.