| @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.
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.
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.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_infoIt 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" } ] Werner Krenn schrieb am Sonntag, 13. Juli 2025 um 21:42:54 UTC+2:
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.
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 schrieb am Samstag, 12. Juli 2025 um 21:44:37 UTC+2:
>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.txt
This 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. 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:- radiation is there - pm and co2 values are there - your version seems to deliver absolute pressure for barometer
![2025-07-12 20_00_52-Das Wetter in AT, Salzburg, Hallein, Rif - Brave.png]() Werner Krenn schrieb am Samstag, 12. Juli 2025 um 13:40:09 UTC+2:
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.
>difference between your version and the original: Short answer: My modified driver supports all currently possible sensors from Ecowitt and really ALL
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 schrieb am Freitag, 11. Juli 2025 um 18:16:17 UTC+2:
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:
At the moment there are no plans to create an installation package for this!
--
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/c09cd8dd-d8cb-494a-8904-902a21a4869cn%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/12E54FFC-F66F-41AF-991B-3E511654843B%40btinternet.com.
|
