IpCamera: New IP Camera Binding

Tags: #<Tag:0x00007fe736893be8> #<Tag:0x00007fe736893968> #<Tag:0x00007fe736893788>

I have used this binding with great success on an Intel NUC with plenty of horsepower. Now I am looking to get the binding working with two cameras and a RaspberryPi 3 B. Everything works fine until the Pi begins to generate a GIF after a motion alarm. The system appears to run out of resources while the GIF is being created. As soon as the GIF creation process finishes, the Pi comes back to life. So I wonder - do I have things mis-configured, and FFMPEG is working overtime? Is this normal?

I would be perfectly happy using a snapshot instead of a GIF (I am using Pushover to send an image to my iOS device so I can see what generated the motion alarm), but Pushover is looking for a file location for the snapshot image, and I am not sure where on the file system the snapshots are stored. GIF would be better, but snapshot would be fine as well.

If anyone has any ideas of where to start, I would very much appreciate it.

I would start with a new thread and include some TRACE log output when the gif is being created and please disable all cameras except 1 during this time to make the log easier to follow.

I would also suggest you try using gifPreroll of 1, as this will cause the snapshots to be the source for the GIF and you wont be firiing up FFmpeg and streaming RTSP to do the same job.

Two points also to comment.

  1. Some cameras can only handle X number of streams open at the same time. This needs to be considered if you have both the NUC and the PI trying to talk to the camera as well as maybe a NVR or another server. It can also be an issue if the binding is opening multiple RTSP streams up because you are wanting a GIF, and a number of other features all at the same time. The gifPreroll trick may solve this for you by reducing the number of used streams.

  2. The Pi3 has a weakness in its design for camera uses. The network card is attached via USB2 and if your using a SSD or any other USB devices also on the USB2 bus, it could be hitting a bottleneck. If the binding is requesting multiple RTSP streams they will be adding up and filling this bottleneck and a SSD will make the issue worse. The CPU is also very weak for some of the tasks the binding does, in Linux use the command ‘top’ or ‘htop’ (worth googling how to install htop as it is much nicer) to see in realtime what the CPU is doing and how close you are to hitting 100% usage. The PI4 was a big step up in design from the 3, but even the Pi4 is probably not enough in some use cases if you ‘want it all’.

Thanks Matt. I will do that tomorrow. There is only one camera hooked up to the system at the moment. When you say start a new thread, you mean create a whole separate topic in the community outside of this IpCamera binding thread?

Definitely will try that. I would be perfectly happy with a single frame and definitely do not need to fire up FFmpeg and stream RTSP just to send a single snapshot by Pushover.

Yeah - I remember this was an issue, especially with the DB-1. In this case, the only thing requesting streams is the RasPI. This is a completely separate installation from the NUC installation. So it is not a multiple open stream issue.

Thanks for this info. I did not know that. Good to know the Pi4 might not even be enough. This installation will only have two cameras.

Anyway, I have really been banging my head against the wall with this. I am going to strip thing back to the very basics and see what I can find out. I will post what I come up with.

Thank You for explanations on the logs! Over weekend will go with my own thread then (and trace logs included).
The above url is working from browser (asking for password and giving the image0>
Camera is UniView IPC2122LR3. It is behind firewall, but my laptop with browser is on same network as the rpi - if it works from browser, should be working from rpi as well … though I could test out curl from rpi for sake of experiment.
Thank You and see you in new thread! :slight_smile:

Your laptop has a different IP to your Pi, a firewall could allow the laptop to work and block the PI so yes good idea to use curl to test with. I have made a fix to help stop the memory/channels running away like that in the next build, but we need to work out what the root cause is instead of treating the symptom.

1 Like

Binding is now merged into openHAB 2.5.9 and there are a few breaking changes to deal with.

Rrecording to gif and MP4 is now done differently via an Action and a channel with a new name. Example in docs.

Anything in all capitals In your thing and items files needs changing to match the docs.

The gotoPreset channel for pan tilt zoom cameras is now a String channel and not a Number channel. Change the item over and it should work the same.

Docs are now found here.

5 Likes

Great! Will test this.

So i have to remove the binding file and all the small additional files from addon folder and only install the binding from paperui or with textual config?

How do i have to control the lengt of the gif created with the new binding?

Inside things-file with gifPostroll = 20 or inside the action in my rules-file with …).recordGIF(“ipcamera”,20) ???

Can i remove gifPostroll from things-file now?

With the new binding i only get gif with length of 5 sec.

