May be because the default [Accumulator] section contained in the driver code ( in class EcowittHttpDriverConfEditor) seems not to be used !
The driver contain the following function : def confeditor_loader(): return EcowittHttpDriverConfEditor() which should use the Accumulator defaults, but this function is never called within the driver. Le dimanche 14 septembre 2025 à 12:46:57 UTC+2, [email protected] a écrit : > @Ian: > > The point I refer to is the following: > > I use Werner's ecowitt_http.py, afaik he modified it in a way, that > ecowitt devices with piezo rain gauges map the piezo sensor readings to > "hail", so he didn't have to extend the database and he just uses "hail" > for piezo rain readings, labeling it accordingly in the presentation. I > extended the database, a later version Werner published then also mapped > the piezo sensor data to "p_rain". So, using Werner's driver with an > extended schema for "p_rain", in the database "p_rain" and "hail" should > read exactly the same values. They do. (although it's odd they do, see > below) > > Werner's ecowitt_http.py contains an [Accumulator] section, which > contains a [[hail]] section, but it *doesn't* contain a [[p_rain]] > section. > > Now here's the thing: if specifying > > [Accumulator] > [[p_rain]] > extractor = sum > is necessary to get correct readings from the sensor, why don't include > this in the ecowitt_http.py already, just like with "hail"? And there is > the other thing: why is "hail" (the very same data from the piezo sensor) > also wrong in the database? In the ecowitt_http.py driver file there is > already > [Accumulator] > [[hail]] > extractor = sum > Werner himself has this setting another time in his weewx.conf, which > shouldn't be necessary, since it is already in the driver's defaults. > > So I assume there is something wrong in the driver getting the correct > defaults. In addition to correct this possible issue, a default for > "p_rain" should be set in the driver. > steepleian schrieb am Sonntag, 14. September 2025 um 12:12:24 UTC+2: > >> @Michael, >> I think it must be something specific in the way hail is used by WeeWX. >> With the piezo I just added extra columns in the database which mirrored >> the rain columns and it worked without issues. If you do not wish to extend >> the database maybe worth trying another spare existing column. >> >> https://claydonsweather.org.uk >> >> On 14 Sep 2025, at 10:16, '[email protected]' via weewx-user < >> [email protected]> wrote: >> >> OK, that's the missing piece. In the driver's [Accumulator] defaults >> there is no >> >> >> [[p_rain]] >> extractor = sum >> >> But for "hail" it's there, making me wonder why it doesn't work for >> "hail"? >> [email protected] schrieb am Sonntag, 14. September 2025 um 11:02:49 >> UTC+2: >> >>> Because the accumulator rule for "rain" is set by default to "sum" in >>> /weewx/accum.py >>> >>> Le dimanche 14 septembre 2025 à 10:41:16 UTC+2, [email protected] a >>> écrit : >>> >>>> Still, I wonder why this is necessary for "p_rain", while it isn't for >>>> "rain". Same data source, same observation type (not the sam obs_type!) >>>> different source, it seems inconsistent to me. >>>> >>>> [email protected] schrieb am Sonntag, 14. September 2025 um 10:30:36 >>>> UTC+2: >>>> >>>>> [Accumulator] >>>>> [[p_rain]] >>>>> extractor = sum >>>>> >>>>> Seems to do the trick. I remember having it commented out in a prior >>>>> version and it didn't change anything I was aware of. Thanks for the help. >>>>> >>>>> For hail, I think still think it shouldn't be mapped to the piezo >>>>> gauge in the driver, if you need it that way, I'd suggest you set it in >>>>> the >>>>> Corrections Stanza in your config. >>>>> Werner Krenn schrieb am Samstag, 13. September 2025 um 18:28:04 UTC+2: >>>>> >>>>>> Also missing: >>>>>> >>>>>> loop_on_init = 1 >>>>>> >>>>>> Werner Krenn schrieb am Samstag, 13. September 2025 um 18:22:30 UTC+2: >>>>>> >>>>>>> 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/d58615c9-d52f-46cd-af97-3408549fede9n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/weewx-user/d58615c9-d52f-46cd-af97-3408549fede9n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> -- 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/5fde3f7f-2384-45ee-b35f-8602ba03fd28n%40googlegroups.com.
