Author Topic: Ecowitt.net API release  (Read 10908 times)

0 Members and 1 Guest are viewing this topic.

Offline olicat

  • Forecaster
  • *****
  • Posts: 1291
  • GWxx00, HPx5x1C, WN1900C, WN1980C & FOSHKplugin
    • FOSHKplugin
Re: Ecowitt.net API release
« Reply #25 on: October 01, 2021, 06:43:56 AM »
Hi Mauro,

4 months after the call, I would like to ask again whether there have been any results in the meantime.
In the meantime, even the Chinese API documentation has disappeared from the Internet.
The member center for the API is no longer available.
But the actual API access works!

I don't want to be annoying and I understand if it takes longer.
But I would wish for a sign of life every now and then.
Thanks!

Oliver

Offline mcrossley

  • Forecaster
  • *****
  • Posts: 1064
    • Wilmslow Astro
Re: Ecowitt.net API release
« Reply #26 on: November 13, 2021, 05:55:40 AM »
Still nothing?
Mark

Offline mauro63

  • Forecaster
  • *****
  • Posts: 388
Re: Ecowitt.net API release
« Reply #27 on: November 13, 2021, 06:50:25 AM »
I'm so sorry, please is absolutely my fault :(
I will ask news to technical dept on monday

Again, so sorry
M.

Offline mauro63

  • Forecaster
  • *****
  • Posts: 388
Re: Ecowitt.net API release
« Reply #28 on: November 15, 2021, 03:02:48 AM »
Received the update a little while ago, the release is not expected before at least one or two months

M.

Offline mauro63

  • Forecaster
  • *****
  • Posts: 388
Re: Ecowitt.net API release
« Reply #29 on: January 08, 2022, 09:33:29 AM »
very, very close to release

M.

Offline mcrossley

  • Forecaster
  • *****
  • Posts: 1064
    • Wilmslow Astro
Re: Ecowitt.net API release
« Reply #30 on: January 09, 2022, 10:37:54 AM »
I have not seen anything about alpha/beta testing this?
I raised a concern with Ecowitt about the whole approach of this API and a possible problem and heard nothing back confirming my thoughts one way or another.

I had hoped to get Cumulus MX ready to use this once it was released, it looks like I'll have to play catch-up.
Mark

Offline olicat

  • Forecaster
  • *****
  • Posts: 1291
  • GWxx00, HPx5x1C, WN1900C, WN1980C & FOSHKplugin
    • FOSHKplugin
Re: Ecowitt.net API release
« Reply #31 on: January 09, 2022, 11:02:47 AM »
Hi!

I also find it deeply disappointing to first ask the users for cooperation and then not allow any cooperation.
We should submit requests and suggestions - but never received any response. There was never any insight into the current state of development.
I would have expected a lot more communication and influence.

For future projects, Ecowitt should urgently rethink its communication strategy.

Oliver

Offline olicat

  • Forecaster
  • *****
  • Posts: 1291
  • GWxx00, HPx5x1C, WN1900C, WN1980C & FOSHKplugin
    • FOSHKplugin
Re: Ecowitt.net API release
« Reply #32 on: January 26, 2022, 01:59:27 AM »
Hi!

Finally the Ecowitt API is available:
Quote
A big delay, but we eventually managed to complete the API feature for www.ecowitt.net.  If anyone would like to fetch the data from our server, you may get the current and historical data via the API.   So now we completed a loop for data fetching from our ecosystem:
1. TCP/IP protocol to read the data from our devices like GW1100, WN1900, GW2000 series. This can only be possible for local WLAN
2. Custom server mode to exchange data either in WU or ecowitt protocol. This can be handled locally on the WLAN or via the Internet.
3. API for remotely accessing device current data or history data. This is only possible with the internet as it needs talking to our server.  You may start the API feature under your user profile on ecowitt.net.

The link provided there does not (yet) work. Perhaps this is the more suitable link.
At least the documentation there seems to work.

Oliver

Offline mcrossley

  • Forecaster
  • *****
  • Posts: 1064
    • Wilmslow Astro
Re: Ecowitt.net API release
« Reply #33 on: January 26, 2022, 03:18:01 AM »
So what happened to the beta?
Mark

Offline olicat

  • Forecaster
  • *****
  • Posts: 1291
  • GWxx00, HPx5x1C, WN1900C, WN1980C & FOSHKplugin
    • FOSHKplugin
Re: Ecowitt.net API release
« Reply #34 on: January 26, 2022, 03:47:17 AM »
Hi!

Probably this IS the beta ...
I've only had a quick look (I'm still a little upset and my motivation to deal with it is low right now) - but the "new" API seems significantly different to me than in the previous test state.

Oliver

Offline waiukuweather

  • Forecaster
  • *****
  • Posts: 1072
