Ok, I added the entries into accumulator. So, this part is completed now. 
But still the battery value is missing. 

The construct in sensors.inc
#def get_battery_status($x)
#if $x == 0
<span class="status_ok">$get_battery_status($current.wh65_battery.raw : 
GOOD</span>
#else
<span class="status_low">$get_battery_status($current.wh65_battery.raw : 
LOW</span>
#end if
#end def 

does not work either. The error is somewhat different:
ERROR weewx.cheetahgenerator: Generate failed with exception '<class 
'RecursionError'>'
ERROR weewx.cheetahgenerator: **** Ignoring template 
/etc/weewx/skins/alltimeSeasons/index.html.tmpl
ERROR weewx.cheetahgenerator: **** Reason: maximum recursion depth exceeded

I think, that there is an extra turn, I do not understand at all. I can 
see, that this expression seems to evoke a recursion. So, where comes the $x 
from? Why does it only work starting with #def, but not with $? This is to 
much inside knowledge for me. And I am not sure, that an explanation of 
this part would help. Anyway, it seems, that there is a black hole between 
StdArchive and Record, concerning the battery thing. 
gjr80 schrieb am Donnerstag, 17. Dezember 2020 um 07:54:13 UTC+1:

> 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/a3d2e8d5-67a1-43f5-b137-af41070b9c8cn%40googlegroups.com.

Reply via email to