confused about elk rules

[wired-up]

I'm sure I'm missing the answer somewhere, but here goes:
in an elk rule, if one then states " turn on out9 for 3 minutes" and the next then says "turn on out10 for 3 minutes" will the elk wait until the three minutes are up for out9 before turning on out10 or will they fire in rapid succession?
David

 

[sharby]

They should fire in rapid succession (which stinks). You're required to write a third rule that says:
Whenever output 9 is turned off, then turn output 10 on for x minutes.

-=*Sharby*=-

I hope ELK will add the "DELAY" function into the system

 

[upstatemike]

They should fire in rapid succession (which stinks). You're required to write a third rule that says:
Whenever output 9 is turned off, then turn output 10 on for x minutes.

-=*Sharby*=-

I hope ELK will add the "DELAY" function into the system

Curious why you think the current setup stinks? I certainly would not want output 9 linked to output 10 unless I programmed it that way. A delay command might simplify the code in some situations but at the end of the day would not do anything different than what you can do now.

Also in your example are you really writing a third rule or just modifying the second one?

 

[Spanky]

Each output has its own timer. Setting Output 9 is not connected to Output 10's running.

 

[sharby]

Each output has its own timer. Setting Output 9 is not connected to Output 10's running.

I am not knocking the concept. I'm knocking that fact that the coding of "rapid firing" should be coded so that if you want to wait "x seconds" and you want to write the rule the way ELK interprets it, the rule should be designed as:

whenever {condition},

Then
Turn Output 9 on for 3 minutes
- and -
Turn Output 10 on for 3 minutes

The above state would do what ELK does without the "and" command.

My beef with a 3rd rule is that there is a memory restriction in ELK that maxes out on the rules. Because of this, I have to offload non-essential rules to PowerHome for processing.

I have 4 ELK installs for August and most of my automation coding nearly fills the ELK rules on the M1G system.

-=*Sharby*=-

 

[BraveSirRobbin]

Each output has its own timer. Setting Output 9 is not connected to Output 10's running.

I am not knocking the concept. I'm knocking that fact that the coding of "rapid firing" should be coded so that if you want to wait "x seconds" and you want to write the rule the way ELK interprets it, the rule should be designed as:

whenever {condition},

Then
Turn Output 9 on for 3 minutes
- and -
Turn Output 10 on for 3 minutes

The above state would do what ELK does without the "and" command.

My beef with a 3rd rule is that there is a memory restriction in ELK that maxes out on the rules. Because of this, I have to offload non-essential rules to PowerHome for processing.

I have 4 ELK installs for August and most of my automation coding nearly fills the ELK rules on the M1G system.

-=*Sharby*=-

The Ocelot's ladder logic programming can do this type of logic very well (the M1's big weakness is the way it handles timers). I just don't know how much of a hassle it would be to "marry" one to an Elk M1.

 

[upstatemike]

My beef with a 3rd rule is that there is a memory restriction in ELK that maxes out on the rules. Because of this, I have to offload non-essential rules to PowerHome for processing.

I have 4 ELK installs for August and most of my automation coding nearly fills the ELK rules on the M1G system.

-=*Sharby*=-

I agree that memory is a weak point with the M1. Also the fact that resources like timers are "hard code" associated with outputs. Many applications require you to use the timer from a "spare" output to do something but what if you are using all the outputs and there are no spares left?

Hoping this is addressed in the M2 along with an expanded command set and the ability to control thermostats from a keypad.

 

[Spanky]

Every light also has a timer and you can use them to do timing things. Outputs = 208 timers, lights = 255 timers.

 

[upstatemike]

Every light also has a timer and you can use them to do timing things. Outputs = 208 timers, lights = 255 timers.

OK, I guess that's enough timers... but I still want to adjust thermostats from keypad locations (actual real time adjust, not trigger a pre-defined setpoint).

 

[Lagerhead]

Hoping this is addressed in the M2...

Please say more about this "M2".

 

[upstatemike]

Hoping this is addressed in the M2...

Please say more about this "M2".

My general reference to the next generation Elk panel whenever that might occur. I don't think any announcement has been made for a new model to be available any time soon. I also don't know if it will be called the Elk M2, Elk M1 Platinum, or what. (Although I'm pretty sure it won't be called Moose).

 

[sharby]

Hoping this is addressed in the M2...

Please say more about this "M2".

My general reference to the next generation Elk panel whenever that might occur. I don't think any announcement has been made for a new model to be available any time soon. I also don't know if it will be called the Elk M2, Elk M1 Platinum, or what. (Although I'm pretty sure it won't be called Moose).

Stick with the PowerHome automation software for the time being. It's solid and runs more then 50% of my rules. I'm working with Dave Howard on the UPB protocal spec and direct Aprilaire integretion so one can take advantange of the 2 way text messaging to the stats. Also, the PH software will be able to pull temperature stats in real time versus the "hit or miss" temperature updates that occur on a few of my production systems.

-=*Sharby*=-