Triggers are a way to identify one or more Flex II Audit Trail Events and designate a resulting Inter-hub signal or an output pattern from a selected set of output lines on the local Flex II Controller hub. Each hub gets a distinct set of triggers.
Flex II Trigger Execution LogicTriggers may also be set to execute only during certain time frames and if selected inputs are either in a high or low state. Delays may be added prior to evaluating the input line states and then prior to executing the trigger. The chart below illustrates the logic executing a trigger.
Flex II Triggers List
Each Flex II controller has a distinct list of triggers. They are viewed by selecting properties for a Flex II controller in the Flex Hub listing page then selecting from the tabs on the left.
Click the to add a new trigger.
A click menu for each trigger in the list enables editing the trigger properties or deleting it.
Triggering an Inter-hub Signal
To use audit trail events to trigger an inter-hub signal:
|
|||
|
|||
|
|||
|
|
||
|
|||
|
|||
|
Triggering Local Output Lines
To use audit trail events to trigger an output pattern on one or more lines connected to the local controller, follow these steps:
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
Additional notes about Triggers:
- Inter-hub signals have priority over triggers. An Inter-hub signal will override output behavior on any output currently executing a trigger. However if an output behavior is not specified for a given output, the output behavior specified in the trigger will continue.
- A trigger will not override output behaviors specified in an Inter-hub signal. However if an Inter-hub signal does not specify a behavior for an output, a trigger may execute an output pattern for that output.
- A trigger which toggles a relay will override a door being held closed in a Man Trap. If that door were opened, it would also generate a Flex II audit event 578 (Door Opened Without Access Permissions).
- Once created, triggers should be tested to ensure they operate as expected.
- If delays are used before evaluation of inputs or execution of output, the schedule, if used, is NOT evaluated again after those delays. It is only verified to be in-schedule immediately following the triggering event.
- unlike Inter-hub signals, triggers are not tracked by the server and not persisted in storage on the controller. If the hub is restarted during an 10 minute execution delay, it will not resume a trigger. This is unlike an Inter-hub signal which will resume upon hub startup. *Note