Installation issues - Ecowitt Local HTTP API Driver

[NotThePainter]

I'm trying to install the cowitt Local HTTP API Driver from https://github.com/weewx-contrib/weewx-ecowitt_local_http?tab=readme-ov-file

I want the Local HTTP API Driver, not the old cloud / push driver.

% weectl extension install https://github.com/weewx-contrib/weewx-ecowitt_local_http/archive/refs/heads/main.zip --config ~/Documents/WeeWX/weewx-data/weewx.conf

Reconfiguring this way doesn't work:

weectl station reconfigure --driver=user.ecowitt_local_http --config ~/Documents/WeeWX/weewx-data/weewx.conf

I get:

ModuleNotFoundError: No module named 'user.ecowitt_local_http'

If I reconfigure this way:

% weectl station reconfigure --driver=user.ecowitt_http --config ~/Documents/WeeWX/weewx-data/weewx.conf

it works but when I run I get this error:

 %  weewxd --config ~/Documents/WeeWX/weewx-data/weewx.conf

AttributeError: 'EcowittHttpDriver' object has no attribute 'api_key'

which means I'm using the old cloud/push driver.

How can I reconfigure it to use the new Local HTTP API driver?

[Vince Skahan]

Module not found tends to be a typo. What does ‘weectl extension list’ say ?

[Vince Skahan]

And run 'weectl station reconfigure' and look carefully at the selections there.  You don't see one called user.ecowitt_local_http in the list.

[Rainer Lang]

the "no attribute 'api_key' " suggests that you have an api_key entry in your weewx.conf but no key entered

I suggest you get yourself an API and an APP key in your ecowitt.net account and enter it into the [EcowittHttp] stanza on your weewx.conf including the MAC address of the console
or
in the [EcowittHttp] stanza in weewx.conf comment the line with "api_key" out by placing a # in front

[EcowittHttp] 

......

# provide Ecowitt API and APP key to have permission for the ecowitt.net backfill download
       # api_key = xxxxxxxxxxxxxxx
       # app_key = xxxxxxxxxxxxxxx
    # MAC address to identify the console
       # mac = xx:xx:xx:xx:xx:xx

......

--
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/59e2b382-4e85-4074-b96f-b749d74a1c7fn%40googlegroups.com.

[NotThePainter]

% weectl extension list --config ~/Documents/WeeWX/weewx-data/weewx.conf

Using configuration file /Users/pcezanne/Documents/WeeWX/weewx-data/weewx.conf
Extension Name    Version   Description
Ecowitt_HTTP      0.1.0a28  WeeWX driver for devices supporting the Ecowitt local HTTP API.

## lets try the Extension Name listed in the GitHub ReadMe
## this reconfigure succeeds but weewxd fail with the api-key message

% weectl station reconfigure --driver=user.ecowitt_http --config ~/Documents/WeeWX/weewx-data/weewx.conf

## lets try the Extension Name listed by weectl
## this fails with ModuleNotFoundError: No module named 'user.Ecowitt_HTTP'
% weectl station reconfigure --driver=user.Ecowitt_HTTP --config ~/Documents/WeeWX/weewx-data/weewx.conf

[NotThePainter]

On Thursday, 15 January 2026 at 03:24:19 UTC-5 Rainer Lang wrote:

the "no attribute 'api_key' " suggests that you have an api_key entry in your weewx.conf but no key entered

I don't! I was so hopeful...

[EcowittHttp]
    # This section is for the Ecowitt Local HTTP API driver.
   
    # The device IP address:
    ip_address = 10.0.4.37
   
    # How often to poll the API, default is every 20 seconds:
    poll_interval = 20
   
    # The driver to use:
    driver = user.ecowitt_http
   
    # Is a WN32P used for indoor temperature, humidity and pressure
    wn32_indoor = False
   
    # Is a WN32 used for outdoor temperature and humidity
    wn32_outdoor = False
    [[field_map_extensions]]
        rainRate = rain.0x0E.val

 

I suggest you get yourself an API and an APP key in your ecowitt.net account and enter it into the [EcowittHttp] stanza on your weewx.conf including the MAC address of the console

