@wmaker - Thank you very much for that explanation - I finally understand what needs to be implemented now, after reading various other threads and still being left a little confused. I’m going to go with option 1. I was on the right lines and created a trigger based sensor already which works, but my attributes: forecast section is simply:
This gives the trigger based sensor attributes in the exact same format as the response when the weather.get_forecasts service is called manually against the Openweathermap entity:
Will this work OK for creating my various daily template sensors as per 1.b above? Or should I change my attributes section to match the example that you linked to, i.e
It looks like the above was mainly suggested for the rounding of certain values (which you mentioned to disregard). If it makes any difference, I will be looking to create template weather for condition, high temp and low temp, just for the purpose of this PWC, for the next 5 days.
[EDIT] For step 1b), when using sensors in a PWC configuration, PWC primarily uses the sensor’s state and not its attribute, so it won’t use the sensor’s forecast as an attribute.
Thanks a ton for forking and fixing this card! I finally have my weather card back to how I had/wanted it months ago; I’d just about given up on using it.
Have you reached out to the original author to look at rolling your fixes/updates into the original or considered actively maintaining your fork? I’m just now seeing it hasn’t been updated for 2 years (I could have sworn it had a more recent update). It’d be a shame for this card to just die if there’s a future breaking-change.
In my case I don’t use template sensors anymore, but I think it would be something like the following (try it and see if it works for you):
Let’s say you created a template sensor using 1a) that shows in the developer’s tools as:
sensor.weather_forecast_daily
w. attributes:
friendly_name: Weather Forecast Daily
forecast:
- detailed_description: >-
We could see an early morning shower, otherwise look out for patchy fog this
morning. We'll be mostly cloudy for much of the day, but we could see some
peeks of sun later this afternoon. Highs in the upper 70s to lower 80s.For
the night: Mostly cloudy and turning cooler. Our southern counties could see
showers this evening. Lows fall into the low 50s.
wind_bearing: 0
precipitation_probability: 20
datetime: '2024-04-20T06:00:00-04:00'
condition: cloudy
temperature: 75
templow: 52
wind_speed: 9
... this is a list so it repeats for the forecasts for the next several days...
Then for 1b) you can create several sequential forecast sensors representing the next several days and you can add your own attributes to each sensor. Using configuration.yaml, it might look something like:
I’ve downloaded the forked PWC, and also tried setting up 1b) so that I have template sensors for condition, temperature, and min temperature for the next 5 days. All this information is pulling through to the new template sensors from my trigger sensor fine:
I’m not able to utilise the attributes from these new sensors in the forked PWC, unless I’m doing something wrong? I can only use the states, so I am getting the condition for each day, but trying to use the attributes for min/max temp results in NaN displaying, as I can only specify the sensor and not the sensors attributes for each config field in the card.
Should attributes be able to be used in this card in this way, like in the examples template sensors above, or do I need to create a sensor with a state for each item I want to target, rather than attributes?
I think my answer to you above was misleading/incorrect. When using sensors in a PWC configuration, PWC almost always uses the state of the sensor. There are a couple of configs where you can configure PWC to use attributes of a sensor instead of state, but otherwise it only uses state, so sorry for being incorrect about that, so I will edit my answer above.
BTW, you don’t need the forked PWC to use sensors.
Ah I see, thanks for clarifying. In that case I’ll add to my new sensors and create more new ones, each with a state only, and no attributes, so that i can use each sensor for each piece of data. I will have a sensor for tomorrow’s condition, one for tomorrow’s low temp, and one for tomorrow’s high temp, and the repeat for each of the 5 days that i need. Seems like a lot of new sensors, but if that’s what is needed to continue to use this card then so be it!
OK. I’ve created all of the new template sensors, so that I have a sensor for the condition, min temp and max temp for each of the 5 days that I get data for in my weather forecast. These sensors are getting state values correctly.
So I guess there are a couple of issues here, but what should I be using as the ‘weather entity with forecasts’ in the Daily Forecast Section configuration? I only have one weather entity, which is my weather.openweathermap entity, which is the one that gets called by my trigger, and this populates my sensor.weather_daily_forecast sensor:
Since you using my forked version…
it looks to me like openweathermap is a native HA integration, so it should be supporting the new subscribe methods for getting forecasts data. My forked PWC added these new subscribe methods so that a weather entity could still be used by PWC to get forecast data (these subscribe methods are kinda like the service call weather.get_forecasts). So you shouldn’t need all those sensors derived/created using the get_forecasts service call. I would say If you have time to play with this, then save away (copy/paste) your PWC yaml config for safe keeping, and then try configuring pretty much all PWC entities with weather.openweathermap and see if it works (start with just the slots section first to see if it works, then proceed on to the daily section. Make sure you at least have one yaml config: weather_entity: weather.openweathermap
Back to the sensors question …
It looks like the warning: entity_pop=sensor.openweathermap_forecast_precipitation_probability value needs to have a number is a bug introduced in my forked version. entity_pop shouldn’t require a number. The workaround is to add yet another template sensor with a number in it, or go back to the original PWC.
Thanks for the explanation @wmaker - I’ve created a new forked PWC on a test dashboard and configured using the weather.openweathermap entity for each of the slots, overview and daily forecast section fields, and that works! As straightforward as that - I’m not sure why I struggled so much, but reading through this topic and several others, I figured I needed to create a bunch of new weather sensors regardless of the card.
The entity_pop=sensor.openweathermap_forecast_precipitation_probability value needs to have a number
message confused me, as the state of that entity appears to already be a number, such as ‘70’ or ‘100’ for example - so this can’t be what the message is actually referring to
Yeah I can see why its confusing…what the warning means to say is “entity_pop”=value. Value here is a sensor with name sensor.xxxxx, so what it is really trying to say is that xxxx has to have a number in its name.
I think I know why… PWC has a list of weather conditions it tries to match: “sunny”, “cloudy”, “raining”, etc. and then picks an icon. This list however doesn’t include “Partly cloudy, light rain”, so it doesn’t find a match and thus can’t pick an icon.
I understand thanks for pointing in the right direction.
See where it is in the code now.
Also see there is no new code for 2 years to bad.
Not so platinum after all.
I went to Weather Chart Card now. Got also possibility to add some custom entry’s.
HI Andrew / All
I too am using BOM (Australia) Integration for Sensor data along with my Personal Weather Station for some sensors - all works well but for one thing. I just have NOT got the 5 day forecast ICONS to display. (screenshot below)
In the Platinum card Config I have:
‘entity_forecast_icon_1: sensor.bangalow_mdi_icon_1’
and the HA state sensor for the BOM Integration shows that sensor state as ‘mdi:weather-rainy’ ie to me that looks correct? but nothing shows.
would you mind sharing your Platinum Weather Card Yaml settings for the weather icons please - Im sure its something obvious my end that im missing. i had it working but somewhere along the way I or it busted.
Thanks.
Thanks for your replies. I’ve checked and as I have the BOM setup I don’t have the necessary sensor states exposed to HA, I’ll delve back in to the integration and hopefully now that I know what the issue is can set it up to produce these states for the Icons. Appreciate the guidance. I actually have Two BOM services configured (was experimenting) one the full forecast and another with Hourly forecast. I’m not sure the latter is necessary now but I’ll leave it for now, unless anyone advises this is not a good idea or unnecessary? Cheers
