Page 1 of 1
triggering of multiple monitors
Posted: Mon Mar 21, 2005 6:02 pm
by alexl
Can one monitor activate another monitor (s) when being triggered?
Alex
Posted: Mon Mar 21, 2005 6:03 pm
by 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
Posted: Mon Mar 21, 2005 6:17 pm
by 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.
Posted: Mon Mar 21, 2005 9:49 pm
by 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
Posted: Wed Mar 23, 2005 12:10 am
by 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)
Posted: Wed Mar 23, 2005 12:51 am
by 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...
Posted: Wed Mar 23, 2005 10:46 am
by zoneminder
What have you defined your source S2 as? And how are you driving it?
Phil
Posted: Wed Mar 23, 2005 6:04 pm
by 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
Posted: Thu Mar 24, 2005 1:24 pm
by lazyleopard
lazyleopard wrote: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...
Posted: Thu Mar 24, 2005 7:16 pm
by 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
Posted: Fri Mar 25, 2005 12:26 am
by 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...
Posted: Thu Mar 31, 2005 10:42 pm
by 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
Posted: Fri Apr 01, 2005 7:19 pm
by zoneminder
Interesting, thanks for that. I'll see if I can add that in a generic way in the next release.
Phil