Peter,
Comments below.
Gary
On Wednesday, 16 December 2020 at 23:18:26 UTC+10 Vetti52 wrote:
> Thanks, Gary, for your polite explanations.
> Since I have read some of your comments with equal advices in other
> threads, I proceeded already to sucessfully map the fields. Otherwise I did
> not even had an idea about field_map in GW1000. Sorry, that you need to
> explain again and again the comparison of --live-data and mapped loop data.
> But at that point, I feel better, not to miss any point. Thanks for your
> patience.
>
I noted you had worked through the mappings, I wanted to outline the entire
process, mainly for the next person that comes along.
> Well, data are mapped, weewx running directly gives this output:
>
> $ sudo weewxd /etc/weewx/weewx.conf
> LOOP: 2020-12-16 13:29:56 CET (1608121796) altimeter: 30.09246486970751,
> appTemp: 46.07291271146897, barometer: 30.092169667712717, cloudbase:
> 944.6426189788297, dateTime: 1608121796, daymaxwind: 3.6, dayRain: 0.0,
> dewpoint: 45.0455158818643, heatindex: 47.403000000000006, humidex:
> 48.934644083871206, inDewpoint: 50.88299985988465, inHumidity: 60, inTemp:
> 65.12, luminosity: 8184.0, maxSolarRad: 86.02828823732644, monthRain:
> 0.6653543307086613, outHumidity: 87, outTemp: 48.74, pressure:
> 29.97589031125, radiation: 64.59352801894238, rain: None, rainEvent:
> 0.4015748031496063, rainRate: 0.0, relbarometer: 1019.2, usUnits: 1, UV:
> 0, uvradiation: 6.5, weekRain: 10.9, wh65_battery: 0, windchill: 48.74,
> windDir: 187, windGust: 3.3554127779089566, windGustDir: None, windSpeed:
> 2.6843302223271652, yearRain: 29.17716535433071
> LOOP: 2020-12-16 13:30:56 CET (1608121856) altimeter: 30.09542729292998,
> appTemp: 45.69491271146897, barometer: 30.095134121428384, cloudbase:
> 944.6426189788297, dateTime: 1608121856, daymaxwind: 3.6, dayRain: 0.0,
> dewpoint: 45.0455158818643, heatindex: 47.403000000000006, humidex:
> 48.934644083871206, inDewpoint: 50.88299985988465, inHumidity: 60, inTemp:
> 65.12, luminosity: 8075.0, maxSolarRad: 85.3176898825967, monthRain:
> 0.6653543307086613, outHumidity: 87, outTemp: 48.74, pressure:
> 29.978843310000002, radiation: 63.73322809786898, rain: 0.0, rainEvent:
> 0.4015748031496063, rainRate: 0.0, relbarometer: 1019.3, usUnits: 1, UV:
> 0, uvradiation: 6.4, weekRain: 10.9, wh65_battery: 0, windchill:
> 47.93087953525257, windDir: 162, windGust: 5.816048815042191, windGustDir:
> None, windSpeed: 3.3554127779089566, yearRain: 29.17716535433071
> REC: 2020-12-16 13:30:00 CET (1608121800) altimeter:
> 30.09246486970751, appTemp: 46.07291271146897, barometer:
> 30.092169667712717, cloudbase: 944.6426189788297, dateTime: 1608121800,
> daymaxwind: 3.6, dayRain: 0.0, dewpoint: 45.0455158818643, ET:
> 0.00012174671890853505, extraTemp1: 124.89439999999999, heatindex:
> 47.403000000000006, humidex: 48.934644083871206, inDewpoint:
> 50.88299985988465, inHumidity: 60.0, inTemp: 65.12, interval: 5.0,
> luminosity: 8184.0, maxSolarRad: 86.02828823732644, monthRain:
> 0.6653543307086613, outHumidity: 87.0, outTemp: 48.74, pressure:
> 29.97589031125, radiation: 64.59352801894238, rain: 0.0, rainEvent:
> 0.4015748031496063, rainRate: 0.0, relbarometer: 1019.2, usUnits: 1, UV:
> 0.0, uvradiation: 6.5, weekRain: 10.9, wh65_battery: 0.0, windchill:
> 48.74, windDir: 187.0, windGust: 3.3554127779089566, windGustDir: 187,
> windrun: 0.22369418519393044, windSpeed: 2.6843302223271652, yearRain:
> 29.17716535433071
>
> So I am glad to see, that the StdArchive service is ok. Right?
>
Yes. One small thing though that I did not highlight is the accumulator
extractor functions. By default when WeeWX synthesises an archive record
from the accumulated loop data WeeWX takes the average of the accumulated
values for each field. In essence you get the average value of the filed in
the archive period. For something like temperature this is appropriate, but
for something like WeeWX field rain (the amount of rainfall seen in the
archive period) we want the sum not the average. For something like
rainEvent which is a cumulative value we likely want the last value seen
rather than the average (and certainly not the sum). Similarly for
wh65_battery, if we had two loop packets arrive in the archive period and
the first one had wh65_battery = 0 and the last had had wh65_battery = 1 do
we want the resulting archive record to have wh65_battery = 0.5? No, we ant
it to have the last value seen ie 1.
The way we tell WeeWX how to extract a given archive record field from the
accumulated loop data is by specifying the extractor function to use in
weewx.conf. In your case you will need to add something like the following
to weewx.conf:
[Accumulator]
[[rainEvent]]
extractor = last
[[wh65_battery]]
extractor = last
If you have a look in weewx.conf you will likely find an [Accumulator]
stanza towards the bottom of weewx.conf already. You will likely find it
already has a [[wh65_batt]] entry and not [[rainEvent]] entry. You will
need to add the [[wh65_battery]] and [[rainEvent]] entries above anywhere
under [Accumulator].
> Your last question needs some explanation and preparation: I am no longer
> bothering with rainEvent, as this works now as expected. Thus, my approach
> focussing wh65_battery data, was, that I looked at the output the value
> of $x in sensors.inc. So, when interpreting your question, I should not
> print $x, but $current.rainEvent.raw instead at the same place? Sorry for
> the dumb question, but I do not clearly understand the difference between
> $current and $current.raw. To me the format of the recorded battery value
> is a decimal number. When using interceptor's Ecowitt-client, $x returns
> this value as a decimal number 0.0 as well. So, do you expect, that in case
> of GW1000 the recorded number is converted into a string and thus not
> evaluated in #if $x == 0 ? Said that, should I simply compare the output
> of $current.wh65_batt and $current.wh65_batt.raw instead of $x at the
> same place I depicted above?
>
I have not had much experience with declaring and using in-template
functions in Cheetah, but given your get_battery_status() declaration you
will need to call it using $get_battery_status($current.wh65_battery.raw).
You indicated you were using $current.wh65_batt.raw but that will not work
as changing the mapping of wh65_batt to now map it to wh65_battery means
that wh65_batt no longer appears in your loop packets/archive records,
instead you now have wh65_battery (refer to the above LOOP: and REC:
output).
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/weewx-user/5756ce7e-f787-4439-a5a2-7ed278d24087n%40googlegroups.com.
