You can do this by using card_mod. I have reduced the gaps in my card with the following settings:
card_mod:
style: |
.overview-top {
margin-top: 3px;
margin-bottom: -25px;
padding-right: 25px;
}
.slot-section {
margin-top: -5px;
padding-left: 40px;
}For the last day or two, my platinum weather card hasnāt been rendering at all - just a big blank space on my dashboard, and no errors. When I try to make a new card, it renders while Iām populating the fields, and then totally disappears when I save it. Everything was working fine previously, and I have no other dashboard glitches.
Any guidance about how to troubleshoot?
Ugh. Tough one.
Perhaps try to start from a minimum configuration and incrementally add content to find out where it breaks. Hopefully, itāll render from the minimum content. If youāre using any sensor templates, check to see if theyāre working as expected.
Iām having the same issue after updating to 2023.8.1 (I skipped 8.0). I can create a new one with nothing in it and it renders. When I get some time, Iāll sit down and slowly rebuild it and see what seems to break it.
Edit: Seems it doesnāt like having any entities populated by the National Weather Service (NWS) integration. I have 5 of those used for my forecasts, and it seems that if any of them are included it wonāt populate the entire card. As soon as I remove them all, it populates the card (without the forecasts section). Iāve also confirmed I can add OTHER integrations into the forecasts and it populates. Can anyone else confirm this?
It seems to be related to NWS for me too. Actually, I use a template weather entity populated mostly from NWS, and as soon as I add this to the daily forecasts section, the card stops rendering. But, as we both noticed, this worked before.
I donāt see anything obviously amiss in the NWS data.
I found this in the 2023.8 release notes:
Iām guessing itās the culprit and the card doesnāt know how to handle it?
I removed all humidity entries by adjusting the state of the weather entity in Developer options, and I still had the rendering problem.
Have you enabled all of the entities you need for current conditions and forecasts? Thatās everything except hourly data, unless youāre specifically using that entity.
FYI, Iāve modified two files of the NWS integration to provide a shortened short-term forecast entity. You can leave entity_summary empty unless youāre populating it with something else.
Iām using the following entities directly. The rest are templates.
entity_forecast_icon: weather.kbwi_daynight
entity_humidity: sensor.kbwi_relative_humidity
entity_pressure: sensor.kbwi_sea_level_pressure
entity_temperature: sensor.kbwi_temperature
entity_visibility: sensor.kbwi_visibility
entity_wind_bearing: sensor.kbwi_wind_direction
entity_wind_speed: sensor.kbwi_wind_speed
Something just dawned on me. Iāve modified two files locally, so Iāve been using a prior version of the NWS integration. A newer version may have resulted in a breaking change w.r.t. the Platinum Weather Card. Iāll update to the latest version over the next day and see if my templates and card still work.
Iām only using it for the forecast data as I have my own weather station for current conditions (so no, I only have the forecast entities enabled).
The issue only occurs when the NWS forecast entity is added to the forecast section of the card. Simply removing it and even adding the forecast entity from another integration causes it to render normally.
Thanks. Thatās good info.
Apologies if you already know this, but the NWS integration uses indexed attributes for the forecasts. You need a sensor template to extract forecast.[0], which is always the near-term forecast, day or night.
Hereās the YAML template needed to use the attribute. Youāll need to put it in a file, either a new one or paste it into configuration.yaml. I usually put things like this in the packages directory under the config directory. It can be named anything you like, but must have the .yaml extension. Of course, you need to replace xxxx with your station ID.
template:
- sensor:
- name: summary_0
state: >
{{ states.sensor.weather.xxxx_daynight }}
attributes:
detailed_forecast: >-
{{ state_attr('weather.xxxx_daynight', 'forecast')[0].detailed_description | string }}
When itās running, you should see sensor.summary_0 in your entities. There will be no state, just an entry for the attribute.
This is how you configure the Extended Section of the card:
You should see entity_extended: sensor.summary_0 in the Code Editor.
Fingers crossed it works for you.
Iām not using the Extended Section, rather the Daily Forecast Section. And yes, Iām aware how the forecast data is handled within the attributes. While I COULD create template sensors to pull this out (and maybe it would work then), I really would prefer not to have to do this and never had to in the past. It was the upgrade to 2023.8 that broke it for me but only for the NWS forecast. For the time being, Iāve switched back to the OpenWeatherMap forecast. I just strongly prefer the NWS one, as the OWM one is wildly inaccurate for my location at least.
The long/short: prior to 2023.8 the NWS forecast could be selected for all of the Daily Forecast Section āitemsā but now breaks the entire card if thatās done. Other weather forecasts donāt.
I understand your position. Itās still possible the recent core update broke something with the current version of the NWS integration. I hope to test that later today, but in my case it has been working with a fairly elaborate YAML file. For the moment, the Platinum Card here is working as expected with the 2023.8.1 core.
Definitely let us/me know how your test goes.
@NYZack, I assume youāre still having the same issue as well?
Hereās the poop. The best I can say is the templates for forecasts are working (with the exception below).
This (from a sensor template), which could be the reason the card is on strike.
Hereās the capture from the daynight forecast:
Hereās a capture of the same data with an older version of the NWS integration:
Edit: Iāve now seen multiple instances of the same offending content in the daynight entity. Moreover, a closer look reveals itās not a unicode character because it says unitCode, which is a schema. We live and learn. It doesnāt change the conclusion, so Iāve submitted an issue.
Edit 2: Some of the issues have turned out to be temporary. Perhaps there was an outage of some of the API endpoints. The missing individual current observation measurands are being populated now. Moreover, everything seems to be working with the exception of a few precipitation_probability attributes. These result in NaN (not a number) instead of a value.
The conclusion is thereās something amiss with the current version of the NWS integration. Still, it might be worthwhile to make another attempt at configuring the forecasts. Iād allow it some time to populate.
Thanks for submitting the issue!
See my edits. Things that werenāt working earlier in the day are working now. The issue with precipitation_probability has been confirmed and is getting some traction from the integration owner.
The issue is in pynws, an upstream component used by the NWS integration.
https://github.com/MatthewFlamm/pynws/issues
The issue affects only the precipitation_probability attribute. As far as I know, it occurs when the probability is 0%.
If you make another attempt, or change your mind regarding a sensor template, Iām willing help as best I can.
Hello everyone,
I have the issue that this card will not display in the language of my profile/system.
(language is English and profile language is Dutch, so everything else besides the innate text on the card is Dutch)
Is there a way to fix this?
I believe this isnāt possible, but is there any way to change the order of the forecasted highs and lows in the forecast section? It defaults to the low coming before the high (for instance: 67/81F, which makes sense since itās usually coldest in the morning), but Iām using a weather integration (weatherunderground) that actually has the low reported a day early (so the low forecast for today is actually listing the low that will be hit TOMORROW morning). Looking through the documentation, Iām not seeing any way to alter this.
Can anyone confirm itās not possible to change this before I put a feature request on Github? Thanks!
