Aaah, now I start to understand! The first part is just a definition. Got
it! Thanks!!!!
In skin.conf stanza [Labels] [Generic] I found
txBatteryStatus = Transmitter
I replaced the left side with wh65_batteryStatus
In Seasons.inc I found:
#set $have_battery_status = 0
#for $x in [$day.txBatteryStatus, $day.windBatteryStatus,
$day.rainBatteryStatus, $day.outTempBatteryStatus, $day.inTempBatteryStatus]
#if $x.has_data
#set $have_battery_status = 1
#end if
#end for
and later on:
#if $have_battery_status
<tr><th>Batterie Status</th><th></th></tr>
#if $day.txBatteryStatus.has_data
<tr>
<td class="label">$obs.label.txBatteryStatus</td>
<td class="data">$get_battery_status($current.txBatteryStatus
.raw)</td>
</tr>
#end if
I replaced all txBatteryStatus entries by wh65_battery except
$obs.label.wh65_batteryStatus according to the label in skin.conf.
First, all this looks simply logic. However, now the sensors data were no
longer displayed at all. Checked for typos. Nope. So, my logic failed again.
I then tried to replace all entries step by step. So, at first, it was
evident, that the expression #for $x in [$day.txBatteryStatus, ... still
results in status = 1, but not, when replaced with $day.wh_65battery,.
Ok, next step. Then I have to keep the original condition also here:
#if $have_battery_status
<tr><th>Batterie Status</th><th></th></tr>
#if $day.txBatteryStatus.has_data
<tr>
but still use the new values in the next two lines here:
<td class="label">$obs.label.wh65_batteryStatus</td>
<td class="data">$get_battery_status($current.wh65_battery.raw)</td>
</tr>
#end if
So, finally everything looks fine, same like the results from
interceptor.py. But why do I still need txBatteryStatus? Where does this
value come from? Obviously $current.wh65_battery returns a valid result,
thus providing data. But it is not suitable for evaluating $x. This is
still not logical to me...
Actually to me it looks like txBatteryStatus is not the Ecowitt-client
field name, as mentioned in my first post here, but is an internal field
name in Weewx (or why is it regularily used in seasons.inc?). So, it could
have been much less complicated to map wh65_batt to txBatteryStatus. But I
am afraid, that there still was something wrong with it.
Peter
gjr80 schrieb am Donnerstag, 17. Dezember 2020 um 11:24:17 UTC+1:
> 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/7664a566-04e3-4428-8850-4a9abb8bcf63n%40googlegroups.com.
