Then don’t assume how much programming it will involve…
Almost everything is possible, but someone needs to do the work. It looks like it is not that easy to implement it, otherwise I’m sure someone would have picked it up already as it has quite some votes.
Didn’t know “Thinking” was a crime,.,
To me it doesn’t look that hard if similar things already exist.
I’ll go back to my corner and hide from your mood bro.
It also contained a question mark, that a forbidden character, # “asking something”
It’s harder then you think. Automations and Scripts are the wrong example to pull from. Those were some of the first things to be made UI-configurable and UI was specifically built for the automation and script editor. That definitely took a lot of work though, iterations over many releases.
Now there’s a much simpler way to make an integration UI-configurable using config flows. These aren’t trivally easy to do but there’s a clear pattern. However unfortunately there’s a big gap that that would get in the way: They only support scalar config values currently. I can’t ask for a config value and say its type is [string] and have it present a list of input boxes with a “+” button. Think about all the integrations you’ve configured via the UI, this is why you never see this currently.
Considering a group is literally just a list of entity IDs, that makes this tricky. You could do it with config flows but it wouldn’t be a great user experience. You’d have to collect a comma-separated list of entity IDs in an input box. Or have two screens where the second one just has a single input box. Not great options.
If someone adds support for a config value of type [string] then it does become pretty easy. And I’m sure that would be a valuable addition to config flows for many integrations. But I know that was out of my depth when I looked into it. Hopefully someone else can figure it out.
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…
