Welcome to the Cumulus Support forum.
Latest Cumulus MX V4 release 4.4.2 (build 4085) - 12 March 2025
Latest Cumulus MX V3 release 3.28.6 (build 3283) - 21 March 2024
Legacy Cumulus 1 release 1.9.4 (build 1099) - 28 November 2014
(a patch is available for 1.9.4 build 1099 that extends the date range of drop-down menus to 2030)
Download the Software (Cumulus MX / Cumulus 1 and other related items) from the Wiki
If you are posting a new Topic about an error or if you need help PLEASE read this first viewtopic.php?p=164080#p164080
Latest Cumulus MX V4 release 4.4.2 (build 4085) - 12 March 2025
Latest Cumulus MX V3 release 3.28.6 (build 3283) - 21 March 2024
Legacy Cumulus 1 release 1.9.4 (build 1099) - 28 November 2014
(a patch is available for 1.9.4 build 1099 that extends the date range of drop-down menus to 2030)
Download the Software (Cumulus MX / Cumulus 1 and other related items) from the Wiki
If you are posting a new Topic about an error or if you need help PLEASE read this first viewtopic.php?p=164080#p164080
Ecowitt Data Access API's
Moderator: mcrossley
-
Phil23
- Posts: 888
- Joined: Sat 16 Jul 2016 11:59 pm
- Weather Station: Davis VP2+ & GW1000 (Standalone)
- Operating System: Win10 Pro / rPi Buster
- Location: Australia
Ecowitt Data Access API's
I'm Assuming you only need 1 pair of API keys even if you have multiple stations on your Ecowitt.net account.
Simple testing found I could make multiple keys and initially I thought they were different per station, but on generation a second one for the same station it was different again.
Next assumption is that it's just the Mac Address that distinguishes them.
I have 2 Ecowitt stations uploading to ew.net.
First uploads from 3 devices, (Out of curiosity)
HP2551, GW1000 & GW1100.
Second only uploads from the HP2551 while it's GW1000 only communicates with CMX.
Is there any issue in using the HP2551's Mac for the catch-up when CMX it's self used the GW1000 on that site?
https://s7.inverellit.com/
(Remote site & 3/4 hour drive away with only VNC access to CMX rPi).
Simple testing found I could make multiple keys and initially I thought they were different per station, but on generation a second one for the same station it was different again.
Next assumption is that it's just the Mac Address that distinguishes them.
I have 2 Ecowitt stations uploading to ew.net.
First uploads from 3 devices, (Out of curiosity)
HP2551, GW1000 & GW1100.
Second only uploads from the HP2551 while it's GW1000 only communicates with CMX.
Is there any issue in using the HP2551's Mac for the catch-up when CMX it's self used the GW1000 on that site?
https://s7.inverellit.com/
(Remote site & 3/4 hour drive away with only VNC access to CMX rPi).
:Now: :Today/Yesterday:

