ET Incorrect In Seasons Skin- Calculated Where?

[gary....@gmail.com]

I'm setting up WeeWX 4.2.0 with WeeWx-MQTTSubscribe and after getting help from Rich, have it working well.

In the Seasons skin, I see that ET is reported at 100 times the value in the loop packets.

Loop has ET: 0.018

Seasons displays ET 1.80 in

Before I make an entry in weewx.conf StdCalibrate Corrections, where is the value calculated for the Seasons skin?

I only find items like these in the skin files:

#if $day.ET.has_data and $day.ET.sum.raw > 0.0

                #if $day.ET.has_data and $day.ET.sum.raw > 0.0

        <td class="label">$obs.label.ET</td>

                <td class="units">$unit.label.ET</td>

                <td class="data new_row">$archive.ET.sum.format(add_label=False)</td>

[gjr80]

Ultimately ET comes from either your driver or StdWXCalculate, depending on the capabilities of your station (it could also come from another service if your are running a driver that is capable of providing ET as a service). Seasons draws ET data from the database. 

When you say ‘Seasons displays ET  1.80 in’ where is that? Seasons can display a number of different ET values/aggregates. Remember that the loop packet value is the amount of ET in the period covered by the loop packet,  Seasons can display the cumulative amount of ET over an archive period, a day, a week, a month or a year depending on what you are looking at.

This construct:

<td class="data new_row">$archive.ET.sum.format(add_label=False)</td>

is used by Seasons to display day, week, month or year ET, so not really able to be compared to a loop value.

Gary

[gary....@gmail.com]

I'm running a VP2+ via WiFiLogger2

This is a loop from my weewx instance:

LOOP:   2020-12-27 19:25:13 EST (1609115113) altimeter: None, appTemp: 25.040385870017634, barometer: 30.341, cloudbase: 2600.178047939499, consBatteryVoltage: 4.76, dateTime: 1609115113.643625, dewpoint: 20.0, ET: 0.018, heatindex: 30.0, humidex: 30.0, inDewpoint: 40.586487665962366, inHumidity: 30.0, inTemp: 74.0, maxSolarRad: 0.0, outHumidity: 67.0, outTemp: 30.0, pressure: None, radiation: 0.0, rain: 0.0, rainRate: 0.0, usUnits: 1, UV: 0.0, windchill: 30.0, windDir: None, windGust: 2.0, windGustDir: 247.0, windSpeed: 0.0

This is where it appears in Seasons skin.

[gary....@gmail.com]

Since the ET value wants to be for the loop period, then I'll just let weewx calculate this value as I have only ETDay as the smallest interval.

These are the fields I can choose from with my current values from the VP2:

"etday":"0.018"

"etmon":"0.60"

"etyear":"1.95"

Either way, it doesn't seem to be incrementing in the skin and displays a suspicious 100 times the loop value.

[gary....@gmail.com]

I removed the ET field from the loop and now see ET 0.00 in the Seasons skin.

It's winter so this value has little meaning for me.

In the growing season though, I do use it in my irrigation system that is fed local data from WeeWX.

[gjr80]

So where was the ET coming from that was in the loop packet? The vantage driver does not emit field ET in loop packets and the StdWXCalculate service does not calculate an ET field for loop packets. Also are you using software or hardware archive record generation, there are some peculiarities to the hardware archive record ET value emitted by the Vantage driver/station. 

Gary

[gary....@gmail.com]

I have a WiFiLogger2 installed exporting json to my mosquitto server. Then WeeWX-MQTTSubscribe pulls in the data from the MQTT server.

In StdWXCalculate  ET = prefer_hardware
In StdArchive  record_generation = hardware

[gary....@gmail.com]

Here's an exported json file content.

On Sunday, December 27, 2020 at 8:09:34 PM UTC-5 gjr80 wrote:

[gjr80]

OK, never used a wifilogger or MQTTSubscribe, suggest you get some help from the respective developers.

Gary

[G Hammer]

Ok, I have no idea what I would ask them for.

The WiFilogger sends good data to the MQTT server and MQTTSubscribe retrieves those accurately into loop packets.

That one of them is multiplied by 100 for display doesn't seem to be on either of them.

--
You received this message because you are subscribed to a topic in the Google Groups "weewx-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/weewx-user/oo6K0FVMny4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to weewx-user+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/8a28d3c5-4df5-425f-ac7e-7e20dbcfa7a1n%40googlegroups.com.

[gjr80]

The json values.txt you provided includes no per-period ET value, only cumulative values. So what is calculating that ET value? If the json file you posted is a loop ‘packet’ from the wifi logger then does the MQTTSubscribe driver calculate ET from successive cumulative ET values? StdWXCalculate does not calculate loop based ET so that really only leaves the driver.

