Paper control UI would be perfect – if it would just use top level groups instead of locations for tabs…
Some way of drilling down into item group hierarchies would be nice.
Is there something like this? Am I overlooking something? Isn’t this the most obvious and straightforward organization schema?
PaperUI is an admin interface, and is not intended for fancy UI configuring.
BasicUI is used to construct user oriented UI via sitemap.
HABpanel is an alternative highly configurable UI system.
The point is: I can live without fancy if it saves me from the redundant work.
For BasicUI, I need to construct a sitemap, which seems to be more or less redundant with my group hierarchy. HABpanel seems to have the same problem.
Is there a non-obvious reason why the group hierarchy is not a good starting point for the UI? Am I just overlooking a way to generate the sitemap from the group hierarchy?
Yes: a group is not a list. Items inside groups have no order.
No. But it’s one-time work so jump the barrel once and you’re done.
Yes: a group is not a list. Items inside groups have no order.
Items have labels, providing a natural (alphabetical) order.
No. But it’s one-time work so jump the barrel once and you’re done.
Until one adds or removes an item. And one needs to leave PaperUI for something that feels like a completely different system. And I don’t know if I should use Basic UI or HABPanel, and I’ll probably only learn by doing all that work twice… And HABPanel asks me about the number of colums at the very start – what does that even mean in the time of responsive web design? And in HABPanel I need to select a control before I can select and item – the other way around would limit the choice in a meaningful way and could pre-populate values. And PaperUI knows that I can open, close and stop a shutter. In HABPanel I first need to select a widget (a button? three?) and the it asks me for crap like the “value to send” that the PaperUI seems to know already.
You want alphabetical order, someone else will want a different order. You can’t have both.
So there is no order, like it or not. If you want that you can do it but you have to specify the order using sitemap. So what?
You can reference the group name only in BasicUI if you’re fine with a random order.
Then you have to touch a second file. So what ? As your setup matures, you will be doing that a lot less than in the beginning soon.
Please read the docs more carefully to understand what PaperUI and BasicUI are.
They are different systems.
Well, yes. It’s a home automation system, there is an assumption that you’d want to provide an interface for non-technical people to use so they can turn lights on without worrying about (or being able to interfere with) binding settings, deleting Items, etc.
Part of this is history - the UI is a carryover from OH1, the specialist admin interface is newer.
You can reference the group name only in BasicUI if you’re fine with a random order.
Well that certainly helps with getting started: I could have a basic site map
sitemap default label="OpenHAB" {
Group item=Root
}
And then do all other configuration in PaperUI until I am happy. I could probably even bookmark the open root group as a starting point.
So I think if the Group element would have an option to specify the desired order (e.g. label) or would just sort by label by default, I’d never need to touch the sitemap again, perhaps except from adding top level groups directly.
Now instead of providing a reasonable default order that can be controlled by the user (label), you chose to have no order in particular at all (it seems to be stable though). Why is that? Are you not able to do this? Or is it a kind of “we need to educate the user to use sitemaps, this is not what groups are intended for” education approach? Or is the “design committee” not able to agree on a reasonable default order? Wouldn’t ordering by label be a reasonable default, potentially sufficient for many users? Would ordering by label be accepted as a contribution to BasicUI? I agree that it wouldn’t serve all users, but isn’t it reasonable to assume that this would be good for many users? Users who don’t like this order could still resort to spelling out all their items manually, so for them it wouldn’t be a regression.
I reckon it orders by the creation time of the member Items.
I would say no-one has bothered developing Group display methods very much because it precludes any of the other fancy features you can apply to individual Items, like colour changes or button mapping or hiding/showing depending on condition.
People sometimes find they never use a Group display at all as they develop more sophisticated tailored sitemaps.
Don’t ask contemplatively but go code it and submit a PR.
You’re the more or less first to expect/complain about so it obviously wasn’t worth in the other developer’s eyes to take on the effort of implementing this as all the ordering functionality already is there (you just need to write down some more lines).
Remember, this is an OpenSource project, so are YOU able to?
Remember, this is an OpenSource project, so are YOU able to?
I guess I should have phrased the question as “are there technical limitations that prevent this”.
Reasons why I haven’t taken a stab yet are:
Just to reiterate; when you choose to display a set of Items using Group, you give up individual line control:
selection of widget type (it defaults)
selection of icon (it defaults)
selection of label text (it defaults)
selection of state formatting and/or mapping(it defaults)
selective label colors (not available)
selective value/state colours (not available)
selective visibility of line (not available)
mapped button format (not available)
Group widget is great to get you off the ground, and handy for diagnostics. For any serious UI design it becomes a huge hinderance and just about everyone quickly abandons it, leading to little interest in development.
I guess if you really wanted to order display of members, this ought to be a function of the sitemap Group widget - so as to allow parameters for tailoring - order by name, by value, by label, by age.
It is possible to change Group membership in flight, this needs catering for but presumably the existing widget copes.
I have an idea the widgets (three versions) will be part of BasicUI and ClassicUI and IoS app.
Don’t know if anything at server end would need tweaking to allow extra parameters.
Don’t know if there’s anything like this in HABpanel that could/should be similarly tweaked? (it doesn’t use sitemaps)
Group widget is great to get you off the ground
Exactly. I’d argue that this quite important. I was tempted to just try HomeAssistant instead (before investing too much time) – but then I saw that it’s implemented in Python 
For any serious UI design it becomes a huge hinderance and just about everyone quickly abandons it, leading to little interest in development.
We seem to have opposite views of what “serious” means. How would you even know people don’t just “abandon” groups because of the absence of a reasonable default order?
I guess if you really wanted to order display of members, this ought to be a function of the sitemap Group widget - so as to allow parameters for tailoring - order by name, by value, by label, by age.
Sounds good to me
I have taken a stab at implementing label order as a starting point, but I am not even sure how to test…