IpCamera: New IP Camera Binding

Add-ons Bindings
, ,
2738

Hi matt,

UPDATED:

Thanx for the reply,

Sorry, your correct I meant using gotoPreset, the camera doesn’t expose its presets above 127 to the pull down unless you set and refresh, but the log shows any value above 127 as invalid when a gotoPreset 233 is done. btw these presets are not really settable they are hard wired.

sending a gotoPreset 233

21:28:35.087 [TRACE] [camera.internal.onvif.OnvifConnection] - Sending ONVIF request:PullMessages
21:28:35.617 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'LivingRoomAmazonEcho_Speak' received command Hey you silly Kitties,  stop running all over my she it!
21:28:35.620 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'ONVIFIPCamera_GoToPreset' received command 233
21:28:35.622 [INFO ] [openhab.event.ItemStatePredictedEvent] - Item 'LivingRoomAmazonEcho_Speak' predicted to become Hey you silly Kitties,  stop running all over my she it!
21:28:35.624 [TRACE] [camera.internal.onvif.OnvifConnection] - Sending ONVIF request:GotoPreset
21:28:35.625 [DEBUG] [camera.internal.onvif.OnvifConnection] - IndexOutOfBoundsException occured, Index: 232, Size: 127
21:28:35.625 [INFO ] [openhab.event.ItemStatePredictedEvent] - Item 'ONVIFIPCamera_GoToPreset' predicted to become 233
21:28:35.628 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'LivingRoomAmazonEcho_Speak' changed from  to Hey you silly Kitties,  stop running all over my she it!
21:28:35.629 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'ONVIFIPCamera_GoToPreset' changed from NULL to 233
2

sending a gotoPreset 127

21:33:10.598 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'LivingRoomAmazonEcho_Speak' received command Hey you silly Kitties,  stop running all over my she it!
21:33:10.600 [DEBUG] [camera.internal.onvif.OnvifConnection] - Onvif Event Topic:RuleEngine/CellMotionDetector/Motion, Data:IsMotion, Value:true
21:33:10.605 [TRACE] [camera.internal.onvif.OnvifConnection] - Sending ONVIF request:GotoPreset
21:33:10.602 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'ONVIFIPCamera_GoToPreset' received command 127
21:33:10.606 [TRACE] [camera.internal.onvif.OnvifConnection] - Sending ONVIF request:Renew
21:33:10.608 [INFO ] [openhab.event.ItemStatePredictedEvent] - Item 'LivingRoomAmazonEcho_Speak' predicted to become Hey you silly Kitties,  stop running all over my she it!
21:33:10.609 [INFO ] [openhab.event.ItemStatePredictedEvent] - Item 'ONVIFIPCamera_GoToPreset' predicted to become 127
21:33:10.610 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'LivingRoomAmazonEcho_Speak' changed from  to Hey you silly Kitties,  stop running all over my she it!
21:33:10.611 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'ONVIFIPCamera_GoToPreset' changed from 233 to 127

sending a gotoPreset 1 or 2 works as expected with similar log results.

Tim

2739

Onvif has preset tokens and the camera SHOULD report the presets and a token for each preset. The binding has to know the preset token to recall the preset so it will be interesting to see what the camera reports for these locations.

Without the token, the binding can not just blindly ask to go to preset 233 or any number, onvif does not work that way.

It would also be interesting to know if it works with the onvif device manager software?

2740

matt,

ONVIF Device Manager functions much the same way, 1 an 2 work but doesn’t show anything above 127 unless a preset of 233 is created, then it doesn’t do anything when selected… using CMS or VMS is able to goto preset 233 and toggles the cameras overlay graphics as this command is supposed to.

I believe those programs appear to blindly set the command

Tim

2741

Then they most likely do not use ONVIF and use some other method of control. Suggest you use wireshark to spy on what the program sends as it may be something you can emmulate with the http binding. If they are not ONVIF, then their is no point in the trace logs as that would only show what is happening in the ONVIF traffic between the camera and the binding.

2742

matt,

Thank you again,

Just curious, can’t IpCamera send a forced gotoPreset 233 etc ignoring it isn’t on the cameras list ?

It looks to me ODM and IpCamera are reading the list from the camera, getting 127 entries and denying a send of anything higher…

ONVIF Device Manager when selecting goto preset 1 or 2 work as expected so would think CMS/VMS are using a bastardized ONVIF just ignoring the read ? they don’t show a list of presets just a box to enter the number.

IpCamera binding correctly controls preset 1 and 2 I believe ODM and IpCamera are behaving spec wise reading the list from the camera but Barlus had to do this because there is no ONVIF commands for white or IR lamp control etc so they picked > 232 to stay away from generic presets < just spit balling here.

