IpCamera: New IP Camera Binding

Understood, changing config will force binding reconfigure, that is quite ok. Doing it in realtime, e.g. via rule does not make much sense IMHO.

BTW, two things I noticed:

  1. The animated GIF is triggered in my system by the Camera motion alarm. This leads to some delay when the GIF is captured. The GIF_PREROLL and GIF_POSTROLL will help that greatly, since I send that GIF via email to my phone.
  2. My realtime stream has about a 10s delay, i.e. what I see is always 10 seconds in the past?

New build 2019-06-01 has these changes:

  • New gif pre and post roll options as discussed in above posts
  • Will now serve the ipcamera.gif when asked
  • Ability to create and serve snapshot jpg files with the above new feature when using a preroll.
  • Minor changes to HLS

TIP:

In your sitemap or habpanel you can now use this link if you replace the xx’s and the port to be correct…

Webview url="http://192.168.xx.xx:54321/ipcamera.gif" height=9

Can do, just ordered a TTGO Camera Plus as peephole camera and will write a firmware for it.
I’ll post when ready.

4 Likes

Great I have one on a slow boat from China as well with the screen and PIR sensor.

What IDE do you use? Arduino, programio or another as I am just setting up to do some work with esp range for the first time.

I was also thinking about what the best way to implement the PIR and button push would be and it makes more sense not to use mqtt and instead to use an alarm stream like dahua and hikvision since the code is already there for sending a mjpeg stream. Less code to do it that way and the binding can use the alarm to start and stop image fetching.

Few different ways to choose from.

1 Like

Thx Matt,

got my Dahua IPC-HDBW2431RP-ZS working with livestream. Camera only supports rstp, so no image capturing possible.
Working with OpenhabianPi, the live stream will blur in 5-10 seconds and will then stop. Think the resolution is too high for OpenhabianPi.

Your binding works well.

New build 2019-06-09 has these changes:

  • Fix for error when trying to stream with no password.
  • Binding will now create a folder if the one specified as the ffmpeg output does not exist. Easier to create a single tmpfs and use multiple cameras each in a sub folder.
  • Changed the way the updateImageNow channel works to make it simple to use with external zwave or Zigbee PIR sensors. Snapshots will update at the polling rate whilst the switch is ON.

@Zijl
It is possible your issue with the livestream is the SD card is not fast enough to write and read a live stream. See the readme file on how to setup a tmpfs folder for the camera to use and this should fix it if related to SD card. Image capture should be possible as it is a basic feature that all Dahuas should be able to do otherwise they can not label it as an ONVIF camera.

1 Like

I’m using Arduino as it is IMO the easiest to set up for novices.

I’m starting with mqtt as I’m already using it big time but I’d like to offer the option for an alarm stream as this prevents users to go for mqtt just for this.

Maybe we had a little misconception - I’m waiting for the Camera PLUS and you are looking forward for an Camera.

Yes I am wanting the PIR sensors mostly and less interested in the camera side, but will have a bit of fun playing. The camera you are getting has the button labelled RST so I hope that does not mean it can not be reprogrammed for other tasks and only resets the esp32.

The last build for this binding changed the updateImageNow channel and this was done with these cameras in mind and if someone wanted to use a MQTT trigger for the channel to start and stop the image channel.

Hi matt…
I´m currently using this version:

openhab> bundle:list -s |grep -i ipcam
207 x Active x  80 x 2.5.0.201901260300    x org.openhab.binding.ipcamera
openhab>

I wonder, if I update the binding to the latest would require ffmpeg to be installed as well? I´m not sure if my Rpi 3B+ is capable of handling it.

Second:
Do you know if it would be possible to cast the image channel to a chromecast device? (I know this is not about ipcamera binding, but I have search and couldn´t find any answer). Or is there a local path where the graped image is stored?

You can use the latest bindingversion without ffmpeg, but if you try and use a feature that needs it then you will get an error in logs. The features u have now will all work without it installed. There were some minor breaking changes around 2019.02.27 and I kept the last version available in the old version download area. This thread covers the breaking changes so use the search function to find the info.

But why not install ffmpeg as I suspect it will work on the pi3 if u setup a tempfs for ffmpeg to use for the hls streaming. The read me covers this.

It may be possible to cast a static picture but the hls works so well I would not bother. Hls does not use much cup power if the camera is set to use h264 and the cup load is only when you are using the stream.

