Problem with Elk Counters when using as a countdown timer

[TrojanHorse]

Is there a known issue when using the Elk Counters as timers and decreasing the value every second?


There's an old post here (http://cocoontech.com/forums/topic/16687-counters-timers/?p=140463) where @wuench says "As mentioned above you don't want to use counters as timers, you want to use phantom outputs.", which I'm starting to agree with, although it conflicts with some Elk examples here (https://www.elkproducts.com/using_counters.html)


Oddly, I had a problem before when I was using counters to monitor whether a zone was violated for more than 45 seconds and speak a message over the speakers and repeat every 45 seconds. If I had the counter start at 0 and count to 45 I would get unusual results (triggering at not always 45 second increments). If I started at 45 and counted down to 0 it worked as expected (similar to the Elk examples linked above). Perhaps this should be a clue to me and others, although it seems it really shouldn't matter whether I count up or down to a certain value.


Anyway, I have a more important set of programs that open gates if a fire or CO alarm is active for more than 60 seconds (the 60 second delay is to allow us to turn off a false alarm if appropriate before gates open). Randomly in the middle of the night when we were away these programs triggered. These programs have been stable for more than 6 months since initially set up. I'm suspecting an issue with the counters. Any ideas?


I'm pasting the programs below, basically I'm setting a counter to 60 upon Fire or CO alarm, decreasing by 1 every second, then when the counter is 0 trigger an output and send me a message so I know the program ran. Bottom line seems to me that if there was no fire or CO alarm active (there wasn't and there are no other events in the log), then the outputs should never have triggered and I shouldn't have received the email messages from these programs. The counters are not used in any other programs.


Any thoughts? Why are some people here saying not to use counters this way when Elk suggests it's okay with examples. I can use a phantom output instead but wanted to better understand what's going on here. It certainly seems like there is an issue with using counters this way...


Relevant Elk Rules:
Count how long fire alarm has been active
WHENEVER ANY FIRE ALARM TURNS ON
THEN SET FireCOsec (Counter 1) TO 60


Count how long CO alarm has been active
WHENEVER ANY CARBON MONOXIDE ALARM, ANY AREA TURNS ON
THEN SET FireCOsec (Counter 1) TO 60


Subtract one from counter every second the fire alarm has been active
WHENEVER EVERY 1 SECONDS
AND ANY FIRE ALARM IS ACTIVE
THEN SUBTRACT 1 FROM FireCOsec (Counter 1)


Subtract one from counter every second the CO alarm has been active
WHENEVER EVERY 1 SECONDS
AND ANY CARBON MONOXIDE ALARM, ANY AREA IS ACTIVE
THEN SUBTRACT 1 FROM FireCOsec (Counter 1)


Open Both Gates if fire or CO alarm active for 60 seconds
WHENEVER FireCOsec (Counter 1) CHANGES TO 0
THEN TURN FIRE North Gate (Out 38) ON FOR 2 SECS
THEN TURN FIRE South Gate (Out 34) ON FOR 2 SECS
THEN SEND EMAIL MESSAGE 3 TO me (Email 3)
THEN SEND EMAIL MESSAGE 4 TO me (Email 4)
THEN SET FireCOsec (Counter 1) TO 60


Reset the counter once the fire alarm is turned off
WHENEVER ANY FIRE ALARM CUTS OFF
THEN SET FireCOsec (Counter 1) TO 60


Reset the counter once the CO alarm is turned off
WHENEVER ANY CARBON MONOXIDE ALARM, ANY AREA CUTS OFF
THEN SET FireCOsec (Counter 1) TO 60

 

[mikefamig]

I've used both counters and phantom outputs as counters. Make certain that you reset your counter to zero after each use.
 
Mike.

 

[mikefamig]

"Randomly in the middle of the night when we were away these programs triggered. These programs have been stable for more than 6 months since initially set up. I'm suspecting an issue with the counters."
 
Could there be something else triggering this event in the middle of the night? Why do you suspect the counters? Are the sensors wireless?
 
Mike.

 

[TrojanHorse]

"Randomly in the middle of the night when we were away these programs triggered. These programs have been stable for more than 6 months since initially set up. I'm suspecting an issue with the counters."
 
Could there be something else triggering this event in the middle of the night? Why do you suspect the counters? Are the sensors wireless?
 
Mike.

 
Thanks for your responses.  I'm certain there's nothing else triggering these events.  This counter is only used in these rules, which I triple-checked by printing from ElkRP to PDF and searching the text.
 
I'm suspecting the counters based on, well, this odd behavior and also Wuench's old post saying not to use counters this way.  I also had unexpected results when I used counters to count up, rather than down to 0.  That's actually the reason I added the email notification to these rules, so I would know if the rule actually fired, or if there was something else (perhaps a short in the wiring) that would have caused the gate to open (effectively the "THEN" in the rule...)   When I was counting up, rather than down to 0, the rule was, I guess, "unstable".  It would trigger when it should, but also randomly when it shouldn't - so I added the email notifications.
 
So, counting down from 60 to 0 seemed to fix that problem for months, until now.  Counting down rather than up also fixed a problem that I had when I was announcing a violated zone every 45 seconds.  I sat there with a stopwatch and the rule wasn't consistently doing what it should every 45 seconds.  So I now can't help but believe that there's some issue here.  Maybe Wuench will chime in at some point to explain his comment from years ago.  He seemed to be pretty certain about his position on the issue but didn't really explain why.
 
To be clear, the relevant sensors are smoke / CO detectors or could also trigger from a heat detector.  They are all hardwired.  The only way it should trigger is when the counter is at 0, which should only happen after 60 seconds of a fire or CO alarm.  
 
I know there was no fire alarm, since the central station would have been notified, it would be in the logs, and I would get a text, etc.  
 
Note: I went back to edit my original post since when I came back here looking at it for some reason it was all one long paragraph, so I added extra line spacing.   If you haven't yet taken a close look at the rules, they're pretty simple and it seems to me if there was no fire alarm the counter should never have gotten to 0...

 

[AnotherOne]

I spent multiple days talking to ELK about my problems with counters.  I even bought a new M1G after they said it must be a hardware problem with my 7 year old M1. 
This was with firmware 5.3.10.  I never had a problem with 5.2.10 but had to upgrade when i got a new ethernet module.
 
The new M1G had the same problem - just longer before it triggered.  Output 40 would NOT BE SET ON, but I would get "stuff" over my serial port (which turned on\off lights).
 
The rules that caused the problems were of the form:
 
whenever output 40 is on
  then set counter 7 to 1
 
whenever every 1 seconds
  and counter 7 is not equal to 0
  then add 1 to counter 7
 
whenever every 1 seconds
  and counter 7 is equal to 4
  send "stuff" through port 1
  set counter 7 to 1
 
whenever output 40 is turned off
  set counter 7 to 0
 
 
I now use outputs to accomplish the same thing and have never had a problem and have eliminated all use of counters.

 

[RAL]

I spent multiple days talking to ELK about my problems with counters.  I even bought a new M1G after they said it must be a hardware problem with my 7 year old M1. 
This was with firmware 5.3.10.  I never had a problem with 5.2.10 but had to upgrade when i got a new ethernet module.
 
The new M1G had the same problem - just longer before it triggered.  Output 40 would NOT BE SET ON, but I would get "stuff" over my serial port (which turned on\off lights).
 
The rules that caused the problems were of the form:
 
whenever output 40 is on
  then set counter 7 to 1
 
whenever every 1 seconds
  and counter 7 is not equal to 0
  then add 1 to counter 7
 
whenever every 1 seconds
  and counter 7 is equal to 4
  send "stuff" through port 1
  set counter 7 to 1
 
whenever output 40 is turned off
  set counter 7 to 0
 
 
I now use outputs to accomplish the same thing and have never had a problem and have eliminated all use of counters.

What did you use to turn output 40 on and off?
 
Looking at your rules, it seems like you are trying to create a 3 second delay before sending out "stuff."  You then set the counter back to 1, and it will start counting again and repeat sending the stuff after another 3 seconds?  Was the to ensure that whatever "stuff" was doing, it caused output 40 to turn off?
 
One thing I have seen in other programmable systems that attempt to do real-time tasks is that due to other priorities, sometimes things don't execute as you expect.  For example, with your Then clause that checks for counter = 4, it might not get executed every 1 second as you expect.   A higher priority task might delay the rule until the counter has incremented again, and now it equals 5, and your Then clause never gets executed.  So best to write the rule as When counter is greater than 3, rather than equal to 4.

 

[TrojanHorse]

AnotherOne -
 
Thanks for your input.  This suggests to me that there is a problem here.  I was having more problems when I was counting up, rather than counting down like I tried instead.  I noted that Elk's example counted down rather than up and it helped but it still wasn't 100% reliable so I've switched to timed outputs instead.  I guess it's good and bad to know that I'm not alone here...  I'm really starting to believe there is some type of problem with using counters as timers.  
 
RAL -
 
Thanks for your input as well.  I hear your point on the competing priorities and you make a good general point about <> rather than =.  Yet I still think it's reasonable to assume that this should work, and I'd note that my set of rules was simpler in the sense that there was more time elapsed.  And in my example, nothing should have been decreasing the counter to 0 when the Rule triggered the THEN.  But they didn't work as they should.  
 

I spent multiple days talking to ELK about my problems with counters.  I even bought a new M1G after they said it must be a hardware problem with my 7 year old M1. 
This was with firmware 5.3.10.  I never had a problem with 5.2.10 but had to upgrade when i got a new ethernet module.
 
The new M1G had the same problem - just longer before it triggered.  Output 40 would NOT BE SET ON, but I would get "stuff" over my serial port (which turned on\off lights).
 
The rules that caused the problems were of the form:
 
whenever output 40 is on
  then set counter 7 to 1
 
whenever every 1 seconds
  and counter 7 is not equal to 0
  then add 1 to counter 7
 
whenever every 1 seconds
  and counter 7 is equal to 4
  send "stuff" through port 1
  set counter 7 to 1
 
whenever output 40 is turned off
  set counter 7 to 0
 
 
I now use outputs to accomplish the same thing and have never had a problem and have eliminated all use of counters.

 
 

What did you use to turn output 40 on and off?
 
Looking at your rules, it seems like you are trying to create a 3 second delay before sending out "stuff."  You then set the counter back to 1, and it will start counting again and repeat sending the stuff after another 3 seconds?  Was the to ensure that whatever "stuff" was doing, it caused output 40 to turn off?
 
One thing I have seen in other programmable systems that attempt to do real-time tasks is that due to other priorities, sometimes things don't execute as you expect.  For example, with your Then clause that checks for counter = 4, it might not get executed every 1 second as you expect.   A higher priority task might delay the rule until the counter has incremented again, and now it equals 5, and your Then clause never gets executed.  So best to write the rule as When counter is greater than 3, rather than equal to 4.

 

[RAL]

But they didn't work as they should. 

I agree that there is a bug in the rules execution.  But I've seen enough cases in my job over the years to understand how difficult it is to get things right in a system that has to respond to both time-based events plus asynchronous events.  I wish the M1 would process the counters correctly, but I am not surprised that it doesn't always work right.  Sometimes, you can find a way around it by writing the counter rules differently.  And other times you just have to do things a different way, such as by using timed outputs.
 
Maybe one of these days, Elk with actually fix the problem.

 

[hgupta1]

UGh.. I wish I saw this post earlier.  I struggled with the same thing -- using counters as timers to control my driveway gates,  but for me it was causing random reboots.   I too was suckered into buying a whole new control panel thinking that it would resolve the issue.  Have you had any issues since you stopped using counters?

 

[aalarms]

Old thread.....but use the less then 1 in your rule! Not and exact number!

 

[hgupta1]

Old thread.....but use the less then 1 in your rule! Not and exact number!

Does this resolve the issue?  I haven't gone back to revise my rules yet.  

 

[wmahvd]

Although over a year later, thought I'd add my two cents.... I use several counters in countdown mode in various rules, but I always check for a zero value before decrementing. I'm not sure what Elk rules do when decrementing a counter value of zero, but in other programming contexts it often just keeps going (rolls over to max value if unsigned, goes to -1 if signed). I've never had an issue and the rules seem very reliable. I use them for both timers and for generating pseudo-random times for turning lights on and off when we're not home. I did have an issue once when writing a set of rules to control a space heater in the kitchen, triggered by both GE motion sensors and an insteon thermostat, and I wanted the heater to run for ten minutes when first warming up the kitchen in the morning, and thereafter only running for three minutes per trigger (or something like that - it was a long time ago). Point being that to do that in Elk rules I needed to use a couple of counters but when a certain trigger in one of the rules occurred, the M1 would crash. Every time, in exactly the same place. I don't remember the details any more but I gave up trying to get it to work. This of course was a bug - regardless of how the counters are being used (or mis-used) the control shouldn't crash. I recall reading another post after that describing a similar problem, I'm hoping that the issue was found and fixed in later firmware (I'm still at the same 5.1.20 version but I'm getting ready to upgrade).  Cheers.