I am experimenting with ONVIF triggers (specifically the AI-driven person detection of a Reolink doorbell) and spotted this evening that an event was stuck in an alarm state and ended up recording for 10 minutes (consuming 300MB) despite the actual 'action' being over in only a few seconds.
Looking at the onvif-related logging I saw the following:
Aug 21 22:23:16 dellt20 zmc_m31[987342]: INF [zmc_m31] [Triggered on ONVIF]
Aug 21 22:23:16 dellt20 zmc_m31[987342]: INF [zmc_m31] [Doorbell (High Res) (Reolink D340W): -01 - Gone into alarm state PreAlarmCount: 0 > AlarmFrameCount:1 Cause:ONVIF]
Aug 21 22:23:16 dellt20 zmc_m31[987342]: INF [zmc_m31] [Opened new event 4379028 ONVIF]
Notably, there was no '[Triggered off ONVIF]' entry like I've seen with other log entries, and so presumably either the doorbell didn't send it when it was no longer detecting a person or Zoneminder didn't see/process it.
Is there any way of making ONVIF triggers behave more like those that can be submitted via zmtrigger i.e. treat the trigger as a kind of 'on+X' trigger rather than an 'on until I tell you off' approach? Perhaps that would in turn cause another issue though that if the detected person hung around the camera/doorbell might not send repeated 'on' events and so recording could be stopped prematurely (this is something I'd have to check unless someone else already knows).
Runaway event caused by missing ONVIF event
Runaway event caused by missing ONVIF event
Last edited by MJN on Fri Aug 23, 2024 9:07 am, edited 1 time in total.
Re: Runaway event caused by missing ONVIF event
That seems like a good feature.
There is also an undocumented option to put in options called closes_event. If you stick that in there the ONVIF poller will automatically close the event.
There is also an undocumented option to put in options called closes_event. If you stick that in there the ONVIF poller will automatically close the event.