Is there an easy way to get human-friendly weather condition strings?

Configuration
1

The Weather Integration has a pre-defined list of possible conditions. These are things like sunny (which is fine) and lightning-rainy or partly-cloudy. Those don’t lend themselves to human display or natural-seeming text-to-speech.

I started to make a template sensor to translate to things like “rainy, with lightning” and “partly cloudy”, but… is there a better way, or something already done?

2

I don’t think it has forecasting.

I was using NOAA for a while, until I got my PWS back up and running and now using Weather Underground.

3

Both my Ecobee thermostats (which pull the data from some service the Ecobee company has contracted with) and the NWS/NOAA integration show up as weather entities. These include forecasts. For example, from the Ecobee, I get a sensor with (currently) a state of sunny and these attributes:

emperature: 59
humidity: 56
pressure: 29.59
wind_bearing: 253
wind_speed: 6
visibility: 16
forecast: 
- condition: sunny
  temperature: 61
  templow: 44
  wind_bearing: 253
  wind_speed: 6
  datetime: '2022-04-08T22:01:35.451916+00:00'
- condition: rainy
  temperature: 55
  templow: 48
  wind_bearing: 203
  wind_speed: 8
  datetime: '2022-04-09T22:01:35.451916+00:00'
- condition: partlycloudy
  temperature: 52
  templow: 42
  wind_bearing: 290
  wind_speed: 10
  datetime: '2022-04-10T22:01:35.451916+00:00'
- condition: sunny
  temperature: 58
  templow: 40
  wind_bearing: 293
  wind_speed: 8
  datetime: '2022-04-11T22:01:35.451916+00:00'
- condition: rainy
  temperature: 64
  templow: 48
  wind_bearing: 274
  wind_speed: 8
  datetime: '2022-04-12T22:01:35.451916+00:00'

I know how to access these. However, strings like partlycloudy are not very useful. As far as I know, jinja2 doesn’t have a “switch/case” statement, so that means a bunch of unwieldy, long if/elsif sections in templates, with a lot of repetition.

I guess I could make a helper entity with, itself, attributes like partlycloudy: "partly cloudy" and so on, and then use that as a translation function. But I’m open to better ideas — ideally, already-done ones!

4

NOAA has forecasting.

5

Yes. But as you can see, Home Assistant provides those forecasts as strings meant for computer use, not human presentation.

6

Use a dictionary.

The following example uses the state value of weather.whatever to find a matching key in the my_forecasts dictionary (and reports the key’s associated value). If there’s no matching key, it reports unknown.

{% set my_forecasts = {'sunny': 'Full Sun', 'partlycloudy': 'A few clouds', 'rainy': 'Showers'} %}
{{ my_forecasts.get(states('weather.whatever'), 'unknown') }}
7

So something like this isn’t what you are looking for? (NOAA) (replace my location knak with yours)

{{state_attr('weather.knak_daynight','forecast')[0].detailed_description}}

8

Thanks – that’s better than a big if/else block. Is there any way to define the dictionary globally, or does it need to go in every template the value might be used?

9

That’s too much information. You get a long string like “Mostly clear, with a low around 38. Northwest wind around 14 mph”, or “A slight chance of rain showers after 2pm. Mostly sunny, with a high near 64. West wind 2 to 7 mph. Chance of precipitation is 20%.” I want a short condition summary, but in human-readable text.

And, unless I’m missing something, the hourly forecasts just have the short string, no detailed description.

10

Store it as a secret in the secrets file.

my_forecasts: "{'sunny': 'Full Sun', 'partlycloudy': 'A few clouds', 'rainy': 'Showers'}"

Use a script variable to reference it wherever you need it.

action:
  - variables:
      forecasts: !secret my_forecasts
  - service: notify.whatever
    data:
      message: "{{ forecasts.get(states('weather.whatever'), 'unknown') }}"
1 Like
11

Clever! That seems like a useful hack for a lot of shared code. Maybe an abuse of “secrets”, but…doesn’t feel awful.