I LOVE the new dialogs for lights, switches and siren entities. Is there a way to use them as the card on the dashboard instead of a dialog popup? They do exactly what I want, but are 1 layer deep for my taste. Having them as a card on my room view is what I need. They don’t require any setup, yet pull the features of the device straight in. Here is an mockup of how I currently have my kitchen, vs how I’d like to have it:
4 Likes
Regarding Sensor display precision in 2023.3: Dialogs! - Home Assistant
I have (template) sensors which don’t have a unique_id: set yet, so sensor display precision can not be set unfortunately (it’s a GUI exclusive thing, right). What will happen once I set one for those with the history of those sensors?
I did this in the past for command line sensors and if I remember correctly, I lost the history for those sensors as states or statistics could not be matched anymore (entity “sensor.abc” without “unique_id” seems HA internally to be NOT the same like entity “sensor.abc” with “unique_id” set).
Can someone please precisely help on this? I really don’t want to ruin my long-term sensors (’ history) for being able to set the sensor value precision…
Whenvever you add a unique_id to the system, do not reload yaml. Restart HA. This will keep everything as-is, but now you can edit it in the UI.
Reloading yaml does not ‘unload’ old entities, and because they don’t have a unique_id, HA doesn’t know that they are being reloaded. Then, HA creates a new entry (for the UI), and it gives it an entity_id. But that entity_id is taken already by your old entity because it still exists. You’ll end up with an _2. Then when you restart, it’s still on _2. Anyways, you avoid this by restarting, not reloading. This is only a byproduct of entities that do not have a unique_id in yaml. If you have a unique_id in yaml, reloading will not create duplicate entities.
4 Likes
Ah, really really great to know - thank you very much @petro!.
I really wish I would’ve known this many months earlier (as I’ve lost a lot of history for many entities already) or even better, HA would not behave like that 
I’ll trust you and give this a try, right for my remaining important entities.
→ Edit: Everything worked smoothly. Great! 
-
But to be even more precise:
Whenvever you add a unique_id to the system for an already existing entity, do not reload yaml […]
Because when creating a new template sensor it really just doesn’t matter as there’s no history.
-
Unfortunately I have one entity created by the Folder integration (Folder - Home Assistant) which seems to not allow adding a
unique_idparameter. Not even using customize.yaml… no idea how to fix this (well, should be fixed in the integration, but: how to work around this).
Another (rather strange) thing I discovered after updating, running the recorder repack (no purge!) service once, is:
Without changing any settings, the recorder size went from 3.1 GB prior the update (2023.2 before) to 3.7 GB right after the update (okay as new columns were added during the schema update from 33 to 35 and those need space) to now 2.2 GB right after starting a partial backup containing HA (at 2 o’clock).
What really makes me feel uncomfortable is the big drop from 3.7 to 2.2 GB.
- no entities have been deleted
- the
purge_keep_dayssetting is unchanged, so are all the other recorder specific settings
How can this huge drop be possible? I’m really wondering because the database optimizations will take place in HA Core 2023.4 release (2023.4: Custom template macros, and many more new entity dialogs! - Home Assistant) which is my next update.
Edit: During backup “home-assistant_v2.db-wal” shall be set to 0 - otherwise one would get a corrupt database backup. Exactly that happened during backup so all the database adaptions have been in the *.db-wal file and unloaded (written to “home-assistant_v2.db”) once the backup started.
Over the past year, there have been multiple database optimizations that will literally cut your db to around 30% of it’s size prior to the optimizations.
1 Like
That’s what I read too. But as mentioned according to the release notes the “big thing” in terms of that happens in 2023.4 (database scalability section).
So I’m wondering if some magic here might have already happened in 2023.3 (without further notice or communication) or if I suffer a data loss. At least looking
- at the history of few entities as well as the energy dashboard and
- the HA log file (no entry regarding recorder/database after the migration message from right after the update)
everything seems to be okay. Not sure how to “finally check” this to regain some confidence. My experience from the past is: the longer you wait after data loss to restore a backup, the bigger the timeslot (backup snapshot until restore snapshot) you don’t have data - that’s why I’m initially wondering and asking at all.
Maybe I’m gonna create SQL sensors with select count(id) from statistics and select count(state_id) from states for the future just to have a rough metric if something bad might have happened (outside of recorder purge runs).
By the way: any last idea on this?
Maybe I should get rid of the folder integration and grab the size another way (I already do that for other folders like backup and share etc.)…
There has been database optimizations in almost every version of HA over the past year, ending around 2023.5. I’m not sure how else to say that to you. Chances are, your db was optimized.
most yaml integrations do not support a unique_id. That doesn’t mean you should remove the integration.
Yes seems I need to just live with that as long as no side effects come up (missing data). Anyway, I checked Full Changelog for Home Assistant Core 2023.3 - Home Assistant again for recorder / database specific changes and could find nothing indicating an optimization in terms of amount / size etc.
Well, if I want to finally be able to set the sensor display precision, I certainly should - because I don’t have the ability to create a PR for that integration to add a UUID right out of the box, which would be the actual fix.
In my case my Heat Pump is my primary heat source and Aux is Natural Gas. I cannot run both as there would be damage to the system. I do have the Ecobee to run Aux when the outdoor temperature is below -10°C as the efficiency is too low.
That said, my Time of Use billing for electricity is crazy from 7am to 11am and again from 5pm to 7pm Monday to Friday. I have HA set up to switch from HP to Aux a) when it’s high billing rate and below 0°C. While I don’t have the science to back up my beliefs, I feel that below freezing and during a high rate period, my Natural Gas would be cheaper to run.