The difference I noticed compared to my weewx.conf is (missing in your case)
[StdWXCalculate] [[Calculations]] rain = prefer_hardware p_rain = prefer_hardware hail = prefer_hardware [Accumulator] [[p_rain]] extractor = sum [[hail]] extractor = sum [email protected] schrieb am Samstag, 13. September 2025 um 15:34:57 UTC+2: > Im really curious. My extensions.py contains apart from comments these > four lines: > > import locale > import weewx.units > locale.setlocale(locale.LC_ALL, '') > weewx.units.obs_group_dict['p_rainRate'] = 'group_rainrate' > > And the config is attached. > Werner Krenn schrieb am Samstag, 13. September 2025 um 14:56:55 UTC+2: > >> Today, I installed a new instance of WeeWx with the EcowittHttp driver >> and the >> database schema >> schema = schemas.wview_ecowittrssi.schema >> and the setting >> [StdConvert] >> target_unit = METRICWX >> for testing purposes. >> >> The extensions.py file has no entries. >> >> The piezo rain quantity is saved to the database with mm values, as >> expected. >> >> @Michael, >> Your problem with the incorrect entries for piezo rain quantity >> in the database can only be due to your settings (weewx.conf and/or >> extensions.py). >> >> You are welcome to send me your weewx.conf for review. >> >> [email protected] schrieb am Freitag, 12. September 2025 um 19:02:40 >> UTC+2: >> >>> p_rain = piezoRain.0x10.val >>> >>> Is not the rain for the given loop. Without calculating a delta, you get >>> ridiculous amounts of rain. I have no such delta define, you? >>> >>> Ian Millard schrieb am Freitag, 12. September 2025 um 18:19:13 UTC+2: >>> >>>> @Michael, >>>> >>>> I have added piezo rain columns to my database and then set up mapping >>>> like this: - >>>> >>>> [EcowittHttp] >>>> # This section is for the Ecowitt local HTTP API driver. >>>> >>>> # the driver to use >>>> driver = user.ecowitt_http >>>> >>>> # how often to poll the device >>>> poll_interval = 8 >>>> # how many attempts to contact the device before giving up >>>> max_tries = 3 >>>> # wait time in seconds between retries to contact the device >>>> retry_wait = 2 >>>> # max wait for device to respond to a HTTP request >>>> url_timeout = 3 >>>> >>>> # whether to show all battery state data including nonsense data >>>> and >>>> # sensors that are disabled sensors and connecting >>>> show_all_batt = False >>>> # whether to ignore battery state data from legacy WH40 sensors >>>> that do >>>> # not provide valid battery state data >>>> ignore_legacy_wh40_battery = True >>>> # whether to always log unknown API fields, unknown fields are >>>> always >>>> # logged at the debug level, this will log them at the info level >>>> log_unknown_fields = False >>>> >>>> # How often to check for device firmware updates, 0 disables >>>> firmware >>>> # update checks. Available firmware updates are logged. >>>> firmware_update_check_interval = 86400 >>>> >>>> # provide additional log information to help debug rainfall issues >>>> debug_rain = False >>>> # provide additional log information to help debug wind issues >>>> debug_wind = False >>>> # provide additional log information to help debug loop packet >>>> issues >>>> debug_loop = False >>>> # provide additional log information to help debug sensor issues >>>> debug_sensors = False >>>> ip_address = 192.168.1.100 >>>> [[field_map_extensions]] >>>> batteryStatus1 = ws90.battery >>>> rain = rain.0x10.val >>>> stormRain = rain.0x0D.val >>>> rainRate = rain.0x0E.val >>>> hourRain = t_rainhour >>>> dayRain = rain.0x10.val >>>> weekRain = rain.0x11.val >>>> monthRain = rain.0x12.val >>>> yearRain = rain.0x13.val >>>> is_raining = piezoRain.srain_piezo.val >>>> p_rain = piezoRain.0x10.val >>>> p_stormRain = piezoRain.0x0D.val >>>> p_rainRate = piezoRain.0x0E.val >>>> p_hourRain = p_rainhour >>>> p_dayRain = piezoRain.0x10.val >>>> p_weekRain = piezoRain.0x11.val >>>> p_monthRain = piezoRain.0x12.val >>>> p_yearRain = piezoRain.0x13.val >>>> vpd = common_list.5.val >>>> lightning_distance = lightning.distance >>>> lightning_last_det_time = lightning.timestamp >>>> lightningcount = lightning.count >>>> pm2_5 = ch_pm25.1.PM25_RealAQI >>>> pm2_52_24h_avg = ch_pm25.1.PM25_24HAQI >>>> pm10_0 = co2.PM10 >>>> luminosity = common_list.0x15.val >>>> >>>> On 12 Sep 2025, at 16:23, '[email protected]' via weewx-user < >>>> [email protected]> wrote: >>>> >>>> And for the record: >>>> >>>> >>>> >>>> <rain_vs_p_rain_vs.hail.png> >>>> >>>> And I don't do anything with hail in my configs or elsewhere. >>>> >>>> And this is what's in the database, using the ecowitt gateway driver: >>>> >>>> <rain_vs_p_rain_vs.hail_ecowitt_gateway_driver.png> >>>> >>>> So with the ecowitt_http driver, the values for p_rain are >>>> p_rain(old)/29. This can't be an inch/mm conversion issue. 25,4 is too far >>>> off 29. >>>> [email protected] schrieb am Freitag, 12. September 2025 um 17:10:39 >>>> UTC+2: >>>> >>>>> No, I haven't and it won't change anything, because the js has no >>>>> effect on database entries (I know that, I'm the maintainer of the >>>>> Bootstrap skin for several years now and more than 90% of the js code was >>>>> done by myself). >>>>> >>>>> These are the values in the database for rain and p_rain for the Sep >>>>> 10, 17:00 - 17:30: >>>>> [image: rain_vs_p_rain.png][image: ecowitt_http_driver.png] >>>>> >>>>> >>>>> >>>>> Werner Krenn schrieb am Freitag, 12. September 2025 um 15:05:49 UTC+2: >>>>> >>>>>> @Michael, >>>>>> Have you tried adding p_rain: >>>>>> p_rain: "group_rain" >>>>>> to the file >>>>>> "units.js" (Bootstrap skin) ? >>>>>> >>>>>> [email protected] schrieb am Freitag, 12. September 2025 um >>>>>> 13:18:25 UTC+2: >>>>>> >>>>>>> My database contains values following METRICWX. >>>>>>> LOOP data also contains p_rain in [mm], so in the MQTT object for >>>>>>> the LiveGauges there is no payload_key "p_rain_in", only >>>>>>> "p_rain_mm", which is 100% I'd expected things to be. >>>>>>> I'll give it a try and use hail instead, and see what will happen, >>>>>>> maybe that gives us a clue what's happening. I mean: why should p_rain >>>>>>> [mm] >>>>>>> behave in another way than rain [mm]? Maybe there is something missing >>>>>>> in a >>>>>>> group/unit assignment for p_rain... it's not a common obs_type, neither >>>>>>> in >>>>>>> wview, nor wview_extended. >>>>>>> >>>>>>> Werner Krenn schrieb am Freitag, 12. September 2025 um 11:32:27 >>>>>>> UTC+2: >>>>>>> >>>>>>>> @Michael, >>>>>>>> I assume you're using >>>>>>>> target_unit = METRIC # Options are 'US', 'METRICWX', or 'METRIC' >>>>>>>> or >>>>>>>> target_unit = METRICWX >>>>>>>> >>>>>>>> I use target_unit = US >>>>>>>> I don't know why p_rain is being then written to the database in >>>>>>>> inches for you; I don't have enough experience with WeeWx for that. >>>>>>>> >>>>>>>> But if you use >>>>>>>> payload_key = p_rain_in >>>>>>>> the display should be correct >>>>>>>> >>>>>>>> [email protected] schrieb am Freitag, 12. September 2025 um >>>>>>>> 05:25:57 UTC+2: >>>>>>>> >>>>>>>>> May it's that I use p_rain and not hail: >>>>>>>>> >>>>>>>>> [[[[rain]]]] >>>>>>>>> [[[[[rain]]]]] >>>>>>>>> payload_key = rain_mm >>>>>>>>> [[[[[p_rain]]]]] >>>>>>>>> plotType = bar >>>>>>>>> aggregateType = sum >>>>>>>>> aggregateInterval = 1800 >>>>>>>>> payload_key = p_rain_mm >>>>>>>>> showMaxMarkPoint = false >>>>>>>>> showMinMarkPoint = false >>>>>>>>> showAvgMarkLine = false >>>>>>>>> lineColor = "#428bca77" >>>>>>>>> decimals = 1 >>>>>>>>> >>>>>>>>> The interesting thing is, when receiving data from LOOP using >>>>>>>>> MQTT, the value is correct, it's only the databa value that isn't. >>>>>>>>> John Smith schrieb am Freitag, 12. September 2025 um 03:57:19 >>>>>>>>> UTC+2: >>>>>>>>> >>>>>>>>>> On Fri, 12 Sept 2025 at 03:41, p q <[email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> I am pretty sure the US uses the international inch for far >>>>>>>>>>> longer. Since before I started working with canadian companies in >>>>>>>>>>> the >>>>>>>>>>> 1990s. There is official looking documentation that shows the >>>>>>>>>>> international >>>>>>>>>>> yard (and thus the inch) defined in 1959 >>>>>>>>>>> https://usma.org/wp-content/uploads/2015/06/sp447-app5.pdf?x40840 >>>>>>>>>>> There are still various survey foot definitions with slightly >>>>>>>>>>> different values in the US, and of course the nautical mile and >>>>>>>>>>> related >>>>>>>>>>> measures. >>>>>>>>>>> https://oceanservice.noaa.gov/geodesy/international-foot.html >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> If you disagree update the Wikipedia page with references... >>>>>>>>>> *grin* >>>>>>>>>> >>>>>>>>> >>>> -- >>>> 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 visit >>>> https://groups.google.com/d/msgid/weewx-user/a5efc423-6f71-4cf3-b5cd-ea89b33170f1n%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/weewx-user/a5efc423-6f71-4cf3-b5cd-ea89b33170f1n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> <rain_vs_p_rain_vs.hail_ecowitt_gateway_driver.png> >>>> <rain_vs_p_rain_vs.hail.png> >>>> >>>> >>>> -- 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 visit https://groups.google.com/d/msgid/weewx-user/0337200c-d34a-47a6-aea2-aa3f0e614f3cn%40googlegroups.com.
