Suggestions for the ElkRP rule 'language'

electron

Administrator
Staff member
Since Elk seems to respond to squeeky wheels, let's tell them what we would like to see changed/added to the rule language.

my requests:
  • It should be possible to trigger a rule by specifying something like "If [light/input/output] has been [on/off] for [at least|exactly] x [hours|minutes|seconds]". I realize you can work around this by using timers etc, but not having this makes it extremely inconvenient, and just makes it harder to 'understand' the rules when you haven't touched the programming for a month or so. I am pretty sure this would make many people happy.
  • There's more, but will post those later B)
*squeek*
 
Funny you should post that Electron. I was playing with mine just last night and was thinking the same thing. I had been waiting for the Insteon support to come out, but decided to setup x10 addresses and tie the lighting into the elk (I had installed it awhile back).

Now, it seems the surge suppressors or other equipment in my wiring close makes x10 all but impossible (I tried a tabletop controller on that circuit as well) but I did go through the same thought process you did. Since Insteon support is supposed to be released soon I'm holding off on this (not sure if it's worth it to start playing with FilterLinc's and the like if I'm going to use Insteon).
 
Elk needs a feature like the standard outdoor motion detector floodlights have:

Turn light on when motion detected and leave it on for X minutes after motion stops.

You can do this via two methods now:
1) repeatedly flood the power line whenever motion detected turning on a light that is already on
2) have the motion turn on an output, then the output indirectly control the light. But this is ugly, error prone and takes extra rules.
 
Keep in mind how the Rules Engine works, everything is triggered from an event occurring. For a Rule to fire from something being ON for a period of time requires a timer on an output or lighting device to expire. At least on this version of the Rule Engine!!

Your request are well taken and logged.



PS: Le M1 ne parle pas francais!!
 
I agree with Spanky, a true ladder logic rules engine is fired from events that are, ideally, visible to any routine. The feature that Electron is asking for would actually be a kind of macro that would compile to lower level code reserving a timer resource to be set by the initial condition and then trigger the second action when the timer expires. This is how slightly higher level languages like the one on the JDS controllers work. I would much rather have access to the raw timer itself in such applications since it allows you to do things like retrigger it (start the timing interval over again) or end it prematurely by totally different triggers. This is how the Ocelot works (and presumably the Elk) and is how most other true ladder logic controllers would (and should) do it.
 
It seems like ELK would have to have a timer assigned to every device and have the timer reset after an "on" or an "off" type command. This would give us the ability to set events like if zone1 is inactive for 30 minutes turn on light1 for 15 minutes with out creating the timers and the tiggers for the timers. This would also come into use in the GUI applications, we could see the light in the kitchen has been off for 30 minutes or the motion sensor in the living room has not been triggered for 2 hours.

This disadvantage is the M1 is running out of room and timers take up space and resources.
 
It wouldn't be such a problem if you could organize the rules a little better. I wouldn't want to do away with timers etc either, but it would be a nice option.
 
FYI: Every Output, 208 of them, and every lighting device, 256 of them, have a timer. Lots of timers to do stuff with.
 
Guy Lavoie said:
I would much rather have access to the raw timer itself in such applications since it allows you to do things like retrigger it (start the timing interval over again) or end it prematurely by totally different triggers.
Adding a higher level of abstraction doesn't necessarily mean you have to remove the lower levels.

As Guy said, there are certainly a lot of things you can do at the lower level that could not be anticipated in a higher level feature, so you would never want eliminate direct timer access. But this doesn't preclude having a timer allocated and managed from a higher level construct at the same time.

Wayne has a good example of a timer being allocated, initialized and re-triggered from a single rule:
Turn light on when motion detected and leave it on for X minutes after motion stops.
This does not stop you from re-triggering or re-initializing the timer directly in another rule (as long as you knew how to address that timer).

The only additional resource it uses is code space within the rules engine.
 
rocco said:
Wayne has a good example of a timer being allocated, initialized and re-triggered from a single rule:
Turn light on when motion detected and leave it on for X minutes after motion stops.
This does not stop you from re-triggering or re-initializing the timer directly in another rule (as long as you knew how to address that timer).
Isn't this possible already? At least for managing outputs:

WHENEVER Hall Motion (Zn 5) BECOMES NOT SECURE
THEN TURN Output 004 (Out 4) ON FOR 20 MINS, RESTART TIMER IF RUNNING

The RESTART TIMER IF RUNNING part is not available when controlling lightning. Looks like this is what need to be fixed.
 
Yes, it is possible, provided you add the rules to control the lighting based upon the output. Since outputs above 16 cannot be named, it is totally up to the user to keep track of what output is mapped to what light, which is error prone.

The ability to restart the timer when controlling lighting directly MIGHT be nice, but I wouldn't use it. The problem is that controlling the lighting directly can flood the powerline or airwaves with a lot of un-needed commands. Since many security motion detectors can fire every 4-5 seconds, you can be turning a light on 10 times a minute for no reason. Turning an output on, doesn't generate any PLC or RF activity.

If you add an "and light is of" clause, then the timer never gets reset, so the light will blink off until the next motion turns it back on. Wifey would not like the lights going off briefly every 3 minutes. :lol:
 
I have been programming high level languages for so long that sometimes is difficult to keep the simple and elegant ladder logic mentality.

One of my major challenges with the M1 are the rule limits regarding the handling of analog zones. Analog zones do not trigger events the way that other zones do. You must use trigger (like time) and perform the test on the analog input. If you want your trigger to launch only once when the analog zone reaches certain value then you have to use a counter to prevent the condition from being evaluated true in every pass. Per instance:

WHENEVER EVERY 1 MINUTE
AND Light Level (Zn 14) IS LESS THAN ANALOG VALUE 0.5 VOLTS
AND LL Flag (Counter 5) IS NOT EQUAL TO 0
THEN ANNOUCE Light Level (Zn 14)
THEN SET LL Flag (Counter 5) TO 0
THEN DISPLAY "Sunny^M" IN Area 1 (Area 1) FOR 60 SECONDS, [*] Clears

This seems real complicated, but this is the way that Elk decided to implement it. The explantion that I have seen is to prevent the trigger from being launched repetively. It makes sense - seems some of us might force the M1 into an infinite loop by using analog zones.

I think that the problem can be fixed by adding a new functionality to the analog zones definition screen. We need to be able to define test values for an analog input. Just like a typical burglar alarm have 3 test values bands (Open circuit, EOL and short circuit).

Per instace, when defining my the zone for my light sensor I would like to define these test bands:

MIN - 0.5 VOLTS -> A (Sunny)
0.5 - 5 VOLTS -> B (Cloudy)
5 - MAX -> C (Dark)

Then the rule would be much simpler:

WHENEVER Light Level (Zn 14) BECOMES A (Sunny)
THEN ANNOUCE Light Level (Zn 14)
THEN DISPLAY "Sunny^M" IN Area 1 (Area 1) FOR 60 SECONDS, [*] Clears

The flag is not needed, because the rule uses BECOMES, so it will be triggered only once.

This is one way of simplifiying usage of analog zones that works for what I'm doing. I'm sure that there are other simpler and may be more complex ways of doing it - as applies to other implementations.

Guy, you are thr ladder loggic expert. What have you seen in other PLCs?
 
With the Ocelot you don't have to set up a "rule" to have it check for a condition every "x" minutes as it continually scans the CMax code, then performs a conditional action when it becomes true.
 
Back
Top