Where can one find the documentation for the API(s).
For what its worth, I am most interested in the backfill
Thanks. rich

On Sunday, 8 February 2026 at 09:19:56 UTC-5 [email protected] wrote:

> 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/4ccdb608-69c8-4ad1-9fea-af394bd477ccn%40googlegroups.com.

Reply via email to