This is what I absolutely do not want to do. I do not want the old cloud/push driver. I want the newer Local HTTP driver.

[Rainer Lang]

I understand what you don't want, but you obviously don't understand what that API/APP keys are about.
It has nothing to do with what you call "your old cloud/push driver", probably the Interceptor driver.

Anyhow, the 2nd option I mentioned was to have no keys/commented them out.

Maybe you tell us what your station model is 😉.

--

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/18c4ec78-3125-431f-b413-729f14c40df5n%40googlegroups.com.

[NotThePainter]

On Thursday, 15 January 2026 at 09:27:52 UTC-5 Rainer Lang wrote:

I understand what you don't want, but you obviously don't understand what that API/APP keys are about.
It has nothing to do with what you call "your old cloud/push driver", probably the Interceptor driver.

Anyhow, the 2nd option I mentioned was to have no keys/commented them out.

Maybe you tell us what your station model is 😉.

Sorry about that, I'm runnig the GW3000 and the get_livedata_info endpoint works just fine.

As far as I understand it, the API key is to talk to the Ecowitt server. I don't want that at all. My data should stay on my network, I don't need somebody elses server. I could be wrong, I'm trying to figure this out and it is complicated until it isn't. :- )

Gary's approach seems to be a modern, robust archicture and I'd like to use that. The code at https://github.com/weewx-contrib/weewx-ecowitt_local_http?tab=readme-ov-file seems to be a fork of that. I just can't get it to run.

And I don't have any keys mentioned at all in my conf file, that's what's weird.

 

[Vince Skahan]

There are multiple things going on here.

• you have your weewx.conf in an odd place, so every time your run a weewx command you need to specify --config=/path/to/weewx.conf or equivalent

• there are multiple ecowitt drivers each with different configurations
  • (1) the original gw1000 driver is Gary's original one:
    • is rehosted at https://github.com/weewx-contrib/weewx-gw1000
    • is listed in the wiki as 'gw1000 - Collect data from Ecowitt GW1000/GW1100/GW2000'
    • does not support any APIs nor keys
    • calls itself [GW1000] in weewx.conf
  • (2) Gary's later development driver using local http: 
    • is rehosted at https://github.com/weewx-contrib/weewx-ecowitt_local_http
    • is not listed in the wiki
    • does not support any APIs nor keys
    • calls itself [EcowittHttp] in weewx.conf
  • (3) Werner has an additional driver with a very very manual procedure to install and configure:
    • is listed in the wiki as "ecowitt_http - Collect data from all Ecowitt gateways/displays which support the http api. Can also import data from SDCard (GW3000, WS6210) or from the Ecowitt Cloud"
    • is hosted at https://github.com/WernerKr/Ecowitt-or-DAVIS-stations-and-Season-skin/tree/main
    • DOES need API keys according to its readme file
    • unfortunately also calls itself [EcowittHttp] in weewx.conf stomping on the original one's name yet has much more elaborate configuration needs
    • does not use the extension installer, so I don't know if 'weectl extension list' or 'weewx station reconfigure' will find i

For a gw3000 gateway:

• you can use the original weewx-gw1000 driver (1) above from Gary and run without backfill
• or you could use the weewx-ecowitt_local_http driver (2) above originally from Gary, but I don't know if backfill works or not in that one
  
• I can't speak to Werner's driver (3) above at all. Personally I find it so complicated and manual in nature I haven't even tried it.  I agree with you on the API key thing FWIW.  The fact that it doesn't use the extension installer and that it stomps on another driver's name makes it a no-go for me personally.  For me that way lies chaos and confusion.

When you say you tried the weewx-ecowitt_local_http and couldn't get it to run, you need to provide more data on what you did and what you saw.  My guess is you have junk in your setup from going back and forth.

If you can do so, I'd basically start over on the station setup:

