IpCamera: New IP Camera Binding

[matt1 (Skinah)]

No the binding tries to keep loads on the openhab server as low as possible and as most users have a raspberry pi with possibly a sd card I don’t believe that is a good idea. The way would be to allow this url to be used which keeps things consistent with how the rest of the binding works.
Openhabip:54321/ipcamera.jpg
Then it only places a load on the server when kodi asks for the file and it does not use the disk, only ram.

Could you do a guide on how u setup kodi to do the overlay?

[Sascha_]

Not to spam this topic, I’ve created a seperate thread for my development

[posixx]

The Kodi Security Cam Overlay can be found here. After installation you can configure up to 4 camera feeds (image URL) and some other stuff like refresh time etc.

within openhab i created a rule which is used to send an animated gif to my phone with pushover, and display image feed onto kodi:

rule "DoorBell"
when
    Item Doorbell changed to ON
then
    if (FrontDoorButtonPressed.state != ON) {
        FrontDoorCreateGif.sendCommand(ON)
        FrontDoorButtonPressed.sendCommand(ON)
        var String content = '{"jsonrpc":"2.0","method":"Addons.ExecuteAddon","params":{"addonid":"script.securitycam"},"id":"1"}'
	    sendHttpPostRequest("http://192.168.x.x:8080/jsonrpc",'application/json',content)
        sendHttpPostRequest("http://192.168.x.x:8080/jsonrpc",'application/json',content)
        sendHttpPostRequest("http://192.168.x.x:8080/jsonrpc",'application/json',content)
    }
end

So it would be very welcome the ipcamera binding could host a snapshot available through an url so i have to configure one URL only, not having multiple requests to the camera.

[peterhoeg]

@matt1

and it does not use the disk, only ram.

You could always mount a tmpfs directory and just store it there.

[higgers (Steve Higton)]

Thanks for your amazing work on this, Matt. I recently rebuilt my OH server which had been upgraded from 2.0->2.1->2.2->2.3-2.4 and was frequently crashing due to running out of Java heap space so I took the opportunity to upgrade to the latest version of your binding.

I’m using several Hikvision 2085 cameras and I noticed that the snapshot capture URL override and the stream URL override needed to be filled in the latest version. I’m fairly sure I didn’t need to specify these with the earlier version of the binding. I say I’m fairly sure but I have a bad memory and never take notes when I configure stuff…

I also got the GIF capture working and can see a ipcamera.gif file in the tmpfs directory. How can I use this file with Telegram. I already have a rule that sends a couple of snapshots:

    rule "Send telegram with fixed message when front door camera intrusion detected"
when
    Item CameraFrontDoor_IntrusionAlarm changed from OFF to ON
then
    logInfo("Dev", "Front door camera intrusion detected.")
    CameraFrontDoor_UpdateTheImage.sendCommand(ON)
	AVTVLGWebOSTVOLED55B6V_1_Toast.sendCommand("Front door camera intrusion detected")
    sendTelegram("Bot", "Front door camera intrusion detected")
    Thread::sleep(100)
    CameraFrontDoor_UpdateTheImage.sendCommand(OFF)
    var String base64Image0 = CameraFrontDoor_SnapshotFromCamera.state.toFullString
    sendTelegramPhoto("Bot", base64Image0, "Intrusion detected at front door")
    Thread::sleep(1000)
    CameraFrontDoor_UpdateTheImage.sendCommand(ON)
    Thread::sleep(100)
    CameraFrontDoor_UpdateTheImage.sendCommand(OFF)
    var String base64Image1 = CameraFrontDoor_SnapshotFromCamera.state.toFullString
    sendTelegramPhoto("Bot", base64Image1, "Intrusion detected at front door")
end

The line

var String base64Image1 = CameraFrontDoor_SnapshotFromCamera.state.toFullString

gets the snapshot into an item that can be passed to the Telegram binding. How can I do the same thing with the GIF file?

[matt1 (Skinah)]

@higgers

How can I do the same thing with the GIF file?

The documentation looks very good… See this link as it could be done by the file or by the URL. NOTE: I have not done it yet so the below rule is just a guess.

Telegram - Actions

rule "Send telegram with local image and caption"
when
    Item CameraFrontDoor_CreateGif changed from ON to OFF
then
    sendTelegramPhoto("bot1", "file:///path/to/local/ipcamera.gif", "sent from openHAB")
