Thanks. I will look into it.
Thanks.
Originally, I started with @mirekmalâs template, but then I realized you had templated the sensors which was very convenient (thanks!). @mirekmal wasnât reading the time, he was calculating it from today on his system. I guess thatâs fine, but Iâd prefer to read it from the same entity I read everything else. Here is that code (shared by @mirekmal elsewhere):
- content: >-
### <center>{{ (as_timestamp(now()) + 5*86400) |
timestamp_custom('%a') }}</center>
I also live in the US and see the same issue with the date as @george_b reported. (My card calculates the display date from todayâs date so it wasnât an issue for me in Lovelace.)
Iâm trying to understand the data we are getting. This integration appears to be using max temp and min temp for the high and low forecast temperatures, which are the high and low in the calendar day (midnight to midnight). Usually when we want to know âhow cold will it be tonight?â we are thinking of the âovernight lowâ, which occurs roughly around 4-5AM of the next calendar day So say for example Forecast Day 1 is Monday. Does this mean that the low given in Forecast Day 1âs data is really the overnight low for Sunday (occurring early Monday morning) and the overnight low for Monday would come from Forecast Day 2âs data?
Hope that makes sense - this low temperature business always confuses me 
The issue with using your own time is that if the entity state does not update, you will be looking at yesterdayâs forecast today and you wonât know. Thatâs why I wanted to read data and datetime from the same source. Similar to the issue we are having as we read the timestamp from the sensor 
Unfortunately partly-clody-day and night is not supported in the Weather Entity by Home Assistant as you can see from below, which are the supported conditions. It is easy for me to do, but most people would then get a default icon and text if they use the standard weather card. So I would suggest you ask for a feature change in Home Assistant for them to add partlycloudy-night to the below list and associate that with a standard Icon for the default weather card. Then I can adjust this Integration.
{
"state": {
"_": {
"clear-night": "Clear, night",
"cloudy": "Cloudy",
"exceptional": "Exceptional",
"fog": "Fog",
"hail": "Hail",
"lightning": "Lightning",
"lightning-rainy": "Lightning, rainy",
"partlycloudy": "Partly cloudy",
"pouring": "Pouring",
"rainy": "Rainy",
"snowy": "Snowy",
"snowy-rainy": "Snowy, rainy",
"sunny": "Sunny",
"windy": "Windy",
"windy-variant": "Windy"
}
}
}
You might be able to make your own Template sensor, where you check for the is_night Attribute and then change the icon based on that, until this is officially supported.
Hi all,
I have now published a new Temporary release called V0.19. The only change here is that each forecast_day_x sensor has a new attribute called local_time. Can you please check if this is accurate as opposed to the current datetime attribute. If it is, this will be the new datetime so donât change anything in your setup. Just report back if this is correct.
From the API, this is what we have access to:
* `valid_date:` Date the forecast is valid for in format YYYY-MM-DD [Midnight to midnight local time]
* `ts:` Forecast period start unix timestamp (UTC)
So local_time is just a direct datetime conversion of the valid_date field, which should be for the current location and timezone. So I do no math on that.
datetime is a conversion of the UNIX timestamp, to local timezone, but it seems to be off.
nice item to jump in this thread⌠above would indeed be a great idea, and has been requested many a time already, but denied unfortunately.
Using a template sensor is the best we can do for all conditions to be represented by their own icons.
The power of which can be augmented, using more than 1 integration 
weather_icon:
entity_id: sensor.dark_sky_icon, weather.dark_sky, weather.woensdrecht
friendly_name_template: >
{{states('sensor.weather_icon').split('weather-')[1]|title}}
value_template: >
{% set mapper_icon =
{'partly-cloudy-night':'night-partly-cloudy'} %}
{% set mapper_br =
{'pouring':'pouring',
'lightning-rainy':'lightning-rainy',
'snowy-rainy':'snowy-rainy'} %}
{% set mapper_ds =
{'clear-night':'night',
'partlycloudy':'partly-cloudy'} %}
{% set icon = states('sensor.dark_sky_icon') %}
{% set woensdrecht = states('weather.woensdrecht') %}
{% set dark = states('weather.dark_sky') %}
{% set weather = mapper_icon[icon] if icon in mapper_icon else
mapper_br[woensdrecht] if woensdrecht in mapper_br else
mapper_ds[dark] if dark in mapper_ds else
dark if dark in
['sunny','rainy','snowy','snowy-rainy','windy','fog','cloudy','hail','lightning']
else 'sunny-alert' %}
mdi:weather-{{weather}}
icon_template: >
{{states('sensor.weather_icon')}}
to give you an exampleâŚ
btw, thanks for working on a strong replacement for Dark sky!
I did not know that - strange as it is such an easy change to make.
it was considered to be a breaking change (which it would be indeed, but one t make HA use consistent naming imho) and not worth the hassle it would cause.
Maybe coming from someone else yet again could create some extra traction⌠use day/night and partly-cloudy instead of partlycloudy would be 2 improvements and most certainly be very worth the breaking change I would think.
It would have to be on HA level for all weather integrations.
had the PRs ready
and an architecure discussion:
Based on @Mariusthvdb unsuccessful attempt to get the HA Core changed (And it seems like this will not happen, even though we get more votes for this) - the only creative suggestion I have is to create an extra Attribute on the Weather Entity, with an alternative condition. Some of them will be same as it is now, but for example we could add partlycloudy-night instead of partlycloudy. This way you donât need to create template sensors, but you can just read the Attribute. Would that be of any use?
1 Like
I can confirm that the new variable local_time has the correct day.
sensor.weatherbit_forecast_day_1 is now:
datetime: 2020-06-08T20:01:00-04:00
local_time: 2020-06-09T00:00:00
and from the weather.weatherbit_XXX entity I read the attribute:
datetime: '2020-06-09T04:01:00+00:00'
The date and time here (as I am writing this) is 06/09/2020 (MM/DD/YYYY) 7:15AM.
So the day is correct in local_time. I checked all the other forecast days and the same is true for any sensor.weatherbit_forecast_day_X.
Thanks!
yeah, that would be a good start. A very good one tbh. No extra templating, finally have an integration that does it all correctly 
I always feel frustrated when during the evening/night, I see a condition Sunny, or cloudy-day⌠It somehow should be night/day sensitive, easiest probably would be sun-up/down for the locale, and change accordingly?
Clear night showing a moon, clear day showing the sun, how obvious could it be 
The issue linked by @Mariusthvdb is only about renaming the existing conditions, but this one was also rejected for adding the corresponding condition for partly cloudy at night.
yep, see also this issue report: https://github.com/home-assistant/frontend/issues/5774
ping ponging away.
The local date looks good, seeing the same as @george_b
I think that would be a good way to deal with this, given the history on getting the HA Core changed. We can have partlycloudy-day and partlycloudy-night and that would solve the problem.
Iâm not sure the local_time is working correctly for me. Here is the day-1 info:
datetime: 2020-06-08T19:01:00-05:00
local_time: 2020-06-09T00:00:00
I am GMT-5, so my local time woudl be 14:01:00. The whole thing seems a bit âoffâ for me, as itâs 9:51 here right now or 14:51 GMT.
Hi Frank,
Sorry I was not clear enough on that. Only the date is what should look at, the time will always be 00:00:00 as this is not supplied by Weatherbit.
And for making sure that Day displays correctly, that should be enough.
Well I will create a new Attribute on the Weather Entity, that will be called alt_condition and that will support both clear-night, partlycloudy-day and partlycloudy-night. Any more conditions we need split?
That sounds great, thank you. As far as I know, there arenât any other conditions to split.
Thats a deal. And it also seems that the local_time solves the forecast_day_x issues, so unless I hear anything else on that topic within the next 12 hours (Thats when I wake up 
) I will also use that as the datetime attribute value.
1 Like