• rename your weewx-data directory to move it aside
• run 'weectl station create --noprompt' to create a new one using the Simulator
• add the driver you want via 'weectl extension install' 
• run 'weectl station reconfigure' to pick the added driver
• answer the questions it'll ask you re: the ip address of your gateway etc.
• test your setup re: the driver's readme file instructions

Lastly remember your odd location of weewx.conf means you will always need to specify where to find the config file in any weectl or weewxd commands.  If you don't do that they'll look in the normal locations (which presumably are not present) and you'll get file-not-found or module-not-found etc. type errors.

[NotThePainter]

On Thursday, 15 January 2026 at 13:08:59 UTC-5 Vince Skahan wrote:

If you can do so, I'd basically start over on the station setup:

• rename your weewx-data directory to move it aside
• run 'weectl station create --noprompt' to create a new one using the Simulator
• add the driver you want via 'weectl extension install' 
• run 'weectl station reconfigure' to pick the added driver
• answer the questions it'll ask you re: the ip address of your gateway etc.
• test your setup re: the driver's readme file instructions

Lastly remember your odd location of weewx.conf means you will always need to specify where to find the config file in any weectl or weewxd commands.  If you don't do that they'll look in the normal locations (which presumably are not present) and you'll get file-not-found or module-not-found etc. type errors.

I went with option #2, Gary's later development hosted at https://github.com/weewx-contrib/weewx-ecowitt_local_http

I also went with your very astute advice, and nuked everything, and paid very special attention to making sure my strange paths were used.

% rm -rf ~/weewx-data ~/Documents/WeeWX/weewx-data
% mkdir -p ~/Documents/WeeWX/weewx-data
% cd ~/Documents/WeeWX
% weectl station create ~/Documents/WeeWX/weewx-data

so far, so good!

% weectl extension install https://github.com/weewx-contrib/weewx-ecowitt_local_http/archive/refs/heads/main.zip --config ~/Documents/WeeWX/weewx-data/weewx.conf 

The install ran successfully. This was the only configure line to run without error:

weectl station reconfigure --driver=user.ecowitt_http --config ~/Documents/WeeWX/weewx-data/weewx.conf

Lets list it out.

 % weectl extension list --config ~/Documents/WeeWX/weewx-data/weewx.conf

Using configuration file /Users/pcezanne/Documents/WeeWX/weewx-data/weewx.conf
Extension Name    Version   Description
Ecowitt_HTTP      0.1.0a28  WeeWX driver for devices supporting the Ecowitt local HTTP API.

The driver test also worked, giving me live data:

% python3 ~/Documents/WeeWX/weewx-data/bin/user/ecowitt_http.py --test-driver --ip-address=10.0.4.37 --config ~/Documents/WeeWX/weewx-data/weewx.conf

2026-01-15 15:22:23 EST (1768508543): dateTime: 1768508543, dewpoint: 0.0, feelslike: 0.8888888888888896, inHumidity: 74, inTemp: 2.000000000000001, outHumidity: 94, outTemp: 0.8888888888888896, pressure: 973.2479568438692, rainRate: 0.0, relbarometer: 973.2479568438692, t_rainday: 4.064, t_rainevent: 7.365999999999999, t_rainmonth: 17.018, t_rainweek: 9.398, t_rainyear: 17.018, usUnits: 17, vpd: 0.406366579057983, wh26_batt: 0, wh26_sig: 4

I was feeling pretty good at this point, let's run it! Sadness, it doesn't run, still wanting that api_key which shouldn't be in play.

% weewxd --config ~/Documents/WeeWX/weewx-data/weewx.conf

...

AttributeError: 'EcowittHttpDriver' object has no attribute 'api_key'

It was a great suggestion, I did find errors in my unusual paths which surely would have vexed me down the road, but still joy here.

 

[Vince Skahan]

I looked at the code for bin/user/ecowitt_http.py and it definitely wants to see an api_key in your weewx.conf file for its catchup/backfill code.  No way around it that I can see if you want to use that driver.  Unfortunately it's not documented in the legacy instructions and Gary's wiki was lost to the sands of time when he went dark and deleted all his stuff on github in early June.

If you can live without backfill just use the gw1000 driver.

[NotThePainter]

