And for the record: [image: 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: [image: 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.
