And you know how hard it was to implement these similar things?
That’s not my mood, that’s my attitude. People come here everyday and demand stuff to be imlemented and it’s mostly accompanied with “shouldn’t be that hard?”, but have no programming background, so just assuming.
And in the end of the day this is an open source product, people sacrifice their free time to implement stuff and don’t expect anything in return.
Relax, I was just voting this up because I would like that function.
I’m not telling you to do this today before bedtime, Definitely not demanding something
I’m programmer/architect, so by your definition I’m the one who should have rights to say it’s not hard. So I say so.
Reloading entities, automations etc without need of HA restart had been also hard, almost impossible to develop. until one guy did it in day or two.
It’s all about good will. Especially in project like HA where there are no bussiness priorities, pressure from stake holders etc.
I can bet that in most cases it’s not done yet because main players are just accustomed to current state so they see no profits to them. So why should they care about that…
The problem is that there is no role who says: let’s do it first because it may give lot of satisfaction with low investment. Or let’s do that because nowadays it looks like serious dept while it’s “cheap” to improve.
Instead it seems that HA consists of pile of random features mostly giving impression those are in alpha stage.
Fine. But It’s their choice, isn’t it?
Thus open source argument isn’t enough to treat their work anyhow special. devs must count on good words as well as criticism or demands once they offer their work to public. And it’s up to them what publicity they get.
The fact they offer their work for free or as open source (those things don’t imply each other) cannot change that.
It is hard right now otherwise I probably would’ve done it already lol. It’s not that challenging to make an integration UI-configurable. There’s a scaffold to set it up, instructions here and plenty of examples to look at.
The problem is you’re limited to what data entry flow can support unless you want to actually wade into the front-end code. And that’s challenging because currently its really only able to understand simple schemas made of scalars. It doesn’t accept arrays at all, it can’t display a list in the screen with add/delete row buttons. If you want to collect a list of inputs you’d have to do something pretty hacky like show the same screen in a loop until the user checks a checkbox that says “I’m done”. Or keep showing 10 input boxes at a time per screen until the user submits without filling up all 10. Not a great experience either way.
Is that unsolvable? No. But it involves going much deeper into the core of how the UI-engine works then I was comfortable with. I’m sure its on someone’s list. I’m hopeful someone with more UI-expertise can close that gap around arrays as I think it would make a large number of integrations UI-configurable, including groups.
Could also build custom UI for groups to allow easy list-based data entry but that also is much harder and requires more frontend expertise then I have personally. If others want to try it would certainly be a great to have a group as an option in the helpers menu!
Back to the topic, what real advantage does anyone think doing this in the UI would really achieve. Doing it yaml is particularly easy.
Well I mean when I submitted it I think it was a little debatable whether it would be an improvement or not. Now though in the current product I definitely want this UI for building groups:
Picking from a dropdown is a lot easier then copying and pasting IDs from developer tools into YAML. Even with the copy button.
+1 for more GUI. Groups included.
I agree with you about the yaml route being easy (and what I prefer). However, I can also see where there should be a UI to modify groups as many users don’t want to deal with editing yaml, reloading groups, etc). Since the big push to “UI all the things” started, not having a groups editor seems, well, odd.
This exact topic popped into my mind today and I too wondered why this had not been implemented yet.
Not sure how many of you listen to the HA podcast, but when Paulus is on, he’s often talking about the move away from yaml, and making things more accessible via the UI. Yaml will always be there for the more advanced users that want it.
Creating groups just seems like a fundamental part of all home automation interfaces/apps, whether it be HomeKit, Philips Hue, etc.
I don’t pretend to understand the complexity of making this work, but if the inevitable goal is to make things more accessible and user friendly, then a feature like this seems pretty logical.
It seems to me with the new “Helpers” section under configuration where input_boolean, input_datetime can be set maybe this is the area in the UI it could appear and thus be unconstrained by the config flow issues mentioned above.
Please can someone get this integrated in the UI, it would be SO much easier and another barrier gone for those put off by yaml. Here is another feature request for it Groups via UI - #2 by barneyhawes
Groups have been added to the UI in 2022.4
I don’t consider this solved. The UI is incomplete, e.g. I cannot configure groups for persons or groups for input_booleans. Any plans on this?
You can still type (as your post proves) so you can still do those via yaml.
But that doesn’t make them UI configurable…
No but there is a route to do what @kongo09 wants, nothing is broken. But I guess moaners will moan.
Not really. The only way to do what @kongo09 is asking for is to do it using an old-style group and as it says:
We don’t recommend using these old-style groups anymore. They are still supported, but we recommend using the groups as described above.
And besides, this topic is “why the heck aren’t groups UI-configurable?” Even at the time of its posting you could make groups in YAML. It’s 156 votes were specifically about people that wanted to be able to do it without YAML.
That being said I think this is solved. The reason is because there were two types of groups:
Group type #2 isn’t really in a sustainable place. It was more created when groups were needed to organize your UI and that’s not how the UI works anymore. So Frenck made every instance of #1 UI-configurable and even added a few to lessen the need for group type #2 and then marked those as not recommended.
To me that’s a pretty solid solve. What should happen now is feature requests should be opened for the types of entities you can’t make groups for (ex. person and input_boolean) so people can vote on those. In fact the two mentioned already have FRs: input boolean and person.
Thanks for pointing to the FR
I’m not moaning but stating that from a user perspective this is not done. No user understands the difference between domain specific groups and generic groups. Let’s streamline this.