On Thursday, 15 January 2026 at 16:14:39 UTC-5 Vince Skahan wrote:

I looked at the code for bin/user/ecowitt_http.py and it definitely wants to see an api_key in your weewx.conf file for its catchup/backfill code.  No way around it that I can see if you want to use that driver.  Unfortunately it's not documented in the legacy instructions and Gary's wiki was lost to the sands of time when he went dark and deleted all his stuff on github in early June.

I want backfill. I just got my API Key. Off to install it.

Thanks for your help Vince and everybody else!

 

[NotThePainter]

I want backfill. I just got my API Key. Off to install it.

So I added this to my conf file and I still get the "AttributeError: 'EcowittHttpDriver' object has no attribute 'api_key'" error.

[EcowittHttp]
    # This section is for the Ecowitt Local HTTP API driver.

    api_key = 3f405ece-90e9-4697-********

   
    # The device IP address:
    ip_address = 10.0.4.37

 

   etc...

 

[Vince Skahan]

Sorry - can't help you.  That thing is too absurdly complicated and undocumented for me.

Again - I'd take the 90% win and just use the gw1000 driver to get 'anything' working unless somebody has battled this variant into submission successfully.

[steepleian]

For this version of the driver which was Gary’s final version, the API key is most definitely not required and is probably why you are having problems with your weewx.conf. Also the backfill only works when the extension is set up as a driver, it does not work when set up as a service.

Quickly reading through this thread, unless I have missed it, I cannot see which device you are using. I have only tested it with a GW3000 which is the only one of the GW series of devices that has the on-board logging to a removable SD card, which is required by this version of the driver for backfill to work.

This is my own working weewx.conf snippet which is working perfectly for me, including backfill (see below link).

[EcowittHttp]

    # This section is for the Ecowitt local HTTP API driver.

    

    # the driver to use

    driver = user.ecowitt_http

    

    # how often to poll the device

    poll_interval = 8

    # how many attempts to contact the device before giving up

    max_tries = 3

    # wait time in seconds between retries to contact the device

    retry_wait = 2

    # max wait for device to respond to a HTTP request

    url_timeout = 3

    

    # whether to show all battery state data including nonsense data and 

    # sensors that are disabled sensors and connecting

    show_all_batt = False

    # whether to ignore battery state data from legacy WH40 sensors that do 

    # not provide valid battery state data

    ignore_legacy_wh40_battery = True

    # whether to always log unknown API fields, unknown fields are always 

    # logged at the debug level, this will log them at the info level

    log_unknown_fields = False

    

    # How often to check for device firmware updates, 0 disables firmware 

    # update checks. Available firmware updates are logged.

    firmware_update_check_interval = 86400

    

    # provide additional log information to help debug rainfall issues

    debug_rain = False

    # provide additional log information to help debug wind issues

    debug_wind = False

    # provide additional log information to help debug loop packet issues

    debug_loop = False

    # provide additional log information to help debug sensor issues

    debug_sensors = False

    ip_address = 192.168.55.102

    [[field_map_extensions]]

        batteryStatus1 = ws90.battery

        rain = rain.0x10.val

        stormRain = rain.0x0D.val

        rainRate = rain.0x0E.val

        hourRain = t_rainhour

        dayRain = rain.0x10.val

        weekRain = rain.0x11.val

        monthRain = rain.0x12.val

        yearRain = rain.0x13.val

        is_raining = piezoRain.srain_piezo.val

        p_rain = piezoRain.0x10.val

        p_stormRain = piezoRain.0x0D.val

        p_rainRate = piezoRain.0x0E.val

        p_hourRain = p_rainhour

        p_dayRain = piezoRain.0x10.val

        p_weekRain = piezoRain.0x11.val

        p_monthRain = piezoRain.0x12.val

        p_yearRain = piezoRain.0x13.val

        vpd = common_list.5.val

        lightning_distance = lightning.distance

        lightning_last_det_time = lightning.timestamp

        lightningcount = lightning.count

        pm2_5 = ch_pm25.1.PM25_RealAQI

        pm2_52_24h_avg = ch_pm25.1.PM25_24HAQI

        pm10_0 = co2.PM10

        radiation = common_list.0x15.val

