using "is not" in a control program

[oberkc]

apostalakisl, dnl,

 

don't get too hung up an this particular program example to conclude there is no value in this particular control condition. I created this program just to verify a theory. There is no practical application intended. But both of your conclusions are the same as mine, however: this particular sets of conditions has a pretty limited appeal.

 

Consider, however, something such as:

 

time is from sunrise to sunset (next day)
or
control 'xxx' is not switched On 

 

This simple change in conditions give a much broader set of possibilities. I think the possibilities are limited only by our imagination.

[Sub-Routine]

A difficult parameter to understand.

 

Watching for On or Not On is a paradigm. It will certainly make things easier to create separate programs.

 

Imagine a switch that can only be On or Off. No dimming. Like a Motion Sensor.

 

If
       Control 'Outside Lights / Backyard Sensor' is switched On
   And Control 'Outside Lights / Backyard Sensor' is not switched Off

Then
       Set Scene 'Backyard Motion' On

Else
       Set Scene 'Backyard Motion' Off

 

Other than the simple On/Off you will need a separate program with the other Conditions.

 

Rand

[apostolakisl]

Here is the most important unique feature that I can see with the "control is not"

 

It evaluates to "true" when nothing is done to the switch.

 

In other words, if something else triggers the program it will evaluate as true (this is why it worked the same in the "and/or" situation previously discussed). This is in contrast to "control is" which evaluates as "false" when something else triggers the program and no action is taken at the switch.

 

I am not sure how to use it exactly, dnr had pointed out that the there is no use for a statement that is always "false" (I agree), but we were wrong, this can be "true".

 

I have a feeling that you could use this feature to turn what otherwise would have been two programs into one. It would probably not be worth the confusion, however, unless you were just super awesome ISY programmer.

[Sub-Routine]

Here are some Wiki links:

 

ISY-99i/ISY-26_INSTEON:Scope,_Precedence_and_Execution_Order

 

ISY-99i/ISY-26_INSTEON:How-To_Guide#Programs

 

Rand

[Goose66]

Its "use" seems to be limited to create trigger events for a program with the evaluation of the corresponding IF statement forcing programs into the ELSE branch.

 

This is the epitomy of the confusion caused by combining trigger events and IF conditions into a single statement.

 

Since ELSE branches are basically useless in the ISY model, I agree with Rand that two programs is a simpler and more effective approach. I think most "super awesome ISY programmers" would agree, as well.

[dnl]

Hi All,

 

I think I have only one more comment on this.

 

The ISY programming model is what it is and we either learn how to use it or we move onto something else. I am new but I like what I have seen in the ISY and look forward to learning how to use it more intelligently.

 

This particular condition is a disappointment, however, because it is not what it could have been. Had it provided what many thought it did, there would have been a variety of immediate applications that many (all?) could have understood and used. The only way I believe we can do what we thought this condition might do is to use several conditions -- not the end of the world of course but disappointing.

 

As it is, however, this condition provides a function that is difficult to understand and, to me at least, is misleading. I think that is born out by the length and content of this thread.

 

There is a certain intellectual enjoyment in discovering how things work but ultimately I want to use the ISY for practical applications. My opinion may change but as of this moment I would not use this particular condition because it I am likely to forget how it really works and I will not use it correctly. If others can find good uses or have the ability to use it well, more power to them.

 

Is there any chance UD will provide a condition that provides what we thought this one did? which is to signal False or True when a device command is received that is or is not, respectively, what is specified in the condition. If so, I think the world of ISY programming will have improved.

[apostolakisl]

Actually that was me with "super awesome ISY programmer" comment.

 

Anyway, I thought I would summarize this "control is not" and compare to "is".

 

Tiggering

"control is" and "control is not" both act as triggers for a program exactly the same. For example, "if switch xyz is (or is not) switched on" acts as a trigger only when the switch is physically acted on by pushing "on".

 

Evaluation

1) When the "control is/is not" statement is the trigger

- "is" evaluates to true

- "is not" evaluates to false

(keep in mind that only physically acting on the switch in the way listed (ie "on") is a trigger, any other action on the switch is not a trigger and the program will sit idle short of some other independent trigger.

2) When something else triggers the program

- "is" evaluates to false

- "is not" evaluates to true

(keep in mind that the status of the switch is irrelevant, on/off/dimmed/whatever. . .no difference)

 

Simply put, "is" and "is not" behave exactly the same except the outcome (true/false) is opposite.

 

So, it seems the usefullnes of an "is not" statement is to have the program evaluate to the opposite state as an "is" statement when presented with the exact same trigger.

 

In a single line program simply swapping the "then" contents with the "else" contents is functionally identical to swapping "is" with "is not".

 

In a multi-line program it might be easier to get the outcome you want using "is not" so that your "true/false" outcome more easily jives with the "true/false" outcome of the other conditions.

 

I can not think of a situation where "is not" allows for an ultimate outcome that you couldn't get to in some other way, but, there it is, use it if you like it.