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/7133cc1f-c7ad-45f8-b410-e7748c389b04n%40googlegroups.com.