If you do not have a device with onboard logging, I would, as Vince has suggested, use the GW1000 driver.

https://claydonsweather.org.uk

On 16 Jan 2026, at 01:27, Vince Skahan <vince...@gmail.com> wrote:

Sorry - can't help you.  That thing is too absurdly complicated and undocumented for me.

--

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/f401c5cb-867b-4ee6-ad37-d762523fb4ddn%40googlegroups.com.

[NotThePainter]

On Friday, 16 January 2026 at 07:10:16 UTC-5 steepleian wrote:

For this version of the driver which was Gary’s final version, the API key is most definitely not required and is probably why you are having problems with your weewx.conf. Also the backfill only works when the extension is set up as a driver, it does not work when set up as a service.

That is good to know, I'd like to get backfill working locally, it just seems like a cleaner way to do it. Until recently, I did not have an API key in my conf, but when I run weewxd it crashes looking for an API key.

I'm running this version:

Ecowitt_HTTP      0.1.0a28  WeeWX driver for devices supporting the Ecowitt local HTTP API.

is that the correct one? I'm starting to think that my code just isn't the right code. I got it from https://github.com/weewx-contrib/weewx-ecowitt_local_http/archive/refs/heads/main.zip which should be the latest, but maybe the latest is broken? Is there a chance you can zip up your driver and send it to me?

 

Quickly reading through this thread, unless I have missed it, I cannot see which device you are using. I have only tested it with a GW3000 which is the only one of the GW series of devices that has the on-board logging to a removable SD card, which is required by this version of the driver for backfill to work.

GW3000, no SD card, but I can pop over to Staples and get one today real quick.

 

This is my own working weewx.conf snippet which is working perfectly for me, including backfill (see below link).

that looks similar to mine.

 

If you do not have a device with onboard logging, I would, as Vince has suggested, use the GW1000 driver.

I really want backfill working.

 

 

[Vince Skahan]

Ian FWIW - I get the same api_key not found error vs. a gw1200 but I couldn’t figure a way to define one. Also couldn’t figure out how to turn backfill off nor say which way(s) to attempt backfill. The code is just too convoluted to follow.

It also blows up if you have no rain sensor so I had to patch the code with a try/except for that.

I still lean toward MQTT being the way to go for ecowitt since mqttsubscribe as a driver is so solid,  but that still leaves the how to backfill question…

[Chuck Rhode]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 16 Jan 2026 06:14:29 -0800 (PST)
NotThePainter <notthe...@gmail.com> wrote:

> I really want backfill working.

Me, too. What's wrong with us?

- --
.. Be Seeing You,
.. Chuck Rhode, Sheboygan, WI, USA
.. Weather: https://LacusVeris.com/Wx
.. 29° — Wind WSW at 10 mph. Sky overcast.
-----BEGIN PGP SIGNATURE-----

iF0EARECAB0WIQT+MY/5I/LMPSswTbVg2/xipKOWUgUCaWp4igAKCRBg2/xipKOW
Uq7lAJ9Y+Qf9dDTBfNiksVjmKc0Q/AEMZQCfTLGv80mURUn7HOz5w3JBoOuFpOs=
=DoV5
-----END PGP SIGNATURE-----

[NotThePainter]

SOLVED!

The solution is to put an SD card into the GW3000. I guess the backfill code asks the GW3000 for data, the GW3000 says "I dunno...." and then the driver asks the Ecowitt server, and that needs an API Key.

Now to get the station up and live!

[NotThePainter]

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.

Right now I just ran weewxd from the command line, next up is to get running for real on my MacOS laptop, that might be a tomorrow project.\

Thanks!

 

[michael.k...@gmx.at]

