ETO always zero

[GTench]

I just set up a tempest weather station a couple of days ago and added the weatherflow node server to my polisy. I added the weather station ID under forecast and added the new key for the station ID and set its value to local. Everything seems to be fine except that the yesterday's ETO is always zero. Am I missing something in the node server setup?
thanks,

Gary

[bpwwer]

There was a bug about 6 months back that set it to zero after the first day, but that should be fixed.  I see mine is at zero also so I'll do some debugging.

It does need forecast information to calculate ETo and it does the calculation at midnight using the previous day's information.

[Bumbershoot]

21 hours ago, bpwwer said:

There was a bug about 6 months back that set it to zero after the first day, but that should be fixed.  I see mine is at zero also so I'll do some debugging.

FWIW, the value is populated and is changing daily in my installation.  Version 3.0.21.

[GTench]

Thanks, I am using the same version but I still see 0 in the weatherflow node in IoP

[GTench]

Just noticed that ETO shows up as 3.17... if I look under the node server nodes but shows up as 0 in IoP?

[GTench]

screen shots

[bpwwer]

ETo is set to zero if there isn't any forecast data.

The node server will enable the ETo calculation only if the custom parameter "Forecast" value matches a station ID returned when it queries the WeatherFlow servers for station meta data.

[GTench]

I believe that I have that set up correctly. I will attach another screen shot. But I see that ETO is being calculated when I look at the nodes but it is not being passed back to my IoP. It is non zero in the nodes display but zero in IoP

[bpwwer]

The setup looks correct.

If PG3 is displaying a value and that value is changing from day to day, then the node server is working correctly. 

The node server never talks to the ISY directly, everything goes through PG3.  So if PG3 has the right value and the ISY doesn't, it's not an issue with the node server.

You didn't mention any other problems, but if it's just that one value that isn't getting sent to the ISY, that would be very, very strange.  The only thing I can think of that might cause something like that would be if the node server's profile file on the ISY was missing the ETo definition, but the AC does get the proper definition.    You can try re-sending the profile files to the ISY (PG3, node server details, upload profile button) and see if that helps.

Otherwise, I'd suggest checking the node server log and look for when it sends the ETo value to PG3, should happen within a minute or so of midnight.  Using the timestamp from that, check the PG3 log for the same time and see what it does with it.  There should be log entries there showing it sending the value on to the ISY.  Then at least we know if the value is making it to the ISY or not.

[GTench]

Thanks very much for the suggestions. I appreciate it. The ETo value in PG3 is updating each day but does not appear in IoP. As far as I can tell this is the only value that is missing in IoP. 

 

Yesterday I deleted and reinstalled the node server. Following that I then noticed that ETo in PG3 was set back to 0 as I believe is correct. This morning I checked in PG3 and ETo had been updated to 2.903759505852784 but was still 0 in IoP. I checked the node server log file  but there is no entry at midnight perhaps because it was not in debug mode. I have now set the log file to debug and now I see log entries occurring for the many data value updates. I will leave it in debug mode and check tomorrow for the ETo line around midnight. 

 

I am using metric units with tempest. I have now changed to all imperial to see if this has an effect... a long shot I know

 

I had a look in the PG3 log file and these are the entries around midnight that seem to deal with ETo

 

 

7/28/2022, 24:00:46 [pg3] info: [00:0d:b9:53:d8:14_6] setup reporting command DOF 7/28/2022, 24:00:46 [pg3] debug: Scheduling http://192.168.2.117:8080/rest/ns/6/nodes/n006_setup/report/cmd/DOF to group commandGroup 7/28/2022, 24:00:46 [pg3] error: ISY Response: [Try: 1] [00:0d:b9:53:d8:14] :: [404 - OK] :: 18.856618ms - http://192.168.2.117:8080/rest/ns/7/nodes/n007_controller/report/status/ETO/2.903759505852784/106 7/28/2022, 24:00:46 [pg3] debug: Scheduling http://192.168.2.117:8080/rest/ns/7/nodes/n007_controller/report/status/GV4/3/57 to group statusGroup 7/28/2022, 24:00:46 [pg3] debug: MQTT Results: [ns/status/00:0d:b9:53:d8:14,7] :: {"set":[{"address":"controller","driver":"ETO","value":"2.903759505852784","uom":106}]} 7/28/2022, 24:00:46 [pg3] debug: [PUBLISH: udi/pg3/ns/clients/00:0d:b9:53:d8:14_7] {"set":[{"address":"controller","driver":"ETO","value":"2.903759505852784","uom":106}]} 7/28/2022, 24:00:46 [pg3] debug: ISY Response: [Try: 1] [00:0d:b9:53:d8:14] :: [200] :: 38.373639ms - http://192.168.2.117:8080/rest/ns/6/nodes/n006_setup/report/cmd/DOF 7/28/2022, 24:00:46 [pg3] debug: [MESSAGE_PUBLISHED] Client pg3_client has published message on udi/pg3/frontend/clients/ed35df13-348f-453e-8601-aeee79ef5703 to broker pg3_broker

[bpwwer]

This is the problem:

24:00:46 [pg3] error: ISY Response: [Try: 1] [00:0d:b9:53:d8:14] :: [404 - OK] :: 18.856618ms - http://192.168.2.117:8080/rest/ns/7/nodes/n007_controller/report/status/ETO/2.903759505852784/106

The ISY is rejecting it. A 404 error means "not found".  I did some experiments and it seems the ISY rejects it if there are too many digits of precision in the value.

I just pushed out version 3.0.22 that rounds the value so this should be fixed.  If you refresh the node server store, and then restart the WeatherFlow node server, it should auto-install the update.

[GTench]

Ahhh that makes sense. I will do as you suggest. Many thanks for looking into this for me

[GTench]

Works great now. ETO now shows up in my IOP. Thanks again!