the weather entity has the status “clear-night” but not “clear-day”.
I propose to change this state to “clear” to not condition the current state according to the time of day.
This entity should only provide weather information (in this case the current weather) and not the time of day. In this way with this state and the position of the Sun you can put the corresponding icon.
It would also be very interesting to extend the “partialcloudy” state to:
partlycloudy-rain
partlycloudy-snowy
partlycloudy-lightning or partlycloudy-storm
I think the names are linked to the state the weather services provide.
Norwegian weather services also have clear-sky-polar-night just to add a more, but it seems the states are not a standard, so the names change from service to service and some service have more.
True, but the weather state is bound to an icon, so you need to have the icons also and if you look at the three links I posted, then you see that those are not the same. You would need to either make icon packs or make one universal icon pack, that fits all the possible states.
I like the icon pack idea, because then users might also be able to make animated icons.
Adding sun integration to weather widgets to know when it is night
Adding more granular states to weather integration so widgets can use a wider variety of icons
For the latter, perhaps it would be better to simply record multiple attributes, so clear/cloud are separate to dry/rain/snow and storm?
Then widgets (and other integrations) can simply choose how to deal with them, instead of adding lots of arbitrary text labels that would require integrations/automations/widgets/etc to be updated to understand each time?
It is not HA that defines what clear means. It is the weather services HA gets data from.
As I wrote earlier in the thread, some weather services have 25 or less states and that means HA then can not show more than that, because there is a lack of data to create more.
Some weather services have 80 or more states and trying to split those up in subcategories are also hard to do.
You can find weather services that have the same names on states, but with different descriptions, so a clear state is not always that clear.
Best bet is to make weather service packs to the weather service integration and then users can choose the ones they want to use, but often there is not that many weather services to really choose from, because even though most weather services cover the entire world, then they still have the higher resolution on the “local” area, so areas otherside this local area will be less precise.
I think that HA should have a set of states large enough compatible with the most common scenarios. But it doesn’t have to be 50, 60 or 80 either. Not all sources will use all statuses.
Each integration would use these states looking for the best option, the problem is that now the options are not well thought out.
Right now HA does not have well defined states nor enough for the most common scenarios.
The states are defined by the weather services, not by HA.
If HA choose to support 50 states, what then when the weather service only provide 25, which ones should be doubled up?
And if the weather service provide 80, then which ones should be scrapped and what about people relying on those states?
HA is not in a place to define those states, because the weather services would not abide to those definitions anyway. HA is simple not a large enough player to be reckond with in this area.
Trying to force this through is just as hopeless as trying to put a shop’s selection of computer into only one class of office, workstation or gaming.
I do not agree with this. HA must have the minimum to be understood with all the integrations and have only the common. What HA has has to be well thought out.