No, I did not say to change the get_battery_status() definition, what I sad
was that elsewhere in your template, where you call get_battery_status(),
you need to call it using $get_battery_status($current.wh65_battery.raw).
You should put the get_battery_status() definition back how it was.
sensors.inc should look something like:
## sensors module for weewx skins
## Copyright Tom Keffer, Matthew Wall
## See LICENSE.txt for your rights
#errorCatcher Echo
#encoding UTF-8
## this is a conditional display of sensor data, including connectivity,
## battery status, and various voltages. if there are no data available,
## then this degenerates to nothing displayed.
#def get_battery_status($x)
#if $x == 0
<span class="status_ok">OK</span>
#else
<span class="status_low">LOW</span>
#end if
#end def
...
#if $day.wh65_battery.has_data
<tr>
<td class="label">$obs.label.wh65_battery</td>
<td class="data">$get_battery_status($current.wh65_battery.raw)</td>
</tr>
#end if
...
Note that in the example I gave above you would need to define a label for
wh65_battery under [Labels] [[Generic]] in skin.conf, eg
[Labels]
# Override some labels. No need to identify these as a "Battery"
# or "Voltage", because that is included in the template.
[[Generic]]
wh65_battery = WH65
...
Gary
On Thursday, 17 December 2020 at 20:09:18 UTC+10 Vetti52 wrote:
> Typo: $get_battery_status($current.wh65_battery.raw), of course with
> closed brakets
>
> Vetti52 schrieb am Donnerstag, 17. Dezember 2020 um 11:01:26 UTC+1:
>
>> 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/d125ad97-e46f-4324-93af-079d31d72252n%40googlegroups.com.
