IpCamera: New IP Camera Binding

I’m also having the same problem with a Hikvision PTZ camera.
Model: DS-2DE3304W-DE
FW: V5.4.8 build 170210

Trace:

2019-07-01 20:25:18.663 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - Fetching the number of Media Profiles this camera supports.
2019-07-01 20:25:22.951 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - Checking the selected Media Profile is a valid number.
2019-07-01 20:25:22.954 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - Fetching a Token for the selected Media Profile.
2019-07-01 20:25:22.957 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - About to fetch some information about the Media Profiles from the camera
2019-07-01 20:25:22.959 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - *********** Media Profile 0 details reported by camera at IP:192.168.1.9 ***********
2019-07-01 20:25:22.962 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - Camera will use this Media Profile unless you change it in the bindings settings.
2019-07-01 20:25:22.964 [WARN ] [ing.ipcamera.handler.IpCameraHandler] - Following NPE occured when trying to connect to the camera with ONVIF.java.lang.NullPointerException
2019-07-01 20:25:22.967 [ERROR] [ing.ipcamera.handler.IpCameraHandler] - Since an NPE occured when asking the camera about PTZ, the PTZ controls will not work. If the camera does not come online, give the camera the wrong ONVIF port number so it can bypass using ONVIF and still come online.
2019-07-01 20:25:23.428 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - Sending camera GET: http://192.168.1.9:80/Streaming/channels/101/picture
2019-07-01 20:25:24.065 [TRACE] [ipcamera.internal.MyNettyAuthHandler] - MyNettyAuthHandler is now setup for    GET:/Streaming/channels/101/picture
2019-07-01 20:25:24.067 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - Have  opened  a  brand NEW channel:0   GET:/Streaming/channels/101/picture
2019-07-01 20:25:24.096 [INFO ] [ing.ipcamera.handler.IpCameraHandler] - IP Camera at 192.168.1.9:80 is now online.

Thanks for the reply @matt1, appreciated the feedback. I’ll go with the better more supported cameras i think. I’d prefer better integration than using work arounds.

@Zippochonda and @lfs_alp5

Yes there does appear to be an issue in the onvif library that I am using as the NPE is occurring in the library and not my code. I am looking at it as I have time and a work around may be possible or there are a number of new onvif libraries being created however they do not yet have PTZ features. This only happens with some cameras, others like mine are working great just with a 8 second delay from when you ask the camera to move to when it actually moves.

@spudatron
Yes you get a lot more value out of cameras that cost a little more.
For example some of my security cameras can produce 3 streams with different settings all at the same time.

  1. 4K video feed with h265 compression goes to storage.
  2. mjpeg format stream
  3. h264 stream to cast to TVs as my older chromecasts don’t support 4k so feed 1 can’t be used.

The cameras can tell me if people are walking towards the house or away from the house plus more via smart alarms. Even the basic video motion alarms can be fine tuned to ignore small animals and only detect humans. Cheap cameras don’t have the highly polished firmwares and features and usually have far lower picture quality especially at night time.

Get 1 decent camera to trial and you will soon see the value in them.

Hello @matt1, congrats on your work on this binding!

I have encountered an issue when using it with my Hikvision DVR.
Since each camera sets up its own streams, there are multiple connections to /ISAPI/Event/notification/alertStream, one for each camera.
Unfortunately the DVR borks after 4-5 concurrent connections with statusCode:4, causing events to not be registered for all cameras.

If you can use a single stream for events for cameras which have the same ip:port configuration, and notify each thing depending on the channelID present in the stream, I thing it would work OK, and we would actually be conserving resources.

I am available to test and provide feedback whenever you need.

Glad to hear you find the binding useful and thanks for reporting the issue, I was not aware there was a limit. I have though about fetching a single stream but so far I have not thought of an easy way to program doing that between multiple things. If it was a HIK only binding it would be to create bridges for the NVR.

I believe there are two ways to use the NVR, one is the way you are now and the second is to enable access to each camera via different ports. See the manual for the NVR for how as I wont assist with that. Then each camera is still the same IP which is the IP of the NVR but each port will be different. If you could test and see if that works around the issue that would be great and I’ll put a note in the readme file for HIK cameras/nvr.

Yes that is the way to go; i use camera direct access this way, every camera on the NVR get’s an unique portnumber.

It is a DVR with 16 Analog cameras (DS-7216HUHI-K2), not an NVR. I don’t see an option to have a different port for each camera, since the event processing is done directly on the DVR and not on the camera itself.

