1.22.1 cause/notes field questions

[gliming]

I'm attempting to parse (re: zmxap) the new, more verbose cause and notes event fields from the 1.22.1 release. Looking at the source, it appears that multiple cause and notes entries are allowed (and delimitted). However, the release notes suggest that the cause and notes fields will not be updated after an alarm has already started. Can you identify some scenarios in which multiple entries in their fields might occur? I do not yet have an ability to experiment with linking. Is it possible to have more than one Linking entry appear in the notes field? Would it ever be possible to have a Signal cause and anything else simultaneously? btw: Identifying the triggering zone(s) is quite nice!

[zoneminder]

I'm attempting to parse (re: zmxap) the new, more verbose cause and notes event fields from the 1.22.1 release. Looking at the source, it appears that multiple cause and notes entries are allowed (and delimitted). However, the release notes suggest that the cause and notes fields will not be updated after an alarm has already started. Can you identify some scenarios in which multiple entries in their fields might occur? I do not yet have an ability to experiment with linking. Is it possible to have more than one Linking entry appear in the notes field? Would it ever be possible to have a Signal cause and anything else simultaneously? btw: Identifying the triggering zone(s) is quite nice!

Basically the cause and notes fields are set when the event is created so if an event is triggered from another monitor and then on the next frame the whole world blows up it will still just say it was caused by the Linked Monitor. You are most likely to get multiple causes if you have two monitors both of which cover the same area and trigger a third, or if you have cam1 with motion detection and cam2 with motion detection and triggered from cam1. Then if the sun goes behind a cloud or something you could get both linked monitor and motion detection triggering. It would have to be the exact same frame though and so is less likely at high frame rates.

Similarly it is unlikely, though not impossible to be triggered from more than one linked monitor, e.g. 1 triggers 2 and 3, 2 triggers 3 though this isn't likely to be an optimal setup!

It is theoretically possible to get a signal cause and a trigger cause for instance, but fairly unlikely.

By the way, you are the first feedback I've had on 1.22.1, did you upgrade or is this a fresh install, or have you just read the docs?

[gliming]

Thanks for the clarification Phil. I will likely need to make the parsing sufficiently smart to handle these cases for zmxap. The good news is that I am now parsing out the responsible zone(s) and including it in the xAP message--which allows HA systems to change behavior as a function of which zone was triggered. I am most excited about using this feature. Many thanks!

By the way, you are the first feedback I've had on 1.22.1, did you upgrade or is this a fresh install, or have you just read the docs?

It was an upgrade; and, quite painless despite my forgetting the appropriate configure params. It has been working flawlessly.

Either it was a slight change in my zone sensitivity or different state updates to shared memory; but, regardless, the transition from/to idle/alarm states seems much more accurate now. Again, thanks for incorporating these latest changes.

[gliming]

from/to idle/alarm states

...ooops. Meant to say from/to alert/alarm states. Previously, I was only seeing an event transition from idle to alarm (0 -> 2) --never from idle to alert to alarm (0 -> 3 -> 2). It's the latter that I'm seeing now. I'm assuming that the "pre-alarm" alert states reflect activity over some threshold that is not yet considered an alarm frame. So, a typical state transition (for my zones/monitors) is something like (0 -> 3 -> 2 -> 3 -> 0).

Gregg

[zoneminder]

Hmm, you should never see a transition from idle to alert. Is this definately happening? The only other possible state between idle and alarm is pre-alarm (1) when you have it set to only create an event after 'n' alarm frames. The alert state is that an alarm has finished but it potentially may restart.

If you are definately seeing these transitions then it implies something is wrong somewhere.

[gliming]

Hmm, you should never see a transition from idle to alert. Is this definately happening?

I am definitely seeing the transition from idle to alert; but admittedly by polling shared memory. My previous polling interval was admittedly too long (1s) and I have since chopped it down to 250ms. But, with a fast frame-rate and certain movements, I can still expect circumstances where the initial alarm state is missed and replaced by a successive alert state. For now, I am going to assume that the issue is aliasing caused by too low a polling rate and that zm is performing the transition as you've described.

Thanks for the clarification, Phil.

Gregg

[zoneminder]

Don't forget that you can check the last event id for a monitor to see if you have missed an event. This is what the HasAlarmed function does, basically check if there is an alarm now and if not has there been onesince the last check.