Oh boy… I feel you… luckily I moved from badges to chips months ago
I don’t like either of them. Badges are awful.
11 Likes
Badges for things running based on visibility are very useful a the top of the view, in this example: lights on, air conditioner on, tv washing machine, main door, lock and alarm
When I’m away from home I can see at a glance if I’ve left something on.
5 Likes
Eh. You do you. I prefer the Auto entities card.
I am may be missing smth - but since when template sensors (not created in UI) are shown in Settings → Helpers? Is it since 2024.8 or since the 1st addition of possibility to create template sensors in “Helpers”?
Hi. It seems that this is a known issue, Alexa Media Player (AMP) not working with HA 2024.08.
The folks that manage the AMP project seem to be working to address this. See this linked issue.
It seems that AMP version 4.12.7 (avaialble via HACS) may fix this issue, although you may have to delete and re-add the AMP integration.
Posting this as an FYI, I have not updated to 2024.08 myself, because of this issue.
Hi. Not showing in 2024.7.4, so must be new with 2024.8 …
Interesting.
Then an obvious question - WTH?
Are all template sensors (even made in yaml) considered as helpers now?
Just noticed - history_stats sensors (made in yaml) are also helpers now))
What is a “helper” then?
Why “ping” sensor is not a “helper”? (answering to myself - “because it is not officially considered as a helper”)
What is a point to overload tables by unrelated data?
I just updated to 4.12.7 and it’s working again.
1 Like
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.
8 Likes
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?