| @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 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"?
Because the accumulator rule for "rain" is set by default to "sum" in /weewx/accum.py
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.
[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: 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
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.
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 # how many attempts to contact the device before giving up max_tries = 3 # wait time in seconds between retries to contact the device # max wait for device to respond to a HTTP request # 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 <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: ![rain_vs_p_rain.png]() ![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) ?
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
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:
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].
--
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.
--
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/0A9B5F40-E3A5-4F77-BF71-11CAA0AAB164%40btinternet.com.
|