I like the new dialogs, even on the pc. It gives a cleaner look and is more intuitive to use.
The only thing i would like to be changed, is to swap the locations of “Settings” and “Device info” . Reason: Home Assistent is in transition phase towards a device-focussed approach. On average, “Device info” will give end-users more often what they are looking for (entity settings is usually not what you’re looking for as an end-user).
1 Like
Please, how did you managed to replace the default graph with history-explorer-card in the more info dialog?
1 Like
It’s in the History Explorer Card docs: https://github.com/alexarch21/history-explorer-card#overriding-the-ha-more-info-history
2 Likes
To be fair, I kinda still need to write that part of the docs 
3 Likes
Just wanted to say that as a user since v 0.2 something, I am always amazed at the continued improvement and stability of HA. I think the development team continues to do an amazing job!
9 Likes
Weird, I restarted HA and I had to do this again (change decimals back and forth) for W instead of kW to reappear.
It’s been 78 minutes already, and database upgrade is still not complete.
mariadb process taking 100% CPU time.
I had run mysqldump earlier and gave me a dump of 669166179 so it’s not that big of a database.
mariadb is running on a quad-core 3.4GHz Intel. How long is this expected to take ?
May be purge recorder , that would remove lot of entries ?
It depends on how large your database is.
It’s been 6h now, and mariadb is still using 100% cpu and python3 on the RPI is at 120%…
Would purging entries now, while it’s still doing the database upgrade, be problematic?
There’s most likely a lock on the db so I would assume a purge would do nothing until the process is complete.
Check your MySQL/MariaDB processlist to see what’s going on. For the default settings it shouldn’t take more than a few minutes to do the latest migration unless you have a massive amount of entities
1 Like
I have a history statistics sensor that stopped resetting at midnight after the upgrade. I just resolved the issue with another reboot, but am not sure why it happened. It may have been related to Make all history stats tests async by balloob · Pull Request #87973 but if it is, I can’t tell why.
sensor:
- platform: history_stats
name: Boiler Runtime Today
entity_id: switch.boiler
state: "on"
type: time
start: "{{ now().replace(hour=0, minute=0, second=0) }}"
end: "{{ now() }}"
Also, the update sensors changed from “off” to “unavailable”. This was not resolved with the reboot, but this could have been intentional (“update unavailable” makes sense). However, I didn’t see that announced in the blog, nor can I find it in any of the release notes.
Apart from understanding why this happened, I’m also curious whether it’s possible to fix the data for the boiler runtime sensor.
It’s definitely not related to that PR. Those are the unit tests for the history stats integration. The integration itself did not change, just the tests we perform on the integration (to make sure it works).
Did you have any errors in your logs?
I see a lot of references to a database upgrade. I had no issue, but am puzzled that there seems to be no reference to a database update in the release notes. Did I miss it? Does it relate to mysql/mariadb only?
Not here. History working fine.
Well, it’s been over 13h now, and it is still in the same state.
I had read about issues for people using mariadb, and upgrade stalling.
SHOW FULL PROCESSLIST
only shows a single hass related entry in running state:
| 3380 | hass_user | 192.168.10.5:38516 | hass_db | Query | 0 | Searching rows for update | UPDATE statistics set start_ts=IF(start is NULL,0,UNIX_TIMESTAMP(start) ), created_ts=UNIX_TIMESTAMP(created), last_reset_ts=UNIX_TIMESTAMP(last_reset) where start_ts is NULL LIMIT 250000 | 0.000 |
I guess I can assume that it’s stuffed now.
