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. [email protected] schrieb am Montag, 14. Juli 2025 um 19:00:55 UTC+2: > 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:10196: SyntaxWarning: invalid escape > sequence '\d' > _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) > steepleian schrieb am Montag, 14. Juli 2025 um 18:29:24 UTC+2: > >> @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 < >> [email protected]> wrote: >> >> 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. >> >> [email protected] schrieb am Montag, 14. Juli 2025 um 16:35:02 UTC+2: >> >>> >>> 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. >>> [email protected] schrieb am Montag, 14. Juli 2025 um 15:27:33 UTC+2: >>> >>>> 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" >>>> } >>>> ] >>>> 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. >>>>> >>>>> [email protected] schrieb am Sonntag, 13. Juli 2025 um 09:25:09 >>>>> UTC+2: >>>>> >>>>>> 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.* >>>>>>> [email protected] schrieb am Samstag, 12. Juli 2025 um 20:03:42 >>>>>>> UTC+2: >>>>>>> >>>>>>>> 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 >>>>>>>> >>>>>>>> [image: 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* >>>>>>>>> >>>>>>>>> >>>>>>>>> https://github.com/WernerKr/Ecowitt-or-DAVIS-stations-and-Season-skin/blob/main/ecowitt_http/compare_%20gw3000_live_data.txt >>>>>>>>> [email protected] schrieb am Samstag, 12. Juli 2025 um 00:17:02 >>>>>>>>> UTC+2: >>>>>>>>> >>>>>>>>>> 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: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> https://github.com/WernerKr/Ecowitt-or-DAVIS-stations-and-Season-skin/tree/main/ecowitt_http >>>>>>>>>>> >>>>>>>>>>> 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 >> >> <https://groups.google.com/d/msgid/weewx-user/c09cd8dd-d8cb-494a-8904-902a21a4869cn%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> -- 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/2c03d668-7540-41b2-94b9-39cac745e92bn%40googlegroups.com.