Then look at the archive record and ask the same question, who is providing the ET value? The MQTTSubscribe driver has a genArchiveRecords() method so the driver and not StdArchive is responsible for creating and emitting an archive record. Does the driver calculate ET or is it received from the wifilogger (Davis stations include hourly ET values in the archive record at the top of the hour, all other archive records have ET=0, again don’t know what the wifilogger does)? If not then in this case StdWXCalculate can step in and calculate ET or since ET is appearing in loop packets StdArchive could calculate ET by summing the loop packet ET values seen during the archive period. I would suggest looking at the archive records coming directly out of the driver(note that is different to observing loop packets/archive records on the console when running WeeWX directly, running WeeWX directly shows packets/records after all services have processed the packet/record), if ET is there then you answer lies in the driver. If it is not it is StdWXCalculate or StdArchive that is calculating it then we need to look at those services.

Gary

[gjr80]

Also, remember under a traditional Davis console/logger/vantage driver setup you will see approx 120 loop packets per five minute archive record. So seeing an archive record value that is 100 times a loop value is not unreasonable for a cumulative field such as ET or rain. The difference here is that a traditional Davis console/logger/vantage driver setup you do not see loop ET values.

The only way to know if it it working properly is to understand who is emitting what and then do the maths to confirm the result one way or another.

Gary

[bell...@gmail.com]

I think the next step would be to capture the loop packets between two archive records and manually sum up the ET values. Or you could estimate the number of loop packets between archive records and if it is close to 100 call it done. Net, it seems like everything is working as expected. MQTTSubscribeDriver is creating the packets. WeeWX is summing the ET values in the packets to create the archive record.

Mulling this over a bit more, I think setting contains_total = true for your etday field might be the answer. This was added for MQTT rain data that is cumulative to calculate a delta for WeeWX.

rich

[gary....@gmail.com]

This seems to work. Currently ET at the logger is 0.002 so it is being reported in loop packets as 0.0
I'll see later in the day, but it sounds like exactly what is needed in this case.

[gary....@gmail.com]

Perhaps I need a tutorial on ET as used by reported by WeeWX.

So, I have made the setting change suggested.

Loop values have remained at  ET: 0.0

I'd think the actual value sent by the logger should be the value displayed by the skin. Kinda like weatherlink does.

[bell...@gmail.com]

You and me both... It might be worth seeing what a full day looks like. Also, if it would work for you using the day/month/year ET values might make sense...

[G Hammer]

Well, it reset the etday at midnight I'm going to say. Nothing has been displayed until now and ET is accumulated mostly during the day.

I'm puzzled with this one as it makes zero sense.

The way ET works on the console, the WLL and weatherlink.com, and in the real-time stats from WiFiLogger is as the various parameters that make up ET grow during a day, the etday is updated. At the end of the day, it is zeroed.

So, the ET value in WeeWX does not accumulate/add that value each time it is reported. It stays 100 times what is in the loop. etday=1 ET=100, etday=2 ET=200, if etday stops growing at 2, ET will remain at 200.

Somewhere, the calculation is just flat incorrect. WeeWX has no idea what device is sending the data as the driver is not tied to hardware. No more records are being sent than are reflected in the loop records, archives are being created every 300 seconds.

I'm going to install a different skin tomorrow and see if this remains the same.

Stay tuned.

--

You received this message because you are subscribed to a topic in the Google Groups "weewx-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/weewx-user/oo6K0FVMny4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to weewx-user+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/d258f315-8929-46f3-99b1-0e11dee81541n%40googlegroups.com.

[Tom Keffer]

In WeeWX, ET is treated like any other extensive quantity: a record contains the amount of evaporation that happened during the archive period, not the total for the day. Think of it as anti-rain. 

One complication: the Vantage series hardware emits ET only on the top of an hour. It is the amount of evaporation that happened during the hour. So, if you use hardware record generation, expect a non-zero value only once an hour. If you use software generation, it will appear with every archive record. 

That's how WeeWX treats it. As for how it's arriving from your MQTT feed, I have no idea.

Finally, how it appears in a skin depends on what tag is used. Usually you want something like $day.ET.sum, which would be the total ET for the day, just like $day.rain.sum is the total rain for the day.

-tk

You received this message because you are subscribed to the Google Groups "weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/CALBRR-1uXPeXk3mMaXsW7K1iT7CQaZEEjEGoD%3DmvMEiDoXLbvg%40mail.gmail.com.

[gary....@gmail.com]

Thanks for the detailed ET tutorial.

I do have a couple of lingering questions.

For my purposes, it isn't critical to use the MQTT server for data acquisition. So, I reset the WeeWX instance to stock/clean state and ran ./bin/wee_config --reconfig selecting Vantage driver, answering ethernet to connection method. In the weewx.conf I do notice I can choose LOOP1, LOOP2, or both. I left all at the defaults.

I made one change to the resulting weewx.conf file adding loop_on_init = True

With the stock/default settings, I let weewx run for awhile before and after the hour.

The first report cycle, the Seasons skin had no ET displayed.

As you said, after the top of the hour, there is ET displayed. However, it is 0.00, the High/Low has 0.00 0.00  The loop packet has  dayET: 0.013

I see this in the current.inc and it looks like there should be data displayed.

#if $day.ET.has_data and $day.ET.sum.raw is not None and $day.ET.sum.raw > 0.0

      <tr>

        <td class="label">$obs.label.ET</td>

        <td class="data">$current.ET</td>

My question is this. If the console is reporting ET values, and the skin wants to show ET values, when would the skin display the ET value?