I think a Bridge type object would be a welcome future addition for supporting multicam devices.

New build 2019-07-08 has these changes:

  • updated methods to support the Esp32 cameras. These cameras used two different ports so I had to make some changes to get these running. Example thing and item files can be found here https://community.openhab.org/t/diy-digital-doorbell-peephole-camera/76417/8
    NOTE: These cameras can not provide more than 1 stream at a time unless you use this bindings features to copy and serve the stream. This means you can not start the stream inside the cameras webpage and in openhab at the same time as only the first one you try to open will work.

  • Temporary work around for a bug where some urls were getting reported as being at double port :80:554 from possible issue in onvif library.

  • Updated channel cleaning to keep track of Netty’s channels.

@AchilleGR
I’ll keep it in mind to see if there is an easy way to do it.

I just updated the binding from version a 2.4. Snapshot version to the latest version. With the new binding, my Amcrest camera starts to produce the following messages in the log (nothing has changed in the config of the camera, the thing and the item):

2019-07-11 12:55:52.616 [INFO ] [ing.ipcamera.handler.IpCameraHandler] - IP Camera at 192.168.2.203:80 is now online.

2019-07-11 12:55:59.625 [WARN ] [ing.ipcamera.handler.IpCameraHandler] - The alarm stream was not running for camera 192.168.2.203, re-starting it now

2019-07-11 12:56:04.627 [WARN ] [ing.ipcamera.handler.IpCameraHandler] - The alarm stream was not running for camera 192.168.2.203, re-starting it now

2019-07-11 12:56:09.627 [WARN ] [ing.ipcamera.handler.IpCameraHandler] - The alarm stream was not running for camera 192.168.2.203, re-starting it now

2019-07-11 12:56:14.638 [WARN ] [ing.ipcamera.handler.IpCameraHandler] - The alarm stream was not running for camera 192.168.2.203, re-starting it now

2019-07-11 12:56:19.621 [WARN ] [ing.ipcamera.handler.IpCameraHandler] - The alarm stream was not running for camera 192.168.2.203, re-starting it now

I am in the process of adding a second camera (also Amcrest, but different model). This new camera does not produce the same errors, although it is configured exactly the same ways as the first camera.

@matt1: if you need more information on the configurations, than please get back to me.

Did you clean the cache and tmp folders? in Linux enter this…

