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, 'michael.k...@gmx.at' via weewx-user < > weewx...@googlegroups.com> 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. > michael.k...@gmx.at 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) ? >>> >>> michael.k...@gmx.at 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 >>>>> >>>>> michael.k...@gmx.at 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 <peterq...@gmail.com> 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 weewx-user+...@googlegroups.com. > > 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 weewx-user+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/weewx-user/e4f96e3b-c545-4511-a423-8b0ddc08d52bn%40googlegroups.com.
