IpCamera binding - Breaking changes and new features in 3.2 Milestone 3 and newer

A quick heads up and a shout out if your able to test the upcoming changes, then please report your findings to help the next release go smoother.

  • Camera groups now can do rotating MJPEG feeds that skip cameras that have no motion when at least 1 camera in the group has movement.
  • Less polling of the snapshot which caused some cameras to store snapshots on SD cards.
  • The breaking change is that files will now get served on these URLs and the string channels are updated. To prepare for the change, please use the String channels and remove any hard coded urls from widgets and rules. Doing this ahead of time will ease the change.
http://openhab:8080/ipcamera/<cameraUID>/ipcamera.jpg
http://openhab:8080/ipcamera/<cameraUID>/ipcamera.mjpeg
http://openhab:8080/ipcamera/<cameraUID>/ipcamera.m3u8
http://openhab:8080/ipcamera/<cameraUID>/snapshots.mjpeg
http://openhab:8080/ipcamera/<cameraUID>/autofps.mjpeg

This means easier setup of cameras as the serverPort will no longer need to be set and Alexa setup will be easier if your wanting to stream HLS to your Alexa devices. If your using Alexa and have cameras then check out this post to help with beta testing:
openHAB Skill for Amazon Alexa New Metadata Syntax Beta Test - Apps & Services / Amazon Alexa - openHAB Community

Jar can be downloaded here if you wish to use it on older 3.1 cores:

http://pcmus.com/openhab/IpCameraBinding/

NOTE: Installing the tellstick binding will take care of any Netty dependency missing warnings or you can install the Netty libraries (more advanced then just installing tellstick) using the console and the commands in this post.

Zwave and ipcamera issue - Setup, Configuration and Use / Installation - openHAB Community

4 Likes

Hi matt1,
I just updated to the 3.2 milestone 3 release (from milestone 2). Whereas the transition to the new settings for my onvif camera was fairly smooth, I’m having trouble with my Instar camera using the API (seemingly unrelated to the changes described above). I now get several error messages in my logs:

 [WARN ] [mera.internal.handler.IpCameraHandler] - Camera is reporting your username and/or password is wrong.
...
[WARN ] [mera.internal.handler.IpCameraHandler] - !!!! Camera possibly closed the channel on the binding, cause reported is: Queue full

The second message is probably a result of the first problem.
I recreated the thing (discovery does not work with this camera), but the problem persists. I double-checked that username and password are correct (I haven’t changed them and they work fine in a web browser).

Use the build here which is newer and I was doing some changes and testing with Instar tonight and had no issues:
Index of /openhab/IpCameraBinding/ (pcmus.com)
If you get dependancy issues, just install the tellstick binding. Any further problems just PM me the trace log when the camera trys to connect and make sure other cameras are paused so they don’t flood the logs.

Hi matt1,

thanks for providing the file. Since I haven’t yet had the need to replace jar files in a production environment, I want to make sure that I don’t mess anything up. Should I place your .jar file into the /usr/share/openhab/addons directory and it should be used automatically after a restart (instead of the existing milestone build)?

Uninstall the binding from the UI
Drop the jar file after being unzipped into that folder
It should then work no restart needed
If you get errors in the logs, then install the tellstick binding to supply the netty library that will be causing the errors.

Very simple and you don’t need to restart.

@sheldon
After doing some more testing, I did find a bug so make sure you download the newer ZIP which has it fixed.

The WARN about user/pass wrong, this was stopping the binding from setting up the alarm server automatically. Only effects INSTAR. Fixed in todays newer PM jar so thanks for reporting it.

The second WARN means the camera or the binding has a full queue of http requests, this may happen if the cameras server is busy and wont answer the binding. You may be getting 50x http errors logged in trace mode, so if you can capture it happening in trace that would help work out the cause.

Either PM me or open a new thread to keep this one cleaner.

Hi matt1,

thanks, the problem seems to be fixed. Both cameras work as expected. However, I decided to uninstall the snapshot release and wait for the next milestone release because the Tellstick binding caused some trouble. I got the following exception in the log:

[ERROR] [l.discovery.TellstickBridgeDiscovery] - Could not load telldus core, please make sure Telldus is installed and correct 32/64 bit java.

And there were also some warnings related to other serial devices (Modbus, EnOcean).

I hope that the Tellstick dependency is not permanent?

No not permanent which is why when you uninstall the ipcamera binding it then misses the needed dependencies. There are other ways to install them via console commands, or downloading the jar files from maven repos.

Now that the newer binding has setup the cameras alarm server settings, you should find it will keep working even when you use the m3 version, just ignore the WARN as it will occur. It only needs to setup the alarm server once.

Milestone 4 will have the fixes in it.

With the new binding I have the following issue:
ipcamera.mjpeg is not working while snapshots.mjpeg is working

old url: http://192.168.178.20:50001/ipcamera.mjpeg
new url: http://192.168.178.20/ipcamera/6e3bb01970/ipcamera.mjpeg

when I replace “ipcamera.mjpeg” by “snapshots.mjpeg” it is working.
I didn’t change anything to the camera (afaik)
Is there something I can check?
I have a Hikvision camera DS-2CD2T85FWD
If it can’t be a binding issue I will downgrade to 3.1 and try again, just to be sure it hasn’t anything to do with the camera.
Thanks.

Shouldn’t

http://192.168.178.20/ipcamera/6e3bb01970/ipcamera.mjpeg

be:

http://192.168.178.20:8080/ipcamera/6e3bb01970/ipcamera.mjpeg

