Cumulus Support

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

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.

Btw: one user Api and one application Api and only differ in Mac Address would work as well

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!

mcrossley wrote: ↑Wed 02 Feb 2022 9:31 am ** I suspect I know how it came to be though!

Now I am curious

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

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?

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.

Looks OK to me.

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

So you have a 200 code and you get a response without data. How long have you been off-line?

In summary: what is actually the problem?

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.

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.

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