Ecowitt_http driver initial release
1,062 views
Skip to first unread message
Werner Krenn
Jul 11, 2025, 12:16:17 PMJul 11
to weewx-user
The driver is almost complete.
The "service" function isn't working and hasn't been touched.
All settings in weewx.conf and further information are documented on GitHub:
The "service" function isn't working and hasn't been touched.
All settings in weewx.conf and further information are documented on GitHub:
michael.k...@gmx.at
Jul 11, 2025, 6:17:02 PMJul 11
to weewx-user
Has illuminance and radiation changed with the http API or why the change in the code?
What is the difference between your version and the original and why didn't you fork the original one?
Werner Krenn
Jul 12, 2025, 7:40:09 AMJul 12
to weewx-user
The reference for the field names in my case is "customized" and there is no "illuminance" field here,
but rather "solarradiation." This is because newer values are always made available first in "customized".
response for url http://192.168.0.110/get_livedata_info?
--> {"common_list":[
{ "id": "0x02", "val": "17.7", "unit": "C" },
{ "id": "0x07", "val": "79%" },
{ "id": "3", "val": "17.7", "unit": "C" },
{ "id": "5", "val": "0.43 kPa" },
{ "id": "0x03", "val": "14.0", "unit": "C" },
{ "id": "0x0B", "val": "0.00 km/h" },
{ "id": "0x0C", "val": "3.96 km/h" },
{ "id": "0x19", "val": "31.32 km/h" },
{ "id": "0x15", "val": "790.77 W/m2" },
{ "id": "0x17", "val": "7" },
{ "id": "0x0A", "val": "2" }],
You can get "illuminance" with
[StdCalibrate]
[[Corrections]]
luminosity = radiation * 126.7 if radiation is not None else None
The factor 126.7 you use may vary. This value can be obtained via
get_calibration_data?
--> {"SolarRadWave":"126.7","solarRadGain":"1.00" ...
This factor of 126.7 is a generally accepted value.
but rather "solarradiation." This is because newer values are always made available first in "customized".
response for url http://192.168.0.110/get_livedata_info?
--> {"common_list":[
{ "id": "0x02", "val": "17.7", "unit": "C" },
{ "id": "0x07", "val": "79%" },
{ "id": "3", "val": "17.7", "unit": "C" },
{ "id": "5", "val": "0.43 kPa" },
{ "id": "0x03", "val": "14.0", "unit": "C" },
{ "id": "0x0B", "val": "0.00 km/h" },
{ "id": "0x0C", "val": "3.96 km/h" },
{ "id": "0x19", "val": "31.32 km/h" },
{ "id": "0x15", "val": "790.77 W/m2" },
{ "id": "0x17", "val": "7" },
{ "id": "0x0A", "val": "2" }],
You can get "illuminance" with
[StdCalibrate]
[[Corrections]]
luminosity = radiation * 126.7 if radiation is not None else None
The factor 126.7 you use may vary. This value can be obtained via
get_calibration_data?
--> {"SolarRadWave":"126.7","solarRadGain":"1.00" ...
This factor of 126.7 is a generally accepted value.
>difference between your version and the original:
Short answer: My modified driver supports all currently possible sensors from Ecowitt and really ALL
michael.k...@gmx.at
Jul 12, 2025, 2:03:42 PMJul 12
to weewx-user
Yesterday at 23:45 CEST on my test system I switched from the ecowitt gateway driver to gary's ecowitt_http driver from and today at 11:10CEST I replaced the ecowitt_http.py with your version:
Three obvious things with your version:
Three obvious things with your version:
- radiation is there
- pm and co2 values are there
- your version seems to deliver absolute pressure for barometer
Werner Krenn
Jul 12, 2025, 3:44:37 PMJul 12
to weewx-user
>your version seems to deliver absolute pressure for barometer
Yes!
The complete mapping is also available on GitHub:
https://github.com/WernerKr/Ecowitt-or-DAVIS-stations-and-Season-skin/blob/main/ecowitt_http/Ecowitt_http_default_mapping.txtThis ensures that users of my Ecowittcustom driver can switch directly to this driver, or users of Oliver's FOSHKplugin can use it in conjunction with my Ecowittcustom driver.
michael.k...@gmx.at
Jul 13, 2025, 3:25:09 AMJul 13
to weewx-user
OK, I missed setting the altitude on this device. with 2x GW2000 and 2x GW3000 it's sometime hard to keep track of things :D The value before the first switch of drivers must have been from another device. Since I want to use the backfilling, I switched from GW2000 to GW3000.
Werner Krenn
Jul 13, 2025, 3:42:54 PMJul 13
to weewx-user
There's a change in "lightning_distance" in V0.1.3!
It's now provided as "lightning_dist" and requires a change in weewx.conf:
[StdCalibrate]
[[Corrections]]
lightning_distance_save = lightning_dist if lightning_dist is not None else None
lightning_distance = lightning_dist if lightning_strike_count > 0 else None
With the former setting:
lightning_distance = lightning_distance if lightning_strike_count > 0 else None
a value for lightning_distance was always recorded after retrieving data from Ecowitt.net or SDCard,
but with this change, this is no longer the case!
Where lightning_distance_save
saves the last received distance so that it can be represented as a value.
It's now provided as "lightning_dist" and requires a change in weewx.conf:
[StdCalibrate]
[[Corrections]]
lightning_distance_save = lightning_dist if lightning_dist is not None else None
lightning_distance = lightning_dist if lightning_strike_count > 0 else None
With the former setting:
lightning_distance = lightning_distance if lightning_strike_count > 0 else None
a value for lightning_distance was always recorded after retrieving data from Ecowitt.net or SDCard,
but with this change, this is no longer the case!
Where lightning_distance_save
saves the last received distance so that it can be represented as a value.
michael.k...@gmx.at
Jul 14, 2025, 9:27:33 AMJul 14
to weewx-user
Thank you for the update!
I encountered the following issue:
Situation:
- A WeeWX instance which uses the ecowitt http driver with a GW3000, a WH40 (for rain) and a WS90 (for p_rain)
- It is currently raining
- The loop value for rain is 'rain': '0.0', while the value for p_rain is 'p_rain': '3.6'
- Below the values from http://x.x.x.x/get_livedata_info
It seems that for p_rain the loop value is the current value from piezoRain.0x0D which is the sum of the current rain_event. This leads to to a wrong p_rain value, because every loop value is an augment to current sum. I don't know if this issue was already in the code before you altered it, or not.
"rain": [{
"id": "0x0D",
"val": "1.7 mm"
}, {
"id": "0x0E",
"val": "0.6 mm/Hr"
}, {
"id": "0x10",
"val": "1.7 mm"
}, {
"id": "0x11",
"val": "1.7 mm"
}, {
"id": "0x12",
"val": "98.9 mm"
}, {
"id": "0x13",
"val": "573.3 mm",
"battery": "5"
}
],
"piezoRain": [{
"id": "srain_piezo",
"val": "1"
}, {
"id": "0x0D",
"val": "3.6 mm"
}, {
"id": "0x0E",
"val": "1.2 mm/Hr"
}, {
"id": "0x10",
"val": "2.2 mm"
}, {
"id": "0x11",
"val": "2.2 mm"
}, {
"id": "0x12",
"val": "98.6 mm"
}, {
"id": "0x13",
"val": "665.7 mm",
"battery": "5",
"voltage": "3.22"
}
]
I encountered the following issue:
Situation:
- A WeeWX instance which uses the ecowitt http driver with a GW3000, a WH40 (for rain) and a WS90 (for p_rain)
- It is currently raining
- The loop value for rain is 'rain': '0.0', while the value for p_rain is 'p_rain': '3.6'
- Below the values from http://x.x.x.x/get_livedata_info
It seems that for p_rain the loop value is the current value from piezoRain.0x0D which is the sum of the current rain_event. This leads to to a wrong p_rain value, because every loop value is an augment to current sum. I don't know if this issue was already in the code before you altered it, or not.
"rain": [{
"id": "0x0D",
"val": "1.7 mm"
}, {
"id": "0x0E",
"val": "0.6 mm/Hr"
}, {
"id": "0x10",
"val": "1.7 mm"
}, {
"id": "0x11",
"val": "1.7 mm"
}, {
"id": "0x12",
"val": "98.9 mm"
}, {
"id": "0x13",
"val": "573.3 mm",
"battery": "5"
}
],
"piezoRain": [{
"id": "srain_piezo",
"val": "1"
}, {
"id": "0x0D",
"val": "3.6 mm"
}, {
"id": "0x0E",
"val": "1.2 mm/Hr"
}, {
"id": "0x10",
"val": "2.2 mm"
}, {
"id": "0x11",
"val": "2.2 mm"
}, {
"id": "0x12",
"val": "98.6 mm"
}, {
"id": "0x13",
"val": "665.7 mm",
"battery": "5",
"voltage": "3.22"
}
]
michael.k...@gmx.at
Jul 14, 2025, 10:35:02 AMJul 14
to weewx-user
Other things I stumbled across:
- There is an inconsistency with naming: ws68 vs. wh68 => there is only a ws68. The ecowitt gateway driver also used wh68 and probably sticked to it for not breaking anything.
- Some value mappings are missing: e.g. ws68 voltage ( common_list.0x0A.voltage if present) , soil moist voltage.
- A bit weird on the get_livedata_info: The WS68 voltage is in common_list.0x0A.voltage, when a WS68 is paired. If a WS90 is paired, there is no common_list.0x0A.voltage and no common_list.0x0A.battery. I assume that it's considered redundant since the WS90's voltage is shown in the piezoRain object.
Werner Krenn
Jul 14, 2025, 11:17:58 AMJul 14
to weewx-user
Since version 1.0.2, the difference between rain and piezo rain values is calculated directly in the driver and
provided as rain and hail, respectively. Therefore, no entry in weewx.conf is required.
#[[Delta]]
# [[[rain]]]
# input = t_rainyear
# [[[hail]]]
# input = p_rainyear
If you want to use the previous p_rain value, you can do so in the weewx.conf.
[StdCalibrate]
[[Corrections]]
p_rain = hail if hail is not None else None
Why this change:
When the rain/piezo rain data was imported from Ecowitt.net (cloud) or SD card,
some rain values were counted even though it wasn't raining at all.
Voltages and other values:
There is an email to Ecowitt's customer service about this:
Subject: Inconsistent data handling between Ecowitt cloud (ecowitt.net), SD card (GW3000), and local http API:
battery.rainfall_sensor
battery.wind_sensor
battery.haptic_array_capacitor
ch_lds?.ldsheat_ch1 ... ch4
from the displays:
battery.console
battery.ws1900
battery.ws1800
battery.ws6006
And there is now V1.0.4 because I had previously overlooked the fact
that no LDS data was retrieved from the data from Ecowitt.net.
provided as rain and hail, respectively. Therefore, no entry in weewx.conf is required.
#[[Delta]]
# [[[rain]]]
# input = t_rainyear
# [[[hail]]]
# input = p_rainyear
If you want to use the previous p_rain value, you can do so in the weewx.conf.
[StdCalibrate]
[[Corrections]]
p_rain = hail if hail is not None else None
Why this change:
When the rain/piezo rain data was imported from Ecowitt.net (cloud) or SD card,
some rain values were counted even though it wasn't raining at all.
Voltages and other values:
There is an email to Ecowitt's customer service about this:
Subject: Inconsistent data handling between Ecowitt cloud (ecowitt.net), SD card (GW3000), and local http API:
battery.rainfall_sensor
battery.wind_sensor
battery.haptic_array_capacitor
ch_lds?.ldsheat_ch1 ... ch4
from the displays:
battery.console
battery.ws1900
battery.ws1800
battery.ws6006
And there is now V1.0.4 because I had previously overlooked the fact
that no LDS data was retrieved from the data from Ecowitt.net.
steepleian
Jul 14, 2025, 12:29:24 PMJul 14
to weewx...@googlegroups.com
@Werner
I find it very confusing that hail is used for p_rain.
My database has columns for p_rain etc from mods I made for GW2000 driver.
On 14 Jul 2025, at 16:18, 'Werner Krenn' via weewx-user <weewx...@googlegroups.com> wrote:
Since version 1.0.2, the difference between rain and piezo rain values is calculated directly in the driver and
--
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/c09cd8dd-d8cb-494a-8904-902a21a4869cn%40googlegroups.com.
michael.k...@gmx.at
Jul 14, 2025, 1:00:55 PMJul 14
to weewx-user
I get the following warnings when starting weewx with a ne version of the driver:
weewx-data/bin/user/ecowitt_http.py:1866: SyntaxWarning: invalid escape sequence '\('
clean_key = re.sub("\(.*?\)","", field)
weewx-data/bin/user/ecowitt_http.py:1866: SyntaxWarning: invalid escape sequence '\('
clean_key = re.sub("\(.*?\)","", field)
weewx-data/bin/user/ecowitt_http.py:10196: SyntaxWarning: invalid escape sequence '\d'
_match = re.search('CH\d+', _name)
_match = re.search('CH\d+', _name)
The lines should be
ecowitt_http.py:1866: clean_key = re.sub(r"\(.*?\)","", field)
ecowitt_http.py:10196: _match = re.search(r'CH\d+', _name)
Werner Krenn
Jul 14, 2025, 2:00:31 PMJul 14
to weewx-user
I don't have these errors.
It would be interesting to see what the name data looks like with
http://%IP_GW%/get_sensors_info?page=1
and
http://%IP_GW%/get_sensors_info?page=2
as that's where the error message comes from.
@steepleian
Sorry, but "hail" was an unused field in the wview_extended database schema,
so I've always used it for piezo_rain.
The other names are taken from "Customized,"
since newly added values via Customized are always immediately available.
It would be interesting to see what the name data looks like with
http://%IP_GW%/get_sensors_info?page=1
and
http://%IP_GW%/get_sensors_info?page=2
as that's where the error message comes from.
@steepleian
Sorry, but "hail" was an unused field in the wview_extended database schema,
so I've always used it for piezo_rain.
The other names are taken from "Customized,"
since newly added values via Customized are always immediately available.
vince
Jul 14, 2025, 2:03:48 PMJul 14
to weewx-user
On Monday, July 14, 2025 at 9:29:24 AM UTC-7 steepleian wrote:
@WernerI find it very confusing that hail is used for p_rain.My database has columns for p_rain etc from mods I made for GW2000 driver.
Agree. I notice that weewx doesn't directly support multiple wind nor rain sensors, so folks with a combination if piezo and old-style spinning/tipping sensors have issues mapping database elements.
Rather than requiring modifying the as-delivered weewx schema, I'm wondering if an alternate approach might be to create an ecowitt-specific schema and a secondary db for whatever ecowitt supports. Granted, skins would need to explicitly reference the ecowitt db binding, but it would make the database mapping issue a non-issue.
FWIW - the purpleair extension I use as well as a couple other extensions create these alternate databases on first use, so it's not a big deal. You might consider taking the same approach for ecowitt which has a growing list of uniquenesses as they add more and more sensor types users can purchase.
That said, I do not know offhand if it is possible to have a driver's sensor_map use a secondary db rather than the default db. That might be helpful to be able to do, or even to map each sensor_map item to the chosen db+element to read from.
michael.k...@gmx.at
Jul 14, 2025, 3:05:17 PMJul 14
to weewx-user
The warnings shows up once, after the ecowitt_http.py was altered when a new pycache object is created, only showing up when starting weewxd manually. It is console output not being logged.
michael.k...@gmx.at
Jul 16, 2025, 9:40:12 AMJul 16
to weewx-user
After a failed connection to the GW300, this happened with the piezo rain data:
Left: Old Ecowitt Gateway driver with GW2000, Right: ecowitt http driver with GW3000:
From the log:
2025-07-16 13:28:17 weewxd[19407] INFO weewx.restx: MQTT: Published record 2025-07-16 13:28:16 CEST (1752665296)
2025-07-16 13:28:27 weewxd[19407] INFO weewx.restx: MQTT: Published record 2025-07-16 13:28:27 CEST (1752665307)
2025-07-16 13:28:37 weewxd[19407] INFO weewx.restx: MQTT: Published record 2025-07-16 13:28:37 CEST (1752665317)
2025-07-16 13:28:47 weewxd[19407] INFO weewx.restx: MQTT: Published record 2025-07-16 13:28:47 CEST (1752665327)
2025-07-16 13:29:07 weewxd[19407] ERROR user.ecowitt_http: URL - Failed to get device data on attempt 1 of 3
2025-07-16 13:29:08 weewxd[19407] ERROR user.ecowitt_http: **** <urlopen error timed out>
2025-07-16 13:29:08 weewxd[19407] ERROR user.ecowitt_http: Unable to obtain live sensor data
2025-07-16 13:29:08 weewxd[19407] INFO weewx.engine: Main loop exiting. Shutting engine down.
2025-07-16 13:29:08 weewxd[19407] INFO weewx.engine: Shutting down StdReport thread
2025-07-16 13:29:09 weewxd[19407] INFO user.ecowitt_http: EcowittHttpCollector thread has been terminated
2025-07-16 13:29:09 weewxd[19407] CRITICAL weewxd: Caught WeeWxIOError:
2025-07-16 13:29:09 weewxd[19407] CRITICAL weewxd: **** Waiting 60.0 seconds then retrying...
2025-07-16 13:30:09 weewxd[19407] INFO weewxd: retrying...
2025-07-16 13:30:09 weewxd[19407] INFO weewx.engine: Loading station type EcowittHttp (user.ecowitt_http)
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: EcowittHttpDriver: version is 0.1.0
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: unit_system: 17
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: device IP address is 10.0.1.84
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: poll interval is 10 seconds
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: rain debug is not set
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: wind debug is not set
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: lightning debug is not set
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: loop debug is not set
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: sensors debug is not set
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: catchup debug is not set
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: parser debug is not set
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: collector debug is not set
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: archive debug is not set
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: wn32_indoor: sensor ID decoding will use indoor 'WN32'
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: wn32_outdoor: sensor ID decoding will use outdoor 'WN32P'
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: device firmware update checks will occur every 86400 seconds
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: available device firmware updates will be logged
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: battery state will not be reported for sensors with no signal data
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: unknown fields will be ignored
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: catchup source: device
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: EcowittHttpCollector startup
2025-07-16 13:30:09 weewxd[19407] INFO weewx.engine: StdConvert target unit is 0x11
2025-07-16 13:30:09 weewxd[19407] INFO weewx.wxservices: StdWXCalculate will use data binding wx_binding
2025-07-16 13:30:09 weewxd[19407] INFO weewx.engine: Archive will use data binding wx_binding
2025-07-16 13:30:09 weewxd[19407] INFO weewx.engine: Record generation will be attempted in 'software'
2025-07-16 13:30:09 weewxd[19407] INFO weewx.engine: Using archive interval of 300 seconds (software record generation)
2025-07-16 13:30:09 weewxd[19407] INFO weewx.restx: StationRegistry: Registration not requested.
2025-07-16 13:30:09 weewxd[19407] INFO weewx.restx: Wunderground: Posting not enabled.
2025-07-16 13:30:09 weewxd[19407] INFO weewx.restx: PWSweather: Posting not enabled.
2025-07-16 13:30:09 weewxd[19407] INFO weewx.restx: CWOP: Posting not enabled.
2025-07-16 13:30:09 weewxd[19407] INFO weewx.restx: WOW: Posting not enabled.
2025-07-16 13:30:09 weewxd[19407] INFO weewx.restx: AWEKAS: Posting not enabled.
2025-07-16 13:30:09 weewxd[19407] INFO user.mqtt: service version is 0.24
2025-07-16 13:30:09 weewxd[19407] INFO user.mqtt: binding to loop
2025-07-16 13:30:09 weewxd[19407] INFO user.mqtt: data_binding is wx_binding
2025-07-16 13:30:09 weewxd[19407] INFO user.mqtt: topic is weather_test_ws90
2025-07-16 13:30:09 weewxd[19407] INFO user.mqtt: data will be uploaded to mqtt://10.0.1.90:1883/
2025-07-16 13:30:09 weewxd[19407] INFO weewx.engine: 'pyephem' detected, extended almanac data is available
2025-07-16 13:30:09 weewxd[19407] INFO weewxd: Starting up weewx version 5.1.0
2025-07-16 13:30:09 weewxd[19407] INFO weewx.engine: Using binding 'wx_binding' to database 'weewx-ws90.sdb'
2025-07-16 13:30:09 weewxd[19407] INFO weewx.manager: Starting backfill of daily summaries
2025-07-16 13:30:09 weewxd[19407] INFO weewx.manager: Daily summaries up to date
2025-07-16 13:30:12 weewxd[19407] INFO user.ecowitt_http: Archive: using 'rain.0x13.val' for rain total
2025-07-16 13:30:12 weewxd[19407] INFO user.ecowitt_http: Archive: using 'piezoRain.0x13.val' for piezo rain total
2025-07-16 13:30:12 weewxd[19407] INFO user.ecowitt_http: Archive: Skipping lightning count of 1.0: no last count
2025-07-16 13:30:12 weewxd[19407] INFO weewx.manager: Added record 2025-07-16 13:28:00 CEST (1752665280) to database 'weewx-ws90.sdb'
2025-07-16 13:30:12 weewxd[19407] INFO weewx.manager: Added record 2025-07-16 13:28:00 CEST (1752665280) to daily summary in 'weewx-ws90.sdb'
2025-07-16 13:30:13 weewxd[19407] INFO weewx.engine: Starting main packet loop.
2025-07-16 13:30:13 weewxd[19407] INFO user.ecowitt_http: Using 'rain.0x13.val' for rain total
2025-07-16 13:30:13 weewxd[19407] INFO user.ecowitt_http: Using 'piezoRain.0x13.val' for piezo rain total
2025-07-16 13:30:13 weewxd[19407] INFO user.ecowitt_http: Archive: skipping rain measurement of 600.4: no last rain
2025-07-16 13:30:13 weewxd[19407] INFO user.ecowitt_http: Archive: skipping piezo rain measurement of 691.3: no last rain
2025-07-16 13:30:13 weewxd[19407] INFO user.ecowitt_http: Archive: Skipping lightning count of 1: no last count
2025-07-16 13:30:13 weewxd[19407] INFO user.mqtt: client established for mqtt://10.0.1.90:1883/
2025-07-16 13:30:13 weewxd[19407] INFO weewx.restx: MQTT: Published record 2025-07-16 13:30:09 CEST (1752665409)
2025-07-16 13:30:19 weewxd[19407] INFO weewx.restx: MQTT: Published record 2025-07-16 13:30:19 CEST (1752665419)
2025-07-16 13:30:30 weewxd[19407] INFO weewx.restx: MQTT: Published record 2025-07-16 13:30:29 CEST (1752665429)
2025-07-16 13:28:27 weewxd[19407] INFO weewx.restx: MQTT: Published record 2025-07-16 13:28:27 CEST (1752665307)
2025-07-16 13:28:37 weewxd[19407] INFO weewx.restx: MQTT: Published record 2025-07-16 13:28:37 CEST (1752665317)
2025-07-16 13:28:47 weewxd[19407] INFO weewx.restx: MQTT: Published record 2025-07-16 13:28:47 CEST (1752665327)
2025-07-16 13:29:07 weewxd[19407] ERROR user.ecowitt_http: URL - Failed to get device data on attempt 1 of 3
2025-07-16 13:29:08 weewxd[19407] ERROR user.ecowitt_http: **** <urlopen error timed out>
2025-07-16 13:29:08 weewxd[19407] ERROR user.ecowitt_http: Unable to obtain live sensor data
2025-07-16 13:29:08 weewxd[19407] INFO weewx.engine: Main loop exiting. Shutting engine down.
2025-07-16 13:29:08 weewxd[19407] INFO weewx.engine: Shutting down StdReport thread
2025-07-16 13:29:09 weewxd[19407] INFO user.ecowitt_http: EcowittHttpCollector thread has been terminated
2025-07-16 13:29:09 weewxd[19407] CRITICAL weewxd: Caught WeeWxIOError:
2025-07-16 13:29:09 weewxd[19407] CRITICAL weewxd: **** Waiting 60.0 seconds then retrying...
2025-07-16 13:30:09 weewxd[19407] INFO weewxd: retrying...
2025-07-16 13:30:09 weewxd[19407] INFO weewx.engine: Loading station type EcowittHttp (user.ecowitt_http)
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: EcowittHttpDriver: version is 0.1.0
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: unit_system: 17
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: device IP address is 10.0.1.84
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: poll interval is 10 seconds
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: rain debug is not set
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: wind debug is not set
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: lightning debug is not set
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: loop debug is not set
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: sensors debug is not set
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: catchup debug is not set
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: parser debug is not set
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: collector debug is not set
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: archive debug is not set
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: wn32_indoor: sensor ID decoding will use indoor 'WN32'
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: wn32_outdoor: sensor ID decoding will use outdoor 'WN32P'
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: device firmware update checks will occur every 86400 seconds
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: available device firmware updates will be logged
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: battery state will not be reported for sensors with no signal data
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: unknown fields will be ignored
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: catchup source: device
2025-07-16 13:30:09 weewxd[19407] INFO user.ecowitt_http: EcowittHttpCollector startup
2025-07-16 13:30:09 weewxd[19407] INFO weewx.engine: StdConvert target unit is 0x11
2025-07-16 13:30:09 weewxd[19407] INFO weewx.wxservices: StdWXCalculate will use data binding wx_binding
2025-07-16 13:30:09 weewxd[19407] INFO weewx.engine: Archive will use data binding wx_binding
2025-07-16 13:30:09 weewxd[19407] INFO weewx.engine: Record generation will be attempted in 'software'
2025-07-16 13:30:09 weewxd[19407] INFO weewx.engine: Using archive interval of 300 seconds (software record generation)
2025-07-16 13:30:09 weewxd[19407] INFO weewx.restx: StationRegistry: Registration not requested.
2025-07-16 13:30:09 weewxd[19407] INFO weewx.restx: Wunderground: Posting not enabled.
2025-07-16 13:30:09 weewxd[19407] INFO weewx.restx: PWSweather: Posting not enabled.
2025-07-16 13:30:09 weewxd[19407] INFO weewx.restx: CWOP: Posting not enabled.
2025-07-16 13:30:09 weewxd[19407] INFO weewx.restx: WOW: Posting not enabled.
2025-07-16 13:30:09 weewxd[19407] INFO weewx.restx: AWEKAS: Posting not enabled.
2025-07-16 13:30:09 weewxd[19407] INFO user.mqtt: service version is 0.24
2025-07-16 13:30:09 weewxd[19407] INFO user.mqtt: binding to loop
2025-07-16 13:30:09 weewxd[19407] INFO user.mqtt: data_binding is wx_binding
2025-07-16 13:30:09 weewxd[19407] INFO user.mqtt: topic is weather_test_ws90
2025-07-16 13:30:09 weewxd[19407] INFO user.mqtt: data will be uploaded to mqtt://10.0.1.90:1883/
2025-07-16 13:30:09 weewxd[19407] INFO weewx.engine: 'pyephem' detected, extended almanac data is available
2025-07-16 13:30:09 weewxd[19407] INFO weewxd: Starting up weewx version 5.1.0
2025-07-16 13:30:09 weewxd[19407] INFO weewx.engine: Using binding 'wx_binding' to database 'weewx-ws90.sdb'
2025-07-16 13:30:09 weewxd[19407] INFO weewx.manager: Starting backfill of daily summaries
2025-07-16 13:30:09 weewxd[19407] INFO weewx.manager: Daily summaries up to date
2025-07-16 13:30:12 weewxd[19407] INFO user.ecowitt_http: Archive: using 'rain.0x13.val' for rain total
2025-07-16 13:30:12 weewxd[19407] INFO user.ecowitt_http: Archive: using 'piezoRain.0x13.val' for piezo rain total
2025-07-16 13:30:12 weewxd[19407] INFO user.ecowitt_http: Archive: Skipping lightning count of 1.0: no last count
2025-07-16 13:30:12 weewxd[19407] INFO weewx.manager: Added record 2025-07-16 13:28:00 CEST (1752665280) to database 'weewx-ws90.sdb'
2025-07-16 13:30:12 weewxd[19407] INFO weewx.manager: Added record 2025-07-16 13:28:00 CEST (1752665280) to daily summary in 'weewx-ws90.sdb'
2025-07-16 13:30:13 weewxd[19407] INFO weewx.engine: Starting main packet loop.
2025-07-16 13:30:13 weewxd[19407] INFO user.ecowitt_http: Using 'rain.0x13.val' for rain total
2025-07-16 13:30:13 weewxd[19407] INFO user.ecowitt_http: Using 'piezoRain.0x13.val' for piezo rain total
2025-07-16 13:30:13 weewxd[19407] INFO user.ecowitt_http: Archive: skipping rain measurement of 600.4: no last rain
2025-07-16 13:30:13 weewxd[19407] INFO user.ecowitt_http: Archive: skipping piezo rain measurement of 691.3: no last rain
2025-07-16 13:30:13 weewxd[19407] INFO user.ecowitt_http: Archive: Skipping lightning count of 1: no last count
2025-07-16 13:30:13 weewxd[19407] INFO user.mqtt: client established for mqtt://10.0.1.90:1883/
2025-07-16 13:30:13 weewxd[19407] INFO weewx.restx: MQTT: Published record 2025-07-16 13:30:09 CEST (1752665409)
2025-07-16 13:30:19 weewxd[19407] INFO weewx.restx: MQTT: Published record 2025-07-16 13:30:19 CEST (1752665419)
2025-07-16 13:30:30 weewxd[19407] INFO weewx.restx: MQTT: Published record 2025-07-16 13:30:29 CEST (1752665429)
Werner Krenn
Jul 16, 2025, 12:50:04 PMJul 16
to weewx-user
Please set
debug = rain
What is mapped for piezo_rain?
By the way, this behavior is why I changed the calculation of rain and piezo_rain.
Connection issues:
Have you read about the issue with GW3000 1.0.9 on GitHub?
debug = rain
What is mapped for piezo_rain?
By the way, this behavior is why I changed the calculation of rain and piezo_rain.
Connection issues:
Have you read about the issue with GW3000 1.0.9 on GitHub?
michael.k...@gmx.at
Jul 16, 2025, 2:18:00 PMJul 16
to weewx-user
I've never heard of such an issue nor have I encountered one, but this one so far with the GW3000
I have mapped p_rain for piezo_rain with
[StdCalibrate]
[[Corrections]]
p_rain = hail if hail is not None else None
[[Corrections]]
p_rain = hail if hail is not None else None
With debug = rain WeeWX didn't start, I've set logging to :
debug = 3
[Logging]
version = 1
disable_existing_loggers = False
# Root logger
[[root]]
level = INFO
handlers = rotate, #console
# Additional loggers would go in the following section. This is useful for tailoring logging
# for individual modules.
[[loggers]]
[[[user.ecowitt_http]]]
level = DEBUG
# Definitions of possible logging destinations
[[handlers]]
# Log to a set of rotating files
[[[rotate]]]
level = INFO
formatter = verbose
class = logging.handlers.RotatingFileHandler
filename = /home/wusr/weewx-data/log/weewxd.log
maxBytes = 10000000
backupCount = 4
version = 1
disable_existing_loggers = False
# Root logger
[[root]]
level = INFO
handlers = rotate, #console
# Additional loggers would go in the following section. This is useful for tailoring logging
# for individual modules.
[[loggers]]
[[[user.ecowitt_http]]]
level = DEBUG
# Definitions of possible logging destinations
[[handlers]]
# Log to a set of rotating files
[[[rotate]]]
level = INFO
formatter = verbose
class = logging.handlers.RotatingFileHandler
filename = /home/wusr/weewx-data/log/weewxd.log
maxBytes = 10000000
backupCount = 4
Werner Krenn
Jul 16, 2025, 3:13:27 PMJul 16
to weewx-user
Of course, it was meant to be debug at EcowittHttp:
[EcowittHttp]
debug = rain
With the current version, under
[[Corrections]]
p_rain = hail if hail is not None else None
is no longer necessary!
[EcowittHttp]
debug = rain
With the current version, under
[[Corrections]]
p_rain = hail if hail is not None else None
michael.k...@gmx.at
Jul 16, 2025, 4:29:28 PMJul 16
to weewx-user
I've updated ecowitt_http.py (warnings gone), set debug = rain, removed the corrections entry for p_rain and here is the log. No 
"lightning_num": "23",
"lightning_strike_count": "0",
No more p_rain with the updated setting and the most recent version. (And yes, we had an considerable amount of rain here today, ~ 40mm so far and counting)
By the way:
"lightning_num": "23",
"lightning_strike_count": "0",
Today 23 strikes were registered. What's the change here, the old driver set the
lightning_strike_count.
Werner Krenn
Jul 17, 2025, 5:24:49 AMJul 17
to weewx-user
lightning_num
is the number of lightning strikes on this day
lightning_strike_count
is the difference from the previous archive value.
That's the only way I know it, and that's how it is now again.
I use additionally
[StdCalibrate]
[[Corrections]]
lightning_noise_count = lightning_strike_count if lightning_strike_count > 0 else None
[accumulator]
[[lightning_noise_count]]
extractor = sum
This allows me to display the last recorded number of lightning strikes per day
without them disappearing after one day.
is the number of lightning strikes on this day
lightning_strike_count
is the difference from the previous archive value.
That's the only way I know it, and that's how it is now again.
I use additionally
[StdCalibrate]
[[Corrections]]
lightning_noise_count = lightning_strike_count if lightning_strike_count > 0 else None
[accumulator]
[[lightning_noise_count]]
extractor = sum
This allows me to display the last recorded number of lightning strikes per day
without them disappearing after one day.
Werner Krenn
Jul 19, 2025, 1:39:00 PMJul 19
to weewx-user
Updated ecowitt_http driver:
Support for wn20 (Mini Rain Sensor)
Wind direction 10 min, Rain 24 hours, Rain Piezo 24 hours, RSSI.
Now also included in the loop data:
Voltage for the WH40 rain sensor, Heat for the LDS sensor.
Everything comes with firmware update GW3000 V1.1.0
Support for wn20 (Mini Rain Sensor)
Wind direction 10 min, Rain 24 hours, Rain Piezo 24 hours, RSSI.
Now also included in the loop data:
Voltage for the WH40 rain sensor, Heat for the LDS sensor.
Everything comes with firmware update GW3000 V1.1.0
Ian Millard
Jul 21, 2025, 2:01:38 PMJul 21
to weewx...@googlegroups.com
@Werner,
How do you generate the last non-zero strike distance and time? I have an X-Type to do that, but maybe you have another way.
--
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/65ac62e1-ca01-48a1-bb84-72ba48e50b59n%40googlegroups.com.
Werner Krenn
Jul 21, 2025, 2:46:58 PMJul 21
to weewx-user
I only use these entries in the weewx.conf
[StdCalibrate]
[[Corrections]]
lightning_distance_save = lightning_dist if lightning_dist is not None else None
lightning_distance = lightning_dist if lightning_strike_count > 0 else None
lightning_noise_count = lightning_strike_count if lightning_strike_count > 0 else None
[Accumulator]
[[lightning_distance]]
extractor = last
[[lightning_strike_count]]
extractor = sum
[[lightning_last_det_time]]
extractor = last
[[lightningcount]]
extractor = last
[[lightning_noise_count]]
extractor = sum
[StdCalibrate]
[[Corrections]]
lightning_distance_save = lightning_dist if lightning_dist is not None else None
lightning_distance = lightning_dist if lightning_strike_count > 0 else None
lightning_noise_count = lightning_strike_count if lightning_strike_count > 0 else None
[[lightning_distance]]
extractor = last
[[lightning_strike_count]]
extractor = sum
[[lightning_last_det_time]]
extractor = last
[[lightningcount]]
extractor = last
[[lightning_noise_count]]
extractor = sum
Ian Millard
Jul 25, 2025, 10:36:35 AMJul 25
to weewx...@googlegroups.com
@Michael, @Werner, @Vince,
I have the WeeWX-Ecowitt_http working flawlessly in driver mode now. So much so that I have confidently moved it across to my live server.
There are just a couple of things to mention: -
1. Using the rain column to generates day, week, month etc gives some rather bizarre results as @Michael discovered. The safe way to go is dayRain, weekRain etc which give the expected results.
2. It makes sense to me that if a dedicated Ecowitt database schema is the way to go. If this is the case, the examples of this that are already out there need to come together to agree a standard. The example I quoted in an earlier post of using the hail column for piezo rain, I understand why this was done in the first instance, but surely if we speak about a dedicated schema, piezo rain should be fully supported in its own right?
I will be interested in our collective thoughts on this.
Thanks,
Ian
To view this discussion visit https://groups.google.com/d/msgid/weewx-user/b2e50c63-665f-4b41-8daa-708c7f9b7ba3n%40googlegroups.com.
michael.k...@gmx.at
Jul 25, 2025, 4:57:11 PMJul 25
to weewx-user
I still have the one or the other issue with p_rain, but that's very special to my ssetup running ecowitt_http as a driver and GW1000 as a service. And I so far couldn't confirm how the lightning detection works out with my settings.
michael.k...@gmx.at
Jul 26, 2025, 3:13:28 AMJul 26
to weewx-user
My issue with p_rain is that the driver uses p_rainrate and my database has the column p_rainRate (camelCase), which is the WeeWX db style to name columns, thus I need to configure:
[StdCalibrate]
[[Corrections]]
p_rainRate = p_rainrate
[[Corrections]]
p_rainRate = p_rainrate
Werner Krenn
Jul 26, 2025, 1:12:27 PMJul 26
to weewx-user
@Ian,
1) Rain
I know this behavior (also with lightning) when the gw1000 driver also is started
as a service or the original ecowitt_http driver (0.1.0a28) is used
and data is read from Ecowitt.net (Cloud) or SDcard
2)Ecowitt special database schema:
At the very beginning, I used wview_extended.
However, as more and more sensors were added, I expanded this schema into a new database schema, wview_ecowitt.
This contains all possible Ecowitt sensors. However,
self-selected signals are assigned to the existing fields signal1..signal8 in
[StdCalibrate]
[[Corrections]]
and extrapolated to 0..100 percent (*25).
And since 'hail' or 'pb' were present but unused, I mapped Piezo Rain or Heap to them.
There is also a script file (add_ecowitt_allsignaldata_v5.sh) that can add all signals to the database.
The same applies to all new RSSI values with the script file
add_ecowitt_allrssidata_v5.sh
The script files and schema file can be found on Github
Skins with the data from ecowitt_http (in German!)
Skin Seasons Ecowitt: https://www.pc-wetterstation.de/wetter/weewx8
Skin Bootstrap: https://www.pc-wetterstation.de/wetter/weewx8/bootstrap/index.html
1) Rain
I know this behavior (also with lightning) when the gw1000 driver also is started
as a service or the original ecowitt_http driver (0.1.0a28) is used
and data is read from Ecowitt.net (Cloud) or SDcard
2)Ecowitt special database schema:
At the very beginning, I used wview_extended.
However, as more and more sensors were added, I expanded this schema into a new database schema, wview_ecowitt.
This contains all possible Ecowitt sensors. However,
self-selected signals are assigned to the existing fields signal1..signal8 in
[StdCalibrate]
[[Corrections]]
and extrapolated to 0..100 percent (*25).
And since 'hail' or 'pb' were present but unused, I mapped Piezo Rain or Heap to them.
There is also a script file (add_ecowitt_allsignaldata_v5.sh) that can add all signals to the database.
The same applies to all new RSSI values with the script file
add_ecowitt_allrssidata_v5.sh
The script files and schema file can be found on Github
Skins with the data from ecowitt_http (in German!)
Skin Seasons Ecowitt: https://www.pc-wetterstation.de/wetter/weewx8
Skin Bootstrap: https://www.pc-wetterstation.de/wetter/weewx8/bootstrap/index.html
michael.k...@gmx.at
Jul 26, 2025, 2:03:07 PMJul 26
to weewx-user
Not too far away from my location. Did you have BBQ for dinner?
By the way, fuzzy-archer is currently at 4.4 :)
By the way, fuzzy-archer is currently at 4.4 :)
Werner Krenn
Jul 26, 2025, 2:20:45 PMJul 26
to weewx-user
@Michael,
>
Did you have BBQ for dinner?
No ;)
It is this problem, described on the Ecowitt homepage:
★★Note:
3.The sensor is sensitive to liquid droplets - rain/fog/sprinkling. When the Dew Point is close to the outdoor temperature(T - D < = 2C), the PM2.5 reading will be very high(which is not the real condition).
michael.k...@gmx.at
Aug 2, 2025, 10:49:18 AMAug 2
to weewx-user
When backfilling data from the GW3000s SD Card, no rain is imported into the database. There is no "rain" in the REC. I'm not so familiar with the process, but I guess there is something missing in my weewx.conf that is calculation rain from the RECs. By the way, is there a documentation what the [Accumulator] is all about and when and how it is to be used?
REC: 2025-08-01 17:18:00 CEST (1754061480) 'altimeter': '1013.6569194849516',
'appTemp': '23.50738354280469',
'barometer': '1011.2',
'cloudbase': '1372.254710571006',
'co2': '342.0',
'co2_Hum': '59.0',
'co2_Temp': '22.9',
'dateTime': '1754061480.0',
'dayRain': '0.6',
'dewpoint': '14.8',
'drain_piezo': '0.0',
'erain_piezo': '0.0',
'ET': '0.015721295892854044',
'eventRain': '15.1',
'extraHumid1': '51.0',
'extraHumid2': '70.0',
'extraHumid3': '64.0',
'extraHumid4': '64.0',
'extraHumid6': '49.0',
'extraHumid7': '66.0',
'extraHumid8': '66.0',
'extraTemp1': '20.2',
'extraTemp2': '21.5',
'extraTemp3': '21.7',
'extraTemp4': '21.9',
'extraTemp5': '21.1',
'extraTemp6': '19.7',
'extraTemp7': '21.9',
'extraTemp8': '21.6',
'hailRate': '0.0',
'heatindex': '22.314444444444444',
'hourRain': '0.0',
'humidex': '26.22374343350731',
'inDewpoint': '15.474126948319904',
'inHumidity': '63.0',
'inTemp': '22.9',
'interval': '5',
'lightning_dist': '20.0',
'lightning_distance': 'None',
'lightning_disturber_count': '1754038860.0',
'lightning_strike_count': '0.0',
'lightningcount': '0.0',
'luminosity': '31810.569',
'maxSolarRad': '481.7560939781643',
'monthRain': '0.6',
'mrain_piezo': '0.0',
'outHumidity': '62.0',
'outTemp': '22.4',
'p_rainrate': '0.0',
'p_rainyear': '0.5',
'pm2_5': '2.9',
'pm10_0': '3.2',
'pressure': '961.8',
'radiation': '251.07',
'rainRate': '0.0',
'rrain_piezo': '0.0',
'soilMoist1': '52.0',
'soilMoist2': '42.0',
't_rain': '15.1',
't_rainRate': '0.0',
't_rainyear': '235.2',
'usUnits': '17',
'UV': '2.0',
'vpd': '10.3',
'weekRain': '89.8',
'windchill': '22.399999999999995',
'windDir': '285.0',
'windGust': '1.0',
'windrun': '0.18',
'windSpeed': '0.6',
'wrain_piezo': '0.0',
'yearRain': '235.2',
'yrain_piezo': '0.5'
'appTemp': '23.50738354280469',
'barometer': '1011.2',
'cloudbase': '1372.254710571006',
'co2': '342.0',
'co2_Hum': '59.0',
'co2_Temp': '22.9',
'dateTime': '1754061480.0',
'dayRain': '0.6',
'dewpoint': '14.8',
'drain_piezo': '0.0',
'erain_piezo': '0.0',
'ET': '0.015721295892854044',
'eventRain': '15.1',
'extraHumid1': '51.0',
'extraHumid2': '70.0',
'extraHumid3': '64.0',
'extraHumid4': '64.0',
'extraHumid6': '49.0',
'extraHumid7': '66.0',
'extraHumid8': '66.0',
'extraTemp1': '20.2',
'extraTemp2': '21.5',
'extraTemp3': '21.7',
'extraTemp4': '21.9',
'extraTemp5': '21.1',
'extraTemp6': '19.7',
'extraTemp7': '21.9',
'extraTemp8': '21.6',
'hailRate': '0.0',
'heatindex': '22.314444444444444',
'hourRain': '0.0',
'humidex': '26.22374343350731',
'inDewpoint': '15.474126948319904',
'inHumidity': '63.0',
'inTemp': '22.9',
'interval': '5',
'lightning_dist': '20.0',
'lightning_distance': 'None',
'lightning_disturber_count': '1754038860.0',
'lightning_strike_count': '0.0',
'lightningcount': '0.0',
'luminosity': '31810.569',
'maxSolarRad': '481.7560939781643',
'monthRain': '0.6',
'mrain_piezo': '0.0',
'outHumidity': '62.0',
'outTemp': '22.4',
'p_rainrate': '0.0',
'p_rainyear': '0.5',
'pm2_5': '2.9',
'pm10_0': '3.2',
'pressure': '961.8',
'radiation': '251.07',
'rainRate': '0.0',
'rrain_piezo': '0.0',
'soilMoist1': '52.0',
'soilMoist2': '42.0',
't_rain': '15.1',
't_rainRate': '0.0',
't_rainyear': '235.2',
'usUnits': '17',
'UV': '2.0',
'vpd': '10.3',
'weekRain': '89.8',
'windchill': '22.399999999999995',
'windDir': '285.0',
'windGust': '1.0',
'windrun': '0.18',
'windSpeed': '0.6',
'wrain_piezo': '0.0',
'yearRain': '235.2',
'yrain_piezo': '0.5'
Werner Krenn
Aug 2, 2025, 11:02:55 AMAug 2
to weewx-user
>
When backfilling data from the GW3000s SD Card, no rain is imported into the database.
It seems that you are not using the current version 0.2.0
michael.k...@gmx.at
Aug 2, 2025, 11:56:33 AMAug 2
to weewx-user
Indeed. A quick test shows the value are now being backfilled.
But for "rain" the "rainRate" doesn't seem to be calculated correctly, or at all: it is zero. Interestingly "p_rainRate" is calculated correctly when backfilled. But to be honest: I don't know if the issue is only when being backfilled, I'll check that real quick. It's raining cats and dogs, so it won't take too long :D
michael.k...@gmx.at
Aug 2, 2025, 2:31:59 PMAug 2
to weewx-user
OK, I've set
[StdWXCalculate]
[[Calculations]]
rainRate = software
[StdWXCalculate]
[[Calculations]]
rainRate = prefer_hardware
[StdWXCalculate]
[[Calculations]]
rainRate = software
Setting it to
[StdWXCalculate]
[[Calculations]]
rainRate = prefer_hardware
And it's there. The question now is, how is the hardware calculating it compared to weewx? The WS28xx did it on a hourly basis, weewx afaik on a 15min basis.
michael.k...@gmx.at
Aug 21, 2025, 9:07:05 AMAug 21
to weewx-user
I still have an Issue with storing p_rain values in the database. In the database (metricwx) are values well below 1/10mm, while from the Loop p_rain values of x/10mm are reported.
Currently (and the next hours) it is raining, the live chart rises in x/10mm steps, when the values are loaded from the db after a refresh, p_rain ist much lower than rain from the traditional gauge.
steepleian
Aug 21, 2025, 10:17:16 AMAug 21
to weewx...@googlegroups.com
Michael,
Are you describing the fact there are an insufficient number of decimal places to record small quantities of rain?
Ian
On 21 Aug 2025, at 14:07, 'michael.k...@gmx.at' via weewx-user <weewx...@googlegroups.com> wrote:
I still have an Issue with storing p_rain values in the database. In the database (metricwx) are values well below 1/10mm, while from the Loop p_rain values of x/10mm are reported.
To view this discussion visit https://groups.google.com/d/msgid/weewx-user/46ceccb1-49ce-40ee-ab5c-f4abf5561c7dn%40googlegroups.com.
michael.k...@gmx.at
Aug 21, 2025, 10:33:50 AMAug 21
to weewx-user
No, the WS90 itself has a resolution of 0.1mm, but I get increments < 0.01mm in the database, which shouldn't be possible. It's with with Werner's v0.2.2. When receiving LOO data emitted through weewx_mqtt, I receiver the correct 0.1mm increments.
steepleian
Aug 21, 2025, 10:46:03 AMAug 21
to weewx...@googlegroups.com
I am actually working on a complete re-write which will also incorporate live data output in a json file. It will also have the option of subscribing to to MQTT topic published directly from the gateway device using the new Ecowitt in built MQTT weather service.
On 21 Aug 2025, at 15:33, 'michael.k...@gmx.at' via weewx-user <weewx...@googlegroups.com> wrote:
No, the WS90 itself has a resolution of 0.1mm, but I get increments < 0.01mm in the database, which shouldn't be possible. It's with with Werner's v0.2.2. When receiving LOO data emitted through weewx_mqtt, I receiver the correct 0.1mm increments.
To view this discussion visit https://groups.google.com/d/msgid/weewx-user/e5034f32-ec88-4372-a13e-c6972f97ff7en%40googlegroups.com.
Message has been deleted
Werner Krenn
Aug 21, 2025, 2:10:43 PMAug 21
to weewx-user
Ok, I use hail instead of p_rain and with hail the value has to be multiplied by a factor of 25.4 to get a correct display,
but only for the graphs, the value is always correct.
[[[dayrainbar]]]
yscale = None, None, 0.02
plot_type = bar
y_label = "mm"
[[[[rain]]]]
aggregate_type = sum
aggregate_interval = 600
label = Rain WH40 (10min)
[[[[hail]]]]
data_type = hail * 25.4
aggregate_type = sum
aggregate_interval = 600
label = Rain Piezo (10min)
[[[[ET]]]]
color = "#edba21"
aggregate_type = sum
aggregate_interval = 600
label = ET (10min)
yscale = None, None, 0.02
plot_type = bar
y_label = "mm"
[[[[rain]]]]
aggregate_type = sum
aggregate_interval = 600
label = Rain WH40 (10min)
[[[[hail]]]]
data_type = hail * 25.4
aggregate_type = sum
aggregate_interval = 600
label = Rain Piezo (10min)
[[[[ET]]]]
color = "#edba21"
aggregate_type = sum
aggregate_interval = 600
label = ET (10min)
michael.k...@gmx.at
Aug 21, 2025, 2:29:01 PMAug 21
to weewx-user
Just caught a LOOP package:
LOOP: 2025-08-21 20:17:16 CEST (1755800236)
'p_rain': '0.10000000000002274',
Which looks correct. The value written to the database in this interval: 0.00344827586206975
michael.k...@gmx.at
Aug 21, 2025, 2:32:03 PMAug 21
to weewx-user
This interval (300s) had only 0.1mm p_rain with the old ecowitt gateway driver.
Francisco Alonso
Aug 26, 2025, 9:35:07 AMAug 26
to weewx-user
Hi guys.
import weecfg
ModuleNotFoundError: No module named 'weecfg'
I am trying to get this up and running in my RPi, but I am afraid I do not have the required knowledge to get it to work without a set of instructions.
As there is no installation package like with the previous driver, I have read the README file in the fork from Werner.
My setup is Weewx with a package installation, which worked OK with the previous driver by Gary.
I have copied the ecowitt_http.py file from Werner's into my system and modified weewx.conf as per Werner's info on the README file and now the driver part looks like this:
[EcowittHttp]
# the driver to use
driver = user.ecowitt_http
# how often to poll the device
poll_interval = 20
# 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 = 5
# max wait for device to respond to a HTTP request
url_timeout = 10
# whether to show all battery state data including nonsense data and
# sensors that are disabled sensors and connecting
show_all_batt = False
# 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 = True
# How often to check for device firmware updates, 0 disables firmware
# update checks. Available firmware updates are logged.
firmware_update_check_interval = 86400
# do we show registered sensor data only
only_registered = True
# Is a WN32P used for indoor temperature, humidity and pressure - default = False
#wn32_indoor = True
# Is a WN32 used for outdoor temperature and humidity - default = False
#wn32_outdoor = True
#former debug_logging (here for wind) not more supported!:
#debug_wind = False
#debug_logging new with list:
#debug = rain, wind, loop, sensors, parser, catchup, collector, archive
debug = parser, sensors, catchup
catchup_grace = 0
ip_address = 192.168.1.201
api_key = 440cd2c9-8919-4836-a2e8-xxxxxxxxxxxx
# the driver to use
driver = user.ecowitt_http
# how often to poll the device
poll_interval = 20
# 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 = 5
# max wait for device to respond to a HTTP request
url_timeout = 10
# whether to show all battery state data including nonsense data and
# sensors that are disabled sensors and connecting
show_all_batt = False
# 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 = True
# How often to check for device firmware updates, 0 disables firmware
# update checks. Available firmware updates are logged.
firmware_update_check_interval = 86400
# do we show registered sensor data only
only_registered = True
# Is a WN32P used for indoor temperature, humidity and pressure - default = False
#wn32_indoor = True
# Is a WN32 used for outdoor temperature and humidity - default = False
#wn32_outdoor = True
#former debug_logging (here for wind) not more supported!:
#debug_wind = False
#debug_logging new with list:
#debug = rain, wind, loop, sensors, parser, catchup, collector, archive
debug = parser, sensors, catchup
catchup_grace = 0
ip_address = 192.168.1.201
api_key = 440cd2c9-8919-4836-a2e8-xxxxxxxxxxxx
app_key = D7FB394F84DFAB3345E6C3Bxxxxxxxxx
mac = 5C:01:3B:42:xx:xx
[[catchup]]
# source = either, both, net, device ## not set = None, default is then either or both
mac = 5C:01:3B:42:xx:xx
[[catchup]]
# source = either, both, net, device ## not set = None, default is then either or both
The log attached shows all the errors, but I am pretty lost on whatever is not correct as it references files and processes and I do not understand weewx internal protocols to make it work.
Lastly, a python3 /etc/weewx/bin/user/ecowitt_http.py --test-driver --ip-address=device-ip-address returns the following:
Traceback (most recent call last):
File "/etc/weewx/bin/user/ecowitt_http.py", line 199, in <module>import weecfg
ModuleNotFoundError: No module named 'weecfg'
If anyone can point me on the right direction, please. I am quite lost as you can see.
Thank you.
vince
Aug 26, 2025, 11:16:10 AMAug 26
to weewx-user
Try "PYTHONPATH=/etc/weewx/bin:/usr/share/weewx python3 --test-driver --ip-address=device-ip-address" and see if that helps....
steepleian
Aug 26, 2025, 11:29:50 AMAug 26
to weewx...@googlegroups.com
Or you can try the other version which is Gary’s original.
On 26 Aug 2025, at 16:16, vince <vince...@gmail.com> wrote:
Try "PYTHONPATH=/etc/weewx/bin:/usr/share/weewx python3 --test-driver --ip-address=device-ip-address" and see if that helps....
To view this discussion visit https://groups.google.com/d/msgid/weewx-user/f629b1e2-242b-4c5c-9a7b-e6e219e99f8dn%40googlegroups.com.
Francisco Alonso
Aug 26, 2025, 11:37:11 AMAug 26
to weewx...@googlegroups.com
Thanks Vince. That worked, now it returns the data from all sensors when testing.
The question is then how to make it work on its own. Do I need to update the ecowitt_http.py file with that specific route for python so that it executes the script when it is told to?
To view this discussion visit https://groups.google.com/d/msgid/weewx-user/f629b1e2-242b-4c5c-9a7b-e6e219e99f8dn%40googlegroups.com.
Saludos/Regards,
Francisco Javier Alonso
vince
Aug 26, 2025, 12:13:58 PMAug 26
to weewx-user
If you have it in the correct place (you do) and have its settings correct, and you have weewx selecting that driver for the station type it should work.
I have no idea why this one is not installable by the extension installer. Settting that up once is just a few minutes work, basically copying from examples in other drivers like Gary’s or any other extension or driver.
michael.k...@gmx.at
Aug 27, 2025, 4:13:28 AMAug 27
to weewx-user
That's why I installed from Ian's fork and manually updated the driver's py from Werner. I'm still hoping there will be a consolidated, installable driver in the future.
steepleian
Aug 27, 2025, 5:04:51 AMAug 27
to weewx...@googlegroups.com, weewx-user
Working on that.
On 27 Aug 2025, at 09:13, 'michael.k...@gmx.at' via weewx-user <weewx...@googlegroups.com> wrote:
That's why I installed from Ian's fork and manually updated the driver's py from Werner. I'm still hoping there will be a consolidated, installable driver in the future.
To view this discussion visit https://groups.google.com/d/msgid/weewx-user/084f45eb-1748-4b62-978d-c03410f4c2b0n%40googlegroups.com.
michael.k...@gmx.at
Sep 11, 2025, 7:38:03 AMSep 11
to weewx-user
Hello @Werner,
did you have a chance to look into the issue, that piezo_rain increments are unusually small?
This was recorded using the ecowitt gateway dirver:
This was recorded using the ecowitt gateway dirver:
This was recorded using the ecowitt http driver:
Looking into the database, it seems that the increment for the piezo sensor is about 1/29 of the value it should be.
Paul R Anderson
Sep 11, 2025, 12:18:45 PMSep 11
to weewx...@googlegroups.com
Inches and millimeters have a conversion ratio where one value is approximately 1/29 the other. Specifically, 1 inch is equivalent to 25.4 millimeters. The approximation is not exact but is a common comparison for visual estimation.
Just Saying
Paul
To view this discussion visit https://groups.google.com/d/msgid/weewx-user/2a355cc0-67c0-4fc7-95d5-c1c142e31994n%40googlegroups.com.
John Smith
Sep 11, 2025, 1:26:26 PMSep 11
to weewx...@googlegroups.com
On Fri, 12 Sept 2025 at 02:18, Paul R Anderson <pa...@pauland.net> wrote:
Inches and millimeters have a conversion ratio where one value is approximately 1/29 the other. Specifically, 1 inch is equivalent to 25.4 millimeters. The approximation is not exact but is a common comparison for visual estimation.
The inch was standardised to be exactly 25.4mm, except for the US, although that changed in 2020 according to Wikipedia.
p q
Sep 11, 2025, 1:41:09 PMSep 11
to weewx...@googlegroups.com
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
This rabbit hole is deep if you want to dive into it.
--
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/CAGTinV4mAG387-k2eidpaZMDZ7i5OTh2diZHjcpHof0ZzqQsig%40mail.gmail.com.
--
Peter Quinn
(415)794-2264
(415)794-2264
Werner Krenn
Sep 11, 2025, 2:47:51 PMSep 11
to weewx-user
Sorry, I can't find any errors with the piezo rain rate,
although the piezo rain rate below 1.5 mm/hr is actually useless.
I've already written to Ecowitt support about this.
For the piezo rain rate (in my case, the hail value), I have to multiply the value by 25.4 in the graph
I've already written to Ecowitt support about this.
For the piezo rain rate (in my case, the hail value), I have to multiply the value by 25.4 in the graph
(and only there) to get the display in mm.
Werner Krenn
Sep 11, 2025, 3:06:20 PMSep 11
to weewx-user
Bootstrap graphic:
[[rain]]
aggregate_interval_minutes = 30
[[[rain]]]
plotType = bar #new: specify plot type
aggregateType = sum #new: specify type for aggregation
aggregateInterval = 1800 #new: specify aggreagtion inteval in seconds for each series
payload_key = rain_in
showMaxMarkPoint = false
showMinMarkPoint = false
showAvgMarkLine = false
lineColor = '#428bca'
decimals = 2
[[[hail]]]
plotType = bar #new: specify plot type
aggregateType = sum #new: specify type for aggregation
aggregateInterval = 1800 #new: specify aggreagtion inteval in seconds for each series
payload_key = hail_in
showMaxMarkPoint = false
showMinMarkPoint = false
showAvgMarkLine = false
lineColor = '#f20e3c'
decimals = 2
aggregate_interval_minutes = 30
[[[rain]]]
plotType = bar #new: specify plot type
aggregateType = sum #new: specify type for aggregation
aggregateInterval = 1800 #new: specify aggreagtion inteval in seconds for each series
payload_key = rain_in
showMaxMarkPoint = false
showMinMarkPoint = false
showAvgMarkLine = false
lineColor = '#428bca'
decimals = 2
[[[hail]]]
plotType = bar #new: specify plot type
aggregateType = sum #new: specify type for aggregation
aggregateInterval = 1800 #new: specify aggreagtion inteval in seconds for each series
payload_key = hail_in
showMaxMarkPoint = false
showMinMarkPoint = false
showAvgMarkLine = false
lineColor = '#f20e3c'
decimals = 2
John Smith
Sep 11, 2025, 9:57:19 PM (14 days ago) Sep 11
to weewx...@googlegroups.com
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?x40840There 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*
michael.k...@gmx.at
Sep 11, 2025, 11:25:57 PM (14 days ago) Sep 11
to weewx-user
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
[[[[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
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.
Werner Krenn
Sep 12, 2025, 5:32:27 AM (14 days ago) Sep 12
to weewx-user
@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
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
Sep 12, 2025, 7:18:25 AM (13 days ago) Sep 12
to weewx-user
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
Sep 12, 2025, 9:05:49 AM (13 days ago) Sep 12
to weewx-user
@Michael,
Have you tried adding p_rain:
p_rain: "group_rain"
to the file
"units.js" (Bootstrap skin) ?
p_rain: "group_rain"
to the file
"units.js" (Bootstrap skin) ?
michael.k...@gmx.at
Sep 12, 2025, 11:10:39 AM (13 days ago) Sep 12
to weewx-user
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:
michael.k...@gmx.at
Sep 12, 2025, 11:23:17 AM (13 days ago) Sep 12
to weewx-user
And for the record:
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:
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.
Ian Millard
Sep 12, 2025, 12:19:13 PM (13 days ago) Sep 12
to weewx...@googlegroups.com
@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:
--
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.
<rain_vs_p_rain_vs.hail_ecowitt_gateway_driver.png><rain_vs_p_rain_vs.hail.png>
michael.k...@gmx.at
Sep 12, 2025, 1:02:40 PM (13 days ago) Sep 12
to weewx-user
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?
Werner Krenn
Sep 13, 2025, 8:56:55 AM (12 days ago) Sep 13
to weewx-user
Today, I installed a new instance of WeeWx with the EcowittHttp driver and the
database schema
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.
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.
michael.k...@gmx.at
Sep 13, 2025, 9:34:57 AM (12 days ago) Sep 13
to weewx-user
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.
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
Sep 13, 2025, 12:22:30 PM (12 days ago) Sep 13
to weewx-user
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
[StdWXCalculate]
[[Calculations]]
rain = prefer_hardware
p_rain = prefer_hardware
hail = prefer_hardware
[Accumulator]
[[p_rain]]
extractor = sum
[[hail]]
extractor = sum
Werner Krenn
Sep 13, 2025, 12:28:04 PM (12 days ago) Sep 13
to weewx-user
Also missing:
loop_on_init = 1
michael.k...@gmx.at
Sep 14, 2025, 4:30:36 AM (12 days ago) Sep 14
to weewx-user
[Accumulator]
[[p_rain]]
extractor = sum
[[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.
michael.k...@gmx.at
Sep 14, 2025, 4:41:16 AM (12 days ago) Sep 14
to weewx-user
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.
jterr...@gmail.com
Sep 14, 2025, 5:02:49 AM (12 days ago) Sep 14
to weewx-user
Because the accumulator rule for "rain" is set by default to "sum" in /weewx/accum.py
michael.k...@gmx.at
Sep 14, 2025, 5:16:40 AM (12 days ago) Sep 14
to weewx-user
OK, that's the missing piece. In the driver's [Accumulator] defaults there is no
But for "hail" it's there, making me wonder why it doesn't work for "hail"?
[[p_rain]]
extractor = sum
extractor = sum
But for "hail" it's there, making me wonder why it doesn't work for "hail"?
steepleian
Sep 14, 2025, 6:12:24 AM (12 days ago) Sep 14
to weewx...@googlegroups.com
@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.
On 14 Sep 2025, at 10:16, 'michael.k...@gmx.at' via weewx-user <weewx...@googlegroups.com> wrote:
OK, that's the missing piece. In the driver's [Accumulator] defaults there is no
To view this discussion visit https://groups.google.com/d/msgid/weewx-user/d58615c9-d52f-46cd-af97-3408549fede9n%40googlegroups.com.
michael.k...@gmx.at
Sep 14, 2025, 6:46:57 AM (11 days ago) Sep 14
to weewx-user
@Ian:
[Accumulator]
[[p_rain]]
extractor = sum
The point I refer to is the following:
I use Werner's ecowitt_http.py, afaik he modified it in a way, that ecowitt devices with piezo rain gauges map the piezo sensor readings to "hail", so he didn't have to extend the database and he just uses "hail" for piezo rain readings, labeling it accordingly in the presentation. I extended the database, a later version Werner published then also mapped the piezo sensor data to "p_rain". So, using Werner's driver with an extended schema for "p_rain", in the database "p_rain" and "hail" should read exactly the same values. They do. (although it's odd they do, see below)
Werner's
ecowitt_http.py contains an [Accumulator] section, which contains a [[hail]] section, but it doesn't contain a [[p_rain]] section.
Now here's the thing: if specifying
[Accumulator]
[[p_rain]]
extractor = sum
is necessary to get correct readings from the sensor, why don't include this in the ecowitt_http.py already, just like with "hail"? And there is the other thing: why is "hail" (the very same data from the piezo sensor) also wrong in the database? In the ecowitt_http.py driver file there is already
[Accumulator]
[[hail]]
extractor = sum
[[hail]]
extractor = sum
Werner himself has this setting another time in his weewx.conf, which shouldn't be necessary, since it is already in the driver's defaults.
So I assume there is something wrong in the driver getting the correct defaults. In addition to correct this possible issue, a default for "p_rain" should be set in the driver.
steepleian
Sep 14, 2025, 7:25:43 AM (11 days ago) Sep 14
to weewx...@googlegroups.com
@Michael,
Yes I understand and that should straightforward enough to do. However I would like to make an additional observation here. I know we are all users of WeeWX with probably a substantial amount of valuable historical data. Imagine a new user who does not have that historical data, would it not be sensible to offer the alternative of a new schema that perfectly mirrored all the known possible sensors connected to the gateway. That could be a very straightforward choice offered in the final version of the driver, facilitated by a setting in weewx.conf.
On 14 Sep 2025, at 11:47, 'michael.k...@gmx.at' via weewx-user <weewx...@googlegroups.com> wrote:
@Ian:
To view this discussion visit https://groups.google.com/d/msgid/weewx-user/ad391d81-55cd-44c3-834f-c2cb29501acdn%40googlegroups.com.
jterr...@gmail.com
Sep 14, 2025, 7:33:10 AM (11 days ago) Sep 14
to weewx-user
May be because the default [Accumulator] section contained in the driver code ( in class EcowittHttpDriverConfEditor) seems not to be used !
The driver contain the following function :
def confeditor_loader():
return EcowittHttpDriverConfEditor()
return EcowittHttpDriverConfEditor()
which should use the Accumulator defaults, but this function is never called within the driver.
michael.k...@gmx.at
Sep 14, 2025, 7:34:55 AM (11 days ago) Sep 14
to weewx-user
That's another topic that already has been mentioned in this thread, afair, but it does go alang with my suggestion, not to map piezo rain to an non-rain obs_type that just hasn't beed used so far.
michael.k...@gmx.at
Sep 14, 2025, 7:36:16 AM (11 days ago) Sep 14
to weewx-user
@ jterr... I think this is the case, I also didn't find any reference calling this part of the code.
Reply all
Reply to author
Forward
0 new messages