ZoneMinder Forums

I've recently been working with the new 1.22.0 perl API. It is a great piece of work! The downside is that it has me wishing for more. Details follow:

1) Motion event cause/text not set in shared memory. I'm not seeing the motion cause (and text has always been blank) from zmShmRead($mon, 'trigger_data:trigger_cause'). (Note: I can overcome this now; but, the suggested ability to report zone info in the text field has me salivating. Will this be readily parsable?)

2) Similar to the above, forced web alarms do not clear the cause (and perhaps text field) values in shared memory on suspend web (requiring a manual detection and forced zmShmWrite w/ blanks.

3) Could a zmDbGetTrigger be added to Database.pm (similar to zmDbGetMonitor)?

4) I'm envisioning an ability to override zm's control over a camera. Is something comparable to SharedMem::zmMonitorSuspend/Resume a possibility?

Gregg

gliming wrote:I've recently been working with the new 1.22.0 perl API. It is a great piece of work! The downside is that it has me wishing for more.

Good I'm glad you like it

gliming wrote:1) Motion event cause/text not set in shared memory. I'm not seeing the motion cause (and text has always been blank) from zmShmRead($mon, 'trigger_data:trigger_cause'). (Note: I can overcome this now; but, the suggested ability to report zone info in the text field has me salivating. Will this be readily parsable?)

The event and cause are stored in the database which is why they aren't in the shared memory. However it is relatively easy to store the 'last' cause and text (as with the x and y coords) so long as you are aware that it may not last long! The text field should be easy to parse. It will be a cr/lf list of causes in the format of label: detail if I recall.

You should be able to read from the trigger cause field if you have set it, but it doesn't get set except by an external trigger.

gliming wrote:2) Similar to the above, forced web alarms do not clear the cause (and perhaps text field) values in shared memory on suspend web (requiring a manual detection and forced zmShmWrite w/ blanks.

I will have a look at this. I''ve rewritten it a bit for 1.22.1 anyway. Ordinary alarms will never interact with the trigger data cause and text by the way.

gliming wrote:3) Could a zmDbGetTrigger be added to Database.pm (similar to zmDbGetMonitor)?

What do you think should be returned? There isn't really a trigger definition in the DB.

gliming wrote:4) I'm envisioning an ability to override zm's control over a camera. Is something comparable to SharedMem::zmMonitorSuspend/Resume a possibility?

Do you mean PTZ control or something else? I'm not quite sure which bit you want to control.

The event and cause are stored in the database which is why they aren't in the shared memory.

Yes, I did realize that I could get this info after the event is recorded to the database. But, I really want/need to get the alarm cause and text at the point that the alarm actually occurs. Is this information stored into the DB at this point and then simply revised on completion of the event? If so, then this will work for me.

However it is relatively easy to store the 'last' cause and text (as with the x and y coords) so long as you are aware that it may not last long! The text field should be easy to parse. It will be a cr/lf list of causes in the format of label: detail if I recall.

Are you saying that you would be willing to add the cause and text values for motion caused alarms? I do realize that the values would be "fleeting" as soon as new alarms occur. But, I don't know of any other way to very quickly identify the fact that an alarm has occurred other than fairly fast SM "polling".

You should be able to read from the trigger cause field if you have set it, but it doesn't get set except by an external trigger.

Right--this is what I'm wondering if you're willing to change. Or, is there another way that I can get this info at the start of the alarm.

What do you think should be returned? There isn't really a trigger definition in the DB.

... event data. I probably should have said zmDbGetEvent...

Do you mean PTZ control or something else?

Yes--PTZ control. Essentially, leveraging the scripts included w/ zm for non-zm initiated control. The reference to zmMonitor and zmSuspend was to allow the external "controller" to tell zm to suspend it's control as well as resume.