Why Is This Running True?

[zerop]

I've recently installed the DarkSky node for my new weather info as the climate module will be going away soon.  It seems to be working fine.  I have a series of programs that run late each night to check how much rain, if any there was that day.  Depending on how much rain there was it adjusts a watering variable.  Here's one of the programs (the one that is causing me trouble).

 

RainL - [ID 00D1][Parent 0119]

If
        'DarkSky / Forecast 0' Rain Today >= 0.400 Inches
    And 'DarkSky / Forecast 0' Rain Today < 0.550 Inches
 
Then
        ScoreSet  = 400
        ScoreSubtract  = 300
        $RainToday  = 1
        $RainTodayAmount  = 'DarkSky / Forecast 0' Rain Today Inches
 
Else
   - No Actions - (To add one, press 'Action')

 

I have 7 programs exactly like this one but the range of rainfall is different for each. 0" - 0.1" another for 0.1" - 0.25" another for 0.25" - 0.4", etc.  At a specific time at night I run (if) all 7 programs.  There is no overlap in the conditions (see greater than equal to in example above) so only one of them should run true.

For the past couple of nights this one program (example above) has run true even though there has been no rain.  I even included the variable $RainTodayAmount just as a test to see what the ISY thinks the rain amount was.  If this program runs true then the variable $RainTodayAmount should be between 0.4 and 0.55.  I checked this morning and the variable is "0.00".  I set the accuracy to 0.00.

I tried deleting the program and recreating it from scratch.  Same result.  I searched all my other programs to make sure I wasn't calling this program from somewhere else...nothing.

Why is this running true?  If I run (if) it manually now it runs true even with the following weather info (see attached).

ISY994i v.5.0.16

[oberkc]

I take it from a lack of response that most, like me, cannot find a programmatic reason why your program would run true under the set of conditions described.  I guess one must conclude that it is possible that something else is calling the program (then path?), that somehow the conditions from darksky are not correctly translating, or there is a bug in the ISY software.

Is this program disabled?  Is this program last run consistent with with the specified time at night when are calling it?  When is your "$RainTodayAmountz" reset back to zero each day?

[larryllix]

Do all of your programs have the
  $RainTodayAmount  = 'DarkSky / Forecast 0' Rain Today Inches    line in them?

Edited March 28, 2020 by larryllix

[apostolakisl]

Is the program that represents the correct rainfall also running true, or only this one?

[zerop]

5 hours ago, larryllix said:

Do all of your programs have the
  $RainTodayAmount  = 'DarkSky / Forecast 0' Rain Today Inches    line in them?

Yes, all the seven programs with different rainfall ranges has this line at the end.

[zerop]

3 hours ago, apostolakisl said:

Is the program that represents the correct rainfall also running true, or only this one?

I don't have a program for 0" of rain so no.  The seven programs I have are only if there IS rain I subtract some points from a variable.  If there's no rain then I add points dependent upon that day's weather conditions.

[zerop]

6 hours ago, oberkc said:

I take it from a lack of response that most, like me, cannot find a programmatic reason why your program would run true under the set of conditions described.  I guess one must conclude that it is possible that something else is calling the program (then path?), that somehow the conditions from darksky are not correctly translating, or there is a bug in the ISY software.

Is this program disabled?  Is this program last run consistent with with the specified time at night when are calling it?  When is your "$RainTodayAmountz" reset back to zero each day?

All seven programs are in a folder, the folder has a state variable set to "0" usually.  At the specified time the folder state variable is set to "1" and all 7 programs called to run (if) then the folder state variable is set back to "0" again.

There is nothing else calling this program, I've check using the find/search.  The program last run is consistent with when it is called to run as well as the $RainTodayAmount  variable has been set to 0.00 at that same program call time.  The $RainTodayAmount variable I put in there just for testing so it doesn't have an automatic reset.  I have been manually adjusting it to different values each day and see when it changes and what it changes too.

[zerop]

There must be a bug somewhere because when I run (if) the program manually it runs true but yet the $RainAmountToday variable gets set to 0.000

That's just not possible.

 

RainL - [ID 00D1][Parent 0119]

If
        'DarkSky / Forecast 0' Rain Today >= 0.400 Inches
    And 'DarkSky / Forecast 0' Rain Today < 0.550 Inches
 
Then
        ScoreSet  = 400
        ScoreSubtract  = 300
        $RainToday  = 1
        $RainTodayAmount  = 'DarkSky / Forecast 0' Rain Today Inches
 
Else
   - No Actions - (To add one, press 'Action')

[zerop]

