Frontend: Weather Card: "sunny" icons are used even at night

[da-anda]

Checklist

• [x] I have updated to the latest available Home Assistant version.
• [x] I have cleared the cache of my browser.
• [x] I have tried a different browser to see if it is related to my browser.

The problem

The new weather card does uses a "sunny" icon even at night. So a clear sky at midnight results in a bright yellow sun icon, which is utterly confusing. (see rightmost icon, which is for 11pm and thus after sunset at my location)

Expected behavior

Use "moon" icons between sunset and sunrise

Steps to reproduce

Just use openweathermap as provider and it's default "hourly" forecast and the new weather card.

[Mariusthvdb]

check: https://community.home-assistant.io/t/0-109-new-integrations-page-and-weather-card-frontend-lost-weight/191097/419?u=mariusthvdb

it would be a weather integration issue, not a card issue.

Which automatically leads back to the discussion of some of the core HA weather integrations not recognizing/using sun-up/down or day/night in their state calculations.

Darksky does it correctly.
This really should be solved indeed... long time standing issue.

[zsarnett]

This should come from the backend not the frontend

[da-anda]

thanks, did not know it's a backend issue. Will report there and/or even try to create a bugfix PR (if time permits).

[Mariusthvdb]

@zsarnett
sorry to persist, but one could argue the frontend card should be intelligent enough to guard for that, especially since more than 1 core integration don't have 'correct' states. in the 109 thread, there's been a few posts about this as you participated: https://community.home-assistant.io/t/0-109-new-integrations-page-and-weather-card-frontend-lost-weight/191097/424?u=mariusthvdb

simply closing and denying the issue is not very helpful, sorry to say.
Could we at least ask the backend/frontend teams talk to each other about this?

[zsarnett]

The fontend card should display the data that the backend has given it. Data Manipulation should not need to be done. I agree this is an issue. An issue in the backend for those integration that don't give the state correctly to the front end should be added

edit: But if it is the Core decision to give the card sun up or down then adjustments can be made. But I would rather make sure the rest of the integration should follow or if dasksky should give the different state

[Mariusthvdb]

thanks! either way, this sounds much better ;-) now who will initiate this? enough issues made already so hope the core team will respond to this, now you've recognized this to be an issue?

btw, Dark sky is using sun up/down correctly:

might be a bit early to call it Night, but hey that would be nitpicking..
Buienradar (Woensdrecht) and Openweathermap are still showing day:

bw note the differences in forecasts (number and selection of days)

[MatthewFlamm]

It was decided to remove the distinction completely from the backend, but no one has implemented such a decision. See https://github.com/home-assistant/architecture/issues/322. Seems like this issue is just being ping-ponged back and forth.

[zsarnett]

I personally like the idea of having Moon phases in icons. Especially now that we can make our own using SVGs. Pretty simple to do if night then use the moon else use the sun. But I also agree with the complication of things. Specifically with Hourly forecasts. I think for consistency and no overcomplicating we leave it out.

What if the sun.sun is not available? You are telling the card to look at a separate entity not specified in the card config, which I am not sure I like. Forecasts would be always sun.

Lots of things to consider... and overall its @balloob and @bramkragten decision about the best way to do it and if its too complicated to add to the code base. And in the Arch issue it seems as though they are against it

[balloob]

It can never be implemented in the frontend because weather doesn't have to be for the current location, so there would be no way of knowing the sunset/sunrise.

[Mariusthvdb]

ping ponged indeed....which doesn't solve the issue, or doesn't even come close to make us feel anyone cares tbh. which I know not to be true of course. it's just that this has been going on for so long.

could it be a start to have a 'default' set, using the default location (as specified in the integrations, being the HA instance), and then use that location for calculating day/night, sun-up/sun-set.

let it be known that if the user uses another location, this behavior will/could be impacted. depending on that location. That would ate least solve the situation for most users using their instances home location.

if not doing this in the frontend, then the integrations should/could be forced to use correct states in the backend, and adhere to some default HA rule, having day/night sensitive states?

sun.sun being unavailable of course is a possibility, but probably highly unlikely, since anyone using a weather integration would have sun.sun configured. Especially if that would be added to 'default' config...

@MatthewFlamm 's suggestion https://github.com/home-assistant/architecture/issues/322#issuecomment-568195153 is rather a strong one, and might be simplest?

only trying to think along here, can't imagine anyone being 'against' a solution for this rather fundamental issue.

would be glad to assist in getting this forward.