I´m not sure if it´s just my concern due to not really understanding the ffmpeg. But I use a Reolink ipcam, and for somehow I can only use it for httponly format even though it´s onvif supported. I have this concern about ffmpeg, that

  1. my Rpi is to small. I have had a hell before when using Grafana on my Rpi to render charts… It simply killed java/openhab.
    and
  2. I probably run into trouble with this Reolink due to my lack of knowledge for things like this.

Thats why I wanted to test with an image insted.

It should be fine as ffmpeg does not run in the background so if you don’t use the features it will not be running at all and the binding will still work the way it does for you now. It is mainly a cpu using program not a ram hog and as mentioned if the cameras feed is h264 which is every cameras default the cpu load is next to nothing as it does not Re encode for HLS which is what u want for casting.

HLS uses the storage device to hold around 10 seconds worth of video so with slow sd cards it is an issue, which tmpfs solves this.

You really should not be scared to give it a go. This shows you do not trust your backup to work. Copy the sd card to a second card and try it out on the copy then any issues just pop your unchanged card back in, easy, no risk and no need to worry.

I use SSD drive for openhab.
I´m not afraid of the backup. I know how to make backups.
I´m afraid experience the same as with Grafana. It worked fine for quite a while, then I updated openhab to 2.4, and hell broke loose with openhab/java restarted several times a day, (Java crashed and restarted openhab). But it only happened randomly. I could render one chart fine, and sometimes two, but often two crashed java, and three charts for certain crashed Java. It was a hell finding the reason, and required deeper Linux knowledged, which I havn´t got. So it took me quite a while to figure this one.

Thats the experience I´m afraid of using rpi and pushing it too hard. But I´m tempted to give it a try as I would rather want HLS streaming than image snapshots… Or perhaps animated gif´s. As you can see in another thread, my plan is to cast this to my Google Home Hub.

When I install the latest binding (06.09.2019) I get this error:

==> /var/log/openhab2/openhab.log <==

2019-06-11 18:50:25.160 [WARN ] [org.apache.felix.fileinstall        ] - Error while starting bundle: file:/usr/share/openhab2/addons/org.openhab.binding.ipcamera-2.5.0-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.ipcamera [295]
  Unresolved requirement: Import-Package: io.netty.bootstrap; version="[4.1.0,5.0.0)"
	at org.eclipse.osgi.container.Module.start(Module.java:444) ~[?:?]
	at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:383) ~[?:?]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [10:org.apache.felix.fileinstall:3.6.4]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [10:org.apache.felix.fileinstall:3.6.4]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:520) [10:org.apache.felix.fileinstall:3.6.4]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [10:org.apache.felix.fileinstall:3.6.4]
	at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [10:org.apache.felix.fileinstall:3.6.4]

In the zip file I downloaded, there are 8 .jar files beside the binding… Are they all suppose to be copied into the addons ?

Got my module today, just got it working with arduino and your binding to just dial into my Wifi and provide regular MJPEG images. Will polish the code (and remove Wifi credentials :wink: ) and publish tomorrow I think. Adding Wifi Manager will be in a later time but on my agenda.

Nifty little thing - great small display.

… this enables to use deep sleep - so this thing will be on coin cell for ages.

Yes all must be in the addons.
You will also need to clear tmp and cache folders.
If you have not done textual config (things file) you need to delete and readd the camera.
There are breaking changes to be aware of especially if you override urls with textual config.

Using the search on this thread will answer these for you.

@Sascha_
Very Cool let me know how it goes.

@matt1: can i somehow display these prefetch images through use of a URL? For me the new animated gif creation (pre- and postroll) work perfectly; i send that to my phone. But i want to display camera images on my kodi systems using Security camera overlay. This uses a URL for image retrieval refreshed every second. As i have 3 Kodi streamers and am using image refresh every second for animated image creation, i get too much calls to my camera and the images are not dispayed. If i can serve the images already retrieved by your binding this will take out any additional stress on the camera; openhab will serve these images to all 3 streamers.

Not currently but it would be possible for the binding to pass them on without being saved to disk if the feature was added. I already do a similar thing for the mjpeg stream for similar reasons.

I would normally say use the camera to serve the files directly but you gave a good description of why that won’t work.

This method may work if you save the file to the HTML folder and use openhabs serving ability.

Just to be clear about the way it works now; does the image channel save the image to disk every poll interval? it doesn’t seem to do that. It would be a welcome addition to have a switch channel available to be able to to just that. If the switch is on the fetched image is also saved to the FFMPEG_OUTPUT location (and thus overwritten every poll), if it is off it behaves as current behaviour. THis way i can save the images to the opehad html folder for some seconds as long as the kodi streamers show the camera overlay…