Re: Ecowitt.net API release
« Reply #35 on: January 26, 2022, 04:42:27 AM »
I got it working
(ie via a simple web page URL paste in a browser window to test)
i.e after getting an application key (change the drop down selector to request that)
then an api key
and then you need to find your Mac address for your station as well
(top left menu of your normal data web page at ecowitt.net, then devices)

the advantage I guess is this will be a way  to get data for weather stations that do not use a GW1000 bridge (i.e the console is sending the data to the cloud?) or to get the data from a remote station?
« Last Edit: January 26, 2022, 04:44:28 AM by waiukuweather »

Offline broadstairs

  • Forecaster
  • *****
  • Posts: 749
Re: Ecowitt.net API release
« Reply #36 on: January 26, 2022, 04:49:24 AM »
From my point of view the most likely use would be to obtain data missed because of a PC or software failure and then import into the software when it has recovered.

Stuart
Ecowitt GW1003 with ultrasonic wind gauge, lightning sensor and PM2.5 sensor with Personal Weather Tablet as a console.

Offline olicat

  • Forecaster
  • *****
  • Posts: 1291
  • GWxx00, HPx5x1C, WN1900C, WN1980C & FOSHKplugin
    • FOSHKplugin
Re: Ecowitt.net API release
« Reply #37 on: January 26, 2022, 05:00:09 AM »
Hi!

Quote
obtain data missed because of a PC or software failure
The question is whether access to the historical data now works. In the test phase, exactly that did not work so far.

In general:
The API also results in completely new possibilities for apps from other providers to visualise the data. Apps like WhatWeather could support extended sensors this way instead using the generic sensors only available by WU-format.
Websites with weather data would no longer have to be supplied locally by the user, but could automatically fetch the data from Ecowitt - PWSDashboard or Meteotemplate or CMX or ... could make good use of this.
Even for Personal Weather Tablet (PWT), this could be usable as a new connection type - for example, when tablet and weather station are in foreign networks.
@Da9L?
;-)

Oliver

Offline mcrossley

  • Forecaster
  • *****
  • Posts: 1064
    • Wilmslow Astro
Re: Ecowitt.net API release
« Reply #38 on: January 26, 2022, 05:24:50 AM »
My first rough thoughts looking at the documentation...

1. I'll need to ask every user to get both an developer Application key and an user API key.
- This is something I pointed out to Ecowitt in an email months ago, the concept of an Application key does not work with open source software where you cannot keep the app-key secure.
- Also the App key is rate limited to 3/sec. If you have thousands of users, you have no way of knowing what the app-key rate usage is going to be, nor limiting it. The users will just be hit with refused connections, so the app retries the request making the situation even worse.

2. The historic data response JSON structure
- Making each sensor a standalone item with the structure is not great
For example "temp_and_humidity_ch1" ... "temp_and_humidity_ch8". I think it would be better to have a top level "temp_and_humidity", and have that contain an array of sensors, each one identified by a channel number. Then if you later decide to add say channels 9-16, the array just expands with the extra sensors and very little/no code change is required at the client end.
- The "list" of dates/values is an object, that is really awkward to handle. It cries out to be an array of key/value pairs. They even called it "list"!

3. Why are most of the numeric values passed as strings?

It was stuff like that I was hoping to thrash out in a beta, this looks like and smells like a published API that isn't going to change.

I hoped it would look more like this...

Code: [Select]
"temp_and_humidity": [
    {
        "channel": 1,
        "data": {
            "temperature": {
                "unit": "F",
                "list": [
                    [1643076300, 32.2],
                    [1643076600, 20.9]
                ]
            },
            "humidity": {
                "unit": "%",
                "list": [
                    [1643076300, 40],
                    [1643076600, 33]
                ]
            }
        }
    },
    {
        "channel": 2,
        "data": {
            "temperature": {
                "unit": "F",
                "list": [
                    [1643076300, 32.2],
                    [1643076600, 20.9]
                ]
            },
            "humidity": {
                "unit": "%",
                "list": [
                    [1643076300, 40],
                    [1643076600, 33]
                }
            }
        }
    },
    ...
    ]
},
Mark

Offline hiljo

  • Senior Contributor
  • ****
  • Posts: 220
    • Weerstation Hattem
Re: Ecowitt.net API release
« Reply #39 on: January 26, 2022, 07:09:30 AM »
Hi mcrossely,

