Wunderground api

[saroele]

@Ryton I will create a specific branch for the wunderground script. I think we should try to put the code in a module instead of a notebook, but the notebook is fine for testing and development. Also, when we put the methods in a module, we can (and should!) write a unittest for them.

As a start for the discussion: I created an account for wunderground, but I'm unable to get the first function, to get current conditions, running. My json response contains an error that my key is not known. Maybe it takes some time for Wunderground to process my subscription?

OTOH, I'm surprised to see my password appear in the http request. Is this normal? What about safety?

[Ryton]

Hi, its not your Wunderground password, but an assigned API key you have to enter in the config, and which appears in the http request. It should be operational instantly, normally.

@saroele For testing, There is a free, public api key available on the wunderground website (api.wunderground.org), that can make unlimited calls to a few weather stations only. Maybe I should add these to the start of the code or in the test module.

+unittest and module seems usefull indeed,

I have no experience with coding in modules or writing tests, but I’ll look into other code for inspiration.

[saroele]

Ok, got it running now. I made some changes to make it more self-explanatory, like changing password in the opengrid.cfg to apikey, and also in the function call.

In only tested fetch_curr_conditions and made some changes. See 1390c94

[Ryton]

I added all wunderground functions to a library (wundergroundapi.py) in /library map, and made modifications based on your comments, such as:

• apikey => key
• Infotype => prop, etc.

PS: a module is the same as a library, right?

Examples were kept in the notebook, which was renamed Demo_Wunderground.ipynb Committed as v83.

[Ryton]

Current list of todo's in this issue/branch (imho, feel free to correct/add where needed): Large WIP / Todos: 1) (high prio) Make a usefull analysis in combination with building utility data: e.g. Current solar radiation vs PV production , or (historic) HDD vs gas usage. 2) (high prio) Develop script to obtain best (closest) "weather station/city name" based on belgian postal code

Small WIP / Todos: A) (low prio) fix figure X-axis in date & make some more fancy graphs (improved date-axis) B) (high prio) Combine multiple API-calls (such as Average_Temp_Xdaysago into a single API-call (api call that fetches longer list of data). Required for long time analysises. C) (low prio) Add script to give list of possible query options (4 lists: current, history average, history detail and prediction). Full lists can be consulted at http://api.wunderground.com/weather/api/d/docs , but available data can be station dependent.

[saroele]

yes, a module is a library.

Nice list with prio/work split! As always we should focus on the high prio's :-) I propose to keep working in this branch, even for the large wip's.

[saroele]

@Ryton I will rename the functions in your library. Some conventions we try to apply (see also pep8 and more specific the naming conventions):

• functions and methods (= functions in a class) have no capitals, and use underscore_style_naming
• capitals are only used for class names (like the Dashboard class)
• objects (instantiations) normally always start with small letters, but we can make exceptions for constants (like a URL or class variables)

[saroele]

I have now rewritten the api in object oriented style. See 1b0c860. This partly implements C) of the small WIPs above.

I propose to include also the historic fetches in the class, maybe in a similar style? Not sure if the caching is required for historic data fetches. Probably not, so actually it's a matter of integrating the functions you already heave in the class.

[Ryton]

Sure, do whatever is proper 😊

Interesting links, I read parts of the conventions, will go trough the remainder soon. I ll try to apply them in future code, but please correct/ point out any issue!

Van: saroelemailto:notifications@github.com

@Rytonhttps://github.com/Ryton I will rename the functions in your library. Some conventions we try to apply (see also pep8https://www.python.org/dev/peps/pep-0008 and more specific the naming conventionshttps://www.python.org/dev/peps/pep-0008#naming-conventions).

— Reply to this email directly or view it on GitHubhttps://github.com/opengridcc/opengrid/issues/26#issuecomment-64089824.

[Ryton]

Looking good! Caching for historic data isnt really usefull, but the multi-fetch would be nice, to correlate flukso measurements with historic weather effectively, imho.

I have now rewritten the api in object oriented style. See 1b0c860https://github.com/opengridcc/opengrid/commit/1b0c8605e10ba89e9f922531c9f0ed43d37e25eb. This partly implements C) of the small WIPs above.

I propose to include also the historic fetches in the class, maybe in a similar style? Not sure if the caching is required for historic data fetches. Probably not, so actually it's a matter of integrating the functions you already heave in the class.

— Reply to this email directly or view it on GitHubhttps://github.com/opengridcc/opengrid/issues/26#issuecomment-64094136.