Hi everyone, I’m sorry for the inconvenience but I need your help. I installed the “Thing- RTSP/HTTP IP Camera” to which I successfully connected an Ip Camera. I’m asking you how I can interrupt the data flow from the camera, since I’d like to use it for the outside. Thank you so much for your patience in advance
PS: but is it possible from a Habpanel Widget to run a “Script” on Openhab? Thanks again
The fix you are wanting wont be released until 3.1milestone3 is released in a week or twos time. Until then you can get a build from here that you just need to uninstall the binding and then unzip all the files into the addons folder.
Hi Matt,
Thank you. That has certainly improved things! I am now getting lineCrossing events. One thing I am not getting however, is fieldDetection, and I realise that in the GUI I had linked it to the motionAlarm which is a different thing. fieldDetectionAlarm is missing in the channels list of the GUI.
As an aside, I had different discovery results with two of my cameras:
DS-2DE4A425IW-DE - discovered as ONVIF only, not Hikvision
DS-2CD2122FWD-IW - not discovered - this one is on wifi so could be why
If you would like me to try anything to resolve this, than happy to do so, but I will otherwise add manually
Kind Regards
Martin
Good news and thanks for feedback as it is good to have the changes tested before it goes out on mass.
I suspect that is because you have not ticked the “show advanced” box. In openHAB V3 all linked channels by default have persistence enabled and will chew system resource that add up if you add all channels for every thing on your system, hence this feature was added. Only commonly used channels are shown by default until you tick the box.
It would be great if you took the time to do the following:
- Hit the pause button on the cameras so they stop sending to the logs.
- enabled TRACE logging, the console command is at the very start of the ipCamera docs.
- Do a search and copy the log output created.
- Unpause the things and it should all go back to normal.
- Send the output to me in a PM or open a github issue as there’s no need to flood a forum with log output.
- Let me know which cameras the logs show as needing attention so I can ignore the IP of the correctly detected cameras.
There’s is no downside to manually adding the cameras if you set the port numbers correctly. By forcing the onvif detected one to be hikvision, also no problem, it just means the binding could not detect the brand so it falls back to generic onvif.
Hello, I hope this is the correct thread and you can help me …
I’ve got a TP-Link Tapo C200 which is supposed to support onvid. After some struggling (I’m new to this) I achieved to get an rtsp-stream in VLC and also in iSpy (Agent DVR). But I couldn’t configure the bridge so far. It says “Camera failed to report a valid Snaphot and/or RTSP URL. See readme on how to use the SNAPSHOT_URL_OVERRIDE feature”, but I didn’t find/understand anything addressing that in the binding-description.
I’m also unsure about the port: 554 works in VLC and iSpy, but somewhere in iSpy there’s port 443 mentioned, and I’ve found a comment which mentiones Port 2020 for onvid (last screenshot) …
And I have no idea what to put ffmepg location (and what it’s good for).
Here’re some screenshots that might clarify things:
OH-installation:
“”
VLC: Stream (working)
some (other) network address (port 443) in iSpy
Another question: Somewhere in the forum I’ve read that there’s a difference between rtsp-stream an onvid-stream; such as onvid-streams are more efficient/need less CPU-resources. If so, how would I make sure that I get the correct/optimal stream - simply use the correct port?
- Start your own thread as I doubt very much 1 reply is going to solve all your issues.
- Your camera probably does not have ONVIF and if it does it certainly will not be on the same port as RTSP. This is probably why you are getting the comm error. Try setting it up as a rtsp only camera.
- Leave things on their DEFAULT values if your using LINUX. The ffmpeg location should be correct in most cases if you have linux.
- Read the binding docs and do what it says in the “how to get help” section at the very top.
I finally got the camera to work (onvif). But I have a question/problem left:
When I open the rtsp-stream (rtsp://192.168.178.69:554/stream1) in VLC or iSpy, I get reasonably good quality and a lag of “only” 2 seconds. In OH, however, I use an http-address (http://192.168.178.25:8003/ipcamera.mjpeg) with rather poor picture quality and - more important - low framerate and a lag of 4 seconds.
I don’t really know what’s happening but my guess is: The camera’s RTSP-stream is fetched by ffmpeg on my Raspi where it gets rerouted to an http-address on the Raspi 4 (and maybe converted as well) and this slows things down.
Now wouldn’t it be possible to access the camera’s RTSP-stream directly, just like VLC does? (if I enter the RTSP address in a Video-card, it doesn’t work). If not, are there other ways to improve picture quality and lag?
The Raspi’s processor is only at about 3-7% if I don’t misinterpret this table (command “top”):
top - 08:23:20 up 20:29, 2 users, load average: 1,55, 1,30, 1,23
Tasks: 147 total, 1 running, 146 sleeping, 0 stopped, 0 zombie
%Cpu(s): 4,6 us, 2,3 sy, 0,0 ni, 92,4 id, 0,0 wa, 0,0 hi, 0,7 si, 0,0 st
MiB Mem : 3876,7 total, 1161,5 free, 968,6 used, 1746,6 buff/cache
MiB Swap: 2648,0 total, 2648,0 free, 0,0 used. 2788,9 avail Mem
Have you read the section in the ipCamera documentation? If so what is confusing and what can be changed to make it clearer? The default setting is low quality deliberately and the doc covers this and how to up it.
Yes your correct and it is converted to MJPEG as that is the format you are asking for by using that URL… 99% of the time a camera will be producing whats called h.264 format.
Not currently and Yes it is possible if someone codes for that but it would require a custom player to be coded for all your viewing devices so it is not simple and may require a license fee to be paid.
Yes the documentation goes into this. HLS is a method of playing the h264 from the camera directly without the need for a special player app.
I can say 100% that is no where close to the CPU load when a MJPEG stream is getting created. Also CPU load does not translate to being able to process a data stream in REALTIME. It is possible for a cpu to be less than 50% and yet it can not process a frame of the video in less time than the frames are incoming.
This is one reason why I moved away from a rasp piX and moved to the far faster odroid N2+ which on my setup it can do 1080p quality video at 20 FPS in real time. A current range NUC or even a x86 processor would be faster again but at a much higher power draw and purchase price.
Thank you for your quick and informative reply, Matt!
I’ll think about getting the odroidN2+ you recommend. But first I’d like things to become more efficient for which HLS seems to be the way. When you refer to the documentation I guess you mean IP Camera - Bindings | openHAB and in particular
- hlsOutOptions: This gives you direct access to specify your own FFmpeg options to be used. Default:
-strict -2 -f lavfi -i aevalsrc=0 -acodec aac -vcodec copy -hls_flags delete_segments -hls_time 2 -hls_list_size 4 - and maybe also to:
hlsUrl- String The URL for the ipcamera.m3u8 file." for the relevant channel.
I’m asking because I don’t sufficiently understand this to set things up correctly.
The camera’s HLS URL (channel/item) says: http://192.168.178.25:8003/ipcamera.m3u8 - when I enter this address in vlc or a oh-video card there’s a time lag of about 10 seconds, which is worse than mjpeg.
Next thing I tried is to get access to the h264-stream. Here’s the iSpy information I used:
when I tried “rtsp://192.168.178.69:2020/video.h264” in VLC, it didn’t work.
And changing the item setting “INVIF Media Profile” to 9 or 10 doesn’t seem to be possible (–> value needs to be <=5).
My last try was to write “rtsp://192.168.178.69:2020/video.h264” into FFmpeg input. But the lag at the moment is 7seconds, so that doesn’t seem to help either.
Here’re my current settings:
I’m at a loss what to do next, do you have any idea? If not, that’s ok, then I’ll just accept the current situation.
If you want low lag behind real-time you need mjpeg. If your openhab processor is not fast enough then you can buy cameras which create mjpeg on board.
My cameras are around 0.5 seconds behind due to being created on the camera. If I use the binding to create the stream with ffmpeg it is around 1 second behind real-time.
Using HLS it is around 5 seconds behind as I have tweaked the settings that the docs mention.
That’s interesting. So these seem to be the options:
- Stream on VLC → no lag because a fast PC does the transformation
- Stream on Openhab
- faster device as you advised
- Raspi: accept lag
- Raspi: get a camera with MJPEG-stream
I guess my Tapo C200 (about 30 EUro) can’t do that. I didn’t find much information on such cameras; looks like starlinks can are capable of that but are quite pricey. Does anybody know if there’re cheap cameras which can stream MJPEG?
Most of what I’m doing so far is testing options. One ultimate goal is a doorbell (and some cameras), where a low lag is quite important. So it should have MJPEG-streams, too. Same question: Does anybody know of good camaras with MJPEG that work well with OH?
This ESP32-CAM firmware works very well with ipcamera:
It’s working smoothly with Arduino 1.8.13. While the (short) sketch is no longer maintained, the heavy lifting is done in the libraries, which are well maintained.
Hi
I got some IMOU Looc Cams.
They are part of Dahua …and by auto discovery via SCAN they are actually discovered as Dahua.
I tried to discover, manually create a dahua, manually create an onvif, manually create a non onvif.
For all tries I don’t get any channel / item populated and they just stay “null”.
I wonder if I make something totally wrong here?
When checking the URLs I e.g. filled into the manually created non onvif cam … I can show the still image. Why is the Item I linked to the cannel for image url never populated?
any hints where I could start looking are appreciated.
edit:
never mind. It just took quite some minutes until it got populated.
no clue why this took so long … but its there 
Hi Team, ive recently migrated to 2.5 and was using things file for the cameras with great success on the 2.4 binding.
Since moving to 2.5, the things file does not create the items in PaperUI, has something changed in this regard?
an example of my thing which used to work fine
Thing ipcamera:HIKVISION:SouthSteps [
IPADDRESS="192.168.1.200", PASSWORD="N!22z844",
USERNAME="admin",
IP_WHITELIST="DISABLE",
POLL_CAMERA_MS=2000,
SERVER_PORT=50001,
PORT=80]
Thanks
There were breaking changes when the binding was merged. Anything in ALL CAPS is wrong and needs to be adjusted to the new format which the docs cover.
I’m using the 3/13/2021 release of the IpCamera Binding on OpenHab 3.0.1 connecting to a Dahua NVR. One activity that we may want to look at is fetching snapshots as a means to determine if the camera/NVR is online. Specifically in pollCameraRunnable(). On the NVR with many channels, the snapshots all hit every 8 seconds and overloads the NVR.
2021-04-12 10:28:15.621 [TRACE] [era.internal.handler.IpCameraHandler] - Sending camera: GET: http://192.168.160.2:80/cgi-bin/snapshot.cgi?channel=1
2021-04-12 10:28:15.640 [TRACE] [era.internal.handler.IpCameraHandler] - Sending camera: GET: http://192.168.160.2:80/cgi-bin/snapshot.cgi?channel=1
2021-04-12 10:28:17.789 [DEBUG] [ipcamera.internal.MyNettyAuthHandler] - Camera at IP:192.168.160.2 gave a reply with a response code of :500
2021-04-12 10:28:18.177 [DEBUG] [ipcamera.internal.MyNettyAuthHandler] - Camera at IP:192.168.160.2 gave a reply with a response code of :500
2021-04-12 10:28:18.241 [TRACE] [era.internal.handler.IpCameraHandler] - Sending camera: GET: http://192.168.160.2:80/cgi-bin/snapshot.cgi?channel=3
2021-04-12 10:28:18.260 [TRACE] [era.internal.handler.IpCameraHandler] - Sending camera: GET: http://192.168.160.2:80/cgi-bin/snapshot.cgi?channel=3
2021-04-12 10:28:18.461 [DEBUG] [ipcamera.internal.MyNettyAuthHandler] - Camera at IP:192.168.160.2 gave a reply with a response code of :500
2021-04-12 10:28:19.010 [TRACE] [era.internal.handler.IpCameraHandler] - Sending camera: GET: http://192.168.160.2:80/cgi-bin/snapshot.cgi?channel=5
2021-04-12 10:28:19.037 [TRACE] [era.internal.handler.IpCameraHandler] - Sending camera: GET: http://192.168.160.2:80/cgi-bin/snapshot.cgi?channel=5
2021-04-12 10:28:19.121 [TRACE] [era.internal.handler.IpCameraHandler] - Sending camera: GET: http://192.168.160.2:80/cgi-bin/snapshot.cgi?channel=7
2021-04-12 10:28:19.148 [TRACE] [era.internal.handler.IpCameraHandler] - Sending camera: GET: http://192.168.160.2:80/cgi-bin/snapshot.cgi?channel=7
2021-04-12 10:28:19.414 [TRACE] [era.internal.handler.IpCameraHandler] - Sending camera: GET: http://192.168.160.2:80/cgi-bin/snapshot.cgi?channel=4
2021-04-12 10:28:19.438 [TRACE] [era.internal.handler.IpCameraHandler] - Sending camera: GET: http://192.168.160.2:80/cgi-bin/snapshot.cgi?channel=4
2021-04-12 10:28:22.665 [DEBUG] [ipcamera.internal.MyNettyAuthHandler] - Camera at IP:192.168.160.2 gave a reply with a response code of :500
2021-04-12 10:28:23.621 [TRACE] [era.internal.handler.IpCameraHandler] - Sending camera: GET: http://192.168.160.2:80/cgi-bin/snapshot.cgi?channel=1
2021-04-12 10:28:23.637 [TRACE] [era.internal.handler.IpCameraHandler] - Sending camera: GET: http://192.168.160.2:80/cgi-bin/snapshot.cgi?channel=1
2021-04-12 10:28:25.306 [DEBUG] [ipcamera.internal.MyNettyAuthHandler] - Camera at IP:192.168.160.2 gave a reply with a response code of :500
2021-04-12 10:28:26.077 [DEBUG] [ipcamera.internal.MyNettyAuthHandler] - Camera at IP:192.168.160.2 gave a reply with a response code of :500
2021-04-12 10:28:26.169 [DEBUG] [ipcamera.internal.MyNettyAuthHandler] - Camera at IP:192.168.160.2 gave a reply with a response code of :500
2021-04-12 10:28:26.241 [TRACE] [era.internal.handler.IpCameraHandler] - Sending camera: GET: http://192.168.160.2:80/cgi-bin/snapshot.cgi?channel=3
2021-04-12 10:28:26.279 [TRACE] [era.internal.handler.IpCameraHandler] - Sending camera: GET: http://192.168.160.2:80/cgi-bin/snapshot.cgi?channel=3
2021-04-12 10:28:26.493 [DEBUG] [ipcamera.internal.MyNettyAuthHandler] - Camera at IP:192.168.160.2 gave a reply with a response code of :500
2021-04-12 10:28:27.010 [TRACE] [era.internal.handler.IpCameraHandler] - Sending camera: GET: http://192.168.160.2:80/cgi-bin/snapshot.cgi?channel=5
My java skills are pretty rough (I’m a C# guy), but wanted to ask what you thought the best way to go about detecting online state with minimal overhead on the far end. Maybe pushing type specific checks down into:
switch (thing.getThingTypeUID().getId()) {
Or even into the DahuaHandler? If I can figure out how to get this to build, I may try a few different things.
In the IDE type in thing. And the autocomplete will suggest what can be used, it is probably getStatus from memory.
Making that changes requires code changes to three different areas or a bug will result as the binding caches the jpg so it does not need to wait for a reply back from a camera before giving the snapshot.
These are on the to do list but low priority so thank you if you create a PR.
As for checking if the camera is reachable you can create a Netty channel and check to see if it opens, if it does not then the camera is offline. Just shorten the already working code that sends get requests to do this.
All cameras would need to have the change not just Dahua so it should not go into a brand handler.
Lastly it would be good to confirm the cause by pausing all things and then unpausing them one by one so they don’t all line up at the same
Time, does that allow it to work? It may be that when 8 camera things all ask with no password the first time it trips the lockout in the nvr due to 8 requests with no password. May be a security feature tripping.
GitHub is probably a better place for this to be talked about as it will need three changes before the code can be merged or it will cause issues as a side effect.
thanks Matt
I checked here and saw nothing 
In any case, updating capitals to lower worked - the thing is added in PaperUI but it says uninitalised, configuration definitely correct because it worked in the old binding.
Using only 1 camera as a test:
Thing ipcamera:hikvision:southsteps [
ipaddress="192.168.1.200", password="N!22z844",
username="admin",
ip_whitelist="disable",
poll_camera_ms=2000,
server_port=50001,
port=80]
1 Like
It’s definitely the NVR, you can trigger it using the browser with multiple tabs. The cameras themselves handle it much better. I have 8 cameras, 4 on the NVR’s POE ports and 4 on the network directly accessible. I’ll probably try and move away from hitting the NVR and go direct to the cameras. I’ve seen some alarm issues on the NVR with the binding, but haven’t had a chance to look into it.
I’ve gotten the binding to build and have swapped the snapshot request with:
/cgi-bin/magicBox.cgi?action=getHardwareVersion
2021-04-12 23:27:48.534 [TRACE] [era.internal.handler.IpCameraHandler] - Sending camera: GET: http://192.168.160.2:80/cgi-bin/magicBox.cgi?action=getHardwareVersion
2021-04-12 23:27:48.725 [TRACE] [era.internal.handler.IpCameraHandler] - Sending camera: GET: http://192.168.160.2:80/cgi-bin/magicBox.cgi?action=getHardwareVersion
2021-04-12 23:27:48.728 [TRACE] [era.internal.handler.IpCameraHandler] - Sending camera: GET: http://192.168.160.2:80/cgi-bin/magicBox.cgi?action=getHardwareVersion
2021-04-12 23:27:48.755 [TRACE] [era.internal.handler.IpCameraHandler] - HTTP Result back from camera is :version=V1.0
:
2021-04-12 23:27:49.275 [TRACE] [era.internal.handler.IpCameraHandler] - HTTP Result back from camera is :version=V1.0
:
2021-04-12 23:27:52.236 [TRACE] [era.internal.handler.IpCameraHandler] - Sending camera: GET: http://192.168.160.2:80/cgi-bin/magicBox.cgi?action=getHardwareVersion
2021-04-12 23:27:52.260 [TRACE] [era.internal.handler.IpCameraHandler] - Sending camera: GET: http://192.168.160.2:80/cgi-bin/magicBox.cgi?action=getHardwareVersion
2021-04-12 23:27:52.291 [TRACE] [era.internal.handler.IpCameraHandler] - HTTP Result back from camera is :version=V1.0
:
2021-04-12 23:27:53.303 [TRACE] [era.internal.handler.IpCameraHandler] - Sending camera: GET: http://192.168.160.2:80/cgi-bin/magicBox.cgi?action=getHardwareVersion
2021-04-12 23:27:53.312 [TRACE] [era.internal.handler.IpCameraHandler] - Sending camera: GET: http://192.168.160.2:80/cgi-bin/magicBox.cgi?action=getHardwareVersion
2021-04-12 23:27:53.339 [TRACE] [era.internal.handler.IpCameraHandler] - HTTP Result back from camera is :version=V1.0
:
This works as a light weight check for Dahua, but doesn’t help for the other types. I like your idea of using another Netty channel and will look into that. From here though, I’ll take the technicals over to github.
As a side note, I’ll post this here for other Dahua owners. The snapshot check causes the cameras and/or NVR to save the snapshot to their storage media. Running this binding as it will not be ideal for that. Hopefully can get that fixed by 3.1 release.
I have a question regarding enableMotionAlarm, do you know if that will work on the HIKVision cameras? Trying to get it to work but nothing changes on the cameras…