Weatherpanel

[fanthos]

Replace table with Google Charts having templow and condition support.
#373

[mention-bot]

@fanthos, thanks for your PR! By analyzing the history of the files in this pull request, we identified @Tommatheussen, @armills and @andrey-git to be potential reviewers.

[balloob]

Can you include a screenshot?

[balloob]

Travis also reported some lint errors that need to be fixed (the final test run will fail, that one can be ignored)

[fanthos]

OpenWeatherMap:

YWeather:

[bramkragten]

What is the policy for UI elements like these, last release it changed from graph to a table, now someone suggests to change it back to a (more extensive) graph, and the release after back to a table?

The weather card is the one I like least of all cards, main reason I want #365 to do this, so I don't mind a few changes, but just wondering if there is a policy.

[mjj4791]

Buienradar weather
I'd like to know where the weather card is going as well; I noticed the new gui element in 0.50 for the weather component, and adapted buienradar weather to that. Now I discover we are reverting that....

The (previously) new design, allowed for more diverse data to be shown (ie series of unequal units); with a graph this is more difficult....
Although I really liked the graph from before, the table provides the opportunity to add more insight....
I always like to know the forecasted temperature together with the rainchance (for example)...

What I had using the (now-old) design of the card (temperature, templow, sunchance, rainchance, rain, snow, wind and date(day)):

[fanthos]

Personally I like the table more because I can see more detailed information.

@bramkragten
The reason revert the table back to chart is the table does not work well when the weather component provides per-hour forecast(like OpenWeatherMap) #373.

@mjj4791
I tested Buienradar component, it provides data similar to YWeather. Maybe make the table and chart both available and display them by which data provided by component? Or its possible show multiple lines with same X-axis on the same chart.

[bramkragten]

The weather component should be more standardized anyway, like the attribute for wind bearing, the one element uses windBearing the other wind_bearing. Besides that the UI doesn't check if the attribute excists and then faulty displays North. That's just one example, for the standard attributes, that we will show in the UI, we should have standards.

[fanthos]

Agree.
Right now there are no standard for forecast property names. They should be defined in Weather platform __init__.py or something, not in every component's python file. When displaying the card, it should check windBearing if exists.

[balloob]

All the property names are standardized in the Weather entity abstract base class: https://github.com/home-assistant/home-assistant/blob/dev/homeassistant/components/weather/__init__.py#L48-L169

There has been no policy on the weather card and I should probably not have merged the previous PR because it was such a major change.

We do have guide lines for things in the frontend in general:

• State cards should show minimal data. All extra data should be moved to a more info card (what you see when you click on an entity). Tables are definitely more info card material.
• We don't do configurable options how things look in the frontend as it will lead to a support nightmare.

For the weather card, I wouldn't mind being inspired by the Google weather card (note that this screenshot is not their original card, I deleted some parts):

And actually, that is already what we get after this PR, so that's good 👍

[balloob]

There is no windBearing attribute. It should be wind_bearing.

[balloob]

We should also always assume that certain attributes might not be available.

[mjj4791]

When implementing the above mentioned change regarding wind_bearing, I would also revise this:

windBearingToText: function (degree) {
  return _DEGREE_TEXT[((parseInt(degree) + 5.63) / 11.25) | 0];
}

into something similar to this:

windBearingToText: function (degree) {
  var index = -1;
  if (!isNaN(parseInt(n)) && isFinite(n)) {
    index = parseInt((degree + 11.25)/22.5);
  }
  if (index < 0 || index >16) {
    return '';
  } else {
    return _DEGREE_TEXT[index]
  }

This changes the following:

• do not assume N as wind direction
• updated calculation, which selects correct direction

[fanthos]

Document for more-info panel is at https://home-assistant.io/developers/frontend_add_more_info/ .

I replaced the <table> with <div>.
Currently the code makes the panel looks like

Should I move the forecast icon back to center?

[mjj4791]

Looks nice!
Just tried this version of the card; using buienradar weather component, it gives me the images shown below. (and if no wind_bearing is passed in, 'N' is no longer assumed)

and without forecast data:

[bramkragten]

Looks better in my opinion! Just make sure the icon, temperature and the 3 attributes are all aligned.

And I think mdi icons would make it look even better, and more consistent. It is easy to implement, just replace the [[nowCond]] with <iron-icon icon="mdi:[[nowCond]]"></iron-icon> and put the icon names in _WEATHER_TO_ICON...

[fanaticDavid]

+1 for using mdi icons!

Consistency pleases my OCD 😛

[fanthos]

Replace the current condition with mdi icons is not hard, but seems Google Charts does not support HTML annotation.
The forecast chart using Google chart, so the forecast chart can not use mdi icons.

[bramkragten]

It is possible... https://stackoverflow.com/questions/39543226/how-can-i-attach-the-image-or-icon-on-edge-of-google-line-chart/39553121#39553121

https://jsfiddle.net/uakgbbo4/6/

[balloob]

Let's leave MDI icons for a next PR and let's get this merged.