State Variable change not triggering program

[gduprey]

Howdy,

 

I have a state variable that I set to 1 or 0 to call for whole house humidification.  The variable can be set by a number of things (from a "manual call" program that sets it to results of hygrometer readings via a program).  The variable is consistently set (or cleared) as expected and triple checked it's a state variable.

 

I've had numerous times when I've noticed humidity was low in the house, but the humidifier wasn't being called.  When I check, the appropriate state variable was correctly set to be calling for the humidifier, but the program that was supposed to trip the humidifier didn't run.  If I then manually run the "If" part of the program via the admin console, the humidifier immediately trips.  And there are times, I can see by looking at my logs, that the program trips as expected, but plenty where it doesn't.

 

1) The program is based on testing the value in a STATE variable
2) The variable is only set to 1 (ON) or 0 (OFF) in a small number of places
3) The program is enabled as it's it's folder and the folder has no conditions

4) The actual state variable IS accurately tracking when the humidifier should be on or off.

5) The program does NOT kick over 100% of the time (but it does some of the time).

6) Based on recent discussion of IF/THEN/ELSE, since the only IF condition is testing the value of the state variable, the THEN/ELSE should trigger anytime that variable changes (the difference being the variable).

 

Any ideas where to look for why this is not happening?

 

Below is the program and it's pretty simple.  The command/wait/command is just a "safety" - I never actually lose events/commands, but given I don't want the humidifier running when not needed, my paranoid side says to "double check"

 

If
        $humidifer_call is 0
Then
        Set 'Humidifier Override Sensor / Humidifier Override Switch' Off
        Wait  15 seconds
        Set 'Humidifier Override Sensor / Humidifier Override Switch' Off
Else
        Set 'Humidifier Override Sensor / Humidifier Override Switch' On
        Wait  15 seconds
        Set 'Humidifier Override Sensor / Humidifier Override Switch' On

I have to assume I'm missing something.  The ISY has always been rock solid and when it's not, I've been able to track it back to my mistake/misunderstanding.  But this one seems so simple, I can't see where that could slip in.

 

Gerry

 

[oberkc]

What does "kick over" mean?

 

Why, in the if/else path, do you turn something OFF/ON, wait 15 seconds, then turn it OFF/ON again?

 

Have you confirmed from the program list, that the program status is true or false as expected? (Is the status of this program always true when the variabe is 0 and always false when the variable is 1?)

 

I dont see anything obvious in this program which would explain your unexpected behavior.

[gduprey]

What does "kick over" mean?

Turn on, start, or in this example, run the programs then or else based on a change to the state variable, when the state variable changes.

 

Why, in the if/else path, do you turn something OFF/ON, wait 15 seconds, then turn it OFF/ON again?

I did mention (right above the code block) that I do this as a safety, especially with the OFF, to insure that the command is received if something were to get lost. That said, I've never had it happen, but for things where there are consequences to a missed command, it's cheap insurance. Most lighting and such I don't bother with such "safeties".

 

Have you confirmed from the program list, that the program status is true or false as expected?

No, it appears the program did not run (when I notice something should have happened but didn't).

 

I didn't see anything obvious in this program which would explain your unexpected behavior.

Me either. I develop HA systems and have been programming and building hardware for 30+ years, so presumably not a total noob, but this case is so "simple" but unreliable, I brought it up here.

[larryllix]

Have you manually changed the value of the variable to divide the problem into output or input from the variable value?

 

Does the variable state have any dependency on the state of the humidifier? Creating a negative feedback loop.

 

Is your program triggers enabled?

 

Have you checked and compared the links in the output module? factory reset it and restored?

Edited March 16, 2017 by larryllix

[gduprey]

Yes, and manually changing the variable (from the "State" tab of the variable tab of the Programs tab) does not seem to trigger the program - at least not always.

 

Per my earlier note, the program is enabled, the variable is absolutely a state variable and the folder the program is in is enabled and has no other conditions on it.

 

There is no connection between the actual humidifier (or the state of the switch) to the variable. The only things that set the state variable to 0 or 1 are 1) the humidity level in the main room falling under a certain level or 2) running a program (with no IF but not enabled) to manually call for humidity.

 

And again, the variable is being changed, but the program that should run when the state changes is not always running. Even if something else was monkeying with the state variable, the program should run (possibly thrashing around under a bad feedback situation, but still should be running as the state variable is changed).

 

Note sure what the "output module" is (I assume the switch), but the problem isn't that the switch isn't switching, it's that the program (which eventually commands the switch) is not running.

 

