Elk M1G start up sequence

dBeau

Active Member
Up until recently, I'd been happy with the automation rules I've been using in my elk. After a recent firmware upgrade, I had to restart the system. This led to my garage door opening.... and closing again. So now I need to question my understanding of things. I traced the problem to a rule that is triggered by a "whenever becomes not secure". It seems that these rules get hit on start up even if the zone is secure at the time. This one in particular caused the door to open. Then, I have another rule, this one a "whenever becomes secure", and it caused my garage door to close. The funny thing is that there was a good 30 seconds between the two events. Should this triggering of the rules be considered normal? If so, how can I code around it. As stable as the m1g is, I really dont want to count on it running all the time.

The short of this is that I would like to understand what is supposed to happen at start up. I am happy to leave the details of garage door programming in the other fine thread on the subject.

Thoughts? Observations? Guesses?
 
To make sure that a system startup does not trigger a Rule:

Whenever System Startup Occurs
Then turn on Output 100 for 2 minutes //this allows all expander zones to checkin upon startup

Whenever Zone X becomes not secure
AND Output 100 is Off //this makes sure the Rule is not triggered during system startup
Then ... do something
 
What happens in the M1 is that all zones are temporarily bypassed on system startup and the temporary bypass is removed when the zone has checked in and stable. There is an event change from bypassed to secure which will trigger a Rule that triggers upon changing to Secure.

There are other considerations that should be followed for system power up such as outputs. I have a fish pond circulating pump that can be controlled from Rules. Upon powerup all outputs are turned off. I wrote a Rule that fires on system startup that turns the fish pond pump on.
 
What happens in the M1 is that all zones are temporarily bypassed on system startup and the temporary bypass is removed when the zone has checked in and stable. There is an event change from bypassed to secure which will trigger a Rule that triggers upon changing to Secure.

If I take what you are saying too literally, it would imply that writing my rules to trigger on Not Secure rather than on Secure would prevent them from triggering at start up. I have some empirical evidence that would suggest otherwise. Perhaps you can confirm my guess that first all zones become Not Secure and those rules are triggered, then a bit later, they become Secure (assuming they are). This observation is from zones on an input expander, btw.

There are other considerations that should be followed for system power up such as outputs. I have a fish pond circulating pump that can be controlled from Rules. Upon powerup all outputs are turned off. I wrote a Rule that fires on system startup that turns the fish pond pump on.

When the outputs are turned off at power up, do they cause the Is Turned Off rules to activate?
 
Another thing that you should be aware of is zones can "change state" when a disarm occurs. Here's what I mean:

I have the follwing rule that whenever a the driveway gate is opened (violated) the M1 announces "gate opened" and beeps the keypads.

WHENEVER Front Gate (Zn 96) BECOMES NOT SECURE
THEN ANNOUNCE Front Gate (Zn 96)
THEN TURN Beep Keypad (Out 51) for 5 seconds

Here's the Out-51 rules:
WHENEVER Beep Keypad (Out 51) STATE IS TURNED ON
THEN START KEYPAD BEEPS IN House (Area 1)
WHENEVER Beep Keypad (Out 51) STATE IS TURNED OFF
THEN STOP KEYPAD BEEPS IN House (Area 1)


Also note, I turn off voice annoucements at 11:01pm.

However, if the gate is left opened, and you disarm the system - you will get a "Gate Opened" announcement and the keypad will beep for 5 seconds.
Note, Zone 96 is defined as "16 = non-alarm"

This took us a while to figure out, as we had a the motion detector outside the bedroom door set to turn off the alarm if it was in night mode and it was after 6am, so my wife wouldn't set off the alarm when she went to work.

Every so often we would hear the keypad beeping in the early morning.

So after much looking at the logs, it turns out the dog was setting off the motion detector, the alarm was gettting disabled, and the rule was processed as the gate was left open, but since voice annoucements were disabled, only the keypad beeped.
 
AnotherOne:

Could you make your non-alarm zones part of another area. That area could always remain disarmed. Haven't tried it.
 
Another thing that you should be aware of is zones can "change state" when a disarm occurs.

Yes, that does sound important and more likely than a system start up.

It would seem that taking Spanky's idea a bit further would help. On any arm/disarm event, restarting that same "lockout" timer would be a good idea. I wonder if there are any other conditions that would trigger a Becomes Secure / Becomes Not Secure rule when there isnt a physical change in the state of the zone. The assumption here too is that the arm/disarm would happen before the state change.
 
Back
Top