Topic: Ecowitt.net API release

[Rover1822]

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.

Without knowing your intent , then you create a wrapper that communicates with the API and do what you want .

Would you mind defining your intent with the use of the API?

I mean I understand the API is not a ready for a prime time application , what exactly are you after in function? . one off? something to make into an app for others? Not meeting your own use?

I mean also you have complained about numeric being supplied as strings. Surprise, you know how common that is in the real world?. If you don't have the ability to convert with or/ if radix is needed, then you should not be complaining to hard. This is done all the time. If this doesn't match your skill set, I suggest you augment it , as this is how we do stuff. If you are trying to plug this into something else and whining it doesn't meet your ability or needs, work on them.
 

[waiukuweather]

why do you say its not ready for a prime time application?
because of the rate limiting applied to the application key? (3 calls per second means even if the application only accessed the data once a minute, on that minute, if 3 applications making a call at the same time, then limit reached...a random time to get data would get around that a bit)

it doesn't mention if that limit resets either? (eg after 5 minutes)

[Rover1822]

Actually I just meant in the simplicity of use. Wasn't really meaning anything towards the whole key issue.

Sorry If it came off that way

[waiukuweather]

I am not the person who complained about strings
that doesn't worry me
you can just parse data out of a string easily anyway

[mcrossley]

It was me!

Don't get me wrong, I think it is great that Ecowitt have released this API. It's just frustration over the process, where it looked like they were going to solicit testing and feedback, but then didn't and we have a poorer produce for that.

For example, they started with a blank piece of paper, and the JSON standard provides a perfectly good value of 'null' for missing values that all the parsers understand. But of the first few sensors I have looked at so far Ecowitt decided sensor #1 will return a value of "140.0" for missing, sensor #2 will return "-", and sensor #3 will not return anything at all. There is no internal self consistency.

It's not that I cannot code all this in, it's just that it all adds up to making things harder and more error prone than they should/could be, and it could have been avoided. That's the frustration.

Anyway, I'll crawl back under my rock and start writing the code!

[olicat]

Sorry to be offtopic, but:

Anyway, I'll crawl back under my rock and start writing the code!

Good luck!


Oliver

[waiukuweather]

getting history data for users of weather programs that use a GW1000 type bridge for when the program is not running seems like a win

[waiukuweather]

one thing that is a bit different re the json data, is that the data is not presented as an array  , i.e ["data"]
but if you treat the data as an object then it works OK

[waiukuweather]

another Q:
re the application API key
would it not be better for the user to create one along with the station api key ?
i.e so that a 3rd party software developer does not have just one application api key being used over and over by stations owners and having the limit rate reached easily?

[mcrossley]

Or remove the rate limit on the application key 

[wvdkuil]

Or remove the rate limit on the application key 

I agree, IMHO hat is the best solution, indeed.
The rate should be applied at the " 1 owner - multiple devices " level.

Wim

[olicat]

To all developers:

remove the rate limit on the application key

Please ask Ecowitt to do this. Explain the problems regarding the current solution.
And any other suggestions for improvement (especially regarding the JSON structure) should (also) be communicated to Ecowitt.
Admittedly, we first have to accept what is available. But perhaps we can influence a future v4 of the API in this way.

Oliver

[waiukuweather]

i have it working (live data)
will work on history data next

the json structure works OK (just treat the data as an object and not as an array)

[mcrossley]

Yeah, I have historic data working as well. I'll push out a test version to some users to get some broader data sampling.

But I think we have to treat this as "experimental" until we have confirmation from Ecowitt if the API is final and stable.

[Rover1822]

Let us hope it is lol. Nothing worse than an API that changes all the time without deprecation. MS, Oracle (JAVA), others really good at messing things up with changes. Everyone hates going back in to alter something. Sadly it happens way too often.

[waiukuweather]

now that the API has been made public and developers have spent time working with it, I hope that it does not change much now

[waiukuweather]

Q:
re the start and end dates for the history data
is it UTC based?
(just tested for local time and I got data back...so will proceed)

[waiukuweather]

the history data json data structure is not as easy to work with as the live data is , but it is what it is

[Rover1822]

I kind of look at it this way, if you are just working with the custom server output, I really don't expect anything better from the API.

I will also be quite honest, I can do what I need from just the custom server output pointed to a service I have, so I have not had a real reason to play with the API.

I di read the doc

[mcrossley]

Q:
re the start and end dates for the history data
is it UTC based?
(just tested for local time and I got data back...so will proceed)

I don't know, it's hard for me to test being in UTC as local time at the moment. Do the first UNIX timestamps you get back match the start time in UTC or local?

[waiukuweather]

the start and end time to request data is working as local time for me (I am 13 hours ahead of UTC)
I know its working as I get data returned with no date error
but then the time stamp numbers in the data returned are unix time
and when I convert that, its returned as UTC time
and then when I convert that to local time
its legit

but, the history data most recent is like 30 minutes old?
(the 5 minute interval data, requesting say the last 3 hours)

edit: the weather station I was using stopped updating...duh

[mcrossley]

Thanks for confirming that they are local time.
Re the latest data, the last record I get is the latest 5 minute interval, I'm not seeing a 30 minute gap in mine.

[mcrossley]

That is requesting anything from a couple of hours to the full 24 hours per request.

[mcrossley]

OK, more testing, and the historic API never returns the last archive interval for me.

So for example at 23:39, sending a request with an end date of 23:39, I would expect the last record to be for 23:35, it will actually stop at 23:30.
This is consistent with every request I make.

[waiukuweather]

re my missing latest data..the station I am working with stopped updating...duh
making good progress re history data...nearly done