2024.8: Beautiful badges!

In the dashboard edit mode, click on the badge pencil, there are settings for appearance, visibility and interactions.

Looks like some great work team! I am excited to upgrade! Thank you!

For those who is interested in using new “created_at” & “modified_at” properties:
New “created_at” & “modified_at” properties: expectations vs reality
Not everything works as expected (by me); and there is a probability that for yaml-defined entities it will not work at all.

To me, this “double” layer of actions is more confusing than services vs. actions.
TBH, not sure why service was confusing in the first place.
But ‘actions’ having ‘actions’ sees way more confusing to me.

Are the 2 levels of action have the same capabilities… can subactions themselves have subactions ad-infinitum?

8 Likes

It’s a work in progress. It will eventually be actions and action, as mentioned in the stream.

Speaking as someone who often misses or misreads minor letter changes, the use of ‘actions’ vs’ ‘action’ seems fraught with chances for confusion and mistake.

8 Likes

It doesn’t seem that these actually give access to having the name appear on the new badge layout in 2024.8.0 I’m checking if this is because they were only imported into the new schema, instead of created with a new dashboard to see if there is a difference.

Once you select the dashboard edit then you just click on the individual badge to get access to those options…thanks for this insight…wish I could have an option for just name and state, for some of them I could really care less about the icon!!

2024.8 Changed some badges to make them larger with less info. I tried the raw config in edit mode to bring back older badge but unable to do so. How can I do so without just restoring the older HA version.

You can add the type custom:hui-state-badge-element for each entity to restore the old look:

 - entity: sensor.raelyn_s_temp
   type: custom:hui-state-badge-element
   ...
1 Like

You can see how by reading this thread. Really, it is around post 10, but I am not your Google.

1 Like

Following recent service to action changes in 2024.8, we need a consistent way to display YAML.

For example in automations YAML is formatted as:

    - action: script.xxxx
      data:
        var: "{{ var }}"

However in Scripts YAML is formatted as:

    - data:
        var: "{{ var }}"
      action: script.xxxx

I find the - action: script.xxxx formatting more intuitive and consistent with the earlier service call.

Aren’t they exactly the same?

I thought so too at first, but it would actually be consistent with how conditions are defined.

Important info like this should be included in the blog post too, which I deem the primary source of information for releases (beyond the full changelog). I don’t think the live stream should be the only source of such information.

Are there plans then to change trigger to triggers and condition to conditions then too?

I agree. Much as I love HA, I spend too much time already. The live streams are just too much time investment.

8 Likes

They are not the same. Although they behave the same they are not the same from a formatting perspective.

If you want to keep consistency with how actions work in other scenarios one could consider this format:

- script:
  data:
    var: "{{ var }}"
  action: xxxx

or

- script:
    var: "{{ var }}"
  action: xxxx

I am referring to being consistent in terms of formatting not in terms of functionality which can be the same regardless of formatting.

IMHO being consistent is very important as it makes visual code scanning easier to spot coding errors.

2 Likes

As I understand yaml the formatting is identical. (In your first example)

Visually the two code blocks are different (- data is contextually out of place IMHO, as it is used in other places differently and therefore not consistently):

    - action: script.xxxx
      data:
        var: "{{ var }}"
    - data:
        var: "{{ var }}"
      action: script.xxxx

Different actions require different data. There is no point in giving an action to change volume on a media player data for brightness or color temperature.

Technically, that is a dictionary item within a list, and generally speaking dictionaries (in programming) don’t have ordered keys.

YAML also doesn’t enforce this ordering (it’s HA that enforces actions as a sequence, but I think that’s about the only place).

Like, in automations, you can put your triggers after actions and conditions. It would read oddly, for sure, but everything would still work.