Forecasts for weather underground#7062
Conversation
|
@pezinek, thanks for your PR! By analyzing the history of the files in this pull request, we identified @tchellomello, @arsaboo and @Teagan42 to be potential reviewers. |
|
|
||
| MIN_TIME_BETWEEN_UPDATES_ALERTS = timedelta(minutes=15) | ||
| MIN_TIME_BETWEEN_UPDATES_OBSERVATION = timedelta(minutes=5) | ||
| MIN_TIME_BETWEEN_UPDATES = timedelta(minutes=5) |
There was a problem hiding this comment.
@pezinek with this change, are you considering the threshold of 500 calls a day?
There was a problem hiding this comment.
yes, in fact with this change all the different API requests (e.g. alerts, conditions, forecasts,... etc.) are combined into single one according to these instructions: https://www.wunderground.com/weather/api/d/docs?d=data/index#examples
So in fact this component will not do more than 288 API calls per day (for single instance)
(FIY: I'm running this code for about a 2 weeks on my home instance already, and I didn't hit the API limit)
@tchellomello are you OK with my explanation above or are there additional steps I need to do before this PR could be approved ?
|
Bummed this didn't make it into the .43 release... maybe in a point release?? |
|
Not sure what should be the next step for this PR, but please let me know if there is still something I am suposed to do in order to proceed further with this request. |
Teagan42
left a comment
There was a problem hiding this comment.
I don't understand why you have this WUSensorConfig when almost all of those fields are available/overrideable in the Entity class
|
|
||
| # Helper classes for declaring sensor configurations | ||
|
|
||
| class WUSensorConfig(object): |
There was a problem hiding this comment.
Why don't you just use the entity class for these?
There was a problem hiding this comment.
Hi @Teagan42, thanks for checking the code !!!
The reasons why I decided to have separate classes for storing the configuration is that the WU API is a mess and I didn't wanted to clutter the WUndergroundSensor code by all the different parsing methods for different sensor types. The second reason to have the parsing/configuration for the sensors in separate class is to allow the possibility for having multiple weather stations in the future, where multiple sensors for the same thing (with the very same configuration/parsing) will coexist in parallel, and instantiating the Entity subclasses directly in the SENSOR_TYPES list will make this much more difficult.
|
Okay, sorry that it took so long for anyone to take a look at your PR. This is great and I'll be down to merge it. However, do note that we're in the process of moving all weather related sensors to the weather component with the goal that we get a nice UI in the frontend. So it's up to you, merge this as is or migrate it to the weather component (should be pretty straight forward) |
|
Actually the weather component right now does have limited set of monitored conditions, so I guess it may have sense to merge this as is and later on write another separate WU component that will plug in to the new weather architecture, similarly as openweathermap components do. |
|
Sooo..... will this make 0.44? Asking for a friend... 😉 |
|
Thanks very much!! |
|
Will be included in 0.44.1 . Forgot about it for 0.44. |
|
No problem, man. 0.44 had a lot going on! |
|
Cherry-picked for 0.44.1 |
Description:
This PR allows forecasts for the Weather Underground component.
Related issue (if applicable): N/A
Pull request in home-assistant.github.io with documentation (if applicable): home-assistant/home-assistant.io#2414
Example entry for
configuration.yaml(if applicable):Checklist:
If user exposed functionality or configuration variables are added/changed:
If the code does not interact with devices:
toxrun successfully. Your PR cannot be merged unless tests pass