https://oss.ecowitt.net/uploads/20260114/HTTP%20API%20interface%20Protocol%20(Generic)-(V1.0.6-2026-1-14)%20.pdf
[email protected] schrieb am Sonntag, 8. Februar 2026 um 17:08:35 UTC+1: > 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/4bce9980-9314-4254-87a2-2f72fd77f3fcn%40googlegroups.com.