sudo service openhab2 stop && sudo rm -rf /var/lib/openhab2/cache/* && sudo rm -rf /var/lib/openhab2/tmp/* && sudo reboot

Also how did you add the camera, with paperUI or with .things files? If with paperUI you will need to delete and re-add the camera due to the way Openhab works, this is not needed if you used things files.

1 Like

thanks for the super quick response.
the cameras are added via things-files.
I cleared cache and temp files with your command above and also restarted openhabian another time afterwards- did not help. The “old” camera continues to report the warning above, whereas the new camera only warns once, and then seems to be ok.

can you disable the working camera, stop snapshots and enable trace mode logging please? I will need some log output to work out why. The first two things just stop loads of logs to make it clearer when the trace is enabled. The readme file covers how to change the log mode.

I will do that in a minute. one question upfront:
I deactivated the running camera in the text file - this became active immediatly.
Then I activated the “old” camera in the text file - the camera does not show up in the log, is not started. Only after a restart of openhab for the camera starts working in openhab.

QUESTION: How do I stop the snapshots?? I took the polling out of the thing file definition and disabled the IMAGE channel, but it still did the snapshots.

here is part of the log - inbetween two snapshots

2019-07-11 14:35:19.202 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - Snapshot recieved: Binding will now close the channel.

2019-07-11 14:35:19.205 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - commonCameraHandler closed channel:2 	URL:/cgi-bin/snapshot.cgi?channel=1

2019-07-11 14:35:20.027 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - Sending camera GET: http://192.168.2.203:80/cgi-bin/snapshot.cgi?channel=1

2019-07-11 14:35:20.056 [TRACE] [ipcamera.internal.MyNettyAuthHandler] - MyNettyAuthHandler is now setup for 	GET:/cgi-bin/snapshot.cgi?channel=1

2019-07-11 14:35:20.060 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - Have re-opened  the closed channel:0 	GET:/cgi-bin/snapshot.cgi?channel=1

2019-07-11 14:35:20.063 [WARN ] [ing.ipcamera.handler.IpCameraHandler] - The alarm stream was not running for camera 192.168.2.203, re-starting it now

2019-07-11 14:35:20.066 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - Sending camera GET: http://192.168.2.203:80/cgi-bin/eventManager.cgi?action=attach&codes=[All]

2019-07-11 14:35:20.099 [DEBUG] [ipcamera.internal.MyNettyAuthHandler] - 401: Mark as closing, the  channel:0 	GET:/cgi-bin/snapshot.cgi?channel=1

2019-07-11 14:35:20.105 [TRACE] [ipcamera.internal.MyNettyAuthHandler] - MyNettyAuthHandler is now setup for 	GET:/cgi-bin/eventManager.cgi?action=attach&codes=[All]

2019-07-11 14:35:20.105 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - Resending using a fresh DIGEST 	URL:/cgi-bin/snapshot.cgi?channel=1

2019-07-11 14:35:20.107 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - Have re-opened  the closed channel:4 	GET:/cgi-bin/eventManager.cgi?action=attach&codes=[All]

2019-07-11 14:35:20.109 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - Sending camera GET: http://192.168.2.203:80/cgi-bin/snapshot.cgi?channel=1

2019-07-11 14:35:20.121 [TRACE] [ipcamera.internal.MyNettyAuthHandler] - MyNettyAuthHandler is now setup for 	GET:/cgi-bin/snapshot.cgi?channel=1

2019-07-11 14:35:20.123 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - Have re-opened  the closed channel:2 	GET:/cgi-bin/snapshot.cgi?channel=1

2019-07-11 14:35:20.127 [TRACE] [ing.ipcamera.handler.IpCameraHandler] - DefaultHttpResponse(decodeResult: success, version: HTTP/1.1)

HTTP/1.1 401 Unauthorized

WWW-Authenticate: Digest realm="Login to AMC0009755AC31D939",qop="auth",nonce="1479015971",opaque="ffb9bd08f8eaf92ba9b9f1fbfd4e518c5939579b"

Connection: close

CONTENT-LENGTH: 0

2019-07-11 14:35:20.129 [TRACE] [ing.ipcamera.handler.IpCameraHandler] - EmptyLastHttpContent

2019-07-11 14:35:20.132 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - commonCameraHandler closed channel:0 	URL:/cgi-bin/snapshot.cgi?channel=1

2019-07-11 14:35:20.150 [DEBUG] [ipcamera.internal.MyNettyAuthHandler] - 401: Mark as closing, the  channel:4 	GET:/cgi-bin/eventManager.cgi?action=attach&codes=[All]

2019-07-11 14:35:20.155 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - Resending using a fresh DIGEST 	URL:/cgi-bin/eventManager.cgi?action=attach&codes=[All]

2019-07-11 14:35:20.158 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - Sending camera GET: http://192.168.2.203:80/cgi-bin/eventManager.cgi?action=attach&codes=[All]

2019-07-11 14:35:20.170 [TRACE] [ipcamera.internal.MyNettyAuthHandler] - MyNettyAuthHandler is now setup for 	GET:/cgi-bin/eventManager.cgi?action=attach&codes=[All]

2019-07-11 14:35:20.173 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - Have re-opened  the closed channel:5 	GET:/cgi-bin/eventManager.cgi?action=attach&codes=[All]

2019-07-11 14:35:20.191 [TRACE] [ing.ipcamera.handler.IpCameraHandler] - DefaultHttpResponse(decodeResult: success, version: HTTP/1.1)

HTTP/1.1 401 Unauthorized

WWW-Authenticate: Digest realm="Login to AMC0009755AC31D939",qop="auth",nonce="783549361",opaque="ffb9bd08f8eaf92ba9b9f1fbfd4e518c5939579b"

Connection: close

CONTENT-LENGTH: 0

2019-07-11 14:35:20.199 [TRACE] [ing.ipcamera.handler.IpCameraHandler] - EmptyLastHttpContent

2019-07-11 14:35:20.204 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - commonCameraHandler closed channel:4 	URL:/cgi-bin/eventManager.cgi?action=attach&codes=[All]

2019-07-11 14:35:20.212 [TRACE] [ing.ipcamera.handler.IpCameraHandler] - DefaultHttpResponse(decodeResult: success, version: HTTP/1.1)

HTTP/1.1 400 Bad Request

CONNECTION: close

CONTENT-LENGTH: 0

2019-07-11 14:35:20.219 [TRACE] [ing.ipcamera.handler.IpCameraHandler] - EmptyLastHttpContent

2019-07-11 14:35:20.224 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - commonCameraHandler closed channel:5 	URL:/cgi-bin/eventManager.cgi?action=attach&codes=[All]

2019-07-11 14:35:20.940 [TRACE] [ing.ipcamera.handler.IpCameraHandler] - DefaultHttpResponse(decodeResult: success, version: HTTP/1.1)

HTTP/1.1 200 OK

Cache-Control: no-cache

Pragma: no-cache

Content-type: image/jpeg

CONNECTION: close

CONTENT-LENGTH: 294270

2019-07-11 14:35:20.945 [TRACE] [ing.ipcamera.handler.IpCameraHandler] - DefaultHttpContent(data: PooledSlicedByteBuf(ridx: 0, widx: 893, cap: 893/893, unwrapped: PooledUnsafeDirectByteBuf(ridx: 1024, widx: 1024, cap: 1024)), decoderResult: success)

2019-07-11 14:35:20.954 [TRACE] [ing.ipcamera.handler.IpCameraHandler] - DefaultHttpContent(data: PooledSlicedByteBuf(ridx: 0, widx: 8192, cap: 8192/8192, unwrapped: PooledUnsafeDirectByteBuf(ridx: 8192, widx: 16384, cap: 16384)), decoderResult: success)

2019-07-11 14:35:20.970 [TRACE] [ing.ipcamera.handler.IpCameraHandler] - DefaultHttpContent(data: PooledSlicedByteBuf(ridx: 0, widx: 8192, cap: 8192/8192, unwrapped: PooledUnsafeDirectByteBuf(ridx: 16384, widx: 16384, cap: 16384)), decoderResult: success)

2019-07-11 14:35:20.987 [TRACE] [ing.ipcamera.handler.IpCameraHandler] - DefaultHttpContent(data: PooledSlicedByteBuf(ridx: 0, widx: 8192, cap: 8192/8192, unwrapped: PooledUnsafeDirectByteBuf(ridx: 8192, widx: 59336, cap: 65536)), decoderResult: success)

2019-07-11 14:35:21.002 [TRACE] [ing.ipcamera.handler.IpCameraHandler] - DefaultHttpContent(data: PooledSlicedByteBuf(ridx: 0, widx: 8192, cap: 8192/8192, unwrapped: PooledUnsafeDirectByteBuf(ridx: 16384, widx: 59336, cap: 65536)), decoderResult: success)

2019-07-11 14:35:21.019 [TRACE] [ing.ipcamera.handler.IpCameraHandler] - DefaultHttpContent(data: PooledSlicedByteBuf(ridx: 0, widx: 8192, cap: 8192/8192, unwrapped: PooledUnsafeDirectByteBuf(ridx: 24576, widx: 59336, cap: 65536)), decoderResult: success)

2019-07-11 14:35:21.030 [TRACE] [ing.ipcamera.handler.IpCameraHandler] - DefaultHttpContent(data: PooledSlicedByteBuf(ridx: 0, widx: 8192, cap: 8192/8192, unwrapped: PooledUnsafeDirectByteBuf(ridx: 32768, widx: 59336, cap: 65536)), decoderResult: success)

2019-07-11 14:35:21.046 [TRACE] [ing.ipcamera.handler.IpCameraHandler] - DefaultHttpContent(data: PooledSlicedByteBuf(ridx: 0, widx: 8192, cap: 8192/8192, unwrapped: PooledUnsafeDirectByteBuf(ridx: 40960, widx: 59336, cap: 65536)), decoderResult: success)

2019-07-11 14:35:21.054 [TRACE] [ing.ipcamera.handler.IpCameraHandler] - DefaultHttpContent(data: PooledSlicedByteBuf(ridx: 0, widx: 8192, cap: 8192/8192, unwrapped: PooledUnsafeDirectByteBuf(ridx: 49152, widx: 59336, cap: 65536)), decoderResult: success)

2019-07-11 14:35:21.061 [TRACE] [ing.ipcamera.handler.IpCameraHandler] - DefaultHttpContent(data: PooledSlicedByteBuf(ridx: 0, widx: 8192, cap: 8192/8192, unwrapped: PooledUnsafeDirectByteBuf(ridx: 57344, widx: 59336, cap: 65536)), decoderResult: success)

2019-07-11 14:35:21.069 [TRACE] [ing.ipcamera.handler.IpCameraHandler] - DefaultHttpContent(data: PooledSlicedByteBuf(ridx: 0, widx: 1992, cap: 1992/1992, unwrapped: PooledUnsafeDirectByteBuf(ridx: 59336, widx: 59336, cap: 65536)), decoderResult: success)

2019-07-11 14:35:21.074 [TRACE] [ing.ipcamera.handler.IpCameraHandler] - DefaultHttpContent(data: PooledSlicedByteBuf(ridx: 0, widx: 8192, cap: 8192/8192, unwrapped: PooledUnsafeDirectByteBuf(ridx: 8192, widx: 65536, cap: 65536)), decoderResult: success)

2019-07-11 14:35:21.080 [TRACE] [ing.ipcamera.handler.IpCameraHandler] - DefaultHttpContent(data: PooledSlicedByteBuf(ridx: 0, widx: 8192, cap: 8192/8192, unwrapped: PooledUnsafeDirectByteBuf(ridx: 16384, widx: 65536, cap: 65536)), decoderResult: success)

2019-07-11 14:35:21.088 [TRACE] [ing.ipcamera.handler.IpCameraHandler] - DefaultHttpContent(data: PooledSlicedByteBuf(ridx: 0, widx: 8192, cap: 8192/8192, unwrapped: PooledUnsafeDirectByteBuf(ridx: 24576, widx: 65536, cap: 65536)), decoderResult: success)

2019-07-11 14:35:21.095 [TRACE] [ing.ipcamera.handler.IpCameraHandler] - DefaultHttpContent(data: PooledSlicedByteBuf(ridx: 0, widx: 8192, cap: 8192/8192, unwrapped: PooledUnsafeDirectByteBuf(ridx: 32768, widx: 65536, cap: 65536)), decoderResult: success)

2019-07-11 14:35:21.101 [TRACE] [ing.ipcamera.handler.IpCameraHandler] - DefaultHttpContent(data: PooledSlicedByteBuf(ridx: 0, widx: 8192, cap: 8192/8192, unwrapped: PooledUnsafeDirectByteBuf(ridx: 40960, widx: 65536, cap: 65536)), decoderResult: success)

2019-07-11 14:35:21.107 [TRACE] [ing.ipcamera.handler.IpCameraHandler] - DefaultHttpContent(data: PooledSlicedByteBuf(ridx: 0, widx: 8192, cap: 8192/8192, unwrapped: PooledUnsafeDirectByteBuf(ridx: 49152, widx: 65536, cap: 65536)), decoderResult: success)

2019-07-11 14:35:21.112 [TRACE] [ing.ipcamera.handler.IpCameraHandler] - DefaultHttpContent(data: PooledSlicedByteBuf(ridx: 0, widx: 8192, cap: 8192/8192, unwrapped: PooledUnsafeDirectByteBuf(ridx: 57344, widx: 65536, cap: 65536)), decoderResult: success)

2019-07-11 14:35:21.118 [TRACE] [ing.ipcamera.handler.IpCameraHandler] - DefaultHttpContent(data: PooledSlicedByteBuf(ridx: 0, widx: 8192, cap: 8192/8192, unwrapped: PooledUnsafeDirectByteBuf(ridx: 65536, widx: 65536, cap: 65536)), decoderResult: success)

2019-07-11 14:35:21.124 [TRACE] [ing.ipcamera.handler.IpCameraHandler] - DefaultHttpContent(data: PooledSlicedByteBuf(ridx: 0, widx: 8192, cap: 8192/8192, unwrapped: PooledUnsafeDirectByteBuf(ridx: 8192, widx: 65536, cap: 65536)), decoderResult: success)

2019-07-11 14:35:21.131 [TRACE] [ing.ipcamera.handler.IpCameraHandler] - DefaultHttpContent(data: PooledSlicedByteBuf(ridx: 0, widx: 8192, cap: 8192/8192, unwrapped: PooledUnsafeDirectByteBuf(ridx: 16384, widx: 65536, cap: 65536)), decoderResult: success)

2019-07-11 14:35:21.136 [TRACE] [ing.ipcamera.handler.IpCameraHandler] - DefaultHttpContent(data: PooledSlicedByteBuf(ridx: 0, widx: 8192, cap: 8192/8192, unwrapped: PooledUnsafeDirectByteBuf(ridx: 24576, widx: 65536, cap: 65536)), decoderResult: success)

2019-07-11 14:35:21.142 [TRACE] [ing.ipcamera.handler.IpCameraHandler] - DefaultHttpContent(data: PooledSlicedByteBuf(ridx: 0, widx: 8192, cap: 8192/8192, unwrapped: PooledUnsafeDirectByteBuf(ridx: 32768, widx: 65536, cap: 65536)), decoderResult: success)

2019-07-11 14:35:21.148 [TRACE] [ing.ipcamera.handler.IpCameraHandler] - DefaultHttpContent(data: PooledSlicedByteBuf(ridx: 0, widx: 8192, cap: 8192/8192, unwrapped: PooledUnsafeDirectByteBuf(ridx: 40960, widx: 65536, cap: 65536)), decoderResult: success)

2019-07-11 14:35:21.154 [TRACE] [ing.ipcamera.handler.IpCameraHandler] - DefaultHttpContent(data: PooledSlicedByteBuf(ridx: 0, widx: 8192, cap: 8192/8192, unwrapped: PooledUnsafeDirectByteBuf(ridx: 49152, widx: 65536, cap: 65536)), decoderResult: success)

2019-07-11 14:35:21.159 [TRACE] [ing.ipcamera.handler.IpCameraHandler] - DefaultHttpContent(data: PooledSlicedByteBuf(ridx: 0, widx: 8192, cap: 8192/8192, unwrapped: PooledUnsafeDirectByteBuf(ridx: 57344, widx: 65536, cap: 65536)), decoderResult: success)

2019-07-11 14:35:21.165 [TRACE] [ing.ipcamera.handler.IpCameraHandler] - DefaultHttpContent(data: PooledSlicedByteBuf(ridx: 0, widx: 8192, cap: 8192/8192, unwrapped: PooledUnsafeDirectByteBuf(ridx: 65536, widx: 65536, cap: 65536)), decoderResult: success)

2019-07-11 14:35:21.175 [TRACE] [ing.ipcamera.handler.IpCameraHandler] - DefaultHttpContent(data: PooledSlicedByteBuf(ridx: 0, widx: 8192, cap: 8192/8192, unwrapped: PooledUnsafeDirectByteBuf(ridx: 8192, widx: 65536, cap: 65536)), decoderResult: success)

2019-07-11 14:35:21.180 [TRACE] [ing.ipcamera.handler.IpCameraHandler] - DefaultHttpContent(data: PooledSlicedByteBuf(ridx: 0, widx: 8192, cap: 8192/8192, unwrapped: PooledUnsafeDirectByteBuf(ridx: 16384, widx: 65536, cap: 65536)), decoderResult: success)

2019-07-11 14:35:21.185 [TRACE] [ing.ipcamera.handler.IpCameraHandler] - DefaultHttpContent(data: PooledSlicedByteBuf(ridx: 0, widx: 8192, cap: 8192/8192, unwrapped: PooledUnsafeDirectByteBuf(ridx: 24576, widx: 65536, cap: 65536)), decoderResult: success)

2019-07-11 14:35:21.190 [TRACE] [ing.ipcamera.handler.IpCameraHandler] - DefaultHttpContent(data: PooledSlicedByteBuf(ridx: 0, widx: 8192, cap: 8192/8192, unwrapped: PooledUnsafeDirectByteBuf(ridx: 32768, widx: 65536, cap: 65536)), decoderResult: success)

2019-07-11 14:35:21.195 [TRACE] [ing.ipcamera.handler.IpCameraHandler] - DefaultHttpContent(data: PooledSlicedByteBuf(ridx: 0, widx: 8192, cap: 8192/8192, unwrapped: PooledUnsafeDirectByteBuf(ridx: 40960, widx: 65536, cap: 65536)), decoderResult: success)

2019-07-11 14:35:21.201 [TRACE] [ing.ipcamera.handler.IpCameraHandler] - DefaultHttpContent(data: PooledSlicedByteBuf(ridx: 0, widx: 8192, cap: 8192/8192, unwrapped: PooledUnsafeDirectByteBuf(ridx: 49152, widx: 65536, cap: 65536)), decoderResult: success)

2019-07-11 14:35:21.206 [TRACE] [ing.ipcamera.handler.IpCameraHandler] - DefaultHttpContent(data: PooledSlicedByteBuf(ridx: 0, widx: 8192, cap: 8192/8192, unwrapped: PooledUnsafeDirectByteBuf(ridx: 57344, widx: 65536, cap: 65536)), decoderResult: success)

2019-07-11 14:35:21.211 [TRACE] [ing.ipcamera.handler.IpCameraHandler] - DefaultHttpContent(data: PooledSlicedByteBuf(ridx: 0, widx: 8192, cap: 8192/8192, unwrapped: PooledUnsafeDirectByteBuf(ridx: 65536, widx: 65536, cap: 65536)), decoderResult: success)

2019-07-11 14:35:21.217 [TRACE] [ing.ipcamera.handler.IpCameraHandler] - DefaultHttpContent(data: PooledSlicedByteBuf(ridx: 0, widx: 8192, cap: 8192/8192, unwrapped: PooledUnsafeDirectByteBuf(ridx: 8192, widx: 21049, cap: 65536)), decoderResult: success)

2019-07-11 14:35:21.222 [TRACE] [ing.ipcamera.handler.IpCameraHandler] - DefaultHttpContent(data: PooledSlicedByteBuf(ridx: 0, widx: 8192, cap: 8192/8192, unwrapped: PooledUnsafeDirectByteBuf(ridx: 16384, widx: 21049, cap: 65536)), decoderResult: success)

2019-07-11 14:35:21.227 [TRACE] [ing.ipcamera.handler.IpCameraHandler] - DefaultLastHttpContent(data: PooledSlicedByteBuf(ridx: 0, widx: 4665, cap: 4665/4665, unwrapped: PooledUnsafeDirectByteBuf(ridx: 21049, widx: 21049, cap: 65536)), decoderResult: success)

Starting later this evening, the new camera also delivered these warning messages on a continouos basis. Had to switch both of them off.

Are you using an admin user? The 400 bad request is not normal and I will have to check the amcrest api as to what can cause that.

@ffr
EDIT:
The API has this info…
400 Bad Request
The request had bad syntax or was inherently impossible to be satisfied.

Looking around I see different reports from non Openhab users stating it may be a bug when you turn on SD card alarms like card full when there is no SD card inserted. I would update the cameras firmware and reach out to your cameras support…

As for why this is only happening with newer builds, that is because it was hiding the error from you in older builds and was only seen if you looked with DEBUG mode on. Recently I improved the way the stream is handled and hence made the log let you know there is an issue. I suspect this has always been an issue you just never saw this in the logs.

As a work around you can select the camera to be AMCREST instead of DAHUA and it should work the same only using a different method to detect alarms which may work fine in your case. If you setup with things files it is very simple to find replace this and try it out.

thank you for your support!
I changed the channels to AMCREST, and both cameras have been working for the last 6 hours without problem.
Re your suggestion to contact Amcrest with this problem, I have to say that I would really not know how to explain the problem to them, because I have no insight into the specific scenarios and the code of the binding that triggers the problem. I think, that a contact to Amcrest would have to be initiated by somebody like you.

Why would I contact support for you?

  • I dont have an issue with mine
  • I dont get paid
  • You paid money to that company for support
  • I better things to do with my time
  • Their support will ask you to try things and since my camera does not have an issue that presents an issue.

Did I mention I am not an employee and dont get paid? I helped you narrow it down to the camera giving an error when a URL is tried to be opened. The same will happen if you try to open it in any web browser. I suspect it is a setting on the camera you need to change or you are not using an admin login to ask the camera for the alarm stream, I asked this already and did not get a reply.

If you won’t fault find and try things then no one else will do it for you.

Older bindings are found on my webpage where you downloaded the current one from, you can go back to any of the older versions as they will hide this warning unless you have debug logging turned on and then you will see it.

You would need to go to a build before build 2019-06-26 as that is when I last changed the alarm stream, before that it had not been touched for a long long time. I have been using it for at least five weeks with no issues since that change and it was to ensure the log is seen when there is an issue.

1 Like

Sorry, I did not want to offend you in any way. Apologolies.
If I contact Amcrest in order to get their bug fixed, I expect they will get back to me with questions I cannot answer. But nevermind, my cameras are working fine with the change you suggested.

I am using an admin login. This error does neither show (I do not say it is not there!) with the Amcrest software nor with the Synology Surveillance Station.

I am not saying it is a bug, i am only saying I am not an expert with their cameras and their support knows more. It may be as simple as you running two or three programs all trying to open the same stream and the camera does not like that many. It may be you have old model cameras that do not have the newer api method supported.