2024.8: Beautiful badges!

Blog
242

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

243

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

244

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.

245

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
246

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

247

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
248

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.

249

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!!

250

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.

Image 12
Image 122480×1606 352 KB

Image 7 2
Image 7 21526×1522 409 KB

1 Like
251

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
252

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

1 Like
253

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.

254

Aren’t they exactly the same?

255

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?

256

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

8 Likes
257

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
258

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

259

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
260

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.

261

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.