Interestingly I think I had this same issue when I was using the OpenWeatherMap node before I tarted using the DarkSky node.  I only used the OpenWeatherMap node for 2 days before it was decided it wasn't working and someone stated they would pull it from the PolyGlot Cloud store so I didn't get a chance to look into it further.

Edited March 28, 2020 by zerop

[TJF1960]

If you take one of the programs that currently run false and change only the values in the condition to equal the program that runs true, does that program now run true as well?

[zerop]

5 minutes ago, TJF1960 said:

If you take one of the programs that currently run false and change only the values in the condition to equal the program that runs true, does that program now run true as well?

Yes, and vice versa. I tried both.  One program that correctly runs false, changed only the values in the condition to equal the program that runs true and now that programs also runs true.  I did it the other way also.  For the program that incorrectly runs true, I changed only the values in the condition to equal the program that runs false and now it runs false.  Maybe I'll start narrowing the range to see if I can figure out what the amount of rain fall it thinks is happening.

[zerop]

I did some testing by running (if) this program manually and changed the Rain Today is X.XXX Inches, 0.1" at a time.  It ran true for all values between 0" - 0.499".

RainL Copy Copy Copy - [ID 00F0][Parent 0069]

If
        'DarkSky / Forecast 0' Rain Today is 0.000 Inches
 
Then
        $RainTodayAmount  = 'DarkSky / Forecast 0' Rain Today Inches
 
Else
   - No Actions - (To add one, press 'Action')

 

 

I then tried this program and it ran true.

 

RainL Copy Copy Copy Copy - [ID 00F1][Parent 0069]

If
        'DarkSky / Forecast 0' Rain Today is 0.000 Inches
    And 'DarkSky / Forecast 0' Rain Today >= 0.250 Inches
 
Then
        $RainTodayAmount  = 'DarkSky / Forecast 0' Rain Today Inches
 
Else
   - No Actions - (To add one, press 'Action')

 

 

But now I'm confused why this one ran false as the values used in this program were true in the first program above.

 

RainLL Copy Copy - [ID 00EE][Parent 0069]

If
        'DarkSky / Forecast 0' Rain Today >= 0.250 Inches
    And 'DarkSky / Forecast 0' Rain Today < 0.400 Inches
 
Then
        $RainTodayAmount  = 'DarkSky / Forecast 0' Rain Today Inches
 
Else
   - No Actions - (To add one, press 'Action')
 

 

[kclenden]

24 minutes ago, zerop said:

I did some testing by running (if) this program manually and changed the Rain Today is X.XXX Inches, 0.1" at a time.  It ran true for all values between 0" - 0.499".

Did it run false for values of 0.500 and greater?  It seems like there is some funkiness going on with how the ISY handles comparisons between a node value and a program constant.

What happens if you change your process and first set a variable to equal 'DarkSky / Forecast 0' Rain Today Inches and then use that variable in your program's IF statement?

[zerop]

2 minutes ago, kclenden said:

Did it run false for values of 0.500 and greater?  It seems like there is some funkiness going on with how the ISY handles comparisons between a node value and a program constant.

What happens if you change your process and first set a variable to equal 'DarkSky / Forecast 0' Rain Today Inches and then use that variable in your program's IF statement?

Yes, it runs false for values of 0.500 and greater.

That is exactly how I've fixed the problem.  I set a variable equal to 'DarkSky / Forecast 0' Rain Today Inches first and then I run my other programs dependent upon that variable value rather than directly from the 'DarkSky / Forecast 0' Rain Today Inches node value.

[kclenden]

8 minutes ago, zerop said:

That is exactly how I've fixed the problem.

Then I would classify the problem as a bug in the ISY coding.  Perhaps the 'DarkSky / Forecast 0' Rain Today Inches value is a different precision and IF comparisons simply round the program constant to match the node precision.  Or maybe this is only a problem when 'DarkSky / Forecast 0' Rain Today Inches is equal to 0 in which case maybe it's not really a 0 but a NULL value and the ISY doesn't handle that in its IF routines but does handle it during variable assignments.  Whatever the underlying cause, it appears the ISY handles it correctly for variable assignments, but not for IF comparison.

Edited March 28, 2020 by kclenden

[larryllix]

2 hours ago, zerop said:

Yes, all the seven programs with different rainfall ranges has this line at the end.

Then I believe your verification using that variable as an outcome is invalid.

Try disabling all your programs or removing the test variable line from all but the suspect program, disabling it, and then testing

[zerop]

19 minutes ago, larryllix said:

Then I believe your verification using that variable as an outcome is invalid.

Why?

[larryllix]

4 minutes ago, zerop said:

Why?

Because there are at least 6 programs that affect that variable due to unforeseen triggers.
Many times we save a value and then another program changes it and destroys the evidence.

