Adding Reolink API to the IpCamera binding, beta testers needed

You should not loose any alarm functionality, there appears to be a bug that stops the alarm stream from being watched which is what others are discussing in this thread and that may explain it for you. If you camera does have an unsupported alarm, by logging in DEBUG it will tell you the camera is sending an unknown alarm and ask you to report it so that it can be added.

Yes make sure you using the latest changes that I am trialing and will also log to INFO level if something unexpected happens that you can report back to help with looking into this.

@nickb5 and @Marcdus I just uploaded another build that will log more stuff to INFO here and it does contain a fix for 1 bug that was in the last build already.
http://pcmus.com/openhab/IpCameraBinding/

Thanks for taking the time to post your setup is working 100% would you mind posting if your cameras are using wired network cables or via wifi? I agree with your post that people need to capture in TRACE logging the moment the problem occurs, then it makes it far easier and quicker to respond with a fix.

This is a possibility that the http webserver on the NVR can not handle X amount of parrallel requests. Can you PM me some TRACE level logs that shows just how much traffic is being generated? The time stamps will tell me how often the PullMessages onvif message is sent. I have seen some cameras reply instantly to the request when the ONVIF standard states that it should wait until an event occurs or the timeout occurs. I can determine this in more detail only by looking at the log. Can you send one with all cameras running, and then a second one with only 1 camera talking so that I can more clearly see what is happening?

There is a PR for this here

Are you using the newer not merged changes from my private site? I have made some changes in it to allow the NVR 0 to be used. I’ll take a look at this if you can confirm it still happens in the private build.

1 Like

@matt1 - appreciated, whole heartedly here. Every Reolink camera in my setup is hard wired over Cat6 & behind the Reolink PoE NVR. Pulling down your latest .JAR to test deeply further ASAP! Will report back. I did notice some oddities during setup with the Tellstick binding needing uninstalled/reinstalled, which seemingly solved my aforementioned issues with the OH Settings > Add-on Settings section being wonky, along with only two bindings showing as options under Things > Add (should have 12+ bindings available in my openHAB setup). Managed to resolve that by repeatedly uninstalling/reinstalling (clearing OH cache, service restarts, etc) Tellstick binding and the previous ipcamera JAR via Karaf Console - working alright overall at the moment. Please note - I am still observing issues with camera feeds/channels behind the NVR - they seem to get crossed. For instance, I can’t seem to find a way to stream MJPEG based on NVR channel alone (your camera Widget seems to always loads the first ‘0’ channel on the Reolink NVR), the Human_Alarm channel on just one camera seems to trickle out to change the state of others camera channels that are active (one ‘Human’ detection sets many other Human channels to ‘ON’), and while the OH ipcamera.jpg URLs are working fine and embedded in various openHAB pages, the ipcamera.mjpeg link is always shows the first channel for the feed. No clear rhyme or reason there, but will keep you apprised as I dig deeper and identify any patterns.

I also haven’t been able to get the previous ipcamera binding you compiled to control my Reolink TrackMix PTZ camera via either the Reolink API or ONVIF protocol - hope that is possible now considering the scope of this latest GitHub PR, just now!

Cheers @matt1,
.

This does not make 100% sense. Can you reword it so that it is clearer?

For example, if you want to view channel 2 on NVR, then the RTSP URL will be 1 number higher:
rtsp://admin:111111@192.168.10.92/Preview_03_main
snapshot will be following, note the same as the NVR channel number.
http://192.168.10.92/cgi-bin/api.cgi?cmd=Snap&channel=2&rs=random&user=admin&password=password

Also what URL for RTSP work for channel 0 on the NVR? The reolink API and website do not make this clear at all, so some help with someone that can test would be great. Then we should look at the alarms if they do not match up as well, as I can not test this as I am waiting till enough $ is donated to buy a reolink camera so I can run tests here on my own setup.