It starts with the fact that the API of Ecowitt devices is configuration-dependent and depends on whether you connect other sensors to the stations, makes sensor values available, or hides them: for example, if you have a WS90, it has a humitemp sensor that measures the outdoor temperature and humidity, and these values are displayed via the HTTP API. If you add a WH32 (outdoor humitemp) to the respective gateway, the sensor values of the WS90's humitemp sensor are no longer available; instead, the values of the new WH32 are provided. It is possible to operate a classic tipping rain gaugein parallel with a piezo rain sensor and query these values via the same API, but it is not possible to operate a cup anemometer simultaneously with the WS90's ultrasonic anemometer. Gary's driver for the local HTTP API is a monster; I wouldn't dare to tame it. I think you would have to start from scratch and write a driver that first abstracts the local HTTP API in a configurable way and also makes it possible to query any number of ecowitt devices with HTTP API and bring their data into the loop, where you can then individually configure which data is ultimately written to the database and under what conditions.

[steepleian]

Vince, absolutely agree about MQTT. I am working on a version that uses MQTT and backfill at the moment. My starting point is to extract the backfill function from Gary’s driver and get that working as a standalone in the first instance. I am nearly there on my test server.  I already have a bespoke MQTT driver which on first run checks for a database. If none is present, it generates its own schema based only on the valid data from the gateway. 

On 16 Jan 2026, at 18:17, NotThePainter <notthe...@gmail.com> wrote:

SOLVED!

The solution is to put an SD card into the GW3000. I guess the backfill code asks the GW3000 for data, the GW3000 says "I dunno...." and then the driver asks the Ecowitt server, and that needs an API Key.

Now to get the station up and live!

--
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/cceaf2c3-efc8-4c7b-b2f1-bab2c83a54e2n%40googlegroups.com.

[Vince Skahan]

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'.

[Vince Skahan]

Ian - I asked the more general question over in the weewx-development forum.

I still like Rich's MQTTSubscribe as the solution for MQTT both as a driver or as a service, but I do like the idea of a generic set of sensor mappings with the various combinations possible given all the models of ecowitt gear.

My old MQTTSubscribe stanza is (HERE) if you want to take a look.  I have some FIXME items noted therein where I didn't map things to weewx fields before I sent the test gear back for a refund. I did need to add some fields to be able to support both piezo and tipping rain gauges when I had the WS85 and WH40 here for testing last fall but there are so many sensor models to try to keep track of....

You have my email :-)

[michael.k...@gmx.at]

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]

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.

[michael.k...@gmx.at]

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.

[michael.k...@gmx.at]

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?

[steepleian]

I agree with Vince, MQTT is much the simpler way to go. The payload is a bit of an odd format however you can either parse that payload locally into .json or publish to a broker. That just leaves the backfill issue to resolve.

On 8 Feb 2026, at 14:20, 'michael.k...@gmx.at' via weewx-user <weewx...@googlegroups.com> wrote:

OMG I just took a first glance at their "HTTP API":

--
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/8e3fe557-c826-4529-8cfc-ac9b198df1a5n%40googlegroups.com.

[bell...@gmail.com]

Where can one find the documentation for the API(s).

For what its worth, I am most interested in the backfill

Thanks. rich

[michael.k...@gmx.at]

https://oss.ecowitt.net/uploads/20260114/HTTP%20API%20interface%20Protocol%20(Generic)-(V1.0.6-2026-1-14)%20.pdf

[Vince Skahan]

On Sunday, February 8, 2026 at 6:19:56 AM UTC-8 michael.k...@gmx.at wrote:

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?

I dunno - firmware APIs are pretty typically an adventure.

Look at the construction of a Davis LOOP packet down in https://cdn.shopify.com/s/files/1/0515/5992/3873/files/VantageSerialProtocolDocs_v261.pdf?v=1614399559 starting on page 21 in that file.

I don't miss parsing that kind of stuff the hard way.

[steepleian]

On 8 Feb 2026, at 16:08, bell...@gmail.com <bell...@gmail.com> wrote:

Where can one find the documentation for the API(s).

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

[gary....@gmail.com]

I think the author of this would be quite knowledgeable about getting info from the Ecowitt devices.

https://wiki.loxberry.de/plugins/foshkplugin/foshkplugin_generic_version