Customising the BOM Weather and lovelace - now in HACS

The states I’ve observed in 24 hours:

Entity 18:00 00:00 09:00
now_label Overnight Min Min Max
later_label Tomorrow's Max Max Overnight Min

So, slight adjustment:

The today max value sets at midnight and 9am:

- name: "BoM Today Max"
  unit_of_measurement: "°C"
  state: >
    {% if states('sensor.hobart_now_later_label') == 'Max' %}  {# at midnight #}
      {{ states('sensor.hobart_now_temp_later') }}
    {% elif states('sensor.hobart_now_now_label') == 'Max' %} {# at 9am #}
      {{ states('sensor.hobart_now_temp_now') }}
    {% else %}
      {{ states('sensor.bom_today_max') }}
    {% endif %}

The today min value sets at midnight:

- name: "Bom Today Min"
  unit_of_measurement: "°C" 
  state: >
    {% if states('sensor.hobart_now_now_label') == 'Min' %} {# at midnight #}
      {{ states('sensor.hobart_now_temp_now') }} 
    {% else %}
      {{ states('sensor.bom_today_min') }}
    {% endif %}

Or even better, utilising today’s forecast when available as well:

- name: "Bom Today Max"
  unit_of_measurement: "°C"
  state: >
    {% if states('sensor.hobart_temp_max_0') == 'unknown' %}
      {% if states('sensor.hobart_now_now_label') == 'Max' %}
        {{ states('sensor.hobart_now_temp_now') }}
      {% elif states('sensor.hobart_now_later_label') == 'Max' %}
        {{ states('sensor.hobart_now_temp_later') }}
      {% else %}
        {{ states('sensor.bom_today_max') }}
      {% endif %}
    {% else %}
      {{ states('sensor.hobart_temp_max_0') }}
    {% endif %}

- name: "Bom Today Min"
  unit_of_measurement: "°C"
  state: >
    {% if states('sensor.hobart_temp_min_0') == 'unknown' %}
      {% if states('sensor.hobart_now_now_label') == 'Min' %}
        {{ states('sensor.hobart_now_temp_now') }} 
      {% else %}
        {{ states('sensor.bom_today_min') }}
      {% endif %}
    {% else %}
      {{ states('sensor.hobart_temp_min_0') }}
    {% endif %}

EDIT: Hmm. Or maybe not, as only the top level if entities are monitored for changes.

Screenshot 2022-05-01 at 11-55-08 Developer Tools – Home Assistant

Depending on when they go unavailable this may be equivalent to:

- name: "Bom Today Max"
  unit_of_measurement: "°C"
  state: >
    {% if states('sensor.hobart_temp_max_0') == 'unknown' %}
      {{ states('sensor.bom_today_max') }}
    {% else %}
      {{ states('sensor.hobart_temp_max_0') }}
    {% endif %}

- name: "Bom Today Min"
  unit_of_measurement: "°C"
  state: >
    {% if states('sensor.hobart_temp_min_0') == 'unknown' %}
      {{ states('sensor.bom_today_min') }}
    {% else %}
      {{ states('sensor.hobart_temp_min_0') }}
    {% endif %}

Or maybe better doing it the other way around:

- name: "BoM Today Max"
  unit_of_measurement: "°C"
  state: >
    {% if states('sensor.hobart_now_later_label') == 'Max' %}  {# at midnight #}
      {{ states('sensor.hobart_now_temp_later') }}
    {% elif states('sensor.hobart_now_now_label') == 'Max' %} {# at 9am #}
      {{ states('sensor.hobart_now_temp_now') }}
    {% else %}
      {% if states('sensor.hobart_temp_max_0') == 'unknown' %}
        {{ states('sensor.bom_today_max') }}
      {% else %}
        {{ states('sensor.hobart_temp_max_0') }}
      {% endif %}
    {% endif %}

- name: "Bom Today Min"
  unit_of_measurement: "°C" 
  state: >
    {% if states('sensor.hobart_now_now_label') == 'Min' %} {# at midnight #}
      {{ states('sensor.hobart_now_temp_now') }} 
    {% else %}
      {% if states('sensor.hobart_temp_min_0') == 'unknown' %}
        {{ states('sensor.bom_today_min') }}
      {% else %}
        {{ states('sensor.hobart_temp_min_0') }}
      {% endif %}
    {% endif %}

Screenshot 2022-05-01 at 12-17-04 Developer Tools – Home Assistant

More monitoring required.

It’s based on what the state is now so it won’t monitor for entities that are unreachable in the current state or will not be able to change the value of the result.

The list of monitored entities will change if the state of one of the ifs allows another if to be reached

1 Like

Ah! Thank you.

Very clever.

So either version of the templates should work as intended. I think. Will monitor it for another 24 hours. The best one may depend on the forecast 0 sensor unavailable timing.

The timing for the forecasts is the same as for the now/later sensors. The forecast min should vanish at 9am and return at midnight. I am guessing the BoM remove it since a forecast for something that occurred in the past makes little sense.

The min_0 changed to unknown at 16:00

It varies. It always used to be 4am. I wouldnt depend in a fixed time only the state

Well in that case we have this:

So I guess this is best?

- name: "BoM Today Max"
  unit_of_measurement: "°C"
  state: >
    {% if states('sensor.hobart_now_later_label') == 'Max' %}  {# at midnight #}
      {{ states('sensor.hobart_now_temp_later') }}
    {% elif states('sensor.hobart_now_now_label') == 'Max' %} {# at 9am #}
      {{ states('sensor.hobart_now_temp_now') }}
    {% else %}
      {% if states('sensor.hobart_temp_max_0') == 'unknown' %}
        {{ states('sensor.bom_today_max') }}
      {% else %}
        {{ states('sensor.hobart_temp_max_0') }}
      {% endif %}
    {% endif %}

- name: "Bom Today Min"
  unit_of_measurement: "°C" 
  state: >
    {% if states('sensor.hobart_now_now_label') == 'Min' %} {# at midnight #}
      {{ states('sensor.hobart_now_temp_now') }} 
    {% else %}
      {% if states('sensor.hobart_temp_min_0') == 'unknown' %}
        {{ states('sensor.bom_today_min') }}
      {% else %}
        {{ states('sensor.hobart_temp_min_0') }}
      {% endif %}
    {% endif %}

Though restarting between 6pm and midnight may cause one or both sensors to become unknown until midnight. So not a great solution.

Are triggered sensors restored? EDIT: no they are not.

If so using triggered sensors just before 9am might be better

@DavidFW1960 @theRat I just want to say thanks very much for your recent updates to this card. I have been maintaining my own fork, which has been a challenge since I Iack the coding skills necessary. But now that the pressure units work properly, I can choose how many decimal places I want, and I have the ability to add dew point as a custom slot entry, I am very happy to ditch my fork and use your custom card. Thank you again! :star:

4 Likes

As of 2022.5 they are.

So this would simplify things (untested):

template:
  - trigger:
      - platform: time
        at: '00:15:00'
    sensor:
      - name: "BoM Today Max"
        unit_of_measurement: "°C"
        state: "{{ states('sensor.hobart_now_temp_later') }}"

      - name: "Bom Today Min"
        unit_of_measurement: "°C" 
        state: "{{ states('sensor.hobart_now_temp_now') }}"

For some reason the 1.1.2 release of the BoM Weather Integration has disappeared twice and has been asking people to upgrade from 1.1.2 to 1.1.1b (possibly to a different older version if you don’t have pre-releases ticked).
I have just released 1.1.3 to try and stop this happening. I honestly have no idea why a release would vanish from github, but it has happened twice :frowning:

1 Like

It’d not just the BoM Weather integration doing this. I’ve had other integrations asking to download like this. Seems to be an issue with HACS.

Its not HACS I don’t think… the releases are disappearing from Github. It’s a Github bug I thinl

:astonished: Becoming too popular and hitting rate limits?

I don’t think so. On github the release no longer was listed. Nothing to do with HACS.

Yeah. I am seeing this with a few HACS updates. Some which I haven’t updated (Dwains Dashboard/Alarmo) had new updated last night, but this moring, it seems they are gone. Certaily a gitbub issue.

1 Like

So GitHub are aware of the problem.

Would it be possible to add a new slot type for actual recorded rainfall?
I’m currently using possible_today and pop, but find having forecast and actual values on the same line with pop a little unintuitive.

I would like to use actual rainfall in one slot and popforecast in the other.

Unfortunately I’m already using the two custom slots for forcast temperatures which change to actual temperatures once they have been exceeded.

Why 2 forecast temps? I was going to say that’s what the custom slots are for. Have you tried the new temp now and temp later entities? It’s probably not too hard to add an extra 2 custom slots…
Should also add that @theRat Simon is currently rewriting this card to use Typescript (which the boilerplate card is based on) to replace the javascript. This as I understand it will also fascilitate full GUI configuration for the card so I’m not super keen to make any further major changes to this card at this time. Work on the Typescript version is well underway.

One for forecast/actual max temp, and one for forecast/actual min temp.

I’ve only just removed and re-added the integration to get the temp now and temp later entities. I’ll keep an eye on how they change over the next 24 hours, but I think I prefer to keep the slots for today’s forcast/actual figures. Not overly keen to have the overnight min in there when it’s already in the 5 day forecast below the slots.

Two extra custom slots would be great if you decided to add them when the rewrite is complete.