It’s only disabled if you have those settings in config yaml. For new users this is part of the onboarding and it’s all about a user not being required to touch yaml or a text editor to get started. Experienced users can still use yaml if they prefer. It’s a choice. They want to make HA more accessible to ‘normal’ people
Yep, I agree, sounds like it will certainly help people who don’t want to dig around in yaml. It just seems that it should just make the new panels disappear if they are already set.
6 Likes
I agree with @a3a and @rpress , Even if this is geared to new users, once the info is entered either thru the panels or thru ,yaml, the panels need to move out of the way. The items you need are at the bottom of the page, not the top…
5 Likes
First thing I did once upgrading was removing that part from my configuration.yaml and then configuring in the browser. Why wouldn’t you? I think it looks great and shows how far Home Assistant has come.
The best way to make suggestions is to be positive. This is especially true with open source products and things that are more little annoyances than actual bugs.
4 Likes
I did as well and I have been using HA for almost 2 years now. I like to try the new features. I agree it looks great.
1 Like
I do thank you for bringing to my attention that it is possible to enable those panels without entirely losing manually built configuration. – This ability was not mentioned in the release notes nor the release blog, although I see that earlier today someone mentioned it in the random-grab-bag release thread.
If you want to keep your configuration.yaml while also using the new Configuration > General > Name and Configuration > General > Core forms, then you must remove the following keys from the homeassistant section of your configuration.yaml:
homeassistant:
# Leave commented out to enable name config panel (ha-config-name-form)
# name: Home
# Leave all the following commented out to enable location config panel (ha-config-core-form)
# latitude: !secret home_latitude
# longitude: !secret home_longitude
# elevation: !secret home_elevation
# unit_system: !secret home_unit_system
# time_zone: !secret home_time_zone
Then restart HA and manually select the values that you previously had configured, unfortunately you will need to use meters regardless of the measurement unit chosen and you will have to manually zoom out about 20 steps to see something other than the western Atlantic Ocean, then drag the pin to an approximate location rather than entering precise lat / lon coordinates.
1 Like
Loving this new release apart from this layout. When editing yaml files and needing to restart a lot, it’s a bit of a pain to scroll down, config check, restart. As said above, once this is all set, does it need to be visible, how often will it be changed really ?
I could do a button to restart but use the config check button first and make sure it says OK, is there a way to replicate the “OK”, if so, maybe I can create a card for checking and restarting ?
1 Like
Yes homeassistant.check_config and homeassistant.restart service calls
Thanks, is there a way to get a “configuration valid” message/event ?
There is some discussion around this on the Discord as well, so it sounds like we could see some changes to this as it evolves. Remember that this is the first release of this functionality and it’s still being fine-tuned. I’d agree that a change would be good, as not only is it not useful to see these cards if you’re configuring these settings in configuration.yaml already, but once you’ve set your system up for the first time as well, these aren’t settings that are going to change that often. It probably makes sense to minimize them or move them to the the bottom.
1 Like
Sure, but since my house isn’t moving at all but my configuration.yaml is changing quite often it is more efficient that the check config button is more prominent.
I hope this sound not offending to anybody but i am no native english speaker and can’t write so eloquently, since i use google translator to write this text.
4 Likes
I also apologize if I rubbed anyone the wrong way.
Really I love this software and the community. I just started asking a question about how I could avoid a problem that I have and I should not have written anything in ALL CAPS.
I am a professional software architect and developer and I have people criticize my stuff on a daily basis. I know how hard it is to make everyone happy and develop UI/UX that satisfies newbs and experts simultaneously, and I’m grateful that we have available to us such a powerful tool for home automation.
2 Likes
Since you are a software dev you could try and modify it yourself?
As you probably know, jet engine mechanics still drop their car off at the dealer to get the spark plugs changed and chefs go to restaurants. There is a pretty deep learning curve to getting in the guts of HA and even then getting the core team to accept a Pull Request is not guaranteed.
I do have a few (very small) contributions to the code in HASSIO but I have not taken on any front-end coding yet.
Making a core change to a project like Home Assistant is a multi-week commitment. Asking a question is a multi-hour effort. It makes sense to confirm that the thing you want to change is worth changing before going off on a quest.
- Ask if something is possible
- Find out if other people have the same concern
- Learn if the core team is already working on a solution
- Figure out if a solution is better than living with it – and make sure not too many other people will hate the change
- Climb the learning curve
- Do the work (often the fastest part of the whole process!!)
- Write tests and make sure it doesn’t break anything else
- Integrate with other work-in-progress
- Pull Request for the core team to review (might require several days of back-and-forth)
- Get lucky, PR accepted, now wait for the next release
Every step along the way can have loops and backtracking.
Doesn’t look like there is a way via the service call. It writes errors to the log if there are failures but doesn’t appear to return anything if it’s successful. Certainly, it would be safe to assume that if nothing returns for a certain amount of time, that the check passed.
That being said, I found you can also trigger a config check by sending an authenticated POST request to the /api/config/core/check_config endpoint, and you’ll get returned data to indicate whether the config is valid or not.
Valid configuration returns:
{
"errors": null,
"result": "valid"
}
Invalid configuration example:
{
"errors": "Integration not found: frontend:",
"result": "invalid"
}
You could leverage this with a RESTful Sensor, but the caveats there are:
- It will update on a regular interval, even though it really only needs to update if the configuration is changed.
- You’d need a way to force an update when you change the configuration.
So in terms of trying to use this request purely through Home Assistant, you are a bit constricted. However, I like the potential of this idea, so I’m going to try and put something a little more robust together using AppDaemon.
1 Like
I haven’t updated to v94 yet but I can agree with those who don’t like that the config check button is at the bottom.
If the powers that be want to keep the initial setup boxes at the top (silly IMHO, since it’s usually a one and done configuration, but whatever) then the least they could do is keep the current functionality of the “Configuration and Server Control” exactly as it is and just move it to a new selectable page called “Configuration Validation and Server Control” and leave the new stuff under the “General” page.
the vast majority of people will use the set up page one time. the config checker gets used almost daily by a whole bunch of people. It doesn’t make sense to make it harder to access.
7 Likes
Based on your last comment I guess this is tongue in cheek. But if not I think it’s good to discuss things before spending a bunch of time changing code. I’ll not sure why there is opposition to this discussion.
I’m getting the same disabled card appear at the top of my config also, rather annoying.
Surely if it’s disabled it would be best just to hide the DOM elements here?
Unless there’s something I’m missing?
If they are so distressing for you, you could create a lovelace card to call the service to restart or check config etc.
@DavidFW1960 can you explain how to do this please?
If you store the parameters in plain text in your config, that’s OK, but if you use ‘secrets’ you can’t.
And while you are at it explain why we should be forced to resort to this when a perfectly functional built in solution already exists but has been messed around with to make it less functionally convenient.
Sounds a lot like the old Z Wave Control Panel fiasco…