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/7e90939d-aff3-4efb-8037-7077521a969en%40googlegroups.com.