end

[higgers (Steve Higton)]

I had no idea the Telegram binding could access files. Thanks for the info.

I’ve updated my rule to these two:

rule "Create front door camera GIF when front door camera intrusion detected"
when
    Item CameraFrontDoor_IntrusionAlarm changed from OFF to ON
then
    logInfo("Dev", "Front door camera intrusion detected, triggering camera GIF creation...")
    CameraFrontDoor_CreateAnAnimatedGIF.sendCommand(ON)
end

rule "Send front door camera GIF via Telegram"
when
    Item CameraFrontDoor_CreateAnAnimatedGIF changed from ON to OFF
then

sendTelegram("Bot", "Front door camera intrusion detected")

sendTelegramPhoto("Bot", "file:///etc/openhab2/html/tmpfs/ipcamera.gif", "Intrusion detected at front door, GIF sent")

end

This works as far as sending an image to Telegram but it’s not animated. The ipcamera.gif file on the OH server is around 800k but the file saved to the gallery on my phone is about 50k. This must be a limitation of the Telegram binding, maybe it’s pulling only the first frame from the GIF and sending that?

Have you managed to send animated GIF files via Telegram? Maybe I’m missing something important…

[matt1 (Skinah)]

It is possible the Telegram binding/action does not support the feature. The telegram API does support the sending of animations and also mp4 video files which the binding could be made to support if it does not already, see here…

Telegram Bot API

I know people are doing it with Pushover and having a moving picture in the push messages. See if you can ask this question to the telegram binding maintainer @ZzetT (?) if it is supported and if not if it can be added for both gif and mp4.

[matt1 (Skinah)]

@higgers

I recently rebuilt my OH server which had been upgraded from 2.0->2.1->2.2->2.3-2.4 and was frequently crashing due to running out of Java heap space

If you are running a PI the default amount of memory Openhab can access is way too small in my opinion when all the device is doing is running Openhab and no other major system processes. By default I think the heap size is 1/4 of the ram in your system and that is all Openhab can use unless you make the change in this post. You need to leave some ram for Linux and other processes like Mosquitto that do not run in the Java virtual machine.

IpCamera: New IP Camera Binding

