IoP not responding correctly to EoT

[CoLong]

IoP is not responding correctly to EoT values from the AERISWeather Node Server.

Today, the here EoT is 0.2 as shown in the Forecast 0 table in IoP (see attached), yet the first IF statement (see attached) fails, and the second one (see attached) succeeds.

@bpwwer

[bpwwer]

What is the actual value of ETo being sent to the IOP?   You're seeing what the AC displays, but not what the node server sent.  My guess is that the value is between .270 and .299.  

It looks like the AC isn't honoring the display properties the node server requests.  The node server says that value should be truncated to 2 decimal places, but it looks like it's truncating it to 1.

[CoLong]

I'm not sure that truncation explains this, because e.g. Forecast 2 is currently displaying ETo as 0.24 not 0.2.

[bpwwer]

Either the program logic is correct and the value is between .270 and .299 and the displayed value is truncated or the program logic is failing and the displayed value is correct.  It either case, it's not a problem with the node server so there's nothing I can do about it. 

Looking at what the node server actually sends to the IOP will tell us which of those cases is true and the appropriate ticket can be raised to UDI.

[CoLong]

Thanks @bpwwer.  How do I see/find what the node server is actually sending to IoP, or is that something i need to ask UDI to do?

Edited August 7, 2022 by CoLong

[bpwwer]

3 minutes ago, larryllix said:

I see 0.2 value.

I think @bpwwer typo'd and meant 0.170 to 0.199 values. When rounded off they would show 0.2 as a value using one decimal place.

I don't believe the ISY/IOP rounds the value.  I think it just truncates the display to the number of decimal places the node server specifies.  The node server is rounding the value to 3 (maybe 2) decimal places.

If the ISY/IOP was rounding up, the second program wouldn't be true.

@CoLongplease just post the value the node server sends, that's what's important here.

[CoLong]

This is what the log shows at the time I took the Forecast 0 screenshot above:

2022-08-07 08:35:04,562 Thread-8252 udi_interface      INFO     aeris_daily:set_ETo: Conversion of temperature/wind speed required

2022-08-07 08:35:04,563 Thread-8252 udi_interface.node DEBUG    node:setDriver: forecast_0:Forecast 0 No change in ETO's value

2022-08-07 08:35:04,564 Thread-8252 udi_interface      INFO     aeris_daily:set_ETo: ETo = 0.2

2022-08-07 08:35:04,564 Thread-8252 udi_interface      DEBUG    query:query_forecasts:  >>>>   period

[bpwwer]

Thanks, that answers the question as to where the failure is.  

To me, it looks like the first program should evaluate to true and the second to false.  You're saying it is doing the opposite.  So either we're missing something or the logic is failing.  Someone better versed in ISY programs will have to look at this.  You could also try creating programs for each condition separately and see how they evaluate.  Or try setting a variable to the value to the eto value in the then or else sections.

The node server doesn't have anything to do with the program evaluation other than providing the value, which it seems to be doing correctly.

[CoLong]

Many thanks @bpwwer.  I will open a UDI ticket.

[CoLong]

I've  opened a UDI ticket for the above ETo-related problem, and I've included a link to this thread to show all the background information.

IN addition, we had rainfall this evening and I'm seeing a situation with the PRECIP variable similar to the above problem with ETo.  The AERISWeather table in IoP shown 0.27" of precip (see attached), but two different programs that should have been triggered by any level of precip over 0.100" have failed to run (see attached).  In both cases, the program icon shows green, which (I think) means that the IF condition has been met, but in both cases, the THEN portion of the program fails to run, unless I manually click on "RUN THEN."

[Michel Kohanim]

@Chris Jahn is looking into it.

With kind regards,
Michel

[CoLong]

@bpwwer I thought you might like to know this additional information .  I've added it to the support ticket, which is currently unresolved:

"I've repeated the precip test a couple of times now, and I see a pattern in the error that you might find diagnostic.  With the precip manually set at 0.003 at mid-afternoon, IF precip >0.001 succeeds.  But IF precip <= 0.010 initially fails, and then later succeeds, but only when precip is reset back to 0.000 automatically at midnight."

@Chris Jahn

Edited August 31, 2022 by CoLong

[CoLong]

Issue resolution summary:  ISY to IoP migration process corrupted many lines of code.

Regarding the ETO issues, Chris and I ran various checks and the event viewer showed them to be working correctly.  Then I noticed that copied versions of ETO-checking programs set themselves automatically to the correct True/False state based on the ETO set point after they were copied, even though their originals remained in the incorrect True/False state as though they are not reading the actual ETO.  Just the copies seemed be to reading the ETO correctly.  So, replaced each of the ETO-checking programs with new copies.

Based on that observation, I checked all my programs to see if they were working correctly – some of them don’t get used very often, so they’ve had no opportunity to malfunction in the last several weeks.  I found that many of them had to be replaced with new copies which then showed corrupted/altered lines of code that I had to correct manually.

All my programs come from a backup of my ISY 944i that I migrated over to IoP when I got my Polisy several weeks ago.  I think this means that many lines of code got corrupted in the migration process, even though they displayed correctly on my monitor in IoP.  Now, everything seems to be working correctly after spending several hours checking all my programs for errors, by comparing new copies to the originals, manually correcting the lines of code in the new copies that had errors, and replacing the originals with new copies.

The issue with IoP correctly detecting Precip changes, and taking correct actions based on IF AND statements, resolved itself over the course of the last 5 weeks.  I speculate that there must have been an unannounced change made at the AERISWeather end which caused that correction, since no other changes were made to IoP or my programs in that time fram