What is the differene between 'Status' and 'Control' under Conditions?

[rlanza1054]

Hi all,

 

Just reading some programming examples and gotten myself confused as to when to use Status and when to use Control under the Conditions tab.

 

I was attempting to use Status to determine when something was on or off but in the programming explain on WiKi, they used 'Control' instead of Status.

 

Some it made me wonder when do you use Status and when do use Control?

 

Thank you!

 

Rob

[oberkc]

Mostly, I would describe the difference as what causes the two conditions to trigger and force an evaluation of the condition in which they are included. 

 

STATUS will trigger an evaluation upon any change in status, and for any cause of that change.

 

CONTROL will trigger an evaluation only upon receipt of the specified command  and ONLY when that command is initiated from the specified device.  For example, CONTROL DEVICE X IS SWITCHED ON will trigger only upon receipt of an ON command from DEVICE X.  

 

Another factor is that, for condition evaluation purposes, STATUS will yield TRUE any time the specified device matches the stated value.  CONTROL, on the other hand, will only yield TRUE when that specific condition is received (otherwise, it will yield a false value).

[stusviews]

CONTROL requires that the device be manually changed or changed using a direct command. The ISY can send a direct command to a single device as can a program. So can the sense wire on a Micro Module.

 

STATUS will be true even if another device causes the change such as a linked device (e.g., scene).

[LeeG]

rlanza1054

 

Some noted points need correction.  Using a SwitchLinc as an example ......

 

"If Control 'switchlinc' is switched On'

 

triggers Program with True Condition each time the On paddle is physically pressed.  If the SwitchLinc is already On and the On paddle is pressed the Program is triggered with True evaluation.   Tapping the On paddle three times (not fast enough to generate a Fast On) would trigger a Program three times each with a True Condition.

 

Sending an On command to the SwitchLinc DOES NOT trigger a Program with the above statement, must be a press of the On paddle.  The above statement NEVER triggers a Program with a False Condition.

 

"If Control 'switchlinc' is not switched Off"

 

triggers a Program when the Off paddle is pressed and the Condition is False because of the 'not'.   Same process applies if the Off paddle is tapped multiple times (not fast enough to generate Fast Off).  Each Off paddle tap triggers the Program with a False Condition.   Sending an Off command to the SwitchLinc DOES NOT trigger Program. 

 

 

"If Status 'switchlinc' is On"

 

triggers a Program with a True Condition when the SwitchLinc turns On.  This happens when the ON paddle is tapped that turns the SwitchLinc On; this trigger also happens when an On command (Scene or Direct command) is sent to the SwitchLinc that turns the SwitchLinc On.   

 

The Program is NOT triggered when additional On paddle presses occur nor is a Program triggered when additional On commands are sent to SwitchLinc.    

 

Unlike "If Control",  "If Status" also triggers a Program when Status changes.  If the checked Status (On in this example) does not match, the Condition will be False. 

 

 

It may seem complex but it really is not.  "If Control" requires a physical change initiated to the device itself.  "If Status" requires the "state" of the Switchlinc to change either physically by switch action or by command sent to device.

 

 

So, which do you code in a Program, which situation is the Program designed to handle.   Any change in 'state', paddle or command, use If Status.    Any change that must occur because device is physically operated, use If Control.     

[oberkc]

triggers Program with True Condition each time the On paddle is physically pressed.

 

One of the things that could be unclear is that CONTROL triggers a program each time pressed, but whether or not the program condition is true is based on the entire condition.  For example:

 

if

control switchlinc is switched on

and time is from sunrise to sunset

then

...

else

....

 

this program will be triggered each time the switchlinc is pressed ON, but would be false if outside the specified time range.  As as further point of clarification, this program will also trigger as sunrise and sunset, but will also evaluate as false, since there was no simultaneous receipt of an ON command from the switchlinc (both have to be true for the entire condition to be true).

 

Compare to status

 