I thought of wireshark, because frankly these are under water cameras in my Koi Pond and wanted to automate turning the cameras lights on and off to not mess with circadian rhythm much, and use other ways to view :wink:

ODM does show that there are 1-127 presets and I can add and remove them but they don’t have any purpose. adding and removing 1-2 and 233 and greater have no effect on CMS/VMS working, but simply take away a means for ODM to select presets 1-2, adding them back they work fine again.

Using CMS and VMS with wireshark showed… was fun finding that in the log with 30 active connections heh heh

1¶ÃD…#º@E~µí@@'À¨fÀ¨¯Ú?a	#vPÇ&J7ÿxB{ "Name" : "OPPTZControl", "OPPTZControl" : { "Command" : "GotoPreset", "Parameter" : { "AUX" : { "Number" : 0, "Status" : "On" }, "Channel" : 0, "MenuOpts" : "Enter", "POINT" : { "bottom" : 0, "left" : 0, "right" : 0, "top" : 0 }, "Pattern" : "SetBegin", "Preset" : 233, "Step" : 0, "Tour" : 0 } }, "SessionID" : "0x5" }

Tim

2743

I’m 99.9% sure that is not onvif which uses XML format. Yours is JSON which means it is probably easy to replicate it with the html binding or a script.

As already stated onvif MUST have a token, you can not send a goto preset x as it works by saying go to token x and without a token you can not send the command.

2744

matt,

Thanx again, I’ll dig more toward the html path.

Tim

2745

New build I’m testing if anyone is interested to trial as I found a big bug for ONVIF thing type that meant the onvif would not reconnect if the connection was broken by flakely wifi. Most likely it would have only been the onvif events that would have stopped whilst the rest kept working fine. Surprised no one reported this, so if you have troubles, this build has had the bug fixed for the past 5 days for me.

Index of /openhab/IpCameraBinding/ (pcmus.com)

1 Like
2746

@matt1 Thanks for creating this update. I’ll give it a try as I have been been having significant problems with the ipCamera ONVIF Thing going OFFLINE and not returning to ONLINE. In reading through this thread and some of the comments made, I concluded that the problem must be on my end so I would need to deal with it. However, this issue seemed only to appear in recent releases. I’ve been running ipCamera since 2.5.x and all of the iterations in between to OH3.3 final release using a flashed EZVIZ Doorbell Camera. I ended up just creating a rule that Toggles the ONVIF Thing back ONLINE (Disable/Enable) when it went OFFLINE for more than 30sec. Its working, but I’d much rather have a binding that deals with this issue rather than a rule. I’ll report back with my results.

2747

The binding can handle it, in fact you can be streaming MJPEG from the binding and pull the network cable out for any length of time and plug it back in and the stream will pick back up automatically. Hopefully this is the only bug that needed catching so look forward to hearing how it goes for you.

The odds are good that this will fix it as the camera I used to reproduce and fix the issue was the same camera most likely. BTW the latest hikvision firmware for the ezviz camera breaks the snapshot URL from working, you need to use the previous version, not sure about the other brands of firmware but they most likely suffer the same… The reason I went looking for this bug was I got an ERROR in the logs and the camera went offline for good, if someone had reported the ERROR I would have gone looking sooner, so please any feedback is good to get especially if you can say x version worked and then Y version broke.

Hikvision, Dahua/Amcrest, forscam, and Instar probably are not effected by this bug unless they are PTZ. Only cameras setup as ONVIF thing type would have gotten hit by the bug.

2748

@matt1 today I spent the afternoon evaluating the latest ipCamera 3.4 Snapshot Binding, but unfortunately I had to revert back to 3.3. The issue I was having was related to the FFMPEG motion detection which I could not get to work reliably no matter what I tried. The motion detection was erratic at times, but mostly the FFMPEG Alarm was locked ON. I run OH in a docker with 6 logical cpus and 2GB ram dedicated to OH3.3. While I have the OFFLINE issues when running OH3.3 version of the binding, FFMPEG Motion Detection works fine. I removed the existing ONVIF Thing, deleted the 3.3 binding, tried deleting the container and reinstalling OH, also I removed the cache and tmp files but I still could not get FFMPEG Motion Detection to work reliably with the 3.4 Snapshot Binding. I ended up just reverting back to the 3.3 Binding and everything is working as before. Were there any changes (intentional or inadvertent) that might have affected FFMPEG Motion Detection? Are you using motion detection in your current setup with the Snapshot Binding? Not sure what else I could try.

2749

It is impossible for the changes to have effected the ffmpeg motion, the changes were only in the disconnect and reconnect code for talking to the camera with ONVIF. The ffmeg code is separate and works with cameras that are not onvif at all.