@Pedals2Paddles For anyone that gets OOME (out of memory errors) with the java heap space, then this is how I solved it to allow me to drop the refresh down to 1000ms. I have had my two cameras running for >24 hours without issues. I suspect this has to do with javas garbage collection not running often enough to deal with the large amounts of data passing through the image item if you are running your system close to the max allocated heap size. In the openhab console run this command (option…

@higgers

I’m using several Hikvision 2085 cameras and I noticed that the snapshot capture URL override and the stream URL override needed to be filled in the latest version. I’m fairly sure I didn’t need to specify these with the earlier version of the binding. I say I’m fairly sure but I have a bad memory and never take notes when I configure stuff…

I did make a change recently due to a user request as their camera did not work with ISAPI urls, can you confirm this is the issue by trying these two in a web browser please? Ip of your camera comes first. Otherwise it may be the NVR channel is set wrong and overriding the url removes the effect of the nvr setting.

/Streaming/channels/101/picture

/ISAPI/Streaming/channels/101/picture

[matt1 (Skinah)]

New build 2019-06-22 has these changes:

• Binding can now respond to requests for a current snapshot ipcamera.jpg if you use this url: http://192.168.xxx.xxx:54321/ipcamera.jpg
  @posixx you requested this feature, let me know if it fixes your use case.
  @Kim_Andersen this feature should make casting a static picture very easy if it does not work direct from a camera.

• Changes to Instar to give correct default ONVIF port and snapshot url.

• Huge clean up of the code that means all cameras were touched. This was to make the binding closer to merge to the project and make it easier to maintain the code. Look for bugs and any changes in performance.

[posixx]

@matt1 tnx for the feature. i will install an test tomorrow. To prepare for that; how does this url determine which ipcamera to use for the shapshot? I have 7 camera’s and need a way to select the frontdoor camera?

[matt1 (Skinah)]

Each camera will have its own port that the binding is serving the files on. So just change the number 54321 to something unique for each camera.

[posixx]

Ok, which configuation parameter is used for this port? It seems i’m not able to determine which one…

EDIT: oh i think it’s the default port configured in things file. I get an image when i open this URL but it’s the animated image from the last animated gif creation. I would expect the same image as the image channel content (ipcamera:HIKVISION:FrontDoor:image)…

EDIT2: Sorry, i used ipcamera.gif which is the animated gif ofcourse. using ipcamera.jpg gives me the current snapshot! Looks very gooed will try on my kodi systems tomorrow.

[posixx]

@matt1 it works perfrectly. Many many thanks for your great work!

[higgers (Steve Higton)]

It appears that rebuilding my OH system on a new VM has fixed (or hugely reduced) the memory leak I was experiencing. I’d already had to increase the Java heap size to 1.5GB and even then I’d had to set up a cron job to restart OH every night. Since the rebuild I’ve not seen any OOM issues.

To answer your questions:

The output from /Streaming/channels/101/picture is a snapshot from the camera and the output from /ISAPI/Streaming/channels/101/picture is also a snapshot from the camera. This prompted me to check the config of the camera, it looks like a recent firmware upgrade must have unticked the ONVIF
checkbox. I’ve ticked both the ONVIF checkbox and the HIKVision-CGI checkbox and the binding no longer needs the stream and snapshot override URLs to be filled. Excellent!

However…

I’ve noticed that the current version (2019-06-22) of the binding doesn’t seem to be detecting intrusion alarms. This was working with the previous version I had installed, I can’t remember which version that was. I think it might have been from around February or March.

Here’s an excerpt from the log:

24-Jun-2019 14:42:29.413 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Sending camera GET: http://192.168.0.68:80/Streaming/channels/101/picture
24-Jun-2019 14:42:29.414 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] -    Using the already open channel:0     GET:/Streaming/channels/101/picture
24-Jun-2019 14:42:29.414 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Sending camera GET: http://192.168.0.68:80/ISAPI/System/IO/inputs/1/status
24-Jun-2019 14:42:29.414 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] -    Using the already open channel:2     GET:/ISAPI/System/IO/inputs/1/status
24-Jun-2019 14:42:29.416 [DEBUG] [enhab.binding.ipcamera.internal.MyNettyAuthHandler] - 401: Mark to re-use,  the channel:0     GET:/Streaming/channels/101/picture
24-Jun-2019 14:42:29.417 [DEBUG] [enhab.binding.ipcamera.internal.MyNettyAuthHandler] - 401: Mark to re-use,  the channel:2     GET:/ISAPI/System/IO/inputs/1/status
24-Jun-2019 14:42:33.047 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - commonCameraHandler closed channel:1    URL:/ISAPI/Event/notification/alertStream
24-Jun-2019 14:42:34.413 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Sending camera GET: http://192.168.0.68:80/Streaming/channels/101/picture
24-Jun-2019 14:42:34.414 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] -    Using the already open channel:0     GET:/Streaming/channels/101/picture
24-Jun-2019 14:42:34.414 [WARN ] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - The alarm checking stream was not running. Cleaning channels and then going to re-start it now.
24-Jun-2019 14:42:34.414 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Sending camera GET: http://192.168.0.68:80/ISAPI/Event/notification/alertStream
24-Jun-2019 14:42:34.416 [DEBUG] [enhab.binding.ipcamera.internal.MyNettyAuthHandler] - 401: Mark to re-use,  the channel:0     GET:/Streaming/channels/101/picture
24-Jun-2019 14:42:34.419 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Have re-opened  the closed channel:1    GET:/ISAPI/Event/notification/alertStream
24-Jun-2019 14:42:34.419 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Sending camera GET: http://192.168.0.68:80/ISAPI/System/IO/inputs/1/status
24-Jun-2019 14:42:34.419 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] -    Using the already open channel:2     GET:/ISAPI/System/IO/inputs/1/status
24-Jun-2019 14:42:34.423 [DEBUG] [enhab.binding.ipcamera.internal.MyNettyAuthHandler] - 401: Mark to re-use,  the channel:1     GET:/ISAPI/Event/notification/alertStream
24-Jun-2019 14:42:34.424 [DEBUG] [enhab.binding.ipcamera.internal.MyNettyAuthHandler] - 401: Mark to re-use,  the channel:2     GET:/ISAPI/System/IO/inputs/1/status

Those 401 errors look like a password issue but I’ve checked the password in the binding for the camera user. I created an operator user on the camera and every privilege that can be turned on is turned on. Is there anything I can do to try and debug this?