if

status switchlinc is on

and time is from sunrise to sunset

 

this program would be triggered if the switchlinc changes status.  The program condition would be true when the switchlinc is changed to ON and between the specified times.  Unlike the first example, however, this program will evaluate as TRUE at sunrise if the switchlinc is ON.

 

Sometimes, one has to just practice with things.

[LeeG]

Great points.  My examples were in the context of using a simple "If Control" or "If Status".as they have the most basic rules for the individual statement and are the easiest to understand.    A complex If with multiple conditions, whether True or False depends on an evaluation of all Conditions in the If clause.  An iF clause can have a dozen statements, some Anded together, some Ored together, with parens to combine conditions.   I thought it best to present how the individual statement behaves before opening Pandora's box with a complex If.

 

 

DoorSensor - [iD 005E][Parent 0001]

 

If

        Control '2B.09.AE.1 - Door Open' is switched On

    

Then

        do something when door opened

 

Else

        the Else is never executed with this 'If Control'

 

 

 

DoorSensor - [iD 005E][Parent 0001]

 

If

        Status '2B.09.AE.1 - Door Open' is On

    

Then

        do something when door opened

 

Else

        do something when door closed

 

 

Sorry, the Status example got lost in the first post.

 

 

[rrathke]

Keep in mind that some devices do not report status changes in real time. This is especially true with z-wave devices.

[rlanza1054]

Wow, I had to read both authors very slowly, because at first, itas overwhelming. But as you explained it got easier to understand.

 

I was reading in wiki about the Motion Sensor programming examples.

 

I started to copy each of the examples into my ISY to try and get done what I am trying to do.

 

