As I could not wait for an answer, I tried to replace $x in the example mentioned above (marked in yellow) by any of the supposed expressions. But in any case I get this type of error: ERROR weewx.cheetahgenerator: Generate failed with exception '<class 'TypeError'>' ERROR weewx.cheetahgenerator: **** Ignoring template /etc/weewx/skins/alltimeSeasons/index.html.tmpl ERROR weewx.cheetahgenerator: **** Reason: 'UnknownType' object is not subscriptable
neither $get_battery_status($current.wh65_batt.raw) nor $current.wh65_batt or $current.wh65_battery or any other combination works. I must admit, that I do not understand, what I am doing. This python coils. Vetti52 schrieb am Mittwoch, 16. Dezember 2020 um 14:18:26 UTC+1: > 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. > 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? > > 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? > > Peter > gjr80 schrieb am Dienstag, 15. Dezember 2020 um 23:51:10 UTC+1: > >> Some comments below. Hopefully it gives you a process to work through to >> identify your problem. >> >> Gary >> >> On Wednesday, 16 December 2020 at 06:37:40 UTC+10 Vetti52 wrote: >> >>> Well, I started this conversation already at another thread ( >>> https://groups.google.com/g/weewx-user/c/ua0JjTp1DW8/m/AFGZf7AyAgAJ), >>> concerning wind.gust.dir in version 4.2.0. As TK managed to solve the main >>> problem, there is still the other part unsolved. So, I want to move this >>> topic into a new thread, knowing, that there were similar questions during >>> the last months, whicht could help only partially. >>> >>> I am not able to change from interceptor's ecowitt-client to GW1000 >>> without loss of some data. Gary provided the crucial hints in the thread >>> mentioned above, which brought me almost to the successful end of this >>> story. But still one thing remains to be much too complicated for me: >>> >>> According to Gary's explanations, I introduced an extra stanza in >>> weewx.conf: >>> # Options for extension 'GW1000' >>> [GW1000] >>> driver = user.gw1000 >>> [[field_map_extensions]] >>> # WeeWX field name = GW1000 field name >>> rainEvent = rainevent >>> wh65_battery = wh65_batt >>> >>> I took these two values from the original ecowitt-client mappings in >>> interceptor.py: >>> >>> DEFAULT_SENSOR_MAP = { >>> ... >>> 'rainEvent': 'rain_event', >>> 'UV': 'uv', >>> >>> where the Weewx field is on the left and the Ecowitt-client field to the >>> right side. >>> And here is the other map in weewx.conf: >>> >>> [Interceptor] >>> driver = user.interceptor >>> device_type = ecowitt-client >>> mode = listen >>> port = 9000 >>> [[sensor_map_extensions]] >>> txBatteryStatus = wh65_battery >>> >>> Here, the Ecowitt client field is at the left and thus the Weewx field >>> should be to the right. >>> >> >> Not quite, the sensor map extensions in weewx.conf for the interceptor >> driver are in the format: >> >> WeeWX field name = interceptor field name >> >> This convention has been used by the WeeWX development team now for some >> time in all contemporary drivers with some form of sensor/field mapping. >> Note, drivers developed by others may or may not use the same convention. >> >> >>> The GW1000 field map extension works! But this is true only for >>> rainEvent, no for the battery status. I had a look into sensors.inc in the >>> seasons skin: >>> >>> #def get_battery_status($x) >>> #if $x == 0 >>> <span class="status_ok">$x: GOOD</span> >>> #else >>> <span class="status_low">$x: LOW</span> >>> #end if >>> #end def >>> >>> and found out, that, using the ecowitt-client, $wx == 0.0, but with >>> GW1000 it does not even exist, no value at all. Although I trend to assume, >>> that I understand now, how the mappings work (thanks to Gary), I am still >>> helpless to map the battery sensor properly. >>> >>> Hopefully someone can bring me on the right track. >>> >> >> I think you need to be taking a step back working through this in a >> methodical manner. Data that goes from sensor to web page is processed by >> many different parts of WeeWX each of which could be the cause of your >> problem. The driver reads sensor data and emits data in loop packets, the >> StdArchive service accumulates these loop packets and emits archive >> records, the StdReport service then uses Cheetah and a system of tags to >> present this data in a report. At the moment you are looking at the very >> last step in the process and the result is not what you expect. To >> troubleshoot you need to work through the process from driver onwards. >> >> First up, is the GW1000 driver actually emitting reinvent and wh65_batt >> fields. This can be checked by running the GW1000 driver directly with the >> --live-data command line option, something like: >> >> $ PYTHONPATH=/home/weewx/bin python -m user.gw1000 --live-data >> >> Note you may need to use PYTHONPATH=/usr/share/weewx if WeeWX was >> installed as a package and you may need to explicitly specify the python >> version to run by replacing python with python2 or python3. >> >> The command should result all sensor data available to the GW1000 being >> displayed on the console. The data is raw data from the console before any >> mapping, so you should be looking for rainevent and wh65_batt fields. Do >> they exist, if so good, if not then the GW1000 driver is not obtaining data >> from the relevant sensor. >> >> If you have rainevent and wh65_batt fields the next thing to check is >> the operation of the field mapping. The field mapping occurs in the GW1000 >> driver so you need to look at the loop packets emitted by the GW1000 driver >> to see what they contain. If you have the following in >> [[field_map-extensions]]: >> >> [[field_map_extensions]] >> >> rainEvent = rainevent >> wh65_battery = wh65_batt >> >> >> Then you should see fields rainEvent and wh65_battery in the loop >> packets emitted by the GW1000 driver. The easiest way to do this is to run >> WeeWX directly <http://weewx.com/docs/usersguide.htm#Running_directly> >> and observe the loop packet output (lines beginning with LOOP:) on the >> console. Do the loop packets include field rainEvent and wh65_battery? If >> so the field mapping extensions are working as they should and the issue >> lay further up the chain. If the fields to no exist the issue is within he >> driver and/or the field map extensions. >> >> If the rainEvent and wh65_battery fields exist in the loop packets then >> you need to check to ensure they are appearing in the WeeWX generated >> archive records; let WeeWX continue to run directly and wait for an archive >> record to be emitted (line beginning with REC:). Do rainEvent and >> wh65_battery fields appear in the archive record? If yes then the issue >> is likely in the report generation, if no then we have a serious problem >> with the StdArchive service. >> >> When looking at the StdReport service the first thing to check is your >> template. Start simple and work up to the complex. Can you display the >> fields you are interested in with $current tags, eg $current.rainEvent >> and $current.wh65_batt. If you are intending to use these fields in a >> comparison or expression are you using them with the .raw formatting (eg >> $current.rainEvent.raw which gives a number) or some other formatting >> which gives a string (eg $current.wh65_batt gives a string)? >> >> >> --ph >>> >> -- 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/595ee336-c1a6-4d9b-8ea3-b38bd1e650c5n%40googlegroups.com.