Sorry I have no idea what your talking about here. I really STRESS that you should open a NEW THREAD for each issue so that all the information is contained in the one place and others can contribute. Not the best place to mix multiple issues up in a mega thread like this one. If your certain it is a bug, then it can be opened as an issue at github, if you’re not sure then open a thread in the forum.

It may have been the web browser cache. I have problems and it always stems from Firefox needing the browser cache cleared. A SHIFT + F5 solves it.

There are two different ways the binding can get alarms. Try setting onvif port to 0 to disable the ONVIF methods and it will fall back to using the API method. NOTE this only works for the newer JAR that has non merged changes in it.

Regarding RTSP link: When I configure the URL manually, the images show up fine. Ch1 image appears under Ch1 URL. When I let the binding autodetect the image item then Ch2 image appears under Ch1 item. I tried to solve it by leaving it on manual configuration, but it was increasing my re-boot issue. Obviously through additional polling volumes. So I am now back to autodetect and living with the issue of wrong channels.

I also tried out changing from token to user and password. On the token mode I sometimes lost the image after a while. User and password are much more stable. Token never worked well for me.

Please note that I did upload a changed version of the binding marked as PM which does have a change in the rtsp URL, so this should be fixed from now on. If you can change to the PM build and retest that would be great.

I highly doubt that it would effect your reboot issue, must have been a co-incidence unless the NVR does not like being asked for a non existent channel/stream/snapshot.

Sorry I do not understand this statement, can you explain more?

Actually this does make sense, as each camera thing will be asking for a separate token and will be increasing the load on the NVR having to keep track of them and the time that each one expires.

I can confirm that the RTSP URLs are correct now on the latest addon!

Great thanks for confirming, if we can narrow down any other issues we can solve them too and have the changes merged so everyone can enjoy the improvements.

This is good info. The latest binding versions with default settings, do not talk to the NVR if the ONVIF stream is open, so if your not asking for any pictures of any kind there will only be 1 connection for each thing. If you’re using the token methods, then another call is made to renew the token and it is not very often, but this is easily disabled.

To see what happens, I would make ONVIF port equal 0 to disable the ONVIF for all cameras and this will cause the binding to switch to using the API methods for the alarms instead of ONVIF. Do you still get the reboots? This would help narrow the cause down to if it is an ONVIF compatibility between the binding and the NVR, or if it is to do with the number of calls back and forth.

My current configuration (first time stable for 3 days) is:
Ch0 with ONVIF enabled for doorbell notification which otherwise doesn’t work instantly on API pull.
CH1-7 ONVIF switched off.
Updateimagewhen configured to standard (switching ito 1 also increases reboot)

Regarding ONVIF I should also note that channel 0 reports ANY motion on ANY channel through ONVIF. Probably because NVRs don’t seem to support ONVIF on any other channel than 0. Maybe you could comment on this.

So by switching to username + password, no manual URL configuration and ONVIF only on CH0 I was able to achieve a stable setup.

If you want me to change any of that - step by step - I can do whatever is helpful. It would probably take 2 or 3 days since the reboot only appears after a while unless I force it but opening many browser windows accessing the NVR (which is a bias to finding the openhab cause)

What happens if you stop using the binding, can you make the NVR reboot by only opening many browser windows? How many are needed? If you can cause a reboot that way, then this is something you should report to Reolink as it could be used as a way to crash and reboot the NVR as a form of attack. IE imagine if someone pulled a camera off your home, plugged in a device and was inside your network, then did the multiple tab trick to crash the NVR over and over.

I can not comment on it unless I see the ONVIF replies. You can enable TRACE logging and look for ONVIF reply is: ........... Feel free to PM logs to me in case passwords are left in them, its best to keep them off a forum.

@Marcdus

I will reply here so others can follow along…

To change the logging to TRACE or DEBUG you can do this from the main UI if your using the newer versions of openHAB…

Click on the binding you wish to change, then select the level from the drop down box. TRACE gives the most detail, DEBUG gives you less and INFO is back to the default logging when you do not want to record the extra stuff anymore.

Don’t forget to press SAVE to apply the change after selecting the new log level from the drop down list.