Gerry

[larryllix]

Yes, and manually changing the variable (from the "State" tab of the variable tab of the Programs tab) does not seem to trigger the program - at least not always.Per my earlier note, the program is enabled, the variable is absolutely a state variable and the folder the program is in is enabled and has no other conditions on it.There is no connection between the actual humidifier (or the state of the switch) to the variable. The only things that set the state variable to 0 or 1 are 1) the humidity level in the main room falling under a certain level or 2) running a program (with no IF but not enabled) to manually call for humidity.And again, the variable is being changed, but the program that should run when the state changes is not always running. Even if something else was monkeying with the state variable, the program should run (possibly thrashing around under a bad feedback situation, but still should be running as the state variable is changed).Note sure what the "output module" is (I assume the switch), but the problem isn't that the switch isn't switching, it's that the program (which eventually commands the switch) is not running.Gerry

From your first statement the success of the program running is intermittent.

 

If this is the case, and I think oberkc gave some good troubleshooting techniques, is the running of the program recorded in the program summary tab when the program appears to fail from manually changing the variable?

 

If the summary shows it ran by time synchro, and the program did not run then something is turning it off again, suggesting variable negative feedback or defective ISY engine processing. At that point, with absolute proof, I would do an ISY factory reset and test again, then UDI contact. Bad SD or contacts?

 

Did you state which ISY revision you are using?

[oberkc]

Is there any observed relationship between the value of the variable and when it runs? Does it always run when the variable changes to 0 but never run when it changes to 1? Other way around? No relationship? Have you ever seen the program status as FALSE?

 

Based upon what I have read so far, my best guess is that we both may misunderstand what is a trigger for this program. I thought it would trigger upon any change to the variable. Perhaps it triggers only when the variable changes to 0?

 

I am sorry, but I dont see anything obvious here and can only help with suggestions on how I would troubleshoot. For the record, I have never noticed a program not trigger when input conditions warrant.

[gduprey]

So as a followup -- I got unhappy with the unreliability of this and broke it into two programs -- one which checks $humidity_call is 0 (and turns it off in the THEN) and one that checks $humidity_call is not 0 (and turns it on in the THEN).

 

This seems to work reliably -- so far, 100%.

 

That said, after all the discussion about how IF works, how triggers are determined and how ELSE is supposed to work with triggered IF conditions, this just further cements my "fear" of using ELSE statements. Everytime I've had janky triggering behavior and I split a single IF/THEN/ELSE triggered program into two IF/THEN programs with no ELSE, things got reliable. That said, I have never had a problem with IF/THEN/ELSE when the program is just run and either isn't enabled (manually run) or doesn't have trigger events. Just triggered/event IF's.

 

I would really appreciate someone being able to suggest what might be going wrong with this (and, I assume, implicit actions of an ELSE on a triggered condition). Knowing might start to rebuild my currently zero-confidence in reliable ELSE use with triggering IF statements

 

Gerry

[oberkc]

I have not found it accurate to judge whether a program did not run based on observing redpibse from devices. Sometimes, devices dont respond because of pogram errors. Sometimes they dont respond because of comm issues. Dometimes, there are devicee failures.

 

If you have not already done so, i suggest using the program status (ladt run time, true/false) as the only conclusive evidence regarding whether a profram ran.

[gduprey]

Yep -- all I was looking at was the programs status and last run times and such. Definitely something goofy about ELSE on a IF with a state variable. Hopefully someone from UDI can clarify.

 