I suspect this is the key reason why you hit troubles, is it possible you did not put all the config settings back 100% the same way when you re-created the thing? Its not necessary to delete and re-add the thing between the latest merged and this beta version of the binding. I’m going to assume it is the Ezviz camera that has the issues and this particular camera has limits on how many times its stream can be opened at the same time. The main stream can only be opened 2 times PLUS the second lower res stream can be opened only 1 time.

alarmInputUrl=“rtsp://192.168.1.3:554/Streaming/Channels/102”

Set the config for this camera to use the lower res stream for the Alarm input url. This will do two things, 1 use less CPU power due to lower res, and 2 will mean the main stream can still have the ability to be opened two more times.

Lastly a change was made to the ffmpeg motion and the way it works back in August 2021 and the test results that I wrote at this github issue is worth reading as the way ffmpeg works is it needs a different threshold if you adjust the FPS of the stream OR the RESOLUTION. If you did not put the alarmInputUrl back to the same it was before, then yes I can see you having issues unless you rework the value to suit.

[IPCamera] No FFMPEG Motion Detection · Issue #10683 · openhab/openhab-addons (github.com)

2750

@matt you are correct that the EZVIZ is only capable of 2 simultaneous streams. This I am aware of and has been accounted for in my setup. I’ll give it another try later today using the secondary stream, but I did not knowingly making changes to the configuration. I used the same config I had with the 3.3 binding which works fine. I’ll keep you posted as to what I find.

2751

I gave your suggestion a try, not deleting the ONVIF Thing but just uninstalling the 3.3 Binding and installing the 3.4 Snapshot Binding. This seems mostly to have fixed the issues I was seeing with FFMPEG Motion Detection. I was finally able to use the lower resolution, Channel 2 for motion detection after raising the Threshold Setting well above what I was using with Stream 1. Now I will focus on how well Binding 3.4 does at maintaining and re-initiating a connection if it is lost.

If you have any other thoughts on the motion detection, I’d be interested to try them. I will keep you updated as I evaluate the binding behavior for lost connections.

Thanks again for your efforts.

2752

Yes I had a thought that the ffmpeg may be going down for the same reason the onvif was made to reconnect, only now the camera does not go offline and your fix/workaround is not triggered. There is a GitHub issue requesting the ffmpeg motion detection be improved to auto restart as it will not restart if the camera goes offline or if the stream is interrupted. The camera may be doing a restart if it can not reach its cloud for example which would be an interesting test to make to see if blocking the access to the cloud makes a difference.

I don’t use the ffmepg motion detection nor do I leave streams open non stop.

2753

These are interesting points that you are making and helps to explain a lot of what I have seen. My solutions are empirical, but I had another rule that I was using to toggle FFMPEG Motion Detection OFF and ON every hour as I was noticing that FFMPEG would just die. Now I understand that if the camera went OFFLINE, even though I was able to get it reconnect via a Rule to Disable/Enable ONVIF Thing, the FFMPEG Motion Detection does not automatically restart. And here all this time I thought it was just me :slight_smile: As far as the camera using the Cloud, I have that disabled, but whether it stills call home to the mothership I don’t know. I haven’t really tried to use Wireshark to test that indeed the cloud is disabled, I just assumed it was. When I get some time I might check that. Anyway thanks for the insights.

As for the ONVIF Thing disconnecting, so far so good. It’s been running about 6 hrs without issue. Based on your experience I don’t expect any issues, but I will keep watch and let you know one way or another.

2754

The funny thing is I think only 1 person is having an issue, so it is a low priority to find some time to look at. You can see the github issue and there is a forum post with a work around you may want to try linked to in the issue.
[ipcamera] ffmpeg audio detection stops working/does not start on start-up · Issue #11672 · openhab/openhab-addons (github.com)

100% it will still be trying to dial home as it needs to punch a hole in the firewall so the cloud can talk to the camera through your firewall. You would not be able to open an app and view the uSD card recordings if it did not do this. What I do not know is if the camera assumes the web server in the camera has an issue when it can not reach the cloud and does a restart, this could be the reason for the amount of connection issues with this camera and not the wifi dropping out. This is only a theory, but it would be a reasonable thing for a camera designed to work with an app to do. If you do the test I would be interested to know the result.

2755

I’m upgrading from 2.5 and this was not a problem. On hikvision DVRs the IP channels start on 17. Any thoughts on why this was changed?

@Python I suggest you try providing explicit urls for snapshots, input, etc

2756

See this thread on the topic here

IP Camera Binding - Hikvision NVR, 9 camera limit workaround? - Add-ons / Bindings - openHAB Community

2757

Thanks, Ill check it out. I ended configuring my streams directly to each camera IP instead of going though the NVR/channels which was my work around.

I wouldn’t mind moving back to using the NVR Channels so ill check out the thread you posted @matt1