IpCamera: New IP Camera Binding

Tags: #<Tag:0x00007f5c985e7148> #<Tag:0x00007f5c985e6f90> #<Tag:0x00007f5c985e6dd8>

I have no changed to be using thing file insted… Still the same issue with Google Home…
This is my setup:

Thing ipcamera:DAHUA:DAHUA1 "Front door" @ "Cameras"
[
    IPADDRESS="10.4.28.194",
    USERNAME="admin",
    PASSWORD="password",
    POLL_CAMERA_MS=1000,
    SERVER_PORT=54321,
    IP_WHITELIST="DISABLE",
    IMAGE_UPDATE_EVENTS=1,
    UPDATE_IMAGE=false,
    ONVIF_PORT=80,
    PORT=80,
    ONVIF_MEDIA_PROFILE=0,
    GIF_PREROLL=2,
    GIF_POSTROLL=8,
    FFMPEG_LOCATION="/usr/bin/ffmpeg",
    FFMPEG_GIF_OUT_ARGUMENTS="-r 2 -filter_complex scale=-2:360:flags=lanczos,setpts=0.5*PTS,split[o1][o2];[o1]palettegen[p];[o2]fifo[o3];[o3][p]paletteuse",
    FFMPEG_OUTPUT="/etc/openhab2/html/camera/dahua1/",
    FFMPEG_HLS_OUT_ARGUMENTS="-strict -2 -f lavfi -i aevalsrc=0 -acodec aac -vcodec copy -hls_flags delete_segments -hls_time 1 -hls_list_size 3",
    FFMPEG_MJPEG_ARGUMENTS="-qscale:v 5 -r 6 -update 1"
]

And my items:

String Dahua1HlsUrl    "Fordøren [%s]"     { channel="ipcamera:DAHUA:DAHUA1:hlsUrl", ga="Camera" [ protocols="hls" ] }

In order to make sure the String URL is correct, I inserted the [%s] to the label of the item.
This is how it looks in BasicUI, (notice the last “Fordøren” state).

This tells me, setup should be just fine:

Issue:
When I ask Home Hub to “show me fordøren”. Google respond in less than as second:
Sorry something went wrong. I cant controle your Home Hub right now”.
The streaming switch do NOT get activated.

When I use the same link in Microsoft Edge:
Streaming switch gets activated.
It starts streaming just fine.

I have aprox 80-90 other GA tags, which are working just fine, all controlled from the same Home Hub, (as well as other Google devices I´ve got in the house).
I use GoogleTTS to send say commands from the same openhab/rpi setup to the Home Hub, which is working just fine. This tells me, communication to/from this Home Hub is working just fine.
So this particular ga=“Camera” tag or the ipcamera binding seems to be an issue somehow.

I have to include @michikrug as well, as he may have some deeper info from the GA integration…
In order to troubleshoot this one, I need to know:

