Just noticed that there is no any name displayed for a input_boolean helper:
It is only displayed for helpers:
– created in UI;
– or created in yaml but with “friendly_name” defined:
Hi,
I tried to find changelog entry that could explain behavior I’m noticing after upgrading from 2023.3.5 to 2023.3.6.
I receive sensor values over MQTT from Tasmota device. HA is acting as MQTT broker with mosquitto integration.
Sensor values are received with 10 second interval and I can confirm this with MQTT explorer on broker.
Until version 2023.3.5 sensor values were stored in HA database every 10 seconds, even value didn’t change.
After upgrading to 2023.3.6 sensor value is stored in database only if it changes.
What change caused this behavior and could this be fixed so that all values received would be stored in database?
This can be seen also on HA sensor view. It now says for example “1 minute ago” rather than refreshing every 10 seconds as before.
Hi, is there a way how to revert “dialogs” to previous version? I find them totally confusing and counterproductive. For example when I want to change light color temperature I have to open the light and then click on the color palette and then I can change the color. It is much slower approach then with previous versions.
The same with history - I liked seein the history of the switch right on the page when I opened it. Now I have to open the switch and search tiny button “history” and here it is.
Slower and less transparent.
I would understand this to be available as na option primary for wear (watches) but it makes no sense for desktop or mobile. I don’t think I am the only one that would appreciate a switch between old and new style. Pretty please? 
9 Likes
THIS^
I find the new dialog really awful.
The text based tabs were perfect as they were and easy to navigate from one to another, now i have to click back to go from one to the other.
Also why would i need that big of a slider? I really liked the old thin horizontal slider.
Also if having an RGB lamp i have to go into a separate menu to change color… what a god-awful decision to make 
Also for my new ikea air cleaner i cant select the builtin presets as i could before, which just completely throws me off. now theres a standby icon, what does that do? i really dislike having icons as a complete substitute for text.
sure icons are nice to have… as a compliment for the text for easier recognition, but icons dont tell you exactly what the do.
So please give us, that want the old UI back, the option to actually use it 
6 Likes
yes, the new more-info seems like regression. You press a switch in an entity card only to show the same switch larger. Now there is a second click involved to get the actual useful information, namely the history. I can’t seem to find an easy way to make the history view the default one.
3 Likes
Has anyone found a way to revert back to the old, more useful light dialogues? Really sick of the bad usability, additional clicks with the new light dialogs 
You would need to go back and restore a old back up or more. Hopefully you kept some, along with notes
Well, that would not be a sustainable solution, as it would mean you can never update HA again. I was rather hoping there would be something more along the line of a mod, plugin, integration etc.
1 Like
Samaba add-on will allow you to access the backup directory to offload backups. You can add notations to the file descriptor then. It is what I use. Just in case the EMAC or the SSD start having issues.
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.