New method of detecting host IP and better logging of all combos it finds.
Now serves on all NIC’s so you can ignore it if the IP is wrong as it will still work. @delid4ve give it a try.
Upped the Image channel to update 20% of the poll time.
New ffmpeg motion detection for httponly cameras. Need to work on better debouncing but should work enough to try it out. Single control allows it to be turned on and off and also adjust how sensitive it is in case you need different settings for night VS day. Very little testing done on it so have fun.
The lower the FPS and the lower the resolution the less CPU this chews so if you have 30 fps video streams consider dropping it to 10-12.
2020-01-08 12:47:51.747 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - Possible NIC/IP match found:10.0.3.1
2020-01-08 12:47:51.748 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - Possible NIC/IP match found:10.0.5.1
2020-01-08 12:47:51.749 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - Possible NIC/IP match found:192.168.6.4
2020-01-08 12:47:51.753 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - Possible NIC/IP match found:10.0.3.1
2020-01-08 12:47:51.753 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - Possible NIC/IP match found:10.0.5.1
2020-01-08 12:47:51.754 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - Possible NIC/IP match found:192.168.6.4
2020-01-08 12:47:51.755 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - Possible NIC/IP match found:10.0.3.1
2020-01-08 12:47:51.755 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - Possible NIC/IP match found:10.0.5.1
2020-01-08 12:47:51.760 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - Possible NIC/IP match found:10.0.3.1
2020-01-08 12:47:51.761 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - Possible NIC/IP match found:192.168.6.4
2020-01-08 12:47:51.761 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - Possible NIC/IP match found:10.0.5.1
2020-01-08 12:47:51.761 [DEBUG] [ing.ipcamera.handler.IpCameraHandler] - Possible NIC/IP match found:192.168.6.4
2020-01-08 12:47:51.806 [INFO ] [ing.ipcamera.handler.IpCameraHandler] - IpCamera file server for camera 192.168.4.2 has started on port 50001 for all NIC's.
Not in readme as it needs testing and further work before it is useful. But worth checking out to see what the cpu load is like, the channel is ffmpegMotionControl best linked to a
Slider control.
And the motionAlarm channel will move when it detects movement.
Have it working on a 1080p feed at 10fps on an ARM processor.
So have done a little testing, waiting for the missus to get home any minute so i get some real motion,
Anything other than 100 i get hundreds of false alerts (even at 1 or 99 - not sure what way the sensitivity goes), even at 100 lots of false alerts, have even turned off the date on the cam image.
CPU usage for 1 camera on a QNAP TS-453 Pro (16gb ram celeron 2ghz) spikes from 1-10% usage to 50-60% usage for openhab only
@matt1 yep definitely too sensitive, so worked out that 0 is off, 1 is most sensitive, 100 least, with no motion (other than a tree in the background i cant even see is moving) and set at 100 its too sensitive still, i dont know how it compares but i think we could do with the slider being 1/10th of what it currently is.
UPDATE: Just had ‘real motion’ and although i’m getting false alerts up at 95-100 its not picking up real motion. Going to disable for now until youve had a good look. Let me know if you want tested or anything
and an error after removing the thing and items (textual):
2020-01-08 16:58:17.336 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler IpCameraHandler of thing ipcamera:HTTPONLY:5 tried updating channel motionAlarm although the handler was already disposed.
De-bouncing and bug fixes added to the ffmpeg motion detection feature. It is ready for people to test but please ask questions and give feedback in this separate thread…
I’ve got a INQMEDIA (Chinese) IP camera that I can access through an android app called Onvifer.
The camera is detected through auto-detect and gives me the following data:
The thing in openhab displays ONLINE, yet I can’t see an image.
Also the tilt ans pan items aren’t working. So I ghuess there’s something wrong with the thing parameters, but what am I missing?
I have successfully installed the IP Binding and both cameras have been detected. What does not work is that the PIR alarm shows no reaction in OH as soon as the camera detects a motion/person. Does anyone have any idea what I am doing wrong?
rule "Kamera Garten Bewegung"
when
Item Instar_Garten_Bewegung changed from OFF to ON
then
sendNotification ("XXX", "Bewegung im Garten!")
sendNotification ("XXX", "Bewegung im Garten!")
end
The log only shows that the channel was included. But it does not jump to OFF or similar:
2020-01-10 20:02:37.068 [.ItemChannelLinkAddedEvent] - Link ‘Instar_Garten_Bewegung-ipcamera:INSTAR:XXX:pirAlarm’ has been added.
It may not be anything your doing wrong but two things:
When openhab starts up controls are UNDEF not off so the first alarm will be missed by that rule. Consider changing to remove the “from OFF”.
Instar currently wont send more than 1 alarm per 60 seconds, I have been in contact and this will be adjustable in the next firmware and then you can set this to what you wish. So until then…
Instar just released MQTT features which I have not used but should also be a way to get the alarms into Openhab, since it is ‘Homie’ based it should be a breeze to setup. It also looks to be far more comprehensive on what you can do via MQTT.
Pre-recording will be certainly be nice! And also keeping the native format of the stream by remuxing to e.g. mkv.
I have some cameras recording 24/7 with xeoma, and so maybe it might be useful to already now consider continuous recording with event markers on e.g. motion. Maybe your binding eventually will make xeoma/shinobi etc unneeded.
Great job so far!
first of all, thank you for your answer. I’ve adjusted the rule. However, I still don’t get an alarm from the camera for Openhab. In the logfile it looks like the created item for the channel “pirALARM” is not addressed at all.
Hi @matt1
I have just downloaded the binding, and tried to install it on my Rpi4, with fresh OH 2.5 Stable Rasbian Buster installed.
This is what happens when I add the files to the addons:
2020-01-11 17:39:12.178 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/usr/share/openhab2/addons/netty-handler-4.1.42.Final.jar
org.osgi.framework.BundleException: Could not resolve module: io.netty.handler [269]
Unresolved requirement: Import-Package: sun.security.util; resolution:="optional"
Unresolved requirement: Import-Package: sun.security.x509; resolution:="optional"
Unresolved requirement: Import-Package: org.eclipse.jetty.npn; version="[1.0.0,2.0.0)"; resolution:="optional"
Unresolved requirement: Import-Package: org.eclipse.jetty.alpn; version="[1.0.0,2.0.0)"; resolution:="optional"
Unresolved requirement: Import-Package: io.netty.channel; version="[4.1.0,5.0.0)"
at org.eclipse.osgi.container.Module.start(Module.java:444) ~[org.eclipse.osgi-3.12.100.jar:?]
at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:383) ~[org.eclipse.osgi-3.12.100.jar:?]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [bundleFile:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [bundleFile:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:520) [bundleFile:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [bundleFile:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [bundleFile:3.6.4]
2020-01-11 17:39:12.208 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/usr/share/openhab2/addons/netty-codec-4.1.42.Final.jar
org.osgi.framework.BundleException: Could not resolve module: io.netty.codec [265]
Unresolved requirement: Import-Package: com.google.protobuf; version="[2.6.0,3.0.0)"; resolution:="optional"
Unresolved requirement: Import-Package: com.google.protobuf.nano; resolution:="optional"
Unresolved requirement: Import-Package: com.jcraft.jzlib; resolution:="optional"
Unresolved requirement: Import-Package: com.ning.compress; version="[1.0.0,2.0.0)"; resolution:="optional"
Unresolved requirement: Import-Package: com.ning.compress.lzf; version="[1.0.0,2.0.0)"; resolution:="optional"
Unresolved requirement: Import-Package: com.ning.compress.lzf.util; version="[1.0.0,2.0.0)"; resolution:="optional"
Unresolved requirement: Import-Package: io.netty.channel; version="[4.1.0,5.0.0)"
at org.eclipse.osgi.container.Module.start(Module.java:444) ~[org.eclipse.osgi-3.12.100.jar:?]
at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:383) ~[org.eclipse.osgi-3.12.100.jar:?]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [bundleFile:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [bundleFile:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:520) [bundleFile:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [bundleFile:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [bundleFile:3.6.4]
2020-01-11 17:39:12.212 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/usr/share/openhab2/addons/netty-codec-http-4.1.42.Final.jar
org.osgi.framework.BundleException: Could not resolve module: io.netty.codec-http [266]
Unresolved requirement: Import-Package: com.jcraft.jzlib; resolution:="optional"
Unresolved requirement: Import-Package: io.netty.channel; version="[4.1.0,5.0.0)"
at org.eclipse.osgi.container.Module.start(Module.java:444) ~[org.eclipse.osgi-3.12.100.jar:?]
at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:383) ~[org.eclipse.osgi-3.12.100.jar:?]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [bundleFile:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [bundleFile:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:520) [bundleFile:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [bundleFile:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [bundleFile:3.6.4]
Any ideas why? Seems like there are something missing somewhere.
Yes this keeps the CPU load very low and I plan to use MP4 container as Openhab seems to support this through the UIs more??? I have not tried it yet so not sure what container is best so if anyone has experience they can share it would save me time.
Great idea, I like it but not sure how to present this using Openhabs UI in a clean and easy way. I usually come up with the way a user will interact with a feature before coding it. Perhaps in Openhab 3 this will be easier as one of the main goals is to make it easier for people to contribute to the UI and that sounds like it will need someone who is willing to add new features to the UI. A “Timeline” item type that can have red lines displayed and clicked AFAIK this does not exist.
No I never plan/aim to do that as making a nice UI is too much work, those packages are great for reviewing footage from multiple cameras. For those that don’t want to record and review and only use a camera in automations then yes hopefully the binding removes the need to have a system that is more complex then it needs to be.
@Kim_Andersen
Does restarting Openhab solve it? Openhab 2.5 seems to need everything created in its cache so the first time it starts it creates the cache and the second time it works, whenever you clear the cache and tmp folders you get weird things happening until a second start and I guess it may happen if it is the first time Openhab has ever started up with the files added. If it is not that then it is something new I have not seen. Let me know if a restart solves it.
Hi, i have 2 ip cams. One is a dahua china clone which can show mjpeg-stream, this is working in my basic-ui sitemap diretcly.
My second cam is a cheap china cam which only gives me a rtsp-stream. But with ffmpeg i was able to produce some files in my tmpfs-directory. There is a gif, m38u and many ts-files.
Is there a way to show the ffmpeg output in my sitemap in basic ui? I tried http://ip:port/ipcamera.gif and m38u, but i only get a blank box without any video. Also on my android phone, i can´t see any live video.
I used the standard values in most of my thing-files settings.
As there are ts-files and a gif-file, i can see that ffmpeg is working in general…
Yes, restarting OH seems to get it to run… Will try play with it today to see if I can get the lastest binding to work with my Reolink cam. (It runs using HTTPonly on my main setup using an older version of the binding).
The gif should work everywhere, if the file is created then not much can go wrong. The m38u aka HLS is another story as some browsers need a plugin or an update to support the format otherwise a blank box or a box with a play/pause control is common.
If the hls files are being created this shows your server-port is correct and triggering the creation and ffmpeg is working clearly, not sure what it could be. As always you should check the DEBUG logs and if that does not turn something up check the TRACE level.