[higgers (Steve Higton)]

I forgot to add that I’ve got Hikvision-CGI Authentication set to “digest/basic”.

[matt1 (Skinah)]

Clean and cache and temp folders and reboot, search this forum for how. The event stream is not staying open so no alarms will work until that is sorted and it may be you did not clean the cache when changing binding versions.
401 errors are normal for digest auth it is how it works just ignore.

[higgers (Steve Higton)]

Thanks for the reminder, I should have cleaned the cache already. After running “sudo openhab-cli clean-cache” the log is no longer full of 401 errors:

24-Jun-2019 15:53:19.860 [DEBUG] [org.openhab.binding.ipcamera                      ] - BundleEvent STARTED - org.openhab.binding.ipcamera
24-Jun-2019 15:53:19.896 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - initialize() called.
24-Jun-2019 15:53:20.896 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - About to connect to the IP Camera using the ONVIF PORT at IP:192.168.0.68:80
24-Jun-2019 15:53:21.382 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Fetching the number of Media Profiles this camera supports.
24-Jun-2019 15:53:21.855 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Checking the selected Media Profile is a valid number.
24-Jun-2019 15:53:21.855 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Fetching a Token for the selected Media Profile.
24-Jun-2019 15:53:21.855 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - About to fetch some information about the Media Profiles from the camera
24-Jun-2019 15:53:21.855 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - *********** Media Profile 0 details reported by camera at IP:192.168.0.68 ***********
24-Jun-2019 15:53:21.855 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Camera will use this Media Profile unless you change it in the bindings settings.
24-Jun-2019 15:53:21.855 [INFO ] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - This can be used to stream HLS with low CPU overhead
24-Jun-2019 15:53:21.855 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Media Profile 0 is named:VideoEncoder_1
24-Jun-2019 15:53:21.855 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Media Profile 0 uses video encoder      :H_264
24-Jun-2019 15:53:21.855 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Media Profile 0 uses video quality      :5.0
24-Jun-2019 15:53:21.855 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Media Profile 0 uses video resoltion    :3840 x 2160
24-Jun-2019 15:53:21.855 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Media Profile 0 uses video bitrate      :10240
24-Jun-2019 15:53:21.856 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - *********** Media Profile 1 details reported by camera at IP:192.168.0.68 ***********
24-Jun-2019 15:53:21.856 [INFO ] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - This can be used to stream HLS with low CPU overhead
24-Jun-2019 15:53:21.856 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Media Profile 1 is named:VideoEncoder_2
24-Jun-2019 15:53:21.856 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Media Profile 1 uses video encoder      :H_264
24-Jun-2019 15:53:21.858 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Media Profile 1 uses video quality      :3.0
24-Jun-2019 15:53:21.858 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Media Profile 1 uses video resoltion    :640 x 480
24-Jun-2019 15:53:21.858 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Media Profile 1 uses video bitrate      :768
24-Jun-2019 15:53:21.858 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - About to interrogate the camera to see if it supports PTZ.
24-Jun-2019 15:53:22.563 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Camera is reporting that it does NOT support Absolute PTZ controls via ONVIF
24-Jun-2019 15:53:22.564 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Finished with PTZ with no errors, now fetching the Video URL for RTSP from the camera.
24-Jun-2019 15:53:23.625 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Sending camera GET: http://192.168.0.68:80/Streaming/channels/101/picture
24-Jun-2019 15:53:23.634 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Have  opened  a  brand NEW channel:0    GET:/Streaming/channels/101/picture
24-Jun-2019 15:53:23.636 [INFO ] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - IP Camera at 192.168.0.68:80 is now online.
24-Jun-2019 15:53:23.642 [DEBUG] [enhab.binding.ipcamera.internal.MyNettyAuthHandler] - 401: Mark to re-use,  the channel:0     GET:/Streaming/channels/101/picture
24-Jun-2019 15:53:23.642 [DEBUG] [enhab.binding.ipcamera.internal.MyNettyAuthHandler] - Setting up the camera to use Basic Auth and resending last request with correct auth.
24-Jun-2019 15:53:23.642 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Setting up the BASIC auth now, this should only happen once.
24-Jun-2019 15:53:23.642 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Sending camera GET: http://192.168.0.68:80/Streaming/channels/101/picture
24-Jun-2019 15:53:23.642 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] -    Using the already open channel:0     GET:/Streaming/channels/101/picture
24-Jun-2019 15:53:23.920 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Snapshot recieved: Binding will now close the channel.
24-Jun-2019 15:53:23.930 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - commonCameraHandler closed channel:0    URL:/Streaming/channels/101/picture
24-Jun-2019 15:53:30.635 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Sending camera GET: http://192.168.0.68:80/Streaming/channels/101/picture
24-Jun-2019 15:53:30.649 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Have re-opened  the closed channel:0    GET:/Streaming/channels/101/picture
24-Jun-2019 15:53:30.649 [WARN ] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - The alarm checking stream was not running. Cleaning channels and then going to re-start it now.
24-Jun-2019 15:53:30.649 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Sending camera GET: http://192.168.0.68:80/ISAPI/Event/notification/alertStream
24-Jun-2019 15:53:30.652 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Have  opened  a  brand NEW channel:1    GET:/ISAPI/Event/notification/alertStream
24-Jun-2019 15:53:30.652 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Sending camera GET: http://192.168.0.68:80/ISAPI/System/IO/inputs/1/status
24-Jun-2019 15:53:30.656 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Have  opened  a  brand NEW channel:2    GET:/ISAPI/System/IO/inputs/1/status
24-Jun-2019 15:53:30.945 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Snapshot recieved: Binding will now close the channel.
24-Jun-2019 15:53:30.946 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - commonCameraHandler closed channel:0    URL:/Streaming/channels/101/picture
24-Jun-2019 15:53:35.635 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Sending camera GET: http://192.168.0.68:80/Streaming/channels/101/picture
24-Jun-2019 15:53:35.652 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Have re-opened  the closed channel:0    GET:/Streaming/channels/101/picture
24-Jun-2019 15:53:35.652 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Sending camera GET: http://192.168.0.68:80/ISAPI/System/IO/inputs/1/status
24-Jun-2019 15:53:35.652 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] -    Using the already open channel:2     GET:/ISAPI/System/IO/inputs/1/status
24-Jun-2019 15:53:35.951 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Snapshot recieved: Binding will now close the channel.
24-Jun-2019 15:53:35.953 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - commonCameraHandler closed channel:0    URL:/Streaming/channels/101/picture
24-Jun-2019 15:53:40.634 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Sending camera GET: http://192.168.0.68:80/Streaming/channels/101/picture
24-Jun-2019 15:53:40.636 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Have re-opened  the closed channel:0    GET:/Streaming/channels/101/picture
24-Jun-2019 15:53:40.636 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Sending camera GET: http://192.168.0.68:80/ISAPI/System/IO/inputs/1/status
24-Jun-2019 15:53:40.636 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] -    Using the already open channel:2     GET:/ISAPI/System/IO/inputs/1/status
24-Jun-2019 15:53:40.942 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - Snapshot recieved: Binding will now close the channel.
24-Jun-2019 15:53:40.943 [DEBUG] [g.openhab.binding.ipcamera.handler.IpCameraHandler] - commonCameraHandler closed channel:0    URL:/Streaming/channels/101/picture

