Interesting.
I just updated to 4.12.7 and it’s working again.
ok, got my old badges back using the
- type: custom:hui-state-badge-element
But I have some badges that are conditional using
type: entity-filter
Any Fix for them?
The WLED 0.14.0 requirement is pretty bad since there are a couple crippling bugs that are yet to be resolved in >0.13.3. I have a handful of ESP8266 devices scattered around the house that all suffer from this bug: 8266: WLED keeps rebooting after 0.14.1 update. · Issue #3685 · Aircoookie/WLED · GitHub
I’ve tried every version from 0.14.0-0.15.0-b4 and every one has some bug (different ones on different versions) that is unusable. Any way to circumvent this requirement? I am not using any features that need 0.14.
Anyone have a list handy - or wouldn’t mind pulling it out of their logs - of the order tables are migrated in in the 43->44 schema upgrade?
(I have a 6 GB remote database, so am currently in hour 16 of migration, but I wouldn’t mind getting a feel for actual progress. Last I saw a log entry, it was “modifying columns run_id in table statistics_runs”.)
Just realised both my Yamaha network receivers have been unavailable since the update. New issue:
Yes. Don’t update home assistant.
I get you.
If the section where badges go were at least made horizontally scrollable, it would already be better. I’m just making this single point. I’ve made more ones on the relevant new badges topic.
I think one of the design oversights here is separation of concerns. There should be instead a separate, floatable top section where you place any cards, and otherwise, anything including badges must be usable anywhere else (which, as some here may know, are possible with a custom component). Cards and placement/layout are two different things.
16 hours seems way too long unless there are serious performance issues with your db. Most likely something has gone wrong in the process.
Hi, most things working great and I’ switching from service calls to action in my yaml code and it’s working fine.
But whats about service calls at tap_actions etc:
tap_action:
action: call-service
service: script.script_master_ac_off
tap_action:
action: call-service
service: browser_mod.more_info
data:
entity: sun.sun
double_tap_action:
action: call-service
confirmation:
text: Heizung Master Aus bzw. auf Auto?
service: script.script_master_heizung_off
tap_action:
action: fire-dom-event
browser_mod:
service: browser_mod.popup
data:
Is there something to change too?
yes, its since 2024.8
and probably the reason these pages are now causing so much lag/wont load. templates are constantly being reevaluated, and all of those state changes now impact the /config/helpers page too.
at least that is the assumption for now.
Thanks for showing us how this is done 
Works perfectly 
Just added this to test in the UI and copied the YAML:
tap_action:
action: perform-action
perform_action: automation.turn_off
target:
entity_id: automation.3d_print_finished
data:
stop_actions: true
tap_action:
action: perform-action
perform_action: script.alarm_triggered
Things like that depends on DB size and machine that it sits on (CPU, disk). Mine has over 15GB and it took over 15h to finish (can’t find exact log entry, probably because of the restart I did) and it’s installed on SSD with i5-4570TE.
Looks like my database upgrade failed. Not sure if there is anything I can do with it or just start over with a new blank DB. I’m running MariaDB separately on my Synology with Home Assistant on Home Assistant Blue.
Logger: homeassistant.components.recorder.core
Source: components/recorder/core.py:988
integration: Recorder (documentation, issues)
First occurred: August 8, 2024 at 11:10:47 PM (1 occurrences)
Last logged: August 8, 2024 at 11:10:47 PM
Error during schema migration
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/recorder/core.py", line 988, in _migrate_schema
new_schema_status = migrator(
^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/recorder/migration.py", line 335, in migrate_schema_live
schema_status = _migrate_schema(
^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/recorder/migration.py", line 301, in _migrate_schema
_apply_update(instance, hass, engine, session_maker, new_version, start_version)
File "/usr/src/homeassistant/homeassistant/components/recorder/util.py", line 703, in wrapper
job(instance, *args, **kwargs)
File "/usr/src/homeassistant/homeassistant/components/recorder/migration.py", line 710, in _apply_update
migrator_cls(instance, hass, engine, session_maker, old_version).apply_update()
File "/usr/src/homeassistant/homeassistant/components/recorder/migration.py", line 756, in apply_update
self._apply_update()
File "/usr/src/homeassistant/homeassistant/components/recorder/migration.py", line 1490, in _apply_update
_modify_columns(
File "/usr/src/homeassistant/homeassistant/components/recorder/migration.py", line 575, in _modify_columns
with session_scope(session=session_maker()) as session:
File "/usr/local/lib/python3.12/contextlib.py", line 144, in __exit__
next(self.gen)
File "/usr/src/homeassistant/homeassistant/helpers/recorder.py", line 104, in session_scope
session.commit()
File "/usr/local/lib/python3.12/site-packages/sqlalchemy/orm/session.py", line 2017, in commit
trans.commit(_to_root=True)
File "<string>", line 2, in commit
File "/usr/local/lib/python3.12/site-packages/sqlalchemy/orm/state_changes.py", line 139, in _go
ret_value = fn(self, *arg, **kw)
^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/sqlalchemy/orm/session.py", line 1309, in commit
trans.commit()
File "/usr/local/lib/python3.12/site-packages/sqlalchemy/engine/base.py", line 2629, in commit
self._do_commit()
File "/usr/local/lib/python3.12/site-packages/sqlalchemy/engine/base.py", line 2734, in _do_commit
self._connection_commit_impl()
File "/usr/local/lib/python3.12/site-packages/sqlalchemy/engine/base.py", line 2705, in _connection_commit_impl
self.connection._commit_impl()
File "/usr/local/lib/python3.12/site-packages/sqlalchemy/engine/base.py", line 1146, in _commit_impl
self._handle_dbapi_exception(e, None, None, None, None)
File "/usr/local/lib/python3.12/site-packages/sqlalchemy/engine/base.py", line 2356, in _handle_dbapi_exception
raise exc_info[1].with_traceback(exc_info[2])
File "/usr/local/lib/python3.12/site-packages/sqlalchemy/engine/base.py", line 1144, in _commit_impl
self.engine.dialect.do_commit(self.connection)
^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/sqlalchemy/engine/base.py", line 585, in connection
return self._revalidate_connection()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/sqlalchemy/engine/base.py", line 677, in _revalidate_connection
self._invalid_transaction()
File "/usr/local/lib/python3.12/site-packages/sqlalchemy/engine/base.py", line 667, in _invalid_transaction
raise exc.PendingRollbackError(
sqlalchemy.exc.PendingRollbackError: Can't reconnect until invalid transaction is rolled back. Please rollback() fully before proceeding (Background on this error at: https://sqlalche.me/e/20/8s2b)
how can i have that type of badges with new version.
to avoid discussion on which is better or not I just need to know ho to do this.
1st row is one of the TABS in my dashboard and the 2nd row is in other TAB.
1st one change icon color based on state
2nd is bigger than normal badges
apparently I am not alone Badge pictures not showing - #3 by Caswell1000
Not linking this here because of the legacy versus new badges adjustment cycle.
But I do believe the tendency to use smaller elements is not optimal for accessibilty. The badges look truly shiny, but only for under 40… 
Ofc, adding the option to not use the icon at all is hopefully in the works, and would solve this particular worry.
My remark here is more generic, hope the Frontend team will have eyes for that
