I would not expect a change until you go into double digits ie 10. Testing to see if double digits work at getting their alarm events correctly to the channels is where I would expect a potential bug to arise. When I get some more spare time, I’ll take a quick look into the code to see if further changes are needed to support double digits before getting the changes merged. If someone reports that everything works I can skip looking into the code into too much depth.
The build does have another major bug fixed in it for ONVIF reconnecting, but this did not seem to effect non PTZ hikvision cameras, as the binding does not use the onvif event methods, but instead uses the API method to gain far more info on the alarms, like which line is crossed and which direction movement was made over a line crossing alarm. More on this can be found in the main ipcamera forum thread.
Hi @matt1 . I tested your build and the camera worked fine (as it was the case in OH2.5).
It seems that now the binding tries to listen for alerts and it fails on my DVR (Hikvision DS-7616HI-ST).
2022-08-29 11:30:19.873 [DEBUG] [ipcamera.internal.MyNettyAuthHandler] - Camera at IP:dvr gave a reply with a response code of :404
2022-08-29 11:30:19.874 [TRACE] [g.ipcamera.internal.HikvisionHandler] - HTTP Result back from camera is :Can't locate the url:
2022-08-29 11:30:19.890 [INFO ] [era.internal.handler.IpCameraHandler] - The alarm stream was not running for camera dvr, re-starting it now
2022-08-29 11:30:19.891 [TRACE] [era.internal.handler.IpCameraHandler] - Sending camera: GET: http://dvr:80/ISAPI/Event/notification/alertStream
I tried to manually access the event API and the closest I got was
You need to upgrade, not only to get the bug fixes and many improvements that 3.4 stable provides, but also to get security patches. In theory you (i won’t) could easily make the minor change that the PR shows was needed to allow more, and build your own 2.5 version jar.