Device on, and device is not off as if statement

[adamthp]

I've seen a few example programs lately that use 'if device a is on, and device a is not off' as the trigger statement. Could someone explain the reason for the two conditions? It seems like if the device is on.. then it's not off right? Am I missing something, or is there some advice on the matter? 

Thanks

[simplextech]

Use of the "is not off" comes into play with Dimmers.  

• On = 100% 
• Off = 0%
• What's 42%?  Not On but Not Off...

[mwester]

The two conditions work together with the "then" and "else" clauses.  Consider the following pseudo-code, two programs, one of which handles the event that is triggered when a button is turned "on", and the other handles the "off" case:

 

if switch is switched-on
  then lower blast shields

if switch is switched-off
  then raise blast shields
 

In the above two programs we see a very simple and very understandable flow.  There's a single event (and it's clear which it is), and only an if clause -- this is the fundamental way event-based logic works.  I use the above almost everywhere, because it helps me understand the program logic and how the ISY is really doing things.  However, some prefer to conflate the two programs above into one single program.  In order to do that, we need to make use of two triggers (the "on" and the "off"), and we need to use the "then" and the "else" to sort out which trigger it was.  Clear as mud?  I think so, which is why I avoid this conflated construct.  But for those who prefer, here's how we would construct this using both triggers, and using both then and else clauses:

if (switch is switched-on
     or switch is NOT switched-off)
  then lower blast shields
  else raise blast shields

By mentioning both triggers in the if, we cause the ISY to run this logic on either of the two triggers.  If we were to specify a simple "or" without the "NOT", it would sort of work - the problem is that if we did so, then either event (turning on, or turning off) would lower the blast shields... we don't want that.  Hence, we invert the sense of the "off" event.  The result is that when the ISY evaluates the logic, depending on which of the two events triggered it, it will run either the "then" or the "else" clause.  Confused?  If so, that's good!  Because this sort of conflation of event-based logic into traditional coding logic doesn't work well -- it's like pig-latin, it might sound like programming, but it requires one's brain to do mental gymnastics (and, I'll add that even without knowing the internals of the iSY, I think it safe to say that the translation of this odd coding to the underlying event structures has to likewise be non-trivial, and probably involves simplifying complicated multi-trigger constructs like this into multiple simple event-based bits of code internally).

So, if you get it, good!  If not, no worries, because if you code as I did in the first example, you're not losing anything at least from the perspective of the ISY. 

Some will argue that conflating the triggers into a single program is better for humans, because it makes sure when edit and change things that you can see both the "on" and "off" event logic in one place -- that is true.  On the other hand, doing so requires the sort of "if" clauses that make no logical sense unless you rewrite them in your head (or sometimes as I have to do, on paper) -- and I'd argue that there's just as much chance of mistakes with those strange and odd "if" clauses as there might be by having the "on" and "off" logic in two different programs.  To each their own...

[adamthp]

I feel like Wesley in that scene in the princess bride with iocane powder. 

I surprisingly understand completely. Thanks for taking the time to explain. 

[larryllix]

2 hours ago, adamthp said:

I feel like Wesley in that scene in the princess bride with iocane powder. 

I surprisingly understand completely. Thanks for taking the time to explain. 

OTOH. Knowing that he kwen that you would know.....He spent years building up an immunity to blast shields. Better not go there.

....as you wish!