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 weewx-user+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/2430bcd4-3db4-4064-9bb4-43d01a6c0ea5n%40googlegroups.com.
