IpCamera: New IP Camera Binding

From what I have been able to determine, while the Hikvision Batch Tool may show that this camera is able to perform software motion detection, I have never gotten it to work. As @matt1 says, I have never seen any ONVIF messages from the camera that distinguish PIR from an internally, software calculated motion event.

I plan on using the PIR plus the ffmpeg motion detection that is integrated into the binding to reduce false alarms. And of course, you can adjust the sensitivity of the ffmpeg motion detection (thanks @matt).

 Both the EZVIZ and Hikvision FW allow you to adjust the sensitivity of the PIR sensor. The EZVIZ app has three range settings - near, medium and far. 

Yes. I agree but as you point out these are gross adjustments and it would be nice if further refinement were possible, but it is unlikely, so we live with with what we have. Really isnā€™t bad as it is. Certainly workable. I have used Wireshark in the past for other applications I was developing, but so far not with EZVIZ. Going forward I donā€™t plan on using the cloud servers so everything is local and private VLAN, but are you saying that even though I have cloud services disabled in the app, the notifications from the app being sent via their cloud servers? If so,I need to kill that. Does just disabling Notifications in the app do the trick?

I plan on using the PIR plus the ffmpeg motion detection that is integrated into the binding to reduce false alarms. And of course, you can adjust the sensitivity of the ffmpeg motion detection (thanks

That is/was my plan as well. My current issue with FFmpeg Motion Detection is that I canā€™t seem to adjust the threshold. 1 and 100 seem to give the same result with new binding (7-12) It seemed to work better with 6-29 version, but then I had the frequent reboots. I will play with it a bit more but I may just live PIR for now as it meets most of my needs with an occasional false alarm.

Thanks for weighing-in on this.

@John_Siemon, I am not sure if the notifications are still being sent even though they are turned off in the app. But I do not trust it. If I remember correctly, at one point someone saw audio continuing to be streamed to the cloud even though it was turned off. Could just be rumor.

I did some early experimentation with this, and if I am not mistaken, I was able to adjust the threshold. I know for sure this adjustment worked with one of my cameras - just canā€™t be 100% sure it worked with the doorbell. But since the plugin uses the same calls to ffmpeg for motion detection for all cameras, I canā€™t imagine why it would not work.

I had a few minutes this afternoon to do some additional testing with EZVIZ camera and I am certain the motion detection with camera works. However, I suspect that it uses the same EZVIZ app sensitivity settings as the PIR, so good for redundancy but limited. I removed all sensors links from my rules except the motionAlarm and it triggered when I approached sending an OH notification. I also got a PIR Event from EZVIZ app, but that was out of the loop for OH notifications. So it appears the camera motion sensor does work at least with Laview firmware. What I am struggling with is the FFMpegAlarm. I cannot get it to work with the updated binding from 7-12. It ā€œseemedā€ to be working with the binding from late June, at least when I changed sensitivity the number of false positives was reduced. but that binding had other issues. It also may have been coincidence, since I am only a little over a week into this. I will keep iterating and testing as time permits.

I have also done a very little experimenting with the EZViz DB1 running Hikvision FW - the first time I have been able to look at it since the 7/11 Beta release. Installed the 7/13 Beta. It looks great! @matt1 thank you so very much.

@John_Siemon, with the ipcamera binding in debug, I am seeing two different types of motion alarms in openhab.log.

The first one is clearly a PIR motion event.

2020-07-13 20:56:20.942 [DEBUG] [nding.ipcamera.onvif.OnvifConnection] - Onvif Event Topic:RuleEngine/CellMotionDetector/Motion, Data:IsMotion, Value:true

The second one appears to be a motion alarm from camera-based motion analysis

2020-07-13 20:56:22.822 [DEBUG] [nding.ipcamera.onvif.OnvifConnection] - Onvif Event Topic:VideoSource/MotionAlarm, Data:State, Value:true

I have not had time to get into the ffmpeg motion detection much. From a very quick first look, it is not working as I would have expected, but I did the configuration from memory and may have an error. I set up a Dimmer item for FFMPEG threshold and level, and then I set up a slider in my sitemap and associated it with the dimmer item. The slider definitely changes the motion threshold, but I am not seeing any FFMPEG motion alarms in my log right now. If I have time, I will dig into this more tomorrow.

This is exactly what I am doing and seeing as well. I think that 7-11/12 update may have broken the FFmpegAlarm when it was split out as a separate channel. @matt1 is this something you can confirm or set us straight.

I can confirm I found an issue with the ffmpeg motion alarm silly typo so will have it fixed in next build. Thank you for reporting there was an issue, if you find anything else please post as a huge amount of code got changed recently and it will take me weeks to test every feature multiple times under different brands of cameras and thing types.

3 Likes

Thank you for your response - one more question - you recommend the IPC-HDBW4231E-AS - I found a good deal on the IPC-HDBW4231E-ADT28 I canā€™t find definitive proof, but this appears to be the same thing, just branded for ADT (the alarm company) Does that seem like a good bet? Might I just need to put generic firmware in it?

Thanks,

-Bill Katz

Hi! Thanks for the great work on this binding! One question: turns out I have an oldish Hikvision cam (DS-2CD2032-I) with Fw. v5.4, i.e. no ONVIF. The camera has built-in alarm functions (motion, intrusion, etc.) though. Is there a way to use these functions with the binding, or ffmpeg motion alarm is the only way to go?

New build just uploaded with the ffmpeg bug fixed. @John_Siemon @bgilmer

Without Onvif that is your only option and it works well just with a CPU hit if you have high res and frame rates. Modern cameras have a lower res secondary stream and these are perfect to use as the picture is not seen that the movement is detected on. There has been very little interest in the feature which is a shame as it works better than what is built into some cameras.

Sorry I dont want to recommend anything in case it is no good. I dont work for any company and have very little experience with cameras so your best to ask on a camera forum where there are plenty of arm chair experts waiting for you post :slight_smile: Often you find high pixel cameras have worse night vision so it helps to have someone assist that knows the current range from multiple brandsā€¦
That was just a camera I had in mind due to it being a mini dome that has 1080p (google home hubs require a standard 1080p feed to work), starlight, h265, 3 streams, api and onvif and smart alarms. There is a product selector on their web page and you can just tick boxes with what you are after to find the latest model. Be sure to look at what resolution the mjpeg stream is limited to and also what smart alarms they have as you may like the idea of the camera telling you if a parcel has been left on your doorstep. Mjpeg from the camera can give you a live feed only 0.5 seconds behind realtime so dont gloss over that feature.

The ffmpeg motion issue appears to be fixed. However, I am seeing the following error in the opehab.log file. It does not seem to be affecting motion detection.

2020-07-14 16:42:26.197 [DEBUG] [hab.binding.ipcamera.internal.Ffmpeg] - frame=   96 fps=1.7 q=-0.0 size=N/A time=00:00:51.86 bitrate=N/A speed=0.91x    
2020-07-14 16:42:26.280 [DEBUG] [hab.binding.ipcamera.internal.Ffmpeg] - [Parsed_metadata_1 @ 0x55b2a0b8abc0] frame:96   pts:5021880 pts_time:55.7987
2020-07-14 16:42:26.280 [DEBUG] [hab.binding.ipcamera.internal.Ffmpeg] - [Parsed_metadata_1 @ 0x55b2a0b8abc0] lavfi.scene_score=0.025995
2020-07-14 16:42:27.645 [DEBUG] [hab.binding.ipcamera.internal.Ffmpeg] - frame=   97 fps=1.7 q=-0.0 size=N/A time=00:00:55.86 bitrate=N/A speed=0.957x    
2020-07-14 16:42:29.102 [DEBUG] [hab.binding.ipcamera.internal.Ffmpeg] - [rtsp @ 0x55b2a0abc980] Undefined type (31)
2020-07-14 16:42:29.111 [DEBUG] [hab.binding.ipcamera.internal.Ffmpeg] - [h264 @ 0x55b2a0b725a0] error while decoding MB 49 107, bytestream -5
2020-07-14 16:42:29.111 [DEBUG] [hab.binding.ipcamera.internal.Ffmpeg] - [h264 @ 0x55b2a0b725a0] concealing 2016 DC, 2016 AC, 2016 MV errors in P frame
2020-07-14 16:42:29.120 [DEBUG] [hab.binding.ipcamera.internal.Ffmpeg] - [h264 @ 0x55b2a0adc400] A non-intra slice in an IDR NAL unit.
2020-07-14 16:42:29.120 [DEBUG] [hab.binding.ipcamera.internal.Ffmpeg] - [h264 @ 0x55b2a0adc400] decode_slice_header error
2020-07-14 16:42:29.120 [DEBUG] [hab.binding.ipcamera.internal.Ffmpeg] - [h264 @ 0x55b2a0adc400] no frame!
2020-07-14 16:42:29.125 [DEBUG] [hab.binding.ipcamera.internal.Ffmpeg] - frame=   97 fps=1.6 q=-0.0 size=N/A time=00:00:55.86 bitrate=N/A speed=0.933x    
2020

Any thoughts?

EZViz DB-1 video doorbell running HikVision Firmware

  • ONVIF CelMotionDetector/Motion (PIR) shows up on wrong channel.
    Issue #60 entered in GitHub IpCamera repo.
  • ONVIF /VideoSourceMotionAlarm does not appear to trigger motionAlarm channel
    Issue #61 entered in GitHub IpCamera repo.

tl;dr-
Looks like the PIR ONVIF message is tied to the motionAlarm channel, when actually, the PIR ONVIF message should be tied to the CellMotionDetector ONFIV message. As a result, while the ONVIF VideoSourceMotionAlarm does trigger when something moves in front of the camera, from what I can tell, that message is not associated with any IpCamera plugin channel.

I was just doing some testing and I see the same regarding the PIR. It no longer works independently, but is now tied to the motionAlarm in the binding, but this was not the case before the 7-14 update. Two steps forward and 1 step back, nature of progress.

Question - is it usual with the binding in DEBUG to see updates to the motion item state in the event log every 10 seconds or so?

This is on a HIKVISION Thing. Canā€™t remember if the DB1 does the same thing.

2020-07-14 21:59:28.791 [thome.event.ItemStateEvent] - front1Motion updated to OFF
2020-07-14 21:59:38.694 [thome.event.ItemStateEvent] - front1Motion updated to OFF
2020-07-14 21:59:48.597 [thome.event.ItemStateEvent] - front1Motion updated to OFF
2020-07-14 21:59:58.499 [thome.event.ItemStateEvent] - front1Motion updated to OFF
2020-07-14 22:00:08.411 [thome.event.ItemStateEvent] - front1Motion updated to OFF
2020-07-14 22:00:18.318 [thome.event.ItemStateEvent] - front1Motion updated to OFF
2020-07-14 22:00:28.220 [thome.event.ItemStateEvent] - front1Motion updated to OFF
2020-07-14 22:00:38.128 [thome.event.ItemStateEvent] - front1Motion updated to OFF
2020-07-14 22:00:48.031 [thome.event.ItemStateEvent] - front1Motion updated to OFF

@bgilmer I normally have event logging set to WARN, but to determine if I am seeing anything similar to your log I changed event logging to DEBUG.

log:set DEBUG smarthome.event.ItemStateEvent

Iā€™m not seeing any ipcamera events, unless I trigger it with motion by stepping in front of the camera.

Looks like your system may be polling every 10 secs, or is it possible it is picking up motion from leaves or something blowing in the breeze and the item expires/resets to off after 10 secs? Just a thought FWIW.

Hereā€™s what Iā€™m seeing when I trigger a motion event

2020-07-14 19:51:17.273 [thome.event.ItemStateEvent] - vCamMotionAlarm updated to ON
2020-07-14 19:51:17.386 [thome.event.ItemStateEvent] - vCamMotionAlarm updated to ON
2020-07-14 19:51:18.286 [thome.event.ItemStateEvent] - vCamMotionAlarm updated to ON
2020-07-14 19:51:18.398 [thome.event.ItemStateEvent] - vCamMotionAlarm updated to ON
2020-07-14 19:51:19.296 [thome.event.ItemStateEvent] - vCamMotionAlarm updated to ON
2020-07-14 19:51:19.404 [thome.event.ItemStateEvent] - vCamMotionAlarm updated to ON
2020-07-14 19:51:20.268 [thome.event.ItemStateEvent] - vCamMotionAlarm updated to ON
2020-07-14 19:51:20.377 [thome.event.ItemStateEvent] - vCamMotionAlarm updated to ON
2020-07-14 19:51:21.284 [thome.event.ItemStateEvent] - vCamMotionAlarm updated to OFF
2020-07-14 19:51:21.394 [thome.event.ItemStateEvent] - vCamMotionAlarm updated to OFF
2020-07-14 19:51:22.245 [thome.event.ItemStateEvent] - vCamMotionAlarm updated to OFF
2020-07-14 19:51:22.356 [thome.event.ItemStateEvent] - vCamMotionAlarm updated to OFF
2020-07-14 19:51:23.256 [thome.event.ItemStateEvent] - vCamMotionAlarm updated to OFF
2020-07-14 19:51:23.376 [thome.event.ItemStateEvent] - vCamMotionAlarm updated to OFF
2020-07-14 19:51:24.260 [thome.event.ItemStateEvent] - vCamMotionAlarm updated to OFF
2020-07-14 19:51:24.421 [thome.event.ItemStateEvent] - vCamMotionAlarm updated to OFF
2020-07-14 19:51:25.247 [thome.event.ItemStateEvent] - vCamMotionAlarm updated to OFF
2020-07-14 19:51:25.356 [thome.event.ItemStateEvent] - vCamMotionAlarm updated to OFF
2020-07-14 19:52:17.264 [thome.event.ItemStateEvent] - vCamMotionAlarm updated to ON
2020-07-14 19:52:17.376 [thome.event.ItemStateEvent] - vCamMotionAlarm updated to ON
2020-07-14 19:52:18.284 [thome.event.ItemStateEvent] - vCamMotionAlarm updated to ON
2020-07-14 19:52:18.444 [thome.event.ItemStateEvent] - vCamMotionAlarm updated to ON
2020-07-14 19:52:19.275 [thome.event.ItemStateEvent] - vCamMotionAlarm updated to ON
2020-07-14 19:52:19.578 [thome.event.ItemStateEvent] - vCamMotionAlarm updated to ON
2020-07-14 19:52:20.285 [thome.event.ItemStateEvent] - vCamMotionAlarm updated to ON
2020-07-14 19:52:20.394 [thome.event.ItemStateEvent] - vCamMotionAlarm updated to ON
2020-07-14 19:52:21.284 [thome.event.ItemStateEvent] - vCamMotionAlarm updated to ON
2020-07-14 19:52:21.394 [thome.event.ItemStateEvent] - vCamMotionAlarm updated to ON
2020-07-14 19:52:22.304 [thome.event.ItemStateEvent] - vCamMotionAlarm updated to OFF
2020-07-14 19:52:22.413 [thome.event.ItemStateEvent] - vCamMotionAlarm updated to OFF
2020-07-14 19:52:23.260 [thome.event.ItemStateEvent] - vCamMotionAlarm updated to OFF
2020-07-14 19:52:23.526 [thome.event.ItemStateEvent] - vCamMotionAlarm updated to OFF
2020-07-14 19:52:24.246 [thome.event.ItemStateEvent] - vCamMotionAlarm updated to OFF
2020-07-14 19:52:24.315 [thome.event.ItemStateEvent] - vCamMotionAlarm updated to OFF
2020-07-14 19:52:25.276 [thome.event.ItemStateEvent] - vCamMotionAlarm updated to OFF
2020-07-14 19:52:25.385 [thome.event.ItemStateEvent] - vCamMotionAlarm updated to OFF
2020-07-14 19:52:26.295 [thome.event.ItemStateEvent] - vCamMotionAlarm updated to OFF
2020-07-14 19:52:26.405 [thome.event.ItemStateEvent] - vCamMotionAlarm updated to OFF

I have my trigger items set to expire(OFF) after 7 seconds

How do you do that? I bet that is the problem.

.items

Switch vCamMotionAlarm "MotionAlarm Triggered - Someone Approaching" (gDoorbellSensors) { expire="7s,command=OFF" }

CelMotionDetector is not set aside for PIR and many cameras with no PIR use this for their normal detection reporting. It is explained in less nerdy talk hereā€¦

Yes that is normal in all builds, however it can be filtered out by the binding and I am now testing some changesā€¦ Since I run my system with the event log set to WARN I donā€™t see it, so thanks for mentioning this. It will probably lower CPU usage by a tiny amount.

Your not reaching 1X speed so you may find the alarm lags further behind realtime the longer it is left running. It can be normal for that to happen when first opened and then it settles into 1x speed. I am not a ffmpeg expert so use google on any errors to find what they mean. Would prefer to keep all discussion on ffmpeg detection in its own thread so as not to loose things in this huge thread. Also if it is related to only the ezviz camera it should go into its own thread for the same reason.

Why do you do that? Iā€™m going to take a guess as to whyā€¦ Have a look at the Openhab documentation and there is a difference to UPDATED vs CHANGED. For any rules you create just use the CHANGED TO trigger. If it is because the switch is bouncing back and forth or you want to limit emails getting sent to only 1 per minute then yes the way you are doing it is how I would do it.

Hum. Why would you set it to expire? On my DB1, the motion alarm only triggers for a few seconds and then reverts back to OFF without me having to do anything. Perhaps as @matt1points out, you are using UPDATED in your rules?

I am actually fine with the repetition since I wonā€™t be in DEBUG after things are stable. Just wondered about the behavior. As you say, probably saves a very tiny amount of processing, but given that the ffmpeg processor is very chatty as well, I would not worry about it.

Just trying to understand your thinking here. We have two ONVIF topics, one for PIR, and one for motion trigger coming from internal camera video analysis. The binding creates two channels - one for pirAlarm and one for motionAlarm. Why not link the ONVIF PIR topic to the pirMotion item, and the ONVIF video analytics motion to the channel for motionAlarm? That way, in one device you could create a rule which says you must have both PIR AND video analytics motion before you send a notification? Just got going here, so I will read the article you cited later today.

Understood. I will keep an eye on it for now. If it shows up again, I will do some more research.