Main Station Davis VP2+ Running Via Win10 Pro.
Secondary Stations, Ecowitt HP2551/GW1000 Via rPi 3 & 4 Running Buster GUI.
:Local Inverell Ecowitt Station: :Remote Ashford Ecowitt Station:
Main Station Davis VP2+ Running Via Win10 Pro.
Secondary Stations, Ecowitt HP2551/GW1000 Via rPi 3 & 4 Running Buster GUI.
:Local Inverell Ecowitt Station: :Remote Ashford Ecowitt Station:
- HansR
- Posts: 6926
- Joined: Sat 20 Oct 2012 6:53 am
- Weather Station: GW1100 (WS80/WH40)
- Operating System: Raspberry OS/Bookworm
- Location: Wagenborgen (NL)
- Contact:
Re: Ecowitt Data Access API's
I think you should keep the user key the same for the two cmx installations. (A)
Then you generate two different application keys for the two different CMX installations. (B and C)
In the first CMX you use AB and the Mac address and for the other CMX (the remote) you use AC and the remote MacAddress.
Then you generate two different application keys for the two different CMX installations. (B and C)
In the first CMX you use AB and the Mac address and for the other CMX (the remote) you use AC and the remote MacAddress.
Hans
https://meteo-wagenborgen.nl
CMX build 4070+ ● RPi 4B ● Linux 6.6.62+rpt-rpi-v8 aarch64 (bookworm) ● dotnet 8.0.1
BlueSky: https://bsky.app/profile/wagenborgenwx.bsky.social
https://meteo-wagenborgen.nl
CMX build 4070+ ● RPi 4B ● Linux 6.6.62+rpt-rpi-v8 aarch64 (bookworm) ● dotnet 8.0.1
BlueSky: https://bsky.app/profile/wagenborgenwx.bsky.social
- HansR
- Posts: 6926
- Joined: Sat 20 Oct 2012 6:53 am
- Weather Station: GW1100 (WS80/WH40)
- Operating System: Raspberry OS/Bookworm
- Location: Wagenborgen (NL)
- Contact:
Re: Ecowitt Data Access API's
Btw: one user Api and one application Api and only differ in Mac Address would work as well
Hans
https://meteo-wagenborgen.nl
CMX build 4070+ ● RPi 4B ● Linux 6.6.62+rpt-rpi-v8 aarch64 (bookworm) ● dotnet 8.0.1
BlueSky: https://bsky.app/profile/wagenborgenwx.bsky.social
https://meteo-wagenborgen.nl
CMX build 4070+ ● RPi 4B ● Linux 6.6.62+rpt-rpi-v8 aarch64 (bookworm) ● dotnet 8.0.1
BlueSky: https://bsky.app/profile/wagenborgenwx.bsky.social
- mcrossley
- Posts: 14388
- Joined: Thu 07 Jan 2010 9:44 pm
- Weather Station: Davis VP2/WLL
- Operating System: Bullseye Lite rPi
- Location: Wilmslow, Cheshire, UK
- Contact:
Re: Ecowitt Data Access API's
I think that is a fair summary.
Both User Keys and Application keys are "rate limited" - User keys to 2 requests/second, Application keys to 3 requests/second. CMX will not hit anything like as processing 24 hours of historic data will take longer than a second anyway before the next request is made. Even two instances of CMX running in parallel would still only be two per second.
The rate limiting policy seems a bit odd to me because you can create more than one key, so in theory if you wanted to hammer the system, just create lots of keys and create a program that uses them all in parallel or very quickly sequentially. I still do not understand the requirement for two keys either, it seems to be an extra level of complication that adds nothing**
** I suspect I know how it came to be though!
Both User Keys and Application keys are "rate limited" - User keys to 2 requests/second, Application keys to 3 requests/second. CMX will not hit anything like as processing 24 hours of historic data will take longer than a second anyway before the next request is made. Even two instances of CMX running in parallel would still only be two per second.
The rate limiting policy seems a bit odd to me because you can create more than one key, so in theory if you wanted to hammer the system, just create lots of keys and create a program that uses them all in parallel or very quickly sequentially. I still do not understand the requirement for two keys either, it seems to be an extra level of complication that adds nothing**
** I suspect I know how it came to be though!
- HansR
- Posts: 6926
- Joined: Sat 20 Oct 2012 6:53 am
- Weather Station: GW1100 (WS80/WH40)
- Operating System: Raspberry OS/Bookworm
- Location: Wagenborgen (NL)
- Contact:
Re: Ecowitt Data Access API's
Now I am curious
Hans
https://meteo-wagenborgen.nl
CMX build 4070+ ● RPi 4B ● Linux 6.6.62+rpt-rpi-v8 aarch64 (bookworm) ● dotnet 8.0.1
BlueSky: https://bsky.app/profile/wagenborgenwx.bsky.social
https://meteo-wagenborgen.nl
CMX build 4070+ ● RPi 4B ● Linux 6.6.62+rpt-rpi-v8 aarch64 (bookworm) ● dotnet 8.0.1
BlueSky: https://bsky.app/profile/wagenborgenwx.bsky.social
-
malkie
- Posts: 93
- Joined: Sun 02 Jan 2011 9:38 am
- Weather Station: Davis Vision-Vue
- Operating System: Raspbian Jessie
- Location: Stevenage, Herts, UK
Re: Ecowitt Data Access API's
Having some problems getting this to work.
I have set up a new Pi4 to log the data from my GW1100 which so far has external temp/humidity, Rain gauge and Air Q sensors. The wind gauge should be up later today.
I have created my API keys and copied and pasted them from Ecowitt.net to the User interface. The API key has hyphens and text is in lower case, the Application key is all in Uppercase.
My MXdiag file after a restart shows:
2022-02-13 22:11:08.439 GetHistoricData: Starting Historic Data Process
2022-02-13 22:11:08.445 API.GetHistoricData: Get Ecowitt Historic Data
2022-02-13 22:11:08.456 API.GetHistoricData: Exception:
Yesterday I took the pi off line for a short time and the data uploaded by the GW1100 was not picked up.
Any ideas?
EDIT:
I turned on Debig Logging and got a bit more info:
2022-02-14 12:12:21.290 API.GetHistoricData: Get Ecowitt Historic Data
2022-02-14 12:12:21.290 Ecowitt URL = https://api.ecowitt.net/api/v3/device/h ... _type=5min
2022-02-14 12:12:22.853 API.GetHistoricData: Ecowitt API Historic Response code: 200
2022-02-14 12:12:22.853 API.GetHistoricData: Ecowitt API Historic Response: {"code":0,"msg":"success","time":"1644840742","data":[]}
2022-02-14 12:12:23.201 Lock: Station releasing the lock
2022-02-14 12:12:23.267 Starting GW1000
I have set up a new Pi4 to log the data from my GW1100 which so far has external temp/humidity, Rain gauge and Air Q sensors. The wind gauge should be up later today.
I have created my API keys and copied and pasted them from Ecowitt.net to the User interface. The API key has hyphens and text is in lower case, the Application key is all in Uppercase.
My MXdiag file after a restart shows:
2022-02-13 22:11:08.439 GetHistoricData: Starting Historic Data Process
2022-02-13 22:11:08.445 API.GetHistoricData: Get Ecowitt Historic Data
2022-02-13 22:11:08.456 API.GetHistoricData: Exception:
Yesterday I took the pi off line for a short time and the data uploaded by the GW1100 was not picked up.
Any ideas?
EDIT:
I turned on Debig Logging and got a bit more info:
2022-02-14 12:12:21.290 API.GetHistoricData: Get Ecowitt Historic Data
2022-02-14 12:12:21.290 Ecowitt URL = https://api.ecowitt.net/api/v3/device/h ... _type=5min
2022-02-14 12:12:22.853 API.GetHistoricData: Ecowitt API Historic Response code: 200
2022-02-14 12:12:22.853 API.GetHistoricData: Ecowitt API Historic Response: {"code":0,"msg":"success","time":"1644840742","data":[]}
2022-02-14 12:12:23.201 Lock: Station releasing the lock
2022-02-14 12:12:23.267 Starting GW1000
Malcolm
North Herts, UK
http://elm30net.ddns.net
CumulusMX on Raspberry Pi4 B+ 2GB, running on Raspbian Buster booting from USB SSD
from a Davis Vantage Vue with VP2 ISS.
North Herts, UK
http://elm30net.ddns.net
CumulusMX on Raspberry Pi4 B+ 2GB, running on Raspbian Buster booting from USB SSD
from a Davis Vantage Vue with VP2 ISS.
-
water01
- Posts: 3670
- Joined: Sat 13 Aug 2011 9:33 am
- Weather Station: Ecowitt HP2551
- Operating System: Windows 10/11 64bit Synology NAS
- Location: Burnham-on-Sea
- Contact:
Re: Ecowitt Data Access API's
Works fine for me.
Suggest you switch Data and Debug logging on. Stop Cumulus MX for a few minutes and then restart it and post the MXDiags file.
By the waty you do NOT say you input the MAC address of the device you requested the API for from Ecowitt and I presume you have registered the device with Ecowitt.net and you uploading data to it via the Ecowitt Weather Server setup?
Suggest you switch Data and Debug logging on. Stop Cumulus MX for a few minutes and then restart it and post the MXDiags file.
By the waty you do NOT say you input the MAC address of the device you requested the API for from Ecowitt and I presume you have registered the device with Ecowitt.net and you uploading data to it via the Ecowitt Weather Server setup?
- HansR
- Posts: 6926
- Joined: Sat 20 Oct 2012 6:53 am
- Weather Station: GW1100 (WS80/WH40)
- Operating System: Raspberry OS/Bookworm
- Location: Wagenborgen (NL)
- Contact:
Re: Ecowitt Data Access API's
Looks OK to me.malkie wrote: ↑Mon 14 Feb 2022 12:09 pm Having some problems getting this to work.
I have set up a new Pi4 to log the data from my GW1100 which so far has external temp/humidity, Rain gauge and Air Q sensors. The wind gauge should be up later today.
I have created my API keys and copied and pasted them from Ecowitt.net to the User interface. The API key has hyphens and text is in lower case, the Application key is all in Uppercase.
So you have a 200 code and you get a response without data. How long have you been off-line?malkie wrote: ↑Mon 14 Feb 2022 12:09 pm I turned on Debig Logging and got a bit more info:
2022-02-14 12:12:21.290 API.GetHistoricData: Get Ecowitt Historic Data
2022-02-14 12:12:21.290 Ecowitt URL = https://api.ecowitt.net/api/v3/device/h ... _type=5min
2022-02-14 12:12:22.853 API.GetHistoricData: Ecowitt API Historic Response code: 200
2022-02-14 12:12:22.853 API.GetHistoricData: Ecowitt API Historic Response: {"code":0,"msg":"success","time":"1644840742","data":[]}
2022-02-14 12:12:23.201 Lock: Station releasing the lock
2022-02-14 12:12:23.267 Starting GW1000
In summary: what is actually the problem?
Hans
https://meteo-wagenborgen.nl
CMX build 4070+ ● RPi 4B ● Linux 6.6.62+rpt-rpi-v8 aarch64 (bookworm) ● dotnet 8.0.1
BlueSky: https://bsky.app/profile/wagenborgenwx.bsky.social
https://meteo-wagenborgen.nl
CMX build 4070+ ● RPi 4B ● Linux 6.6.62+rpt-rpi-v8 aarch64 (bookworm) ● dotnet 8.0.1
BlueSky: https://bsky.app/profile/wagenborgenwx.bsky.social
- mcrossley
- Posts: 14388
- Joined: Thu 07 Jan 2010 9:44 pm
- Weather Station: Davis VP2/WLL
- Operating System: Bullseye Lite rPi
- Location: Wilmslow, Cheshire, UK
- Contact:
Re: Ecowitt Data Access API's
The second run only requested 1 minute of history, so it will be empty. So you will need to restore the backup from the first run, leave the Cumulus.ini file so the debug and data logging is still on re-run the start-up. Then post the MXdiags log please.
-
malkie
- Posts: 93
- Joined: Sun 02 Jan 2011 9:38 am
- Weather Station: Davis Vision-Vue
- Operating System: Raspbian Jessie
- Location: Stevenage, Herts, UK
Re: Ecowitt Data Access API's
Thanks Mark, I will try your suggestion later and and post the resulting MXDiag after it has been off for a longer period.
water01, yes I have entered the Mac address, forgot to mention that.
water01, yes I have entered the Mac address, forgot to mention that.
Malcolm
North Herts, UK
http://elm30net.ddns.net
CumulusMX on Raspberry Pi4 B+ 2GB, running on Raspbian Buster booting from USB SSD
from a Davis Vantage Vue with VP2 ISS.
North Herts, UK
http://elm30net.ddns.net
CumulusMX on Raspberry Pi4 B+ 2GB, running on Raspbian Buster booting from USB SSD
from a Davis Vantage Vue with VP2 ISS.
-
malkie
- Posts: 93
- Joined: Sun 02 Jan 2011 9:38 am
- Weather Station: Davis Vision-Vue
- Operating System: Raspbian Jessie
- Location: Stevenage, Herts, UK
Re: Ecowitt Data Access API's
I followed Mark's advice, restored the data from when the station was shut down yesterday evening and restarted with Data and Debug Logging active and left Cumulus to "do it's thing" after a restart.
Seems to be working now:
2022-02-14 18:56:36.390 GetHistoricData: Starting Historic Data Process
2022-02-14 18:56:36.395 API.GetHistoricData: Get Ecowitt Historic Data
2022-02-14 18:56:36.395 Ecowitt URL = https://api.ecowitt.net/api/v3/device/h ... _type=5min
2022-02-14 18:56:37.833 API.GetHistoricData: Ecowitt API Historic Response code: 200
2022-02-14 18:56:37.835 API.GetHistoricData: Ecowitt API Historic Response: {"code":0,"msg":"success","time":"1644864996","data":{"indoor":{"temperature":{"unit":"ºF","list":
Long line of data returned....................
"1644864600":"-"}}}}}
2022-02-14 18:56:38.383 Processing data for 13/02/2022 21:55:00
2022-02-14 18:56:38.440 New all-time record: New time = 2022-02-13 21:55, new value = 10.111 "High temperature" prev time = 2022-02-13 20:56, prev value = 10.100
2022-02-14 18:56:38.463 New monthly record: month = 02: New time = 2022-02-13 21:55, new value = 10.111 "High temperature" prev time = 2022-02-13 20:56, prev value = 10.100
2022-02-14 18:56:38.477 Writing to Month.ini file
2022-02-14 18:56:38.479 End writing to Month.ini file
2022-02-14 18:56:38.491 Writing to Month.ini file
2022-02-14 18:56:38.493 End writing to Month.ini file
etc etc, repeated for each 5 minute interval.
Not sure what I did to fix it, but it is working as intended. Clearly my last test was not long enough.
Thanks for all the help.
Malcolm
Seems to be working now:
2022-02-14 18:56:36.390 GetHistoricData: Starting Historic Data Process
2022-02-14 18:56:36.395 API.GetHistoricData: Get Ecowitt Historic Data
2022-02-14 18:56:36.395 Ecowitt URL = https://api.ecowitt.net/api/v3/device/h ... _type=5min
2022-02-14 18:56:37.833 API.GetHistoricData: Ecowitt API Historic Response code: 200
2022-02-14 18:56:37.835 API.GetHistoricData: Ecowitt API Historic Response: {"code":0,"msg":"success","time":"1644864996","data":{"indoor":{"temperature":{"unit":"ºF","list":
Long line of data returned....................
"1644864600":"-"}}}}}
2022-02-14 18:56:38.383 Processing data for 13/02/2022 21:55:00
2022-02-14 18:56:38.440 New all-time record: New time = 2022-02-13 21:55, new value = 10.111 "High temperature" prev time = 2022-02-13 20:56, prev value = 10.100
2022-02-14 18:56:38.463 New monthly record: month = 02: New time = 2022-02-13 21:55, new value = 10.111 "High temperature" prev time = 2022-02-13 20:56, prev value = 10.100
2022-02-14 18:56:38.477 Writing to Month.ini file
2022-02-14 18:56:38.479 End writing to Month.ini file
2022-02-14 18:56:38.491 Writing to Month.ini file
2022-02-14 18:56:38.493 End writing to Month.ini file
etc etc, repeated for each 5 minute interval.
Not sure what I did to fix it, but it is working as intended. Clearly my last test was not long enough.
Thanks for all the help.
Malcolm
Malcolm
North Herts, UK
http://elm30net.ddns.net
CumulusMX on Raspberry Pi4 B+ 2GB, running on Raspbian Buster booting from USB SSD
from a Davis Vantage Vue with VP2 ISS.
North Herts, UK
http://elm30net.ddns.net
CumulusMX on Raspberry Pi4 B+ 2GB, running on Raspbian Buster booting from USB SSD
from a Davis Vantage Vue with VP2 ISS.