OMG I just took a first glance at their "HTTP API":
"common_list": [{
"id": "0x02",
"val": "8.4",
"unit": "C"
}, {
"id": "0x07",
"val": "83%"
}, {
"id": "3",
"val": "6.2",
"unit": "C"
}, {
"id": "5",
"val": "0.187 kPa"
}, {
"id": "0x03",
"val": "5.7",
"unit": "C",
"battery": "0"
}, {
"id": "0x0B",
"val": "6.84 km/h"
}, {
"id": "0x0C",
"val": "10.80 km/h"
}, {
"id": "0x19",
"val": "27.00 km/h"
}, {
"id": "0x15",
"val": "2.29 W/m2"
}, {
"id": "0x17",
"val": "0"
}, {
"id": "0x0A",
"val": "340"
}, {
"id": "0x6D",
"val": "358"
}
]
I mean, WTF? We have HEX IDs, mixed with integer IDs, we have items with
attributes for values and one for their unit here, but also have value
string with units there, and then just values without unit at all, the
battery indicator is tied to the computed "windchill" value (0x03) and not
to a physical device. The inTemp (0x01) is not there, because it's not in
the "common_list", when you have a WH25 Temp/Humi/Pressure sensor attached.
Could it be worse?
[email protected] schrieb am Freitag, 16. Januar 2026 um 21:47:07 UTC+1:
> And one could separately deal with the backfilling.
> Another approach would be a custom firmware for their devices, under the
> hood ESP32 are doing the job. I didn't do more on this platform but
> building solar powered humitemp sensors that emit MQTT readings, so that's
> beyond my resources. Another more generic approach might be using something
> like the LILYGP LoRa32 devices to transform the raw sensor data into MQTT
> messages. Whatever would be the most straightforward way to get the sensor
> readings into the loop.
>
> Vince Skahan schrieb am Freitag, 16. Januar 2026 um 21:16:38 UTC+1:
>
>> I'm sure a lot of ecowitt's oddities are them cutting corners to minimize
>> cost.
>>
>> My opinion re: MQTT is that it removes a lot of complexity and results in
>> a far more maintainable setup.
>>
>> If you look at the ecowitt_local_http driver it's an unsupportable mess
>> to my eyes. Thousands and thousands of lines of code to deal with the
>> various sensor models. A driver that is over 13,500 lines of code is just
>> beyond too much. Heaven knows how big it would need to grow over time as
>> Ecowitt continues to add new sensors every week it seems.
>>
>> If you instead simply have the gateway emit MQTT it's much (much) easier
>> to see what it's transmitting and map the items specifically in weewx.conf
>> and ignore anything they emit you want to ignore.
>>
>> They even seem to emit somewhat reasonable element names in what they
>> publish to MQTT, far more reasonable than what you get if you query their
>> gateway directly via http://x.x.x.x/get_livedata_info which has some
>> 'very' odd naming conventions if you query the gateway directly.
>>
>> On Friday, January 16, 2026 at 11:43:13 AM UTC-8 [email protected]
>> wrote:
>>
>>> Will using MQTT make any real difference? Isn't it just another way to
>>> get the same data in the same intervals? That's another thing Ecowitt
>>> hasn't solved in the best way, imho: you can only obtain data from the
>>> device at a fixed interval. Why don't they distinguish between continuous
>>> data and discrete events? Why can't I receive lightning strikes as distinct
>>> events? Even if querying the API in a sub second interval was possible, you
>>> won't be able to guarantee to get a single strike event. Their console with
>>> the display receives and shows discrete events, their lightning strike
>>> sensor emits detected strikes as they happen. On the API side you only get
>>> blurred-over-query-interval data.
>>>
>>> Vince Skahan schrieb am Freitag, 16. Januar 2026 um 20:29:47 UTC+1:
>>>
>>>> You're running as a driver. You have the station type set to point to
>>>> the [EcowittHttp] stanza and you selected it via 'weectl station
>>>> reconfigure'.
>>>>
>>>> On Friday, January 16, 2026 at 10:32:29 AM UTC-8 NotThePainter wrote:
>>>>
>>>> On Friday, 16 January 2026 at 07:10:16 UTC-5 steepleian wrote:
>>>>
>>>> . Also the backfill only works when the extension is set up as a
>>>> driver, it does not work when set up as a service.
>>>>
>>>>
>>>> How do I know if I running as a driver or a service, or that even not a
>>>> good question.
>>>>
>>>>
--
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/8e3fe557-c826-4529-8cfc-ac9b198df1a5n%40googlegroups.com.
