This is such a hard thing. I mean, while in absolute pixel terms it doesn’t take up more space, there is an additional row which creates a perception that it is — it’s definitely taking up more rows (another measure of “space”). Then there’s the per badge space issue that you’ve also noted. Good UX and UI design take all of those visual illusions and perceptions into account.
Online communication is hard. I don’t think there was any malice, but I can see how it would’ve upset you (and that’s valid).
I too use card-mod for many things, including on the old badges. Unfortunately, that’s a risk we’re all taking. We really cannot expect the core and frontend teams to accommodate that.
Regarding an “opinions exchange between Users & Devs”.
See, I am not using badges & do not care about them. But this ultimate replacing of a badge by Devs w/o providing users an option to choose between “old” & “new” is a bad trend. And do not tell me about that mentioned hack with “hui-badge-bla-bla” which is not a 100% replacement - hence can be used in some cases only.
It was claimed here like “we are listening etc etc”.
Unfortunately, what I am observing sometimes in Github - is a bit different thing:
User reports smth “I see this behaviour”. Politely.
Dev answers smth like “this is by a design”.
User asks smth like “Why?”. Politely.
Usually an answer is a polite explanation, or a link to Docs, or proposal to move to “Discussions”. But sometimes it could be just IGNORING. What is it - “Devs are too busy & forgot to respond”, “We are making a soft here, do not disturb us”, or what?
Not to mention situations with obvious bugs which are just stalling and need a constant “un-stale” attention from users, like my recent example with “Traccar server” integration which stopped working properly since 2024.5.
There should be a balance between “I am making a soft” & “I am communicating with users”.
Btw, If ignoring occurs after step 1 (see above) - and more users starts participating - this may cause (and does cause) “heating up”, no good output.
Seems that displaying “last-changed” was broken in other cards as well, like Entities:
Glance:
more-info for covers (my favourite - countdown “in xxx sec”, then “xxx sec ago”):
Sorry for posting it here - but I do not recall seeing this before 2024.8.
Update: could be my fault unrelated to HA, related to my system time; checking myself…
Well, system time of both server & client are rather synchronized with NTP - but anyway, “relative_time” should work on a server side only, so client should not affect any glitches. And yes - seems to be unrelated to 2024.8.
Update: got explanations on Github: last-changed is calculated on a client; a possible time difference could cause a countdown. Not a HA issue.
Yes. Multiple times. Restarts and reloads as well.
I noticed 2 things since the upgrade to 2024.8.
it is noticeable slower to load. It takes ‘ages’ to get some of the integration loaded in. Not sure that it has to do with the HACS modification.
I lost my device classifications and I can’t find the reason for it. I rolled back to and earlier version of 2024.8. It restored itself but eventually it went wrong again. So I think there is something buggy in 2024.8.
Thanks for the hint. I checked the thread. It seems different for me. I have integrations which show up in yaml and load very slow. Also graphs load very slow. Difficult to find the root cause of this all. I rolled back to 2024.8.1. which seems to do better.
Following this update my History tab is just spinning. No history is retrievable. No errors in the HA log. All was well in 2024.8.2. Note the iOS Companion App displays history correctly. Using Safari on iOS, Google on W11.
For the first time since becoming an HA user 3 years ago I’ve had to restore a previous month’s release. I installed 2024.8.3 and encountered an unstable setup with memory climbing from around 30% to 80% over about an hour. Rebooting didn’t fix. Tried profiler but got a “Failed to perform the action profiler.start_log_objects. undefined” message so couldn’t diagnose the memory problem. Core and Supervisor logs showed nothing untoward. History graphs loading very slowly or not at all. Using HAOS on a 4 GB rPi5 with an SSD, previously very stable. Have restored 2024.7.4 and everything back to normal. I have a suspicion something went wrong with the database but I don’t know how to interrogate it. Not sure what to do now, apart from holding off updating.
I also had to restore a backup from 2024.8.3 back to 2024.8.2. The only issue I encountered was that the history wasn’t loading. But that alone was enough for me to revert to the previous release, 2024.8.2, which has been running stable.
I also restored a backup from 2024.8.3 back to 2024.8.2. The issue I encountered was that all the values showing in my Dashboard were missing their indicated type. So 100% showed only 100 and things like my leak sensors showed as off instead of dry or wet as they have always displayed. Very strange… Most were on Entity cards…
I experience similar problem. I can’t put my finger on it but everything seems to be more sluggish. Not very responsive as normal. I thought I lost my device classification. I didn’t but it took forever to load them somehow. For sure there is something weird. I have also rolled back to 2024.7.3. Things are normal.
I wish I could revert, since updating to the latest my Pi keeps rebooting, I cant get to logs or anything meaningful. Once Home Assistant has started you click on anything and get either a blank page or page unavailable message.
I can sometimes get into the backups but when I try to restore it says cannot restore while its rebooting.