In answer to your post,
1. Yes, i see your point but that's how a lot of API usage work AFAIK. If I take for example Wordpress, I can install a plugin to see my Google Analytics statistics on the dashboard. I need to get an App-key myself from Google to see my personal data (for security reasons), and also to limit the amount of calls per minute.
2. That is how a lot of responses from Ecowitt work. Also retrieving the data from the custom upload from the console or the gateway works with standalone items: pm25_ch1=23&leafwetness_ch1=55&pm25_ch2=21&leafwetness_ch2=70.
For my personal website i use a different approach and philosophy: all observations of a certain time have one timestamp (they are recorded at almost the same time right?), and per request the unit can differ (Celcius, Fahrenheit, Lux, W/m, etc). So I use the following JSON for my current weather observation (idea is from https://weatherstack.com/documentation, see also for the historical data example):

Code: [Select]
    "request": {
        "language": "nl-nl",
        "temperatureunit": "C",
        "humidityunit": "%",
        "pressureunit": " hPa",
        "wind_speedunit": " m/s",
        "wind_degreeunit": "",
        "precipunit": " mm",
        "solarradiationunit": " W/m",
        "pm25unit": " μg/m",
        "leafwetnessunit": "%"
    },
    "current": {
        "observation_time": "26-01-2022 12:49:23",
        "observation_epoch": "1643197763",
        "condition_code": "701",
        "temperature": "3.8",
        "humidity": "92",
        "dew_point": "2.6",
        "pressure": "1030.6",
        "wind_speed": "1.2",
        "wind_degree": "5",
        "wind_gust": "2.7",
        "windchill": "3.8",
        "rain_today": "0.0",
        "solarradiation": "53.83",
        "uv_index": "0",
        "pm25": "29",
        "lightning_time": null,
        "lightning_num": "0",
        "lightning_distance": null,
        "leafwetness": "0",
        "wind_dir": "N",
        "astro": {
            "sunrise": 1643181956,
            "sunset": 1643213177,
            "moonrise": 1643159520,
            "moonset": 1643193660,
            "moon_phase": "Laatste kwartier",
            "moon_illumination": 31.6,
            "moon_days": 24
        },
        "condition_description": "Mist",
        "condition_icon": "fog.svg"
    }

I think that the way of returning the JSON is just a type of philosophy, and differ from API to API (also for weather services like OpenWeather, WeatherStack, WU, etc..). They all reinvent the wheel..
« Last Edit: January 26, 2022, 07:11:06 AM by hiljolodewijk »
Ecowitt HP2550C v1.9.1
2x GW2000 v3.0.6
Beta WittBoy WS90 v1.3.3
Smart Watervalve (WFC01) Beta tester
3x WH31, WH32, WH40, WH41, WH57
WN34L, 2x WH51, WN35

Dutch translator for Ecowitt.

https://www.weerstationhattem.nl/
  |
  |
  |
  | 
  |
  |
  |

Offline mcrossley

  • Forecaster
  • *****
  • Posts: 1064
    • Wilmslow Astro
Re: Ecowitt.net API release
« Reply #40 on: January 26, 2022, 07:39:08 AM »
Hi mcrossely,

In answer to your post,
1. Yes, i see your point but that's how a lot of API usage work AFAIK. If I take for example Wordpress, I can install a plugin to see my Google Analytics statistics on the dashboard. I need to get an App-key myself from Google to see my personal data (for security reasons), and also to limit the amount of calls per minute.

None of the other weather API's work like this. They either rely on a single API key that the user obtains, and they post that with every request (for the world to intercept, but I guess we are only talking about weather data!). Or like Davis who do it much more securely and have a user API key that is sent openly with every request, plus a user "secret" that is used to encode part of the message to make in non-repayable and authenticated to that user.

The requirement to have a single Application API key is the killer, especially if it is rate limited, and anybody can hijack the key.
So my intent at the moment is to bypass that and make the users use two unique to them API keys which negates the whole point of one of them!

Re the JSON structure, that is a whole other debate and I appreciate there are different views, but that ship has probably sailed. I just wish they had asked for input and we could all have discussed it before they committed to code/documentation/release. But basic stuff like sending numbers as strings is just plain daft imho.
« Last Edit: January 26, 2022, 11:46:48 AM by mcrossley »
Mark

Offline zoomx

  • Senior Contributor
  • ****
  • Posts: 172
Re: Ecowitt.net API release
« Reply #41 on: January 26, 2022, 09:51:12 AM »
Hi!

Quote
obtain data missed because of a PC or software failure
The question is whether access to the historical data now works. In the test phase, exactly that did not work so far.
Only for 90 days. And you have to ask only a day per request.

Offline mcrossley

  • Forecaster
  • *****
  • Posts: 1064
    • Wilmslow Astro
Re: Ecowitt.net API release
« Reply #42 on: January 26, 2022, 10:13:40 AM »
I also just realised that you have to list up to all 48 data categories in the call_back field - again because each sensor channel is a different field request.
It would be nice to have an "all" option to just send everything recorded in the period requested, and omit the fields for which no data was received.
Mark

Offline olicat

  • Forecaster
  • *****
  • Posts: 1291
  • GWxx00, HPx5x1C, WN1900C, WN1980C & FOSHKplugin
    • FOSHKplugin
Re: Ecowitt.net API release
« Reply #43 on: January 26, 2022, 10:34:49 AM »
Hi!

Quote
It would be nice to have
Couldn't you have shared this during the beta test and before the launch?!!
SCNR ...
;-)