As an experiment try changing all those lines from "="  to "+=", then clear the variable to 0, and test. This should show a cumulative result from every program that triggered.
None of the other programs will show True (Green) as they will all trigger False when another program becomes True. This also hides history. I have many of these "selector switch" type banks of programs in usage and they can fool you. 

Also, "selector switch" type program banks cannot ever have Else program lines.

[kclenden]

4 hours ago, larryllix said:

Because there are at least 6 programs that affect that variable due to unforeseen triggers.

But his original programs didn't use a variable in their IF statements.  They made comparisons directly to 'DarkSky / Forecast 0' Rain Today Inches.  So there could be no unknown interactions causing a program to run TRUE when it should have run FALSE.  In an earlier post, he indicated that he checked the "Last Run Time" of the programs after his tests which would tell him if one of them might possibly have affected the test variable.  And finally, all of his programs set the variable equal to 'DarkSky / Forecast 0' Rain Today Inches.  So even if they had run inadvertently, he would still be seeing the value his wanted to see.  Your suggestions for more testing would certainly arrive at a more definitive conclusion, but I don't think they are necessary for before he submits a bug report to UDI.

[larryllix]

2 hours ago, kclenden said:

But his original programs didn't use a variable in their IF statements.  They made comparisons directly to 'DarkSky / Forecast 0' Rain Today Inches.  So there could be no unknown interactions causing a program to run TRUE when it should have run FALSE.  In an earlier post, he indicated that he checked the "Last Run Time" of the programs after his tests which would tell him if one of them might possibly have affected the test variable.  And finally, all of his programs set the variable equal to 'DarkSky / Forecast 0' Rain Today Inches.  So even if they had run inadvertently, he would still be seeing the value his wanted to see.  Your suggestions for more testing would certainly arrive at a more definitive conclusion, but I don't think they are necessary for before he submits a bug report to UDI.

All good logic but in many years and so many users out there, I don't remember hearing  of a program running by an incorrect trigger. Many times we thought we had trapped a bug of this nature but it always turns out to be some sneaky trigger or other source of the erroneous event. Of course anything is possible. We have had some variable roundoff errors before.

Myself, I would be trying to eliminate more possibilities, by disabling the each of the programs affecting the same variable and eliminating all but the one in question. Then polyglot could also be inflicting variable changes. I have complained about the rest interface having no data security before and anything can be changed in ISY erroneously by a runaway box containing your ISY credentials. There are no boundaries.

Then possibly trying a factory reset and reload everything before opening a ticket.
OTOH, Michel may like to see this in action and do some digging of his own, before the possibility of it just disappearing into the unknown.

This will definitely be interesting to find out what is happening here.

[kclenden]

3 hours ago, larryllix said:

Then possibly trying a factory reset and reload everything before opening a ticket.

I applaud your diligence in trying to run down unexpected results before submitting a bug report.  I see two problems with this approach though:

• Let's say you factory reset and reload everything and now the programs work. What has that done?  It's left you with a working system that you can't trust because you don't know what caused the original problem or when the problem might come back.  Additionally you've removed any evidence that UDI might have been able to collect to determine the root of the problem.
• Your time is worth something.  If you've narrowed down the problem to something that you can repeatedly duplicate then why not notify UDI to see if they can duplicate it on their system?  Either they do, in which case you'd have been wasting your own time resetting and reloading everything, or they don't in, which case they might want to look at your system while it's still in a state that you can repeatedly demonstrate the problem.

I'm not saying your way is wrong, but I'm saying it's right either.  ?

[TJF1960]

I can confirm I am seeing the same thing as @zerop when I duplicated his condition of the program using Openweathermap and WeatherPoly, I don't have Darksky.

The following program runs true even though OpenWeatherMap shows 0 rain todayl

AA Weather Test - [ID 004C][Parent 0254]

If
        'PolyGlot / OpenWeather / OpenWeatherMap' Rain Today >= 0.400 Inches
    And 'PolyGlot / OpenWeather / OpenWeatherMap' Rain Today < 0.550 Inches
 
Then
   - No Actions - (To add one, press 'Action')
 
Else
   - No Actions - (To add one, press 'Action')

Changing the first statement to lower numbers always ran true, I tried 5 different numbers, always ran true. I found once the first statement hit .5 the program ran false.

I tried this also on WeatherPoly with interesting results. Pointing to daily rainfall this program ran false as it should, daily rainfall is reporting as 0.03"

AA Weather Test - [ID 004C][Parent 0254]