As per the breaking changes above? Port been changed to 8080 for all?

I don’t think so, I am running openhab on port 80 instead of 8080. besides that, the snapshots.mjpeg is running fine.

You can leave the port 80 out if you have reconfigured openHAB to serve on that port and as you wrote if the other ones work it must be something else. What does the TRACE log show if you pause all cameras except 1 and capture when you open the first stream? The log will tell you it saw the GET request and provide some more hints. If you don’t see the log of the GET request then triple check the URL has the correct uniqueID as that has caught me a few times when deleting and re-adding cameras to test with.

My Hik cameras are working fine, but I need to do a firmware update which I’ll do tonight and retest. If you have not updated the firmware yet, HIK has a security flaw discovered that needs an update to fix.

Edit: @PeterB Still working here after firmware update done to latest to fix security flaw in cameras firmware. Will need trace logs to look at further.

I don’t see anything about the ipcamera.mjpeg stream but at least something doesn’t seem ok.

> 2021-10-12 11:03:18.407 [DEBUG] [g.ipcamera.internal.HikvisionHandler] - Unhandled reply-<!DOCTYPE html>
> <html><head><title>Document Error: Unauthorized</title></head>
> <body><h2>Access Error: 401 -- Unauthorized</h2>
> <p>Authentication Error</p>
> </body>
> </html>
> .
> 2021-10-12 11:03:18.413 [TRACE] [era.internal.handler.IpCameraHandler] - Sending camera: GET: http://192.168.178.65:80/ISAPI/Streaming/channels/101/picture
> 2021-10-12 11:03:18.420 [DEBUG] [ipcamera.internal.MyNettyAuthHandler] - Camera at IP:192.168.178.65 gave a reply with a response code of :503
> 2021-10-12 11:03:18.420 [TRACE] [g.ipcamera.internal.HikvisionHandler] - HTTP Result back from camera is 	:<?xml version="1.0" encoding="UTF-8"?>
> <ResponseStatus version="2.0" xmlns="http://www.hikvision.com/ver20/XMLSchema">
> <requestURL>/ISAPI/Streaming/channels/101/picture</requestURL>
> <statusCode>2</statusCode>
> <statusString>Device Busy</statusString>
> <subStatusCode>deviceBusy</subStatusCode>
> </ResponseStatus>

Try making sure your user / pass is correct and then restart the camera. Hik has a feature where it will lock you out if you get the password wrong 3 times and only restarting the camera will reset it. Hard to know if the 401 or the 503 is the reason.

Do you have digest or basic auth setup on the camera?

I rebooted the camera, but it didn’t change anything.
Both RTSP Authentication and WEB Authentication are set to digest.
I don’t have issues accessing the camera via the web interface.
Btw, I am using the binding shipped with the milestone, not your updated version.

EDIT: I reverted back to openhab 3.1 release and the old URL: http://192.168.178.20:50001/ipcamera.mjpeg is working again, but the errors in the log file are still there.

Digest has a 401 error every time, that is how it works so each request is made twice with the first one failing. So the 503 has stopped when you reverted? How often did you get the 503? I will need to have a in depth look as the reason is not obvious and your logs do not show the GET request is received so it may not even be from the point in time that the request was made.

The URL in the log is for the snapshot and not the stream.

Indeed, no 503 errors on the 3.1 version. On the M3 snapshot I see an 503 error about every 2 seconds.

I have the exact same issue, except that my openhab instance is served on standard Port 8080.

With log of ipcamera-binding set to “TRACE” i get following error after opening a sitemap with html-embedded .mjpeg stream (dahua cam):

[DEBUG] [amera.internal.servlet.CameraServlet] - Not the first stream requested. Stream from camera already open

Seems there is a multiple acces to the (…):8080/ipcamera/UID/ipcamera.mjpeg -stream

With the older Binding (M2) i had no problems directly accessing the MJPEG-Streams from my Dahua Cams.

best regards

I also encounter the following messages into the log:

[DEBUG] [amera.internal.servlet.CameraServlet] - GET:/ipcamera.mjpeg, received from 127.0.0.1
[DEBUG] [amera.internal.servlet.CameraServlet] - First stream requested, opening up stream from camera
[TRACE] [era.internal.handler.IpCameraHandler] - Sending camera: GET: http://192.168.120.52:80/ISAPI/Streaming/channels/102/httppreview
[WARN ] [era.internal.handler.IpCameraHandler] - !!!! Camera possibly closed the channel on the binding, cause reported is: Queue full
[WARN ] [era.internal.handler.IpCameraHandler] - !!!! Camera possibly closed the channel on the binding, cause reported is: Queue full

This is the cause of the problem with missing/freeze mjpeg stream mentioned into 11301. In case the stream starts, it works for few (maximum 5) seconds and then freeze.

I confirm that the code from this commit fixed the issue. Thank you, Matt!

No problem, I have created a PR and made a precompiled jar which can be found here:

[ipcamera] Improvements and fix 503 errors go to offline with Hik by Skinah · Pull Request #11419 · openhab/openhab-addons (github.com)

The 503 errors were only appearing on my Hikvision cameras and I was able to reproduce some issues here, they should be fixed in the changes in the PR linked above. If anyone can help test that would be great.

So I was not having any issues (reolink cameras), but wanted to report the new IP camera binding with breaking changes uses less CPU on my Rpi4. Here is a picture of before and after. A little hard to read, but the change is about the middle of the graph. The spikes are when video was triggered.

Thanks @matt1 for all your efforts. I think it is a very important OH binding.

Bob