My work-around/alternate-implementation has been working great no matter how the variable gets set (manual program that sets it, humidity level that sets it or just me altering the value in the admin console). So I have a solution, but again, utterly do not trust ELSE on a triggering/event-driven IF statement (right this minute, at least

 

Gerry

[larryllix]

Is there any observed relationship between the value of the variable and when it runs? Does it always run when the variable changes to 0 but never run when it changes to 1? Other way around? No relationship? Have you ever seen the program status as FALSE?

Based upon what I have read so far, my best guess is that we both may misunderstand what is a trigger for this program. I thought it would trigger upon any change to the variable. Perhaps it triggers only when the variable changes to 0?

I am sorry, but I dont see anything obvious here and can only help with suggestions on how I would troubleshoot. For the record, I have never noticed a program not trigger when input conditions warrant.

Program logic gets re-evaluated every time a state variable in the logic changes. If the logic section is true the Then section runs. If the logic is false the Else section gets run, and the Then stops.

 

In one of the v5.x versions the program got re-evaluated every time a value was installed in the state variable (think Rest also), instead of only upon a change. I believe this was corrected now to behave like other variable controlling methods. Program logic is not evaluated if the value doesn't change upon a variable value write. It would be a waste of ISY engine time.

[gduprey]

Program logic gets re-evaluated every time a state variable in the logic changes. If the logic section is true the Then section runs. If the logic is false the Else section gets run, and the Then stops.

That was my understanding as well -- an IF on something that can be monitored (events), is only evaluated if one of it's event/triggerable parts changes, then the logic evaluates and the THEN or ELSE runs. But that is not what I was seeing and you can see how small and clean the program is -- there is no nested programs, muddling with the event triggering variable, loops, or other subtleties. Just turn a device on or off based on a state variable changing. And it working about 70% of the time.

 

I have to beleive there is something subtle that I either don't understand or missed here, but I cannot find it.

 

For the record, this system is running 4.3.26.

 

Gerry

[stusviews]

Are you on 4.3.26 for both the UI and firmware? If not, then you can expect the unexpected to occur.

 

You may not need two programs if you test for:

 

If
        $humidifer_call is 0

And $humidifer_call is not 1

 

which, BTW, also ensures that Else is run.

 

Tip: precede integer variable names with i_ and use s_ for state variables.

[gduprey]

Yes, I'm on the same version for UI and ISY -- always am.

 

Not sure why this would work (if var is x and var is not Y) but simply testing "var is 0" won't -- that seems less than obvious. Can you explain the rationale behind that?

 

As for hungarian notation, never took to it (though I understand why you are suggesting it). Prolly from my rabid avoidance of all things Microsoft

 

Gerry

[stusviews]

I don't know why you should need both. I have a habit of using "and not" to ensure that Else runs. Keep in mind that just having a state variable be a specific value is not adequate. It must change from some other value to the specified value.

 

HP calculators depended on reverse Polish notation which, BTW, is the opposite of Hungarian notation

[oberkc]

gduprey

 

To confirm my understanding of variable triggers, I created a test program that is nothing more than:

 

if

state variable is 0

then

nothing

else

nothing

 

I then changed the value of the variable to 0, then to 1, and to 0 again.  I did exactly what you and I and larryllix expected: all changes triggered an evaluation, the program triggered and ran true when the variable went to zero, triggered and false when the variable went to 1.  I have no explanation why yours would be any different. 

 

I must admit to having trouble believing that a program is randomly not triggering for the same input conditions.  There is something else going on here.

 

Perhaps it is the computer's frustration sensor.  As you know, computers can act up if the operator is frustrated or lose confidence.  Computers are very sensitive.

Edited March 16, 2017 by oberkc

[oberkc]

gduprey,

 

One other thought...is it possible that something is causing a variable change during the 15-second wait statement, causing the program to retrigger and cause unexpected results? 

[larryllix]

That was my understanding as well -- an IF on something that can be monitored (events), is only evaluated if one of it's event/triggerable parts changes, then the logic evaluates and the THEN or ELSE runs. But that is not what I was seeing and you can see how small and clean the program is -- there is no nested programs, muddling with the event triggering variable, loops, or other subtleties. Just turn a device on or off based on a state variable changing. And it working about 70% of the time.I have to beleive there is something subtle that I either don't understand or missed here, but I cannot find it.For the record, this system is running 4.3.26.Gerry

Only the Program Summary program run times can tell you if the program ran each time. I don't see any other way to determine your program isn't starting to run, and then cancelling itself, due to some other hidden logic elsewhere modifying the variable.

 

 

Running logic with "is Not 1" is the same truth table logic as "is 0" for a variable only used for boolean function (two values only as 1 or 0)

 

The "is NOT" technique is only necessary with elements creating program triggers that are only True in their dynamic state, while being evaluated from their own event causes.

 

eg.

If

...switchlinc is switched On

AND

...time is 7:30 PM

 

can never be logically true, as both triggers are only ever true when called by their own logic. Neither have any true static state.

Else will be run at 7:30 PM, always

Else will be run when On is received, always.

 

If

....switchlinc is NOT switched On

will run Else when On is received, always

 

None of this is necessary with logic elements having static logic states of On and Off.

[apostolakisl]

The only thing I can think of is that your variable is changing when you don't think it is.

 

Try creating another program that sends you an email every time the variable changes.  This will tell you if there is any unexpected behavior

 

If

state variable  is 1

Then

notify . . .variable is 1

 

IF

state variable is 0

Then

notify, . . .variable is 0

 

IF

state variable is 10000

Then

blank

Else

notify . . . variable changed

Edited March 17, 2017 by apostolakisl

[gduprey]

Howdy,

 

I did similar testing and found the same -- in simple demo cases, it seemed to work reliably. As for something else changing the variable, my thinking is it shouldn't matter what changes the variable -- anytime the value changes, the IF should be evaluated. I completely understand (and never questioned) that simply setting the variable to the same value (no change) wouldn't trigger anything.

 

I also doubt the WAIT has any impact -- according to the previous discussion I had about IF/THEN/ELSE a few weeks ago, a change to the conditions in an IF will interrupt a WAIT and "re-start" the IF, so if a change ocured during the WAIT, it should still be caught.

 

In short, the example is short and the condition simple and based on what has been explained about how IF/THEN/ELSE works, there really should never be a case that a change to the state variable would ever not cause the correct evaluation and execution.

 

I'm pretty sure all the "problems" were in the ELSE -- the THEN portion seemed to work OK. Breaking it into two IF/THEN blocks has worked perfectly now.

 

The whole IF <event> AND NOT <event> to trigger the ELSE still makes me think there is some subtlety to the ELSE portion of a triggered ELSE, however I realize some part of that is the "instantaneous" nature of CONTROL events/triggers.

 

Gerry

[apostolakisl]

Howdy,

 

I did similar testing and found the same -- in simple demo cases, it seemed to work reliably. As for something else changing the variable, my thinking is it shouldn't matter what changes the variable -- anytime the value changes, the IF should be evaluated. I completely understand (and never questioned) that simply setting the variable to the same value (no change) wouldn't trigger anything.

 

I also doubt the WAIT has any impact -- according to the previous discussion I had about IF/THEN/ELSE a few weeks ago, a change to the conditions in an IF will interrupt a WAIT and "re-start" the IF, so if a change ocured during the WAIT, it should still be caught.

 

In short, the example is short and the condition simple and based on what has been explained about how IF/THEN/ELSE works, there really should never be a case that a change to the state variable would ever not cause the correct evaluation and execution.

 

I'm pretty sure all the "problems" were in the ELSE -- the THEN portion seemed to work OK. Breaking it into two IF/THEN blocks has worked perfectly now.

 

The whole IF <event> AND NOT <event> to trigger the ELSE still makes me think there is some subtlety to the ELSE portion of a triggered ELSE, however I realize some part of that is the "instantaneous" nature of CONTROL events/triggers.

 

Gerry

 

What you have done by splitting the program into two and using only "then" output is eliminate the possibility that the variable is going to a value other than 0 or 1.  The else clause will run in that situation, and you are precisely having issue with the else clause.

 

A program that sends you notification every time the variable changes and what its value is is quite simple.

 

If

variable is 1

and

variable is not 1

Then

send notification . . . use variable substitution so that it puts the value of the variable into the email/text/whatever.

[Chris Jahn]

Hi Gerry,

 

I don't know why this would be happening, and why splitting into two programs seemingly fixes the problem.  The conditional logic processing is the same code for both cases.

 

Not that it should matter, but what are all the ways you updating the state variable?  Do you have programs that run based on the status of your Humidifier Override Switch?

[apostolakisl]

Hi Gerry,

 

I don't know why this would be happening, and why splitting into two programs seemingly fixes the problem.  The conditional logic processing is the same code for both cases.

 

Not that it should matter, but what are all the ways you updating the state variable?  Do you have programs that run based on the status of your Humidifier Override Switch?

My suspicion is that there is a "forgotten" program or a program that erroneously includes the variable which is setting it to values other than 0 unexpectedly.

 

Also you might use the "find" command to search all your programs for any instance of that variable.

Edited March 17, 2017 by apostolakisl

[gduprey]

The whole things is new and fresh in my mind. Implementation of the logic is less than a week old. There are only 2 places that set the variable and both set only a 0 or 1. No alternate values.

 

To be 100%, abso-sure. I just did a find and those are the only two places.

 

That said, even if there were alternate values, the original program at the start of this thread should still work -- it tests for zero, so else should be any change to any value other than 0.

 

No programs run based on the state of the humidifer switch state/status - it is only turned on and then turned off in the example program. Again, using find, there are no other references to it.

 

I will try to carve out some time this weekend to do additional debugging. I've already done quite a bit.

 

Gerry

[stusviews]

On a few occasions, I deleted a program that did not function as expected and started anew--using identical statements. The new program ran correctly. No explanation available.