triggering of multiple monitors

[alexl]

Can one monitor activate another monitor (s) when being triggered?
Alex

[zoneminder]

This is a feature that is on the roadmap for a couple of versions down the line so currently no. You can probably bodge it with a script based on zmx10 or zmtrigger though.

Phil

[lazyleopard]

I expect the tricky bit will be getting the "I've been triggered" signal out of the controlling monitor...

Are there any examples of zmtrigger customisations available yet? I've not yet figured the syntax it expects incomming triggers to use.

[zoneminder]

It is likely to require that the triggering zma will have to be attached to the shared memory of the zma processes that it wants to trigger. It can then easily write to the relevant areas to initiate an event and indicate the cause for it. I'm not 100% certain yet as I've not fleshed out the design.

The format for zmtriger is pretty simple, though I don't have it to hand. I think I probably wrote a mini-guide a while back. If I didn't already put it in the README I'll see if I can find it and post it here.

Phil

[lazyleopard]

That'd be this bit from the README, I guess:

zmtrigger.pl - This is a new (for 1.20.0) optional script that is a more generic solution to external triggering of alarms. It can handle external connections via either internet socket, unix socket or file/device interfaces.

Currently you have to configure these using the 'sources' array in the script itself though ultimately I would expect they would be databased. The format of triggers used by zmtrigger.pl is as follows:

"<id>|<action>|<score>|<cause>|<text>"

where:

• 'id' is the id number or name of the ZM monitor
• 'action' is 'on','off' or 'cancel' where 'on' forces an alarm condition on, 'off' forces an alarm condition off and 'cancel' negates the previous 'on' or 'off'. Ordinarily you would use 'on' and 'cancel', 'off' would tend to be used to suppress motion based events. Additionally 'on' and 'off' can take an additional time offset, e.g. on+20 which automatically 'cancel's the previous action after that number of seconds.
• 'score' is the score given to the alarm, usually to indicate it's importance. For 'on' triggers it should be non-zero, otherwise it should be zero.
• 'cause' is a 32 char max string indicating the reason for, or source of the alarm e.g. 'Relay 1 open'. Ignored for 'off' or 'cancel' messages
• 'text' is a 256 char max additional info field, currently not used for anything though anything passed in here will get saved. Ignored for 'off' or 'cancel' messages.

Note that multiple messages can be sent at once and should be LF or CRLF delimited. Without customisation zmtrigger.pl is of little use, but if you configure it correctly it can help integrate other systems to generate external triggers that will cause ZoneMinder events.

...which looks good, though I'm not convinced the "on+1" syntax is doing the right thing... (1.20.1)

[lazyleopard]

Here's a verbose(ish) log from zmtrigger.

Code: Select all

Trigger daemon starting at 05/03/23 00:29:10
Opening source 'S2'
Got input from 1 sources
Got input from source S2 (6)
Got '1|on+10|1|Snapshot|text
' (24 bytes)
Processing buffer '1|on+10|1|Snapshot|text
'
Processing message '1|on+10|1|Snapshot|text'
Found monitor for id '1'
Handling action 'on+10'
Triggered event on 'Snapshot'
Added timed event '1|cancel|Snapshot|text', expires at 1111537795 (+10 secs)
Got input from 1 sources
Got input from source S2 (6)
Got unexpected close on source S2 at /usr/bin/zmtrigger.pl line 210.
Trigger daemon starting at 05/03/23 00:29:45
Opening source 'S2'

Line 210 reads

Code: Select all

die( "Got unexpected close on source $source->{name}" );

and is in response to a !$nbytes test. It never gets to the timed action bit...

[zoneminder]

What have you defined your source S2 as? And how are you driving it?

Phil

[lazyleopard]

I went for what I thought would be the easiest option, which was to define it as "file", and use a named pipe (fifo), which I figured I could then drive any way I chose, but most likely by using, say:

Code: Select all

echo '1|on+1|1|trigger|testing' > named.pipe

[lazyleopard]

Code: Select all

echo '1|on+1|1|trigger|testing' > named.pipe

...which, I guess, results in the pipe being "closed" at the end of the echo text...

[zoneminder]

Yes. I think if you use file, it should work if you just append to it. If you want a pipe-like interface just use unix sockets.

Having said that, I don't think 'die'ing is the best response but I'm not sure why it gets there rather than the normal disconnect. I will try and have a further look at it.

Phil

[lazyleopard]

I suspect the end of the input results in a "close" from the shell on the pipe, and that trips zmtrigger into asssuming it has reached the end of the line. It should, however, at least keep going until it has no more queued events. Experimentation will wait fpr another day, I guess...

[desnaturado]

I just learned that POSIX rules for select() require that you open named pipes r/w and not just r/o. Try:

Code: Select all

open( *sfh, "+<".$source->{path} ) or die( "Can't open: $!" );

and your pipe triggers ok.

Regards

Juergen

[zoneminder]

Interesting, thanks for that. I'll see if I can add that in a generic way in the next release.

Phil