|
Rules
that do not work and why
This
newsletter will cover some examples of rules that do not work as expected,
giving an explanation of the problem and how it can be resolved.
Rules
with “AND” time elements
Scenario 1:
The outdoor flood light should come on when the outdoor motion is
tripped and it is after sunset.
|
WHENEVER
Outdoor Motion (Zn 1) BECOMES NOT SECURE
AND
THE TIME IS LATER THAN SUNSET
THEN TURN Outdoor Light [1(A1)] ON FOR 5 MINS
|
Scenario 2: An LED indicator
connected to output 7 should come on when the back door is opened between
8pm
and
9am
.
|
WHENEVER
Back Door (Zn 2) BECOMES NOT SECURE
AND TIME OF DAY IS LATER THAN
8:00PM
AND
TIME OF DAY IS EARLIER THAN
9:00AM
THEN TURN LED-Back (Out 7) ON
|
Problem:
The first rule will work as expected until
midnight
.
The second rule will not work at all.
This is due to the fact that the system evaluates the “AND”
time statements from midnight to midnight.
This means that “later than sunset” is the period of time from
after sunset to
midnight
.
The second rule does not work, because within the midnight to
midnight period, a time that is after
8:00PM
and before
9:00AM
does not exist.
This period of time spans across two days, therefore the “AND”
statements can never both be true and the rule will never fire.
Solution:
To overcome this problem, two rules can be written.
One rule will cover the period of time before
midnight
, while the other rule
will cover the period of time after
midnight
.
|
WHENEVER
Back Door (Zn 2) BECOMES NOT SECURE
AND TIME OF DAY IS LATER THAN
8:00PM
THEN TURN LED-Back (Out 7) ON
WHENEVER
Back Door (Zn 2) BECOMES NOT SECURE
AND TIME OF DAY IS EARLIER THAN
9:00AM
THEN TURN LED-Back (Out 7) ON
|
For scenario 1, a rule could be written that will turn the light on when
the motion sensor is tripped and it is dark outside.
This would overcome the issue with the rule not working after
midnight
.
|
WHENEVER
Outdoor Motion (Zn 1) BECOMES NOT SECURE
AND
IT IS DARK OUTSIDE
THEN TURN Outdoor Light [1(A1)] ON FOR 5 MINS
|
“WHENEVER”
is the trigger
Scenario:
The control is partitioned into 4 separate areas.
Area 1 is a lobby between 3 separate offices.
When all three offices (Areas 2, 3, and 4) are armed to away mode,
the lobby (Area 1) should automatically arm.
|
WHENEVER
Office 1 (Area 2) IS ARMED AWAY
AND Office 2 (Area 3) IS ARMED AWAY
AND Office 3 (Area 4) IS ARMED AWAY
THEN ARM AREA(S) 1 TO AWAY IMMEDIATELY
|
Problem:
This rule will not work all the time.
It will only work if Area 2 is armed after Areas 3 and 4.
If area 2 is armed before Areas 3 or 4, the rule will not fire
because the AND statements are not true at the time that the trigger (the
WHENEVER statement) occurs.
Solution:
A separate rule must be written with each area as the trigger to
accommodate for the different orders in which the areas may be armed.
In this example, in addition to the rule above, the following two
rules would also be needed.
|
WHENEVER
Office 2 (Area 3) IS ARMED AWAY
AND Office 1 (Area 2) IS ARMED AWAY
AND Office 3 (Area 4) IS ARMED AWAY
THEN ARM AREA(S) 1 TO AWAY IMMEDIATELY
WHENEVER
Office 3 (Area 4) IS ARMED AWAY
AND Office 1 (Area 2) IS ARMED AWAY
AND Office 2 (Area 3) IS ARMED AWAY
THEN ARM AREA(S) 1 TO AWAY IMMEDIATELY
|
ELK
RP
Tips
Resolving
Conflicts
Conflicts are the differences detected between what is programmed in the
system and what is stored in the database for an account.
Conflicts can arise from the customer changing the system
programming themselves (changing user codes, etc.), or from an installer
on a service call modifying the programming through local (keypad)
programming. Conflicts can
also arise when an operator makes a change in ElkRP without being
connected to the system.
If any of these cases occur, the next time ElkRP connects to the account,
it will automatically detect the differences and list them in the
Conflicts Window, provided the system administrator has not disabled this
feature. The operator has
several options for resolving the differences.
After all conflicts have been resolved, the Conflicts Window will
disappear.
If the list of conflicts is very large, you may scroll through it by
clicking the scroll bar. To
see what the specific problem is with an item, select it by clicking on
it. A description of the
problem appears in the lower text box.
To see what changed in the item, select the item, then click the View
differences button. A window
will pop up showing the system’s and ElkRP’s copies of that item side
by side.
If the item was changed in the system, and you know the change should be
accepted, click on the item’s check box to select it, then click the
Receive button. ElkRP will
receive the system’s copy of the item to be saved in the database.
This solution should be used whenever the customer or an installer
makes a change through local programming and you want to update the
database to be current.
If the item was changed in the database, and you know it is correct, check
the item’s check box and click the Send button.
ElkRP will send its copy of the item to the system to be
programmed. Whatever was
already in the system will be replaced.
This solution should be used if an operator changes something
off-line, then later connects to the system.
If the item simply shouldn’t exist at all, check its checkbox and click
the Delete button.
If an item in the conflicts list is sent or received without using the
buttons in the Conflicts Window, the list will still be automatically
updated.
If a new account is created from an account template, then modified
off-line, when ElkRP connects to the newly installed system there will be
several items in the conflicts list.
There is really no need to use the buttons in the Conflicts Window
to resolve the differences in this case.
Since the account was already programmed off-line, and because
there are no changes made in the system that need to be kept, simply send
all the programming to the system using the Send All command in the Send/Rcv
menu.
|
