Counter question: Why doesn't thins work?

[SJK]

I'm not understanding why this works:

 

If  $State_X is not 0 

Then Repeat While $State_X >0, Wait 1 second, $State_X -=1

 

as does

 

$State_X is not 0

Then Repeat While $State_X <0, Wait 1 second, $State_X +=1

 

BUT

 

$State_X is not 0  Then Repeat While $State_X >0, Wait 1 second, $State_X -=1

Else Repeat While $State_X <0, Wait 1 second, $State_X +=1

 

does not? The last example will count down, but not up.

Thanks.

 

[MrBill]

For one thing, anytime $State_X is 0, Else will run.

If you're seeding $State_X as -5 expecting the Else to run that won't happen the only time else will run is when $State_X = 0.

There really is no way to make a single program that will count up if the number is negative and count down if it's positive.  There are several methods with 2 programs, I'd stick to the first two since they are simple. 

A more economical method is:

If  $State_X > 0 

then
   wait 1 sec
   $State_X  =- 1

and 

If  $State_X < 0 

then
   wait 1 sec
   $State_X  =+ 1

The difference is that each time $State_X changes using your method both the 'repeat' condition and the 'if' condition are reevaluate.   Since the If is re-evaluated anytime a state variable changes value no repeat is needed.

Watch out how many programs like that you have running, they eat processing time.  State Variables are nice but they do have more overhead than an integer variable.

Keep in mind that both programs are running when $State_X  has any value other than 0, while positive the count down program is running Then and the Count Up Program is also running the empty Else clause with every change of $State_X

What's the over all goal? why are you wanting to count a signal variable up or down if it's not zero?

Edit: just noticed this is posted in the ISY on Polisy section, if you're really running on Polisy hardware the "don't have too many of these" warning is likely not important.  Polisy hardware is much faster than the original 994 hardware.  Many would make for an interesting hardware load test tho...

 

Edited November 14, 2021 by MrBill

[SJK]

Thanks.  Wasn't clearly thinking that one through. In general I rarely use else actions outside of "if this happens, then set variable to one/true, else set same variable to zero/false."  It was an attempt to cut down on the number of programs to maintain.  It works fine as separate programs, one count down, one count up.  Given this is a large installation, and that I use small simple programs to set variables rather than directly manipulate devices, it gets complex fast.

For those interested, the positive/negative state value is a new thing I'm trying in this house to decrease the number of state variables in play.  In this case, what I'm doing is using a state variable for each room to track occupancy for lighting (there's a separate one for the HVAC delay). I have an integer variable to set the vacancy delay in seconds (minutes for the analogous HVAC variables). If the motion sensor is violated, I set the state timer to the integer declaration, a positive number. That's done in a separate simple program, one for each motion sensor. Then this timer program counts down to zero. Zero is my convention for a vacant room. So if there is continued motion, then the timer keeps resetting to the delay. Once the delay is able to reach zero, the room's been vacant for at least that length of time, and it's time to turn off the lights.  A third program turns on the lights if the room occupied state variable is >0, if they're not already on. A fourth program is looking for the state variable to be zero, after which the lights are turned off (via the room scene). Yet another program determines if any lights are on in the room (as there may be multiple, and may be in a different scene) and sets a second state variable which tracks lighting on/off in the room.

Sounds complex. But- there's an advantage.  I can use another program to watch for manual lighting control.  Turn on any of the lights in the room manually, set the lighting state as on, and set the delay timer (Same as motion, or a different value if desired). Turn the lights off manually, and set the lighting delay state variable to a negative number. That means the lights cannot turn back on until the state is zero again. Previously I had to set up a different state variable altogether to track that. That way you can turn off the lights, and take a bit to leave the room without the lights going back on as your exit motion re-triggers the lights. Here, I can even set a long off delay via a large negative assignment if a fast off is detected. That's essentially an override switch (I beep the keypad so you know you did it) that auto-expires rather than requiring you to remember to disable the override later when you wonder why the lights are not responding like you expect.

So 2 state variables and two or three integer variables per room allows me to manipulate lights in a very flexible manner rather easily. As I add or adjust the system- adding switches or lights, convert more rooms to motion sensors, etc., all I have to maintain is the program which tracks lighting on/off state and the scenes themselves. If I want to adjust delays or the like, all I need to read is the integer variable page. And I can troubleshoot/visualize what is going on easily by doing something then watching the state variable page.

I used to do this differently in the past with other locations. But I'm starting from scratch here, so I'm trying a new tactic with the negative numbers and force ons/offs.  It's actually less state variables than the alternatives and a bit easier to parse.  And I'm on polisy for this home, so I don't feel limited with processing power. Only a couple of timers are ever running at the same time- one for each occupied room per person not in the same room as others. That said, I've not had problems with using over 100 state variables on the ISY994is I've used either. Response times are good. The perceptible delay is and always has been motion sensor -> action which is because of the components involved: Elk response time/resolution, ISY notification over network via Elk M1EXP, then action. The new nodeserver-based interface is pretty good but seems to be slightly slower than the old ISY module (but that's just perception), probably due to adding another component to the chain- the nodeserver itself..