It will probably come down to each user having to take care of their own API and APP key. In the next step, Ecowitt will have to restrict the service due to the high demand - after all, the operation of its own apps and services must be ensured.
I hope I am wrong ...

I still don't understand why we users/developers are first asked for help and then the API is released without participation or consideration of the wishes/ideas.
A missed opportunity. What a pity!

Anyway. It is what it is.
Better a suboptimal API solution than none at all.
With the Ecowitt format (custom server) or the GW1000 API, we were not asked for our wishes and ideas in advance. And even there, Ecowitt manages to realise our wishes and suggestions for improvement after the fact.
It is an additional, "gift" option to set the weather stations of the manufacturer apart from competitors on the market.
So let's see what we can do with it ...

Oliver

Offline Rover1822

  • Forecaster
  • *****
  • Posts: 1739
    • Mini Wind and Solar Data project
Re: Ecowitt.net API release
« Reply #44 on: January 26, 2022, 10:37:15 AM »
I'm just glad they are providing an API. Rarely does one get to suggest much on how an API is provided , unless maybe open source or very large software products, or a product that is entirely based on providing an API, it is normally provided as is. For a low cost weather system, with some pretty good features already, not horrible on the API, providing a public API is in my mind, not something they really had planned.

I really don't have a feel for how many will use it, but as a portion of total unit sales, I would have to think a fairly small percentage. And as one that has to support an API for a software product for which we at least get maintenance fees, I can only imagine the joy of supporting one for which the entire funding is from the sale of the original unit. 

Ambient:
  WS-2000
  PM 2.5(2)
  WH31B(2)
  WH40E
  WH31P
EcoWitt:
  GW1100
  GW1000(4)
  WH31(2)
  WH57
  WH51(12),
  WH40
  WH5360B
  WN34S
  WittBoy WS90 + GW2000
  WS90 (other one) + GW1100
Personal Sites: Weather Cam

Offline olicat

  • Forecaster
  • *****
  • Posts: 1291
  • GWxx00, HPx5x1C, WN1900C, WN1980C & FOSHKplugin
    • FOSHKplugin
Re: Ecowitt.net API release
« Reply #45 on: January 26, 2022, 10:55:52 AM »
Hi Rover,

you are right, of course. That's what I wanted to say with a final sentence. I have now added it.

Oliver

Offline olicat

  • Forecaster
  • *****
  • Posts: 1291
  • GWxx00, HPx5x1C, WN1900C, WN1980C & FOSHKplugin
    • FOSHKplugin
Re: Ecowitt.net API release
« Reply #46 on: January 26, 2022, 11:44:46 AM »
Hi!

I just noticed that the current API documentation describes access via API v3 - but the "old" way (from the previous test phase) with the "access_token" still works here.
Access to history data in v3 seems to work so far.
In fact, however, there is no call_back "all" with History - each sensor must be named individually.

I suspect that Ecowitt uses a different API for its own apps and services than the now published v3 - but I must check this again.

Oliver

Offline waiukuweather

  • Forecaster
  • *****
  • Posts: 1072
Re: Ecowitt.net API release
« Reply #47 on: January 26, 2022, 02:39:47 PM »
just to clarify, the application api key is not a one off unique api key for a developer to use for any stations data, instead it has to be created just like the station api for a persons own ecowitt.net cloud data (along with getting the MAC address)?
i.e so there are 3 things needed from each owner (application api key, api key, MAC address)?
« Last Edit: January 26, 2022, 02:48:54 PM by waiukuweather »

Offline mcrossley

  • Forecaster
  • *****
  • Posts: 1064
    • Wilmslow Astro
Re: Ecowitt.net API release
« Reply #48 on: January 26, 2022, 02:52:53 PM »
Brian, the documentation says that the application key can be used with any user key, then the mac defines the station within that users account. So I think the intent it is one-off per application.
Mark

Offline waiukuweather

  • Forecaster
  • *****
  • Posts: 1072
Re: Ecowitt.net API release
« Reply #49 on: January 26, 2022, 03:57:02 PM »
OK, that is good...one less thing to worry about for the end user -> they just need to get their stations API key and MAC address (yes?)
but I think you have pointed out the rate limiting issue for the application key?

ps, why imperial units?
« Last Edit: January 26, 2022, 04:09:17 PM by waiukuweather »

 

anything