Yes remove gifpostroll as it does not exist and you can now change the length of the recording at will in a rule. The mp4 is done the same way.

Now i removed it in the things-file. But still the recorded video file is only 5 seconds…

In the log i can see, that the email is sent after about 22 seconds from start of the recording. But the recorded file is only 1 mb (formerly it was about 5mb). And the recorded file is only 5 seconds.

I can see in the video time stamp, that i only get about the last 5 seconds of the recorded time. The first about 15 seconds are not there…

Any idea?

Maybe my things file is not compatible with the new binding anymore? I already used the latest test bindings before - with success.

Maybe this has to be changed?

gifOutOptions="-filter_complex fps=4,scale=480:-2:flags=lanczos,setpts=0.25*PTS,split[o1][o2];[o1]palettegen[p];[o2]fifo[o3];[o3][p]paletteuse"

EDIT: changed the options to standard, no change - only smaller picture, but still only 5 seconds.

EDIT2:changed action in rule to 10 seconds, still gif is only 5 seconds.

Should i enable tracing and show you the logs?

In the new doc page there this option is still described. You should remove it there, if it is removed in the new binding.

Thanks for reporting, that is a bug and I fixed it and uploaded a new build for you to try. Will have to wait till V3 most likely to fix it as 2.5.9 may be the last release.

Where can i get the new test build?

Is this only one jar-file or do i have to copy all the jetty… files into addons-folder, again too?

I removed all of the additional files from addons folder. soap.api, jetty, …

Try without the additional files first, if not the ones that are needed are also in the zip.

http://www.pcmus.com/openhab/IpCameraBinding/ipcamera-2020-09-21.zip

There is also a statement like this that I think it’s obsolate, in the new DOC
" Use the updateGif feature and…"

Proud you published, nice job

I tried it:

removed “ipcamera” from my addons.cfg-file
only moved the new jar-file to addons-folder without the netty-files
sudo reboot

Now it works - my gif is 20 seconds again.

Thanks, great job!

Hi,

I have a (maybe) stupid question: is the „mp4Preroll“ channel still working/part of the binding? I can’t get that to work and there is no mention of that in the documentation.

Thank you!

Binding is now merged into openHAB 2.5.9

Congrats, Matt. This is great news!

2 Likes

It is not implemented yet and if/when it is, it will not be done via a channel but via an action. As soon as github has been switched over to have V3 as the main branch I will have to do a cleanup, so thanks for reporting any thing you notice.

1 Like

Sorry, reading this from frontail log

020-09-22 18:15:54.390 [WARN ] [me.config.core.internal.ConfigMapper] - Could not set field value for field ‘updateImageWhen’: Can not set java.lang.String field org.openhab.binding.ipcamera.internal.CameraConfig.updateImageWhen to java.math.BigDecimal

java.lang.IllegalArgumentException: Can not set java.lang.String field org.openhab.binding.ipcamera.internal.CameraConfig.updateImageWhen to java.math.BigDecimal

I also notice this:
xmlns:trt=“http://www.onvif.org/ver10/media/wsdl” xmlns:ter=“http://www.onvif.org/ver10/error” xmlns:tns1=“http://www.onvif.org/ver10/topics” xmlns:trt2=“http://www.onvif.org/ver20/media/wsdl” xmlns:tr2=“http://www.onvif.org/ver20/media/wsdl” xmlns:ewsd=“http://www.onvifext.com/onvif/ext/ver10/wsdl” xmlns:exsd=“http://www.onvifext.com/onvif/ext/ver10/schema” xmlns:hikwsd=“http://www.onvifext.com/onvif/ext/ver10/wsdl” xmlns:hikxsd=“http://www.onvifext.com/onvif/ext/ver10/schema” xmlns:tnshik=“http://www.hikvision.com/2011/event/topics”>SOAP-ENV:BodySOAP-ENV:FaultSOAP-ENV:CodeSOAP-ENV:ValueSOAP-ENV:Sender</SOAP-ENV:Value>SOAP-ENV:SubcodeSOAP-ENV:Subcode</SOAP-ENV:Subcode></SOAP-ENV:Subcode></SOAP-ENV:Code>SOAP-ENV:Reason<SOAP-ENV:Text xml:lang=“en”>Error 401: HTTP 401 Unauthorized</SOAP-ENV:Text></SOAP-ENV:Reason></SOAP-ENV:Fault></SOAP-ENV:Body></SOAP-ENV:Envelope>