Re-add local pyown usage with local api-key. Refactored OWNApi into …

[ulno]

…real wrapper that can use local api_key or default to doing web requests to mycroft.

As discussed with @forslund in the forums.

This allows the weather skill to use a personal OWM api_key (at least when set in local settings.json) and if proxy is set to false.

This effort is probably duplicating issue #27.

Building a connector adapter (that itself could use for example mqtt) into this wrapper might also address issues #98, #100, #115

[krisgesling]

I'm wondering if it would be better to have independent classes for each weather service. They could inherit from a parent WeatherAPI class that defines the structure and handles common functions like caching.

This would keep each more readable and maintainable, as well as opening the door to adding other weather services without needing to produce a Weather Channel Skill, Weather Underground Skill, etc, etc.

This is also a lot more work and outside the scope of this PR, but still interested in any thoughts.

[ulno]

I'm wondering if it would be better to have independent classes for each weather service. They could inherit from a parent WeatherAPI class that defines the structure and handles common functions like caching.

This would keep each more readable and maintainable, as well as opening the door to adding other weather services without needing to produce a Weather Channel Skill, Weather Underground Skill, etc, etc.

This is also a lot more work and outside the scope of this PR, but still interested in any thoughts.

I agree, this should be the long term goal, however, I think we need to stay agile and rather allow ourselves to refactor that at one point when we have enough different usecass.

Talking about sidenotes: it woudl be really nice if we coudl also get some information on precipitation, air pressure, and chance of rain.