2024.8: Beautiful badges!

Blog
202

has been explained quite a few times above now how to add the legacy badges to the 2024.8 Dashboard, just scroll back a bit

203

not just the badge, i’ve been reading since yesterday :slight_smile: ad the badge is easy but the styling is not working.
Like:

badges:
  - entity: person.XXXXXX
    card_mod:
      style: |
        :host {
          --ha-label-badge-size: 65px;
        }

Or:

badges:
  - entity: binary_sensor.XXXX
    card_mod:
      style: |
        :host {
          --card-mod-icon-color: 
              {% if is_state('binary_sensor.XXXXX', 'on') %}
                green
              {% else %}
                red
              {% endif %};
        }
204

Have you read the thread? You should do.

205

This is NOT a bug, this is about “user has not written a new appropriate card-mod code for a changed component”.
There are threads about card-mod, better to discuss there.

206

See no benefits of stacking plenty of unrelated entities in one table.
For me, the whole idea about a word “helper” should be reconsidered - there are entities in this table which are just a “sensor” for me (made by specific platform).
Like we used “services” and did not bother that they are latent “actions” in fact. Voila - they are “actions” now. Change in semantics - which does not seem to bring a trouble.

207

Yes, Home Assistant is full of these terms where “developers’ speak” was made the default. Template Sensors are named after the Python function that makes them possible instead of calling them “User Defined Sensors”.

4 Likes
208

as it seems to turn out, the assumption I made wasnt completely accurate above.

we’ve run several scripts in /entities and /helpers, and much to my surprise, the /helpers page shows even more updates in the states then the /entities page. Moreover, those are not only helpers, but all entities (ofc many sensors float by)

not yet found the solution, or even the true cause here,

about stacking the entities: I am not sure why the yaml (template) entities are now also listed in the Helpers. the subset of Helper entities is only getting bigger now, decreasing the difference between entities and helpers listing.

I kind of liked the UI only listing there, which, made it clear which listing to use.
But hey, I have no idea why this was changed, so maybe missing the advantage entirely.

1 Like
209

Anybody else seeing a broken homekit setup on Hass core? I’ve had a homekit config in my configuration.yaml since 2018, and now it fails with:

$ hass --script check_config
Testing configuration at /home/pi/.homeassistant
Incorrect config
  General Warnings:
    - Component error: homekit - Exception importing homeassistant.components.homekit

Successful config (partial)
  General Warnings:
$

The config is quite elaborate, but it even fails with the minimal config:

homekit:

Hass core 2024.8.0, Python 3.12.2 on a Raspberry Pi 3B with Raspbian Bookworm.

EDIT: The issue appears to be that the chacha20poly1305_reuseable module needs to be upgraded and that doesn’t happen when running the check_config script. Workaround:

  • comment out the homekit integration from the config file
  • rerun the check_config script, fix remaining warnings/errors
  • run hass in the noremal way
  • wait until startup completely (can take some time due to DB upgrades)
  • stop hass
  • restore homekit config
  • start hass
210

Honestly, one more reason for me NOT to get to the Helpers page.
99% of entities in my setup are made in yaml.
Why to use a UI-based solution if:

  • Helpers table is laggy (which you experienced - and I luckily did not);
  • UI-driven entities do NOT allow to use some supported functionality - like they do in yaml;
  • there are no packages, no reusable code.

(Not to mention a frequent glitch which seems to be fixed recently: adding a new “helper” causes showing a rotating ring while attempting to open a “Create helper” window - i.e. this window is opening for about a minute.)
I am simply not using this “Helpers” page - only in rare cases for testing mainly.

211

Created issue: Homekit fails to import with hass core 2024.8.0 · Issue #123460 · home-assistant/core · GitHub

212

yes! I noticed that yesterday, so not fixed yet apparently. Good this is been written up. Or is it? must find a link to then issue, so I can +1

The whole Dashboard feels less brisk than before since. I didnt really notice because all my efforts went to the config and helper page, but since running final betas on 8 and now release, this is really noticeable.

Other than that, I do have a lot of UI based helpers, and I always felt it was super nice to be able to change names/icon/show_as from within the UI.

and, it was super super fast. Was

but I have undying faith in Karwosts :wink: he’ll fix it

edit

@Ildar_Gabdullin where was it mentioned we cant create a new helper in the UI? Cant find a reported issue on the matter?

nvm, found it Cannot add a new helper in UI sometimes - seeing a loading indicator · Issue #20809 · home-assistant/frontend · GitHub

213

I worked it out. It was a custom integration blocking it.

image
image1116×378 15.6 KB

214

This is the issue
And you found it too.
The issue is old, I closed it before 2024.8.
Let me know if there is a need to reopen it (write smth in the issue).

Great that we have various ways to achieve our goals. But ofc it should be working smooth & predictable.

215

I rebooted and it is trying again. It’s four hours in though. If that fails I will just make a new DB and move on. Not sure what else to do.

216

Anybody else has problems with Energy Dashboard?

kép
kĂ©p1479×1063 73.1 KB

Before upgrade everything was ok.
Updated from 2024.06.x

217

I had the same problem.
My Database is about 9GB in size, running in MariaDB on Synology.
It failed after 17 hours!

I restored a backup an exported it to a much stronger server. Currently the much more potent Server is trying to update the DB.

For bigger Databases on smaller Systems e.g. 9GB on a Synology, this change is quite bad
 So far I lost over 24 hours of data


EDIT: On the stronger Server it completed the Job in 50 Minutes.

218

HAOS, no virtual machines, disk use 40GB (inclusive last 6 full backups),

running on

image
image856×519 141 KB

with 8GB RAM

MariaDB

the update took 75 minutes.

1 Like
219

For a comparison:
test setup on Vmware machine
i5-2500k
docker installation
default SQLlite
DB ~1300MB
update 2024.7 → 2024.8 took <5 minutes
May be I am missing smth?

1 Like
220

SQLite DB is not concerned (wrong?)

221

DB schema change only applied to non SQLite DB so you wouldn’t have seen it

“This notice applies only if you use the recorder integration with a MySQL or PostgreSQL database. If you are using the default SQLite database, you can ignore it.”