It still doesn’t appear to be receiving intrusion alarms from the camera though. I’ll check the config on the camera again in case the firmware update broke it.

[Moshe_Dahan]

New Raspberry Pi 4 released with a much stronger CPU and a 4GB RAM option!
I assume this would be awesome for this binding, right @matt1?

[matt1 (Skinah)]

Awesome is too strong of a word as we have had clones that could do this for years already and it is still only a fraction of the CPU power of x86 based systems which are getting very efficient. Yes it is a lot better compared to previous Pis and all the concerns I have over older Pis are solved with the Pi4. I have a clone which is probably similar to the Pi4 and I average 33% cpu load so at some stage I will need to upgrade to something even bigger…

The next step up would be something like this which could double as a NAS/media server with Openhab in a docker container (see open media vault project):

https://www.hardkernel.com/shop/odroid-h2/

4 watts power draw at idle and the cost is about twice the Pi4 for probably twice the CPU power and more IO options.

The Intel Nuc J5005 which is a similar CPU to the above Odroid, with a bigger graphics card added in. So the H2 has better IO options and lower cost than the Nuc of similar specs.

Of course the Pi4 is a lot easier and cheaper to swap out if the hardware fails which is why I am in no hurry to change until I actually need the bigger CPU as prices only fall and newer hardware gets released.