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/16456dc0-f5c3-4c9b-b3da-37a21c39b095n%40googlegroups.com.

Reply via email to