ELK RP and rules

[blmxm]

OK, is it just me or is the ELK a tad finicky about rules order of events, timing etc. I admit I am used to PLC programming with a full range of Boolean logic, but now that I am getting close to having all my expanders / devices in, and getting a bit deeper into the rules woods, it seems I have to fudge around a bit to keep the ELK happy.

Also just a couple of things I have noticed that perhaps others have run across / worked around:

1) I can't get the system to switch arm modes consistently with rules, unless I disarm within the rules first. Anyone have rules that are doing this successfully?

2) When I disable a rule in RP, anytime I connect again, RP shows conflicts. This is more just a note, as I now have figured out that the rule is actually removed from the control. I made a new account connected and downloaded the rules and found the "disabled" ones missing, since I couldn't figure out why it found conflicts right after sending the rules all the time.

3) In RP, I am using a FOB, and wanted to create a user that matched the FOB ID, just so I could add a name to it so it was more easily found in the log. If I add a new user and tick the checkbox that they have a FOB, the code box is set all zeros, I save the user, switch to another user or any other screen in RP, and then return to the just created user, the FOB checkbox is un-ticked. Now the control will log with the named user correctly, but a conflict gets reported every time because it reverts back to unchecked. Obviously if you make other changes and send to the control this user will be uploaded incorrectly. Am I missing something?

I will post some more items here in the coming weeks to see if anyone has ideas on streamlining my rules, and to document a couple items I have done. Nothing ground breaking, but hoping to give a little back to where I have learned much.

 

[nov0798]

1. ??
2. You have to save the changes to the M1 itself, and also to the PC that stores the database. In other words the rules in the M1 and the PC have to match.
3. I also believe you must save the rules before you switch screens.

 

[blmxm]

1. ??
20 WHENEVER grg entr dly (Counter 18) CHANGES TO 6
THEN DISARM AREA(S) 1 IMMEDIATELY

BYPASS GARAGE DOOR AND MOTION, OPEN DOOR,
SWITCH DOORWAY INTO HOME FROM INTERIOR ZONE TO ENTRY/EXIT DELAY ZONE.
Shunt active zone. Bypass garage door. Arm to stay to allow entry.
21 WHENEVER grg entr dly (Counter 18) CHANGES TO 4
THEN TURN Shunt Primary Zn (Out 19) ON
THEN BYPASS Garage Door (Zn 7)
THEN ARM AREA(S) 1 TO STAY IMMEDIATELY
When the system is already armed, without rule 20 to disarm first, rule 21 arm to stay doesn't function all the time. Seemingly it is dependant on whether I toggled through arming modes with the quick arm key at the keypad.

2. You have to save the changes to the M1 itself, and also to the PC that stores the database. In other words the rules in the M1 and the PC have to match.
I am aware of that. When rule 20 in the above is disabled, sent and saved, the next RP connection shows conflicts in the rules. Creating a completely new account and downloading from the control shows rule 20 to not be present. Since one can't compare rule and text conflicts using the RP software, I included this as more of a note than anything else. Maybe it will save someone else some trouble, maybe something goofy is going on with my system. Maybe this is just the way it "works". Doesn't make sense to me that this would report as a conflict.

3. I also believe you must save the rules before you switch screens.
This is not rules related. In the USER section if the keyfob checkbox is marked, it defaults back to unmarked, regardless of saved, saved before leaving the page, sent and saved, saved and sent. I have duplicated it on a fresh install of the latest RP on a different machine. Create a new user, tick the FOB box, save, go anywhere else in the software and come back to the user created, no check in the FOB box. I did this with and without being connected. With user names that match and don't match the FOB ID as setup in the wireless section, all with the same results. When box is ticked and sent to the control, the control will report with the created name so the control sees that, but the software doesn't save it whether connected or not. I don't know how to explain it any better than that.

 

[signal15]

I will concur that item #2 is indeed a problem. It doesn't break anything, it's just annoying.