anyone else experiencing sudden view refreshes/reloads at all? At first thought it to be my instance running the dev nightly, but kept quiet because of ‘being on the bleeding edge’. Now my 2 other instances run the release versions and also exhibit this, I might not be alone?
open the browser, after some time of being away, browse a bit and whoops, a full page refresh happens.
2022.4.1 is out. Reading the release notes it seems that it is fixed now. I didn’t try it yet though.
Quite a few ZHA fixes, looking forward to test.
Yeah. 2022.4.1 release notes can be found here https://github.com/home-assistant/core/releases/tag/2022.4.1
I do use these cards but then again I don’t want to have my UI littered with lots of radio fav buttons. Thanks for the suggestion though.
I like the improved updating panel though, with a Skip button and a progress bar. Very nice. I suggest placing it persistently on the bottom or something, so you can see it even if you navigate away from the window.
Fix confirmed. Just updated to 2022.4.1 and problem is gone.
In fact it would not.
Updating docs and new default-paths to dashboard should be a given due to the announcement.
Leaving old routes in place is possible to, just have a deprecation notice in logs and give people time to adapt. Home Assistant has been doing this for many other features already.
Due to the fact that the placement of the “lovelace”-string in the path is strictly specified, having an alterantive alias route is easy enough to implement.
This change feels have baked and instead of easing the transition from “lovelace” to “dashboards” it makes it harder.
Ever tried to google lovelace?
For me google suggests a movie called “lovelace” from 2013.
Searching for a single word is never getting you what you actually want.
Searching for “matter iot” oder “matter smart home” in fact will result in what you are looking for.
In case of “Home Assistant Dashboard” or “Home Assistant Lovelace” google will be more precice with the later. While the first one only gives a vague idea of what home assistant can do.
Imo it is more benefitial to educate your users to understand that the dashboard engine is called lovelace instead of creating a wierd state of documentation, official wording and wording used in the community and understood by a search engine.
Users who are not willing to learn a tool will not get any benefit of it. So while it may straightens the introduction into HA it complicates the learning process.
In general i do think that Home Assistant is focusing to much on easing the use.
Having plain text files (yaml) for configuration gives users a widely adopted format of interacting with configuration. Having password auto-rotate, generating new configuration by script, etc. is lost by moving everything to front-end configuration and deprecating yaml files.
i do not agree with this change either but this is the way we are going…
First of all; Thanks for this release with a lot of good improvements!.
One of them is the step to integrate groups in the UI. By using groups to define all lights in a room and all rooms on a floor and all floors in a house, you can easely change a light without modifying all automations. Personally, I also created ‘season’ groups wher I define all lights or switches that play a role for christmas lightning for example.
The way it is implemented however seems not so flexible and clear as I hoped for:
Yeah I know, there is the switch as X, that could be used to make it all lights and then group them. That meansI have to create all my 34 light switches as switch as X entities and having the same amount of double entities and change all my automations for that. That doesn’t make me feel excited, it doesn’t make things beter organised and manageble. Thinking of that; why can’t we ‘configure’ all entities at the entity level to represent as X (and even add some templated attributes to it? That would enable us to overcome some brand specific habits…
Also, I found it not inuitive to define groups as helpers. Groups are combined entities and I expected it at the entities tab. If you think about it, helpers are all entities, not automations, so even moving helpers to entities would be something to consider in my opinion.
Im not sure what you mean by “focusing to much on easing the use” , can’t be a bad thing, in my opinion, however, as this imply that more and more get into the “core” ( As per user/feature request ), it ofcause lead to that a-lot “configuration” are loaded, that many users don’t ever will use ( Like the “Mastodont” Windows ) , and that could kill the low-print HA-installation … so question is, who’s to decide what’s in the core, vs what’s in configuration.yaml, and additional custom yamls ?
Same here, I also thought there would be more to see / set now. Or is it only available in service calls?
Turn the light on. Then look again.
By your argumentation:
A yaml parser is already on board and will probalby never leave. And reading an object with a certain schema to create a component has to be done either way.
So going without a GUI to configure basic components is the more lightweight way. In the past it was the only way. The feature has already been implemented and has been tested by many users.
Deprecating yaml-configs in favor of a GUI is more complicated and more work for the developers.
But by new users it is seen as more user-friendly as homeassistant is giving a direct feedback on wether something is configured corretly or not.
By all means direct feedback can be done with yaml files to and even without an addition to the core eg. by adding a schema to JSON Schema Store and using a yaml plugin in your editor.
This is the way many dev-plugins do it.
Anyway: there has, for the time i can remember, always been a button to check the configuration.
For me, who has been with Home Assistant from the very begining and is a working as a DevOps Engineer, this was a magnificent way to do configuration.
I can write template files which will be rendered before each start of homeassistant. I can auto rotate passwords in my password manager of choice export them and have a script but them in my secrets.yaml. Once i added e.g. a new light with my specific naming schema ( e.g. light.livingroom_diningtable_center ) it is automatically added to my lightgroups for livingroom and dining table. And futher was recognized by my autoamtions etc.
(Thank goodness, that groups can still be done by yaml-files).
On the other hand: i lately rotated my passwords, my script automatically inserted my new password into the secrets.yaml which is nolonger referenced by e.g. the tado-component so my whole heating did no longer work (well it did, but not from HASS-side). In the UI is no option to set a new password so i had to delete the component and re-add it and thus had to rename all new devices and entities to their old names.
So while adding Configuration via GUI is more newcommer-friendly it overall misses the point of homeautomation and lacks features which are inherently available when using yaml files.
Back to your statement, that “focusing to much on ease of use” can indeed be a bad thing if essential features like manually setting a new password fall behind, espacially when automated password rotation was possible before.
Yes i do know how it works, but your argument falls on your “example” as i don’t have "auto-rotation of password, and never will, so it’s a non-essential use-case for me, on the other hand there might show up use-case where i would Love to have the option to make my own configurations( most likely already some case, but they really don’t pop-up in my head now ) as im most sure that you have requested / wanted something “available/easy” to do in the GUI … or You prefer not to use UI at all ? … my point is what you think/like/want is not what i think/like/want, and from what i know there are about 100.000 opinions out there , i wonder how many of these use “auto-rotate password” ? ( PS: i don’t even know what it’s for) 
No, they are not, helpers can be managed in YAML or via the UI. The UI has been newly added, but YAML remains an option.
Because old-style (generic) groups work for some things, but don’t know anything about e.g., light or covers. For example, a cover group will take all its member covers into account and handle all cover features and is able to reflect the “position” state of all those covers. The groups you are referring too, can’t do that. See our documentation on groups for more information on the differences.
Sure. You can put a light group in a light group, that works.
Oh i’m sure auto-rotating passwords i one of the most unthought of use-cases out there. And the average jo out there won’t think of it. But in coorporate land out there it is one of the easiest ways to increase cybersecurity.
For clarification:
I hope we agree that we should never reuse a password for a online service and all services used should at all times have a differnt password.
Now image that i am so terrified that i will change my password on all of my servces every few months.
This is what i actually do, not manually but automated.
If you ask me for any of my passwords: i only can tell you one and thats the one for my password manager. For every other password: i don’t know it, i have never typed it and every singe one of them is way too long for me to remember it.
Btw. did you know that Netflix only allows your password to be 60 chars long?
But the fact that this out-of-the-wild use-case can be done with stupid lame yamls should be proof enough that yamls allow for so much usability and flexability that they should stay and never leave.
This is what user-friendly is.
And this is not only my personal optinion. Take a look at the probably most productive Softwares out there: Kuberentes, Ansible, AWS Cloudformation and many more use yaml files for configuration, automation, etc.
As i tried to clarify: while it is not perticular newcommer-friendly it is THE WAY most of the world does it.
Home Assistant is a tool to allow Users to connect different vendors, ecosystems etc.
If one is not willing to learn how to use a tool then this person is a fool.
And as a teacher of mine once said: A fool with a tool remains a fool.
I do agree that Home Assistant should become more newcommer friendly as it is by now to only way to grow it’s userbase and thus get funding. But leaving behind a powerfull configuration possibility and therefore forgetting some of it veterans is plain wrong.
In the beginning i critiqued the wording change from “lovelace” to “dashboard”. This boils down to that.
Yes “dashboard” is more newcommer-friendly but it does not give a hint on how to configure them.
“lovelace” hower, is the more precice term in google-searches and will give you more precice answers.
So when you are acutlly working with it, which everyone but a few will, it will be more benefitial to adopt to the term lovelace.
I tried to ‘Hide’ some unavailable entities, but they still show up in the UI.
refresh your page. this is probably a caching thing.
I guess I like groups going into the UI, but after spending a couple of hours manually transferring all my light groups over with motion groups and utility meter still to go which will be another couple of hours I kind of wishing there was an automated way of doing it.
On the bright side, it’s giving me an opportunity to clean up my groups and find lots of lights that have long gone but still being referenced I’m also liking the Hide entities and Switch as X enhancements.
Overall a very good release, thx!