So I now changed the ONVIF port to 0 and tried with
NVR 0: no /api.cgi?cmd=GetAiState polling started
NVR 1: /api.cgi?cmd=GetAiState started but no alarms found
I did trigger the alarm and received it on the mobile phone app bot nothing in openhab.
Shall I wait for the next milestone? Is it worthwhile deactivating the ONVIF port on the cam?
Update:
I polled the URL on my iPAD while triggerring the alarm (luckily my neighbours can’t see me doing that ).
I don’t get anything polling channel 1 but I get
“people” : {
“alarm_state” : 1,
“support” : 1
when polling channel 0.
Looks to me like waiting for the next build where NVR channel 0 is polled would be the right thing to do.
However, there isn’t much detail provided (unlike the Dahua camera that provides details of the region etc.)
You never need to disable onvif on the camera, this is only telling the binding what method you prefer via the config of the binding.
The newer build is on my. Private site or is also on jfrog server under the snapshots, you can download just the binding jar from jfrog and stay on whatever openhab version you are currently using.
You can then navigate to download the jar for just a single binding from the last automated build coming from only reviewed and merged changes. There is also a branch to get stuff from PR that are not yet reviewed, however it only works if there is only 1 open PR for that binding and often there are more then 1. This is why I just upload them to my own server.
Currently the direct download link for the last build is this one…
Doing testing on this jar will help find any issues before they make it into the next 4.2 STABLE release which is around 3 weeks away. Any help testing and reporting of issues would be great to ensure the stable build is better then all previous builds.
@nickb5 Thanks for reporting that the latest builds helps with your issues, I will reply here to your PM because it is a waste of time making a reply to 1 person when the info may help others if it is posted publicly.
Regarding the ONVIF event stream stopping until you pause and then un-pause the thing, I will need some DEBUG output from when the stream stops. The newer build which is linked above will give more logs if/when something goes wrong, it should give clues by the last few lines in the log just as the stream is stopping.
Any connection issue should get logged.
Any non 200 OK http code sent back as a reply from the camera will get logged.
The only thing that I can see that would stop any logs getting produced in this newer build would be if the camera replied with a 200 OK reply and did not tag it as a PullMessagesResponse in reply to a PullMessages request, which I have seen a camera do.
If this happens the TRACE level logs will give you a line like…
Unhandled ONVIF reply is: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
If you can capture this information I can see what is happening and make a plan to move forwards. Only the latest changes will provide this extra info in the logs.
Thanks a lot, that does the trick.
I get the human event now (hopefully also the pet once it’s triggered).
NVR Input Channel needs to be 0.
I activated " * Use API Token" for authentication.
I had to set the onvif port to 0 as it seems to have connection issues that stop the rest from working.
Thanks for the feedback. I would like to know the reason why it does not work fully on default settings, as the readme may need to be updated to help people setup if it is not a bug that needs fixing.
As mentioned Reolink have onvif disabled by default in nvr and cameras and in some cases you need to connect a screen to the nvr to turn it on.
By needing to disable onvif at the bindings configs it uses other methods which will work if onvif has issues or is disabled. If it is just some missing alarm types then you can watch the trace logs and it will tell you if the binding needs support added for a new unknown alarm getting reported. If you see no alarms at all of any type coming from onvif then it may be disabled at camera or nvr.
Great that your now working, but it would be good to narrow the cause down to help others, either through adding better support or documentation.
Hi @matt1, First, thank you for this binding - it has been working well for me for almost a year using a Reolink Doorbell WiFi.
Within the last few days the binding has lost its connection to the doorbell. I am getting “connect failed - cause connection timed out: 192.168.20.50:8000” error messages in the log. I’ve tried deleting and recreating the add-on and the Thing, restarting OpenHAB, and deleting and re-creating the OpenHAB docker container.
Over the last few days I updated OpenHAB to 4.1.3 Release build and installed the WeatherFlow SmartWeather and Weather Calculations bindings.
OpenHAB is running in Docker on a Synology NAS. I created a Docker container for Firefox on the NAS and I am able to get to the doorbell’s web GUI without issue. All of the GUI functions are working as expected from the NAS.
I don’t know where else to look. From my perspective the doorbell is working ok, and the NAS is able to reach the doorbell. Any and all help will be greatly appreciated.
The following log messages are repeated every 30 seconds.
2024-06-19 19:02:23.843 [DEBUG] [era.internal.handler.IpCameraHandler] - About to connect to the IP Camera using the ONVIF PORT at IP: 192.168.20.50:8000
2024-06-19 19:02:23.843 [DEBUG] [amera.internal.onvif.OnvifConnection] - Connecting 192.168.20.50 to ONVIF
2024-06-19 19:02:23.843 [TRACE] [amera.internal.onvif.OnvifConnection] - Sending ONVIF request: GetSystemDateAndTime
2024-06-19 19:02:23.844 [TRACE] [amera.internal.onvif.OnvifConnection] - Sending ONVIF request: GetCapabilities
2024-06-19 19:02:33.854 [TRACE] [amera.internal.onvif.OnvifConnection] - connect failed - cause connection timed out: /192.168.20.50:8000
2024-06-19 19:02:33.854 [DEBUG] [amera.internal.onvif.OnvifConnection] - Camera is not reachable on IP 192.168.20.50
2024-06-19 19:02:33.855 [TRACE] [amera.internal.onvif.OnvifConnection] - connect failed - cause connection timed out: /192.168.20.50:8000
2024-06-19 19:02:33.855 [DEBUG] [amera.internal.onvif.OnvifConnection] - Camera is not reachable on IP 192.168.20.50
A log of a restart of the OpenHAB container is attached. Reolink.log (95.6 KB)
The Thing definition is also attached Thing.txt (8.3 KB)
You need to fault find. What changed between it working and it not? Can you ping the camera from the openhab server? Perhaps the camera died or it changed IP address.
If your running inside a container, you need to fault find if the container is restricting the network traffic.
Thanks @matt1, the issue is resolved. I could ping the camera and access the UI from the NAS so I installed Wireshark and learned enough to see that all of the RTP protocol packets sent by the camera were malformed. I had an extra AP so I configured it and connected the camera to the new AP and the camera came online. After verifying that it continued to work for awhile out of curiosity I switched the camera back to the old AP and it continues to work ok. I have no idea why.
I switched the log level in the binding back to INFO but I am getting the following four log warnings every 20 seconds. Should I be concerned? If not, is there some way to suppress them without suppressing other warning entries?
tried updating channel rssi although the handler was already disposed.
tried updating channel firmware_version although the handler was already disposed.
tried updating channel lastReport although the handler was already disposed.
tried updating channel uptime although the handler was already disposed.
I only ever see this when I drop new jar files to the addons folder overwriting another jar of the same name. This seems to create a broken state sometimes if the handlers are not shutdown smoothly. I usually do a restart when this happens and that fixes it.
I guess the BETTER way is to uninstall a binding, wait and then install the newer version so it runs the code as intended. By ripping the running jar out my guess is this is the cause of what I have seen. Does that explain it and fix it for you?
As for the cameras http traffic getting corrupted before reaching the binding, always do a turn off and turn back on before getting too serious with fault finding.
Yes, a restart fixed it. I don’t remember for sure. but I probably dropped in the new .jar while OpenHAB was running. Lesson learned.
I’m not sure I understand how the Reolink app was able to process the video with the malformed packets, but I’m not concerned with it. It’s water under the bridge.
I am interested in getting some feedback on some changes just made that should help out Reolink cameras. @Baschtlwaschtl@dniklas1
You can now specify a low res (sub stream) RTSP url for creating the mjpeg from and leave the high res stream for recording and other tasks in openHAB. This should be automatic for Reolink cameras, so to setup do the following if you do not want to delete and re-add the thing. People adding new cameras after these changes go live should have the binding settings happen by default.
Change MJPEG Options to have the value -q:v 4 -r 4 -update 1 removing the resizing/scale section actually reduces CPU load when fed an already low res stream.
Make sure MJPEG URL is empty so the new binding will auto detect and use the sub stream.
Camera settings:
Set the sub stream to be 4 FPS and 640*320 resolution. Going higher will just tax your CPU more.
Then enter this URL into any web browser http://openhab:8080/ipcamera/192168125/ipcamera.mjpeg
With these changes I can get a mjpeg stream that only uses 3% of my Odroid n2+ CPU so this should easily run on any of the Pix boards.
And if I don’t want the lowres stream? I like the highres stream in the mjpeg As I understand, I have to set the highres stream. If I leave it I get the lowres stream, right?
When a battery-powered camera is used as a standalone device, due to hardware limitations, it does not support RTSP, RTMP, ONVIF and related communication protocols that third-party software requires. In addition, most third-party software doesn’t have the battery management option that allows the camera to enter the power-saving standby mode when no motion is detected, thus they can’t work together.
Because AFAIK your camera does not produce mjpeg on board so the binding is creating mjpeg for you. A mjpeg stream is put simply, a stream of jpgs to create motion, so since your camera can supply a jpg, it is simple for the binding to just throw them into a stream. Currently the binding can only do this at a maximum of 1 frame per second because it literally takes longer than 1 second to fetch the jpg from the camera (multiple reasons for this delay) for high resolution cameras, so the binding is fetching multiple snapshots and waiting for them to arrive before piecing it all together.
FFmpeg can transcode the h264 stream to jpgs so it is a totally different method. Not all cameras can do a snapshot, so multiple methods are done so a user can choose.
Other brands of cameras can produce mjpeg on board and you can get smoother video feeds from them without needing FFmpeg and the added delay of the stream starting up. These cameras always seem to be limited to lower resolutions for this stream so loosing 3% of the CPU per camera is not a big deal, but the much quicker starting of the mjpeg stream may be worth paying more for.
I have a page in openHAB where I can view all cameras at the same time, for this use case having a 640*320 resolution stream is no big deal as the picture is small to fit all cameras on the screen at the same time.
Everyones use case is different and budget is as well, so this new feature only opens up more possibilities and also makes default settings work better out of the box and still lets a user tweak and change things if they wish.
I am sure it will work to some degree as FFmpeg can open a lot of different types of streams. The question is how that bridge software does this and what the downsides are? The battery cameras have a limited power source so you will not be able to watch the feed non stop at night without the battery going dead. I would always prefer a POE camera with a hardwire if given a choice.
).