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 <
> weewx...@googlegroups.com> 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.
>
> michael.k...@gmx.at 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.
>> michael.k...@gmx.at 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.
>>>>
>>>> michael.k...@gmx.at 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.*
>>>>>> michael.k...@gmx.at 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
>>>>>>>> michael.k...@gmx.at 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 weewx-user+...@googlegroups.com.
> 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 weewx-user+unsubscr...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/weewx-user/136b24d6-f699-40c5-9fc8-2b77a7910ba8n%40googlegroups.com.
