The approach I took when writing the driver was to pass through all of the available Ecowitt fields, whether or not they are used by WeeWX, so the user can make use of them if they wish (eg WeeWX does not need/use day rain, week rain, month rain etc fields but the driver uses one of them to derive WeeWX field rain, but the driver already knows what units these cumulative rain fields use so the driver does not need a unit group). What I did was apply unit groups to all of the Ecowitt fields that equate to fields in the WeeWX extended schema. This was the wrong approach, as invariably there will users wishing to use these additional fields (and they are not just rain based, off the top of my head there is a UV based one as well) and without a unit group they will cause errors for anyone wanting to display/use them outside of their native (Ecowitt) units. So if an Ecowitt field is being passed through by the driver it should come with a unit group assigned if one exists, this is the approach that will be taken in the next driver release.
In terms of mapping, yes you should have a mapping for all available Ecowitt fields the driver does this by default, it is just the unit group that is missing from some. Gary On Friday, 16 June 2023 at 07:50:00 UTC+1 [email protected] wrote: > Thanks for confirming. Since you've already identified more fields than I > did and they are already in the master, there's no need for a pull request > :) > Interestingly, for dayRain, monthRain , yearRain, and stormRain I already > have a mapping. Maybe I should take a closer look, where these mapping are > coming from, on my installation, if they are not weewx standard. > > Btw.: I'm new to the "Ecowitt universe" and really appreciate your work on > the driver. The variety of supported hardware is imho one of the key > factors for weewx' success. > > gjr80 schrieb am Donnerstag, 15. Juni 2023 um 21:56:37 UTC+2: > >> Yes they should be included, and to take it further so should dayRain, >> monthRain , yearRain, totalRain and stormRain. >> >> To be fixed in the next release. In the interim the following code added >> to user/extensions.py will achieve the same end: >> >> import weewx.units >> weewx.units.obs_group_dict['dayRain'] = 'group_rain' >> weewx.units.obs_group_dict['weekRain'] = 'group_rain' >> weewx.units.obs_group_dict['monthRain'] = 'group_rain' >> weewx.units.obs_group_dict['yearRain'] = 'group_rain' >> weewx.units.obs_group_dict['totalRain'] = 'group_rain' >> weewx.units.obs_group_dict['stormRain'] = 'group_rain' >> weewx.units.obs_group_dict['p_rainRate'] = 'group_rainrate >> >> Gary >> >> On Thursday, 15 June 2023 at 20:27:25 UTC+1 [email protected] wrote: >> >>> Version of driver used: v0.5.0b5 >>> <https://github.com/gjr80/weewx-gw1000/commit/be1ca870c3e0142cd51566e78989e172ca66c452> >>> >>> In default_groups: >>> https://github.com/gjr80/weewx-gw1000/blob/master/bin/user/gw1000.py#L455 >>> >>> Shouldn't there be values for "weekRain" and "p_rainRate"? Without them >>> specified I have issues with the unit. >>> >>> default_groups = {'extraTemp9': 'group_temperature', >>> 'extraTemp10': 'group_temperature', >>> 'extraTemp11': 'group_temperature', >>> 'extraTemp12': 'group_temperature', >>> 'extraTemp13': 'group_temperature', >>> 'extraTemp14': 'group_temperature', >>> 'extraTemp15': 'group_temperature', >>> 'extraTemp16': 'group_temperature', >>> 'extraTemp17': 'group_temperature', >>> 'weekRain': 'group_rain', >>> 'p_rain': 'group_rain', >>> 'p_rainRate': 'group_rainrate', >>> 'p_stormRain': 'group_rain', >>> 'p_dayRain': 'group_rain', >>> 'p_weekRain': 'group_rain', >>> 'p_monthRain': 'group_rain', >>> 'p_yearRain': 'group_rain'} >>> >>> >>> -- 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/57bcc9c1-3f66-4796-8000-2edab9bd8398n%40googlegroups.com.