I did not (and still don't, not just yet) want anyone writing the program for me. I need to learn how to do this on my own.

 

When I run into issues I will be asking for help.

 

Which I am about to just to get past one of the problem's I was having in understanding of what is going on.

 

The specific page that I am reading is:

ISY-99i/ISY-26 INSTEON:Using Motion Sensors in Bathrooms

http://wiki.universal-devices.com/index.php?title=ISY-99i/ISY-26_INSTEON:Using_Motion_Sensors_in_Bathrooms

 

It was in those examples where I noticed the use of both 'status and 'control'.

 

It starts off with a basic example of having the ISY take toltal control of the Motion Sensor's actions on devices.

 

There are about 10 examples maybe more and each example after the first adds in a little more complexity of control of the Motion Sensor and the device you what it to control.

 

It pretty much goes over the complete list of options for programming with the ISY of ant device, the MS is just used as an example.

 

But in my case, its exactly what I am trying to write for.

 

As I said, I might have disappointed myself by copying the programming examples, but it is the way Steve and Michael suugested I do.

 

To break the full program down to very small macro programs.

 

Since I still think in logical programming, not event programming, they said to write the full program down in the logical very on paper then break down the program into the individual parts (very small macro programs). Each program testing for the many specific conditions of the full program.

 

I'm going to go off topic here but:

 

I realize that UDI is fast at work developing version 5.0 for the ISY.

 

I'll make a statement that I'm sure most will agree with, the ISY is not designed for average Joe, you do need to know what programming is all about and you need to have some technical background to be able to fully use the ISY.

 

I have some of both, less on the programminbg side.

 

I read that they are changing the GUI in version 5.0.

 

I would like to see some sort of visual programming be implemented for the 'average Joe people' (maybe in reality I am an average Joe). A drag and droip inteface.

 

I also think it there was a 'until' option in the condition area, it would make it easier to program. I know there is a 'wait' optopn, but that is a timed option. With a 'until' option, it would be easier to write a test for for condition because in most cases we are 'waiting until something happens', example: 'wait until button is pressed', 'wait until motion is sensed'.

 

Right now it takes many lines of code to get what one condition could do, until!

 

Am I wrong?

 

Am I wrong for wanting a visual programming GUI? Something that actually looks like a real flow chart.

 

Ok, back to my task at hand.

 

I am trying to get as much copied over and modified to use for my situation before I present it here and ask for further help.

 

So please bear with me while I get back to that, its getting too late to do much more tonight.

 

Thank you again, for the great explainations of my trying to understand 'status' ans 'control', I think I got it,

 

Rob

[larryllix]

....

 

Thank you again, for the great explainations of my trying to understand 'status' ans 'control', I think I got it,

 

Rob

I think of control and status as

 

Control is the signal sent from a device and status is the current state of a device.

So you can send and receive a "control On" signal as many times as you want but once the device has "status On"  it won't change anymore.

 

Event based programming is quite different than linear flow programming although we do use the latter inside our programs. It can give linear flow programmers a tough time at the beginning.

[rlanza1054]

OK, here is what I am reading and it really doesn't make sense to me.

 

Here is the part from the wiki reference that gives the examples of the Motion Sensor:

 

12. Program Main Bath Door Status Change - Enabled

If        Control 'Main Bath Contact.1' is switched Off    And Control 'Main Bath Contact.1' is not switched OnThen        Run Program 'Main Bath Door Status Closed' (Then Path)Else        Run Program 'Main Bath Door Status Closed' (Else Path)

In program 12 they are testing the door status but how are you testing for status when you haved something like:

      Control 'Main Bath Contact.1' is switched Off    And Control 'Main Bath Contact.1' is not switched On

What the heck is that providing?

 

Is the switch off and is the switch not on?

 

If the switch is off, why do you need to have that second line of is switch no on? Isn't the switch not on, the same as if swtch is off?

 

Confusing me totally.

 

What am I missing from this?

 

Thank you,

 

Rob

[LeeG]

An "If Control" statement DOES NOT have a False state.

 

If Control 'Main Bath Contact.1' is switched Off

 

is True (driving Then clause) when door is closed (sends an Off command).  Again, that statement has no False state.   It cannot drive the Else clause.

 

If Control 'Main Bath Contact.1' is not switched On 

 

can only be True because it is If Control (no False state) but since the 'not' is included it drives the Else clause when True (when On command sent).   This action of driving the Else when True is unique to If Control '....' is NOT switched  xx.

 

The net, when Off command is received the Then clause executes.  When On command is received the Else clause is executed because of the 'not' in the statement.

 

Note:  If Control DOES NOT look at Status of device.   If Control is looking at the command the device sends to the PLM/ISY.  If Status looks at the Status of the device.

[oberkc]

I'll make a statement that I'm sure most will agree with, the ISY is not designed for average Joe, you do need to know what programming is all about and you need to have some technical background to be able to fully use the ISY.

 

 

I would like to see some sort of visual programming be implemented for the 'average Joe people' (maybe in reality I am an average Joe). A drag and droip inteface.

 

When I see these types of comments, I often get a chuckle.  I am not even sure who is the average joe anymore.  Is this the person who is helpless if the car breaks down and extent of household repairs is limited to changing of light bulbs?  If so, then, yes, the ISY (and home automation in general) is probably not for such a person.  When I hear folks asking for a more "visual" interface, it saddens me a little.  Are these average joes the ones who cannot comprehend the written word and need pictures to understand things.  It seems so many of the instructions I see anymore are all picture-based.  Really!?  Are we that stupid that the only thing we can understand are pictures?

 

Part of the complications of programming is that computers are the ultimate engineer.  They will do exactly what you tell them to do.  Every time.  But the downside is that they will do exactly what you tell them to do, and no more.  One must be very specific.  I am not sure that visual approaches will solve this unless some flexibility is lost.

 

Enough of the political commentary...to your specific question....

 

What the heck is that providing?

 

If the switch is off, why do you need to have that second line of is switch no on? Isn't the switch not on, the same as if swtch is off?

 

 

The example program is a typical ISY example that is the solution to the question: if the switch is turned ON, to this....if the switch is turned off, do that.  THe reason you need both is because the first statement is triggered (event) only by an ON command.  The second is triggered only by an OFF command.  If you want a program to respond to both, you must include statements that are triggered by both.

 

To LeeG's response, I add that the CONTROL IS TURNED ON statement is triggered by an ON command.  The CONTROL IS NOT TURNED OFF is triggered by an OFF command.  When the first statement is triggered by the ON command, that statement is TRUE.  At any other time it is evaluated, it is FALSE.  When the second statement is triggered by the OFF command it is FALSE.  Any other time it is evaluated, it is TRUE. 

 

So, lets say somebody turns the switch ON, triggering an evaluation of the entire (two statement) condition.  The first statement is TRUE.  The second statement is TRUE.  Therefore the complete condition is TRUE (runs then path).  If somebody turns the switch OFF.  The first statement is false.  The second statement is false.  Therefore, the complete condition is false (runs ELSE path).

 

The reason such constructs are useful is that it allows (contrary to your observation) single programs to achieve what would otherwise take multiple programs.  Similar logic can be used to differentiate when a switch is turned ON from an OFF condition, versus when it is turned ON from an ON condition. 

 

As you get into this, it will become more intuitive.  It is, simply, one has to learn a new language.  It is necessary to understand precisely what is the meaning and consequences of each statement.   Fortunately, the vocabulary is limited.

[stusviews]

Dragging devices into scenes is visual. Beats entering the device's ID.

[oberkc]

Dragging devices into scenes is visual. Beats entering the device's ID.

Which is a great point.  Really, there is no typing when creating a program.  It may not be "drag-and-drop", but it is far from manual data entry.  That is kinda visual, yes?

[rlanza1054]

OK, before I finishing reading the full explainations, I have to say something.

 

I have a mild form of dyslixia, so reading these programming instructions are hard for me to follow.

 

In requesting a method of visual programming is a way for someone like me to aid me in the composing of the program.

 

But here is what might help me.

 

When reading these examples, to be able to actual watch a video, not necessairly showing the coding, But to watch what each step is actually doing.

 

I should tell you about myself, it takes me extra time to learn and comprehend certain things, but once I learn it, I will end up being on top.

 

But its taking me a lot of effort going from the linear programming to this event based programming. I have stated that programming wasn't my thing.

 

When you understand something, it easy to forget that someone else can't yet see what you do.

 

I took more classes in Unix, and hated every minute of it. It was designed for and by what they were called back in the day, Unix Priests!

 

Have you ever heard the term?

 

Oberic you wrote: "if the switch is turned ON, to this....if the switch is turned off, do that."

 

The actual line was: If switch is turned On, do this and if switcfh is NOT turned off, do that!

 

switch on and switch not off = the same thing in my world!

 

That is what I wrote, you answered as if it was: if switch is on and if switch is NOT on!

 

Am I mistaken?

 

Rob

[rlanza1054]

Dragging devices into scenes is visual. Beats entering the device's ID.

Yes, that is for scenes not the programkming of the logic, whether it be linear or event based.

 

Rob

[rlanza1054]

Which is a great point.  Really, there is no typing when creating a program.  It may not be "drag-and-drop", but it is far from manual data entry.  That is kinda visual, yes?

Yes! And maybe have a feature where you can watch what the program does in a virtual screen as you are programming.

 

There are many ways to bring more of a visual type of programming to the ISY.

 

Visual programming doesn't take anything away from what you do now, it just aids those that need it in a viual way.

 

Unless your goal it to keep it out of the hands from people that can't do programming. A very Unix Priest attitdue.

 

I never said to dummy down the actual function.

 

Do you remember the time when the MacIntosh came out, I do, DOS people hated working with the icons and drag and drop. They loved the text editor.

 

They looked down on people that could not figure out what 'ls' or 'grep' meant! Or in the DOS world 'dir' or 'rmdir'.  That somehow clicking and saying new folder or draging to the trash can did not accomplish the same thing.

 

Of course, draging a folder to the trash can is the same as typing 'rmdir C:/windows/system32/drivers/temp'.

 

That is what I mean by visual programming they both get done the same thing, one way is not less then other. But the visual way allowed the average Joe accomplish the same thing that the Priest was doing. The priest were very upset by it. They felt threatened!

 

Rob

 

PS I needed to add one more thing:

 

The ISY is sold with a warning, it not for those that are not technical. If one of the objectives it to sell more of this terrific device and get Home Automation into the masses, you are not going to accomplish that by making it only programmable to those with the know how, the priests!

 

On the other hard, it you want to keep the device only for the insiders, then keep selling it with that warning.

 

Rob

[LeeG]

Sorry, but 

 

If Control 'device' is switched On

 

is very different from

 

If Control 'device' is not switched Off

 

When using If Control statements the command received from device must match the command specified.  The If Control ...... is switched On triggers the Program ONLY  when an On command is received from device.   The If Control ..... is not switched Off triggers the Program ONLY when an Off command is received from device.   None of the other commands that may come from a device (Fast On, Fast Off, Dim, Bright, etc) have any affect on the Program.

 

The difference between the two If Control statements is which clause, Then or Else, is executed when the Program is triggered.  The If Control ..... is switched On drives the Then clause when On command is received.   The If Control ...... is not switched Off drives the Else clause when the Off command is received.   Driving the Else clause is the result of the 'not' keyword in the 'not switched Off'.

 

This action is very easy to prove.  Code a Program with If Control ....... is not switched Off.    Place an Action statement in the Then clause and a different Action statement in the Else clause.  Use Action statements that have a visual affect so the event trace will not be required.   Send as many commands from the device as you wish.   On, Fast On, Fast Off, Dim, Bright, and Off command.

 

The ONLY command that triggers the Program is the Off command and the Else clause will execute. 

[rlanza1054]

Hi,

 

i just read this from an old post.

 

It actual might have been you (Lee) that wrote it, but it made sense now.

 

This is the wording that was written:

 

"If a switch is turned on from off, a Status On occurs. If the switch is switched on again while it is already on, there is no status change"

 

If that is what you've been trying to get me to understand, I think I get it now.

 

One thing I realized when trying to explain things to people, if they are not getting it try another way of explaining it, just changing around the phrasing made it make sense now.

 

And your probably saying, but that's what I've said the whole time.

 

But is not what my brain was able to  comprehend, but having it said another way for some reason made it 'click'.

 

I also went back to reading the wiki.

 

I started to read 'understanding motion sensors' which is old because it referenced the old motion sensors that were out at the time, the X-10 motion sensors.

 

I had been reading 'using motion sensors in bathrooms', which I printed out to more easily read it. Or in other words, made it easier to read.

 

I am determined to get there, even if I cry along the way.

 

Thank you!

 

Rob

 

PS I hope you don't come back and say 'that is not what you were trying say'

[larryllix]

....

In program 12 they are testing the door status but how are you testing for status when you haved something like:

      Control 'Main Bath Contact.1' is switched Off    And Control 'Main Bath Contact.1' is not switched On

What the heck is that providing?

 

Is the switch off and is the switch not on?

 

If the switch is off, why do you need to have that second line of is switch no on? Isn't the switch not on, the same as if swtch is off?

 

Confusing me totally.

 

What am I missing from this?

 

Thank you,

 

Rob

Control statement are not two state. Statuses are two state.

 

Status can be On or Off

Control can be On, Off  or neither, Three states..

[oberkc]

Oberic you wrote: "if the switch is turned ON, to this....if the switch is turned off, do that."

 

The actual line was: If switch is turned On, do this and if switcfh is NOT turned off, do that!

 

switch on and switch not off = the same thing in my world!

 

That is what I wrote, you answered as if it was: if switch is on and if switch is NOT on!

 

Am I mistaken?

 

 

 I am concerned that you are, indeed, mistaken.  They are not the same in the ISY world.  As an aside, these statements are not a term of status...they are a statement of an event.  There is a "control" word as part of the statement that you omitted.  This is important.  Also, as you get into "status" statements (as opposed to "control" statements), consider the possibility that ON = 100%, whereas NOT OFF is anything over 0%.  This distinction can be important for dimmer switches.

 

Control Switch not off is triggered by an OFF command.  Control Switch on is triggered by an ON command.  That is one difference.

Control Switch not off is FALSE when triggered.  Control Switch on is TRUE when triggered.  That is another difference.

 

Take the simplest of examples...

 

if

control switch is not off

then

do something

else

do another thing

 

This program will be triggered (if condition evaluated) only when the switch paddle/toggle is turned off, and always when the switch is turned off.  It will NOT be triggered by turning the switch ON.  It will not be triggered by dimming or brightening the switch (if so capable).

 

Once triggered, the condition will be evaluated.  This particular condition will ALWAYS evaluate as false when triggered.  It will never evaluate true.  Since it will never be true, it will never do something.  Since it evaluates false, it will only do another thing.

 

Compare to this program...

 

if

control switch is turned on

then

do something

else

so another thing

 

This program will be triggered only when somebody presses the switch ON (compared to OFF in the prior example).  It will not be triggered by turning the switch OFF.  It will not be triggered by brightening or dimming.  Once triggered, the condition is evaluated and will ALWAYS evaluate TRUE.  Since this program is only triggered by an ON command, and when triggered, always comes back as TRUE, this program will never do another thing.  It will only do something.

 

Combining the two statements into a single IF condition...

 

if

control switch is on

and control switch is not off

then

.....

else

.....

 

Such a program will be triggered by BOTH ON and OFF commands from the switch.  The condition is evaluated when triggered, regardless of whether by an ON or OFF command.  Once triggered, the evaluation results will be based on both statements.  This is where it is useful to understand basic logic statements.  In this case, you have two statements (calling them statements A and B, for brevity sake).  If A and B are true, then the condition is true.  If A is false, the condition is false regardless of B.  If B is false, the condition is false, regardless of A.  Both have to be true for the condition to be true.

[oberkc]

I took more classes in Unix, and hated every minute of it. It was designed for and by what they were called back in the day, Unix Priests!

 

Have you ever heard the term?

 

And, by the way... Yes, I have used Unix (and DOS).  I have not hear to the term you use.  Sorry.

 

I hated Unix.  I found it completely unintuitive, with commands based on words not used by normal people.  The one I specifically got a kick out of was "cat", which I guess was short for "concatenate".  I still don't know what that means.

 

I will take your word for the fact that things can be visual without loosing function.  My concern, however, is that most of the devices designed for the "masses" are, in my mind, dumbed down.  I use examples such as the hub, iris, IFTTT, things like that. My perceptions, perhaps mistaken, is that they lack the flexibility and power that I experience with the ISY. 

 

Perhaps there is a way to combine power with simplicity or with a more visual interface, but I also suspect that there is a relationship between power and learning curve.  I think there is a reason that microsoft paint is easier to learn than adobe photoshop.  Audacity is easier to learn than FinalCut Pro.  I just don't see many examples out there that are both simple and powerful. 

[stusviews]

Rob,

 

dir /s is still the only command from a Windows machine to get an accurate file and directory/folder count

[larryllix]

But Windows still cannot print out a directory listing. It was so easy on a Unix work-alike system back in the 80s.

[stusviews]

But Windows still cannot print out a directory listing. It was so easy on a Unix work-alike system back in the 80s.

 

Issue dir > filename.txt and print filename.txt

 

Or try dir /s >filename.txt to list every file on the hard drive including the folder, date, time, file size, and name.