If
        'PolyGlot / WeatherPoly_Acuparse / WeatherPoly / Precipitation' Daily Rainfall >= 0.400 Inches
    And 'PolyGlot / WeatherPoly_Acuparse / WeatherPoly / Precipitation' Daily Rainfall < 0.550 Inches
 
Then
   - No Actions - (To add one, press 'Action')
 
Else
   - No Actions - (To add one, press 'Action')

However when I pointed it to Rain Rate, which is reporting as 0", this program ran true

AA Weather Test - [ID 004C][Parent 0254]

If
        'PolyGlot / WeatherPoly_Acuparse / WeatherPoly / Precipitation' Rain Rate >= 0.400 inches/hour
    And 'PolyGlot / WeatherPoly_Acuparse / WeatherPoly / Precipitation' Rain Rate < 0.550 inches/hour
 
Then
   - No Actions - (To add one, press 'Action')
 
Else
   - No Actions - (To add one, press 'Action')

 

[kclenden]

On 3/29/2020 at 4:02 PM, TJF1960 said:

I tried this also on WeatherPoly with interesting results. Pointing to daily rainfall this program ran false as it should, daily rainfall is reporting as 0.03"

 

On 3/29/2020 at 4:02 PM, TJF1960 said:

However when I pointed it to Rain Rate, which is reporting as 0", this program ran true

That might indicate that the ISY is rounding the IF conditions "i.e. 0.400" to the precision shown by the node (i.e. 0).  Mathematically, probably the correct thing to do since you can't infer more precision than is present, but not what one might expect based on common sense.  What happens if you add an additional check to the IF to make sure the node isn't 0?  Like so:

AA Weather Test - [ID 004C][Parent 0254]

If
        'PolyGlot / WeatherPoly_Acuparse / WeatherPoly / Precipitation' Daily Rainfall >= 0.400 Inches
    And 'PolyGlot / WeatherPoly_Acuparse / WeatherPoly / Precipitation' Daily Rainfall < 0.550 Inches
    And 'PolyGlot / WeatherPoly_Acuparse / WeatherPoly / Precipitation' Daily Rainfall is not 0 Inches
 
Then
   - No Actions - (To add one, press 'Action')
 
Else
   - No Actions - (To add one, press 'Action')

@Michel Kohanim can you explain how the ISY deals with precision differences between different components of an IF comparison?

Edited April 5, 2020 by kclenden

[larryllix]

@kclenden  I have experimented with three decimal place variables against 1 decimal place variable and vice versa. The precision conversions always worked flawlessly.

Since the OP program is showing three decimals of precision in the comparison, along with superfluous zeroes, I have to conclude this is a problem with the NS supplied values and not ISY arithmetic, or precision conversion. When a floating decimal value  is used in any 'If' section  comparison,  the trailing zeros are always truncated and never displayed, as in the OP program. These must be predetermined pulldown menu values supplied by the NS.
 

In the If line:
'PolyGlot / WeatherPoly_Acuparse / WeatherPoly / Precipitation' Daily Rainfall >= 0.400 Inches
"0.400" is a predetermined selection made by the NS and I suspect the decimal arithmetic is
is being done correctly by ISY's arithmetic engine but using incorrect values supplied by the NS software.

Test decimals - [ID 00D0][Parent 0001]
If
   - No Conditions - (To add one, press 'Schedule' or 'Condition')
Then
        $Test_terminate_value  = 0.5
        $Test_Ramp_var  = 0
        Repeat While $Test_Ramp_var < $Test_terminate_value
           $Test_Ramp_var += 0.001
Else
   - No Actions - (To add one, press 'Action')

 

Edited April 5, 2020 by larryllix

[kclenden]

@larryllix You may be right, but your test is not an apples to apples test.  Your test uses two variables for which the ISY knows everything because it created them.  The OP is using a node that was not created by the ISY and comparing it to precision represented by trailing zeros after the decimal point.  I can easily see why the ISY would handle your variables differently than it handles the OP's comparison.

On 4/5/2020 at 8:03 AM, larryllix said:

Since the OP program is showing three decimals of precision in the comparison, along with superfluous zeroes, I have to conclude this is a problem with the NS supplied values and not ISY arithmetic, or precision conversion.

A problem with that conclusion is that the OP says that if the node value is first put into a variable, and then the variable is used in the IF the programs run correctly.  The ISY seem to be able to understand the node value well enough to put it into a variable, but not understand it well enough to use the node in a direct comparison.  One possible explanation for that is that the ISY takes a zero (whose precision it doesn't fully know) and forces it into the precision of the variable it is being assigned to, while doing something different when using the node in a direct IF comparison.  I'm sure there are other explanations, but only @Michel Kohanim or @Chris Jahn can tell us.