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/8c5eb391-b56e-46f3-920e-b808cb67aa7cn%40googlegroups.com.