It’s set to trace. So far nothing new showing up on openhab.log and events.log other than what I sent you in private message.

Then you probably did not press SAVE for the change to take effect.

Installed and trace level logging enabled, will report back.

Just a question on the current OH milestone 4.3. as I would like to use AI events with my RLC-811A.
The only events I see in the logs (and in the items) is CellMotion.
Are the changes, in particular the humanAlarm now part of the milestone releases or do I need to install that manually?

Yes they should be in the latest released milestone if your camera supports those alarm types you should see the channels. The binding will remove any channels for alarms that the camera reports it does not support.

I also made some more changes for reolink that got merged this past week, you can get these from my personal website, or via the jfrog server if you navigate to the snapshot builds.

1 Like

I see the channels but I don’t see any events in the logs. I’m on the M3 and I created a fresh thing to avoid any problems with legacy configuration and to be sure to have a proper Reolink API thing.
The only event type I can see is cellMotion. However, in the App I get Person detecte alerts, so the detection is configured correctly as far as I can see. I’ll have a look at the snapshot builds when I have a moment.

Update your firmware and then post some trace level logs when you unpaused the thing. Since the password can be in the url of reolink either do a find replace to remove the password, use the token feature, or PM the log.

Firmware was indeed not the latest (automatic update does not seem to work any longer with Reolink).
I tried nvr channel 0 and 1, ONVIF profile 0 and 1, with and without API token (without dows not seem to work at all.

Update:
Switching the NVR channel to 1 + clean-cache and reboot did the trick to actually get some data. I even got an alarm event but only once (tried restarting, rebootig:

2024-06-07 19:26:03.861 [TRACE] [era.internal.handler.IpCameraHandler] - Sending camera: GET: http://192.168.1.156:80/api.cgi?cmd=GetAiState&channel=1&user=admin&password=
2024-06-07 19:26:03.862 [TRACE] [era.internal.handler.IpCameraHandler] - Sending camera: GET: http://192.168.1.156:80/api.cgi?cmd=GetMdState&channel=1&user=admin&password=
2024-06-07 19:26:03.930 [TRACE] [era.internal.handler.IpCameraHandler] - HTTP Result from /api.cgi?cmd=GetAiState&channel=1&user=admin&password= contains :[
{
“cmd” : “GetAiState”,
“code” : 0,
“value” : {
“channel” : 1,
“dog_cat” : {
“alarm_state” : 0,
“support” : 1
},
“face” : {
“alarm_state” : 0,
“support” : 0
},
“people” : {
“alarm_state” : 0,
“support” : 1
},
“vehicle” : {
“alarm_state” : 0,
“support” : 1
}
}
}
]
:
2024-06-07 19:26:03.958 [TRACE] [era.internal.handler.IpCameraHandler] - HTTP Result from /api.cgi?cmd=GetMdState&channel=1&user=admin&password= contains :[
{
“cmd” : “GetMdState”,
“code” : 0,
“value” : {
“state” : 0
}
}
]
:

I’m at the end of my wits.
Any ideas what to try next?

Try setting the ONVIF port to 0, this will turn off the onvif features and will poll those two URLS.

I suspect you do not have ONVIF enabled on the NVR and cameras? I believe by default this is disabled on Reolink cameras, and that if you did enable it, doing some firmware updates can turn it off.

  1. enable ONVIF and try it with the correct onvif port to use onvif for the alarms.
  2. Stop the binding from using ONVIF by setting the onvif port config to 0.

NOTE: These changes were only merged 3 weeks ago, so older versions of the binding may act differently and in those versions it was setting the NVR channel to non 0 that started the polling of those urls.

I am on MS3, ONVIF is activated on the cam and I configured NVR channel 1 even though I don’t have an NVR (I’m using Openhab and Shinobi). I read that somewhere that this is required to trigger alarms. That corresponds to my observations as I didn’t get the alarm polling with NVR channel 0.
I’ll try to deactivate ONVIF on the cam with NVR 0 to see what that does. I’ll report back.