When exactly do the streaming switch gets activated? Does Home Hub/chromecast devices check the media before it actually starts streaming, or is this check only beeing done, when the streaming activated has been switched on? If Home hub checks the media first, it may be some settings in the FFMPEG setup, which is breaking the stream for Home Hub.
But if it does not check the media before activating, I would say something is wrong, either in the GA integration (specific for the ga=“Camera” tag, this is a Google issue, which seems to affect the danish language…
Personally I think this is a Google issue which may be only affect the danish language setup. But that dont fit with Google Nest Hello (Google own cameras) are working just fine in Denmark according to other users. Or Google checks the media before it actually activate the streaming switch, and therefore there might be a setup fault in the FFMPEG setup for the media.

I really could need some help with this one!!!

This will be my last reply because I stated you MUST NOT use labels with the string or any variable in them. IT WILL BREAK it from working. Create your own thread asking for help as your issue appears to not be with this binding…

items

String Dahua1ForSitemap "HLS" { channel="ipcamera:DAHUA:DAHUA1:hlsUrl" }
String Dahua1ForHub "Fordøren" { channel="ipcamera:DAHUA:DAHUA1:hlsUrl", synonyms="The front door, front doorway, front entry", ga="Camera" [ protocols="hls" ] }

Then say, "ok google, sync my devices" After that succeeds say this "Show the front door" or any of the synonyms or the label, but they must be an exact match which is why you can not use the string in the label.

If the binding does not log the request then you must have 1 of a few things happening.

  1. The nest hub is trying to use the wrong url. Not likely as it is being sourced direct from the channel.
  2. There is an issue with your network stopping the request. Highly likely, but more likely it is caused by what is in my first sentence.
  3. The special character may be causing issues, change Fordøren to something with more plain characters as the REST api may be having issues if it is a non legal character to be used in a GET request. This is not my area of knowledge hence why this should be in a new thread as it is not to do with this binding.

I use this feature for many hours every day, have been doing so for more than a year and it works.

I DID try everything you´ve suggested. (I told you why I´d add the [%s], simply to make absoluly sure the Url was correct, cause thats the only way to see it).
I tried with and without variable in the label.
I changed the label to something more accurate using more words etc.
I tried all possible combinations of whats in the docs.
I tried using different serverport.
I just tried your exact example above including with synonyms. (Synonyms does not seem to work at all in danish language).

I end up with the same result no matter what I try:
Google respons, “Something went wrong. Cant control your Google device right now
ipcamera stream switch not activating.

I´ll create a new thread, or find some help elsewhere.

EDIT - For who it may concern.

Seems like I have moved one big step forward a “reason”…
My streaming is working just fine. But only if I pick up my phone, start the Google Assistant and tell Google to “show (cameraname) on (device)” Then my Home Hub (device) will start streaming just fine.

But if I aks my Home Hub to “show (cameraname)” I get the above error, “something went wrong…”

Its highly strange… But at least I no longer have to deal with the videoformat beeing wrong!

Considere the new Google home assistant integration wich change a bit the TAG call method

I am able to view an image if I set the FFMPEG_INPUT to the rtsp stream URL. So I guess authentication is working with the doorbell camera.

I continue to troubleshoot the Hikvision/EZVIZ DB-1 type doorbells, trying to get them to work with this great binding. If we can work it out, I will post something on the ipcamtalk site and see if we can get some OH converts.

Here are the issues I am aware of with this binding and these cameras:

  • Binding fails to retrieve rtsp and shapshot URLs over ONVIF even though camera supports ONVIF with Hikvision Firmware, and URL info is available (see below)
    ** Solution for now: Manually add URLs using SNAPSHOT_URL_OVERRIDE, and FFMPEG_INPUT Thing file definitions.

FWIW, I do not see why I would need to set STREAM_URL_OVERRIDE=“ffmpeg” even though this is recommended in the README. With or without this, as long as FFMPEG_INPUT is set to the rtsp url, the binding seems to fire up ffmpeg and create the stream just fine. Am I missing something?

  • No MJPEG available on any stream (doorbell supports two streams, but only with h.264 encoding)
    ** Solution: Let binding create mjpeg stream on the fly by using the FFMPEG_INPUT Thing set to the rtsp stream IP address

  • No web interface
    ** No solution, but interface really not needed

  • No regular Hikvision API for reporting events from the camera
    ** Solution - an ONVIF to MQTT docker container is available here. This allows events from the doorbell to be used by OH with the MQTT addon.
    ** Feature request - Would it be possible to have this binding get events thorough ONVF from this doorbell? It would simplify the use of the doorbell with OH substantially.

Here is some other information about this doorbell and getting it to work with this binding:

  • It supports discovery (camera is found by Hikvision iVMS-4200 app)
  • It supports ONVIF IF it is running Hikvision Firmware (ONVIF Device Manager is able to connect to the device)
    ** Camera reports ONVIF version 2.60
    ** ONVIF URL is camera.ip.address/onvif/device_service
    ** It is possible to set the camera to use the same NTP server as the OH server (eliminates timing/authentication errors)
    ** ONVIF may be used to retrieve the rtsp streaming URL (proven because it can be seen in ONVIF Device Manager)
    ** ONVIF may be used to report motion events (PIR for sure, not positive if Hikvision motion analysis events are reported or not)

Snapshot URL: http://camera.ip.address/onvif/snapshot.jpg (no username/password needed)
Streaming URL: rtsp://camera.ip.address:554/Streaming/Channels/101 for Main Profile
Streaming URL: rtsp://camera.ip.address:554/Streaming/Channels/102 for substream profile

The HTTPONLY Thing definition seems to work. I am not using the HIKVISION Thing because the doorbell does not support the Hikvision API. The ONVIF definition reports errors getting the snapshot and stream URLs.

Thing ipcamera:HTTPONLY:doorbell
[
	IPADDRESS="camera.ip.address",
	USERNAME="admin",
	PASSWORD="mypassword",
	POLL_CAMERA_MS=2000,
	SNAPSHOT_URL_OVERRIDE="http://camera.ip.address/onvif/snapshot.jpg",
	SERVER_PORT=54030,
	FFMPEG_INPUT="rtsp://camera.ip.address:554/Streaming/Channels/101",
	FFMPEG_OUTPUT="/tmpfs/doorbell/"
]

If something works in onvif device manager but not the binding then it is worth creating an issue and attaching some trace logs of when the camera is connecting.

I have been adding the feature for onvif events but it is not yet ready for release but it is for alpha level testing. @bgilmer If interested I have already uploaded a build for you to try as it is working on 1 of my cameras and still yet to find the time to try it on a number of brands.

  1. It only works if the thing type is ONVIF
  2. You can use the over ride urls if the onvif does not detect them automatically just the same way you are with httponly.
  3. Use DEBUG level log output and you should see the onvif events getting logged, If it does not work I will need a copy of the log output.
  4. Only motion detection is coded, but if people send me the log output I can add any other events very easily.

Any idea why I get this netty warning?

2020-05-24 22:19:39.960 [WARN ] [io.netty.channel.nio.NioEventLoop   ] - Selector.select() returned prematurely 512 times in a row; rebuilding Selector io.netty.channel.nio.SelectedSelectionKeySetSelector@1d1a4aa.
2020-05-24 22:19:39.992 [WARN ] [io.netty.channel.nio.NioEventLoop   ] - Selector.select() returned prematurely 512 times in a row; rebuilding Selector io.netty.channel.nio.SelectedSelectionKeySetSelector@37459f.
2020-05-24 22:19:39.990 [WARN ] [io.netty.channel.nio.NioEventLoop   ] - Selector.select() returned prematurely 512 times in a row; rebuilding Selector io.netty.channel.nio.SelectedSelectionKeySetSelector@a7f2a7.

Using latest ipcamera binding, running openhab (openhabian) 2.5(stable) on a Rpi3B+

That’s great! I have not been able to get back to this since I made my last post. Was just in the process of grabbing some wireshark captures of the onvif2mqtt utility setting up a pullpoint subscription, and then capturing the dialog when I trigger a PIR event. This is with the EZVIZ DB1 running LaView Firmware.

The problem with dmitrif’s utility is that while it works with the LaView firmware, it does not seem to work with the Hikvision firmware. This is not good because the Hikvision FW provides a lot more in terms of software-based motion detection, line crossing, etc. Anyway, I do not know how much I can work on this tomorrow since it is a holiday, but if I get a chance, I will pull down your new version and see if it works. Will post as soon as I get a look. Thanks very much for working on this.

Hi @matt1, I gave it a quick try, but no luck so far. Here are some config. files…

Thing file

Thing ipcamera:ONVIF:doorbell
[
	IPADDRESS="camera.ip.address",
	USERNAME="admin",
	PASSWORD="my.secret.password",
	POLL_CAMERA_MS=2000000,
	SNAPSHOT_URL_OVERRIDE="http://camera.ip.address/onvif/snapshot.jpg",
	SERVER_PORT=54030,
	FFMPEG_INPUT="rtsp://camera.ip.address/Streaming/Channels/101",
	FFMPEG_OUTPUT="/tmpfs/doorbell/"
] 

Here is the .items file…

String doorbell_MJPEGStreamURL "MJPEG URL" { channel="ipcamera:ONFIV:doorbell:streamUrl" }
Switch doorbellMotionAlarm "Motion Detected" { channel="ipcamera:ONVIF:doorbell:motionAlarm" }
Dimmer doorbellMotionThreshold "Motion Threshold" { channel="ipcamera:ONVIF:doorbell:ffmpegMotionControl" }

Here is the sitemap file

sitemap ipcamera label="IP Cameras" {

	Frame label="Doorbell Camera" {
		Text item= doorbell_MJPEGStreamURL
		Text label="Snapshot" icon="camera"{Image url="http://oh2.server.ip:54030/ipcamera.jpg"}
		Text label="MJPEG Stream" icon="camera"{Video url="http://oh2.server.ip:54030/ipcamera.mjpeg" encoding="mjpeg"}
		Switch item= doorbellMotionAlarm
		Slider item= doorbellMotionThreshold
	}
}

I have set DEBUG level on the logs, and they produce a LOT of data. What is the best practice for getting that to you?

Here is the contents of the event.log.

2020-05-24 21:16:05.087 [hingStatusInfoChangedEvent] - 'ipcamera:ONVIF:doorbell' changed from UNINITIALIZED to INITIALIZING
2020-05-24 21:16:06.227 [hingStatusInfoChangedEvent] - 'ipcamera:ONVIF:doorbell' changed from INITIALIZING to ONLINE

Moving my hand around the PIR sensor does not cause any new entries in the openhab.log file. But I know the ONVIF event is available. Here is the output of the onvif2mqtt utility.

root@OH-Test /opt/onvif2mqtt # npm run dev

> onvif-cam@1.0.4 dev /opt/onvif2mqtt
> cross-env CONFIG_PATH=./config.dev.yml nodemon -e js,yml --exec babel-node src/index.js | pino-pretty

[nodemon] 2.0.2
[nodemon] to restart at any time, enter `rs`
[nodemon] watching dir(s): *.*
[nodemon] watching extensions: js,yml
[nodemon] starting `babel-node src/index.js`
[1590369536807] INFO : Loading configuration. {"configPath":"./config.dev.yml"}
[1590369536814] INFO : Validating configuration file.
[1590369536889] INFO  (Manager): Beginning initialization...
[1590369536889] INFO  (MQTT on 127.0.0.1:1883): Connecting.
[1590369536918] INFO  (MQTT on 127.0.0.1:1883): Successfully connected.
[1590369536918] INFO  (ONVIF/doorbell on 192.168.18.30): Attempting connection.
[1590369536919] DEBUG (MQTT on 127.0.0.1:1883): Publishing. {"topic":"onvif2mqtt/doorbell/motion","value":"OFF","retain":true}
[1590369537122] INFO  (ONVIF/doorbell on 192.168.18.30): Successfully connected.
[1590369540338] DEBUG (MQTT on 127.0.0.1:1883): Publishing. {"topic":"onvif2mqtt/doorbell/motion","value":"ON","retain":true}
[1590369545427] DEBUG (MQTT on 127.0.0.1:1883): Publishing. {"topic":"onvif2mqtt/doorbell/motion","value":"OFF","retain":true}

That’s it for now. Please let me know the best way to get the openhab2.log file to you.

One quick note: this is with the LaView FW. Let me try loading Hikvision and see what happens. But not tonight.

I got some more time to do testing of ONVIF events with 3 different brands.

INSTAR= does not work in ODM but works in binding.
HIK = works in ODM but does not in binding.
AMCREST= works in ODM but does not in binding after a firmware update.

There are at least 2 ways to get the events and I have only implemented 1 of them so far (Hikvision use the method I have not yet fully implemented) and some cameras are very very fusy on the messages sent.

I know this is very frustrating. Non-standard “standards” only serve the PR departments of the manufacturers while still locking customers into one vendors’ products.

I will create an issue on GitHub and start collecting wireshark traces and other information for you. Just let me know what you need, and I will get the info for you.

I completed the coding for both methods and will need to create a newer Alpha build (not done yet), then all I need is the TRACE level log output of when the camera is connecting for the first time to a camera. It probably wont work on many cameras but the trace log will allow me to improve the coding so don’t stress if it does not work. Please don’t send an entire 30mb log file. Because it only contain one half of the digest strings it is safe to publish, but if you use wireshark and include the request and response messages you can decode and get your password from it, so use a silly password and change it afterwards if doing wireshark and putting on the web.

I narrowed down why Hikvision is not working and that is because the end point is different for the events and the onvif lib I am using does not allow me to access this. Possibly one of the other firmwares you have will be different. Wireshark is needed to determine this.

Hi @matt1. I just finished uploading a whole set of scenarios on your GitHub page as Issue number 56. I included wireshark captures of the onvif2mqtt as it attached to the camera, and I also captured what happens during a PIR event.

I also uploaded data including the openhab.log and events.log along with wireshark captures. I simply started wireshark, and then renamed ipcamera.things~ to ipcamera.things. So the capture is just of the initial registration. Once the registration was done, I then started a fresh capture and generated a PIR event.

The interesting thing is that it sure looks as if the camera sends the binding all of the information normally associated with a PIR event. So maybe I am doing something stupid with my .items file? Or maybe I am looking at the wrong thing in my .sitemaps file? But in any case, there is no record of a motion event in the events.log.

I am not worried about posting public info from the wireshark or OH logs. Everything on my network is non-public, and I will change all passwords in any case once I tear down my lab and actually move out of a dev environment. (Or am I being stupid there too? In which case, please let me know and once you have the files I will delete them from GH.

Let me know when you have the newer Alpha and I will give it a try.

Uploaded it and it is not marked as Alpha as the newer code only runs if the thing type is ONVIF.

Changes are:

  • New channel ‘pirAlarm’ for onvif thing type. Keeps the triggers for normal motion and PIR separate.
  • Both forms of onvif alarms are hopefully implemented enough that it will work for ‘some’ cameras. If not it should log some info I need.
  • Changes to the way it detects a missing snapshot url for onvif.

@matt1 Loaded 5-26 alpha. Not quite working but seems camera is responding with PIR events. Wireshark capture uploaded to your GitHub.

New build 2020-05-30 has had these changes and extensive testing done:

  • More reliable snapshot url detection for ONVIF cams.
  • Logging to help guide new users to what is wrong.
  • ONVIF event changes. Not used for api cameras.
  • Better online/offline detection and re-connecting after network issues for ONVIF cams.

Tested with esp32 cameras.
Tested with 3 different brands of onvif cameras.
Tested with API based cameras.

Last area needing testing is with a RTSP only camera to look for any setup gotchas or if they work after a network issue occurs.

@matt1 - Sorry for the long post.

First:
You can add this Dahua camera to your list of working devices:

Device Type     IPC-HDW4631C-A
System Version  2.460.GP01.16.R, Build Date: 2017-09-04
WEB Version     3.2.1.491565
ONVIF Version   16.12(V2.4.0.485616)

Some notes:
This Dahua is a bit strange. It has 3 streams, main0, sub1 and sub2. Notice, Sub1 is highly limited in setup options, but Sub2 has more options (among MJPEG format). All streams support different types of audio, incl aac.
Ipcamera sometimes has an issue discovering the correct stream. I dont know exactly why. It may be due to not restarting the binding when doing changes on the camera. If anything goes wrong in discovering the stream, Ipcamera will fall back to default stream0, which is main stream. This issue has fooled me quite a few times. A user advice: Keep an eye on the openhab logfile when making changes to the camera. It may not happen at the very second you change a setting on the camera, but sometimes after you reboot camera/openhab or ipcamera binding, Ipcamera can fail in discovering the stream, and then Ipcamera falls back to main stream (stream0).

You can add Reolink RLC-410 as well, (latest firmware), for HTTP ONLY camera. Onvif do not work.
Some Notes:
Reolink RLC-410 is not recommended in my opinion, as its very limited in its output formats and possibilities, making it a bit of a hell demuxing the output to stream HLS through ffmpeg. It can work, but it puts alot of pressure on the system. The camera will do snapshots and animated gif just fine though, as well as direct RTSP streaming.

Notes about pressure the system.
My latest discoveries running my main openhab system with Google Assistant integration (main system is guite busy) on an Rpi3B+ and untill recently with the Reolink only.
Having this Rpi3B+ which is busy enough doing other openhab stuff, there will be consequences adding too many cameras to Ipcamera/ffmpeg, if they dont support a very good compressd format, consequences like openhab acting up strangely, running slower etc. I had to give up Ipcamera on my main system and is now using one of my test systems (Rpi4 4GB) to handle Ipcamera binding and ffmpeg demuxing with one Reolink RCL-410 and one Dahua IPC-HDW4631C-A, (Next step is to add another Dahua IPC-HDW4631C-A camera). This moving of the ipcamera binding as the cameras feed to another system, leads to my next problem.
I have focus on Google Assistant integration mainly. And since only one system can handle the GA integration, I had to setup a proxy switch item on my main openhab system with a static url pointing the HLS startStream on the test setup. I used Karaf to set the static url for this switch item on my main system, cause for some very strange reason openhab do not allow a static url to an item without a channel binding. (Very unlogic to me, but thats what I´ve been told in another thread).

To be specific, this setting do NOT work, openhab will not set the item to the url:

String Dahua1ForHub   "hovedindgang"   { url="http://10.4.28.127:54322/ipcamera.m3u8", ga="Camera" [ protocols="hls" ] }

But this will work if the user use Karaf to set the static url for the item Dahua1ForHub:

String Dahua1ForHub   "hovedindgang"   { ga="Camera" [ protocols="hls" ] }

I wonder if an easy solution for this could be an option to set the streamStart to a static url (local IP), through ipcamera binding insted? I dont feel its a good solution to set the static url though Karaf or Rest API, as the user cant see it anywhere. Do you think this would be a good idea?
I personally think the only obvious solution would be for openhab to support direct url for an item as default. But thats probably too much work to be done by the developers.

Thats it for now… As mentioned, my next step is to add my second Dahua camera (It’s already here on my table). But I doubt I´ll be having issues when using my Rpi4 for this.
Then I´ll probably return back with a updated “report”.

When was the last time you tested that? I made many changes to the binding and some may mean the rtsp is not needed as a source for the snapshots… As a last resort you can always keep it as ONVIF and set the snapshot over ride to be ‘ffmpeg’ and it will then not auto find the url and use the rtsp source instead. With ONVIF alarms now partly added, some cameras will now have this ability.

No. I recommend using what is in the readme file which uses the bindings channel as the source. This way if the ip is changed everything follows automatically. You are not understanding the openhab framework and that is best discussed in the other thread you opened.

It should follow what u have set as the onvif media profile number, if it does not, then please explain how to reproduce and I will look at it. If you are wanting to use multiple streams for different sources then using the override is the way to do it, otherwise the same source gets used for snapshot, rtsp and ffmpeg.

I would not use a pi3 or older device, the Pi4 was the first one to be decent as all the previous models the USB ports and network shared bandwidth, also the PI4 was a big jump up in CPU power and 1 gb of ram is not enough. You will see a big difference because the 4 is a far better device for many reasons.

org.openhab.binding.ipcamera-2.5.4-SNAPSHOT is the one I´m using on my Rpi4 right now. I think its from the 15. of May.

Must have missed that part of the readme.

I need to test this some more cause I have not been able to reproduce it. But I think it happened if I turn off Sub stream 1, and only having main and sub2 turned on in the camera… As mentioned, Sub stream 1 doesnt provide many options, but sub stream 2 does. Right now I have all three streams turn on in the camera settings. And there is no issue.

I know… I just havnt had the time to move my whole system. I also got a Odroid C2 as test setup.