Sorry, but this is not possible. If you use a group as an item in your sitemap, you have no control over any aspects of order or appearance in the sitemap. If you want to influence the order or appearance, you will need to handcode all items in your frame.
I found a solution: using subframe without grouping items:
sitemap kontakt label="Kontaktsensoren" {
Frame label="Eingangstür" {
Text item=Door_Eingang_OpenStatus label="Zustand [%s]"
Text item=Door_Eingang_LastOpened label="Änderung [%1$td.%1$tm.%1$ty %1$tH:%1$tM]"
Text item=Door_Eingang_Battery label="Batterie [%d %%]"
Text item=Door_Eingang_ThingStatus label="Gerätestatus [%s]"
Text label="Event Log" {
Frame label="" {
Text item=EventLog00 label="[%s]"
Text item=EventLog01 label="[%s]"
Text item=EventLog02 label="[%s]"
Text item=EventLog03 label="[%s]"
Text item=EventLog04 label="[%s]"
Text item=EventLog05 label="[%s]"
Text item=EventLog06 label="[%s]"
Text item=EventLog07 label="[%s]"
Text item=EventLog08 label="[%s]"
Text item=EventLog09 label="[%s]"
Text item=EventLog10 label="[%s]"
Text item=EventLog11 label="[%s]"
Text item=EventLog12 label="[%s]"
Text item=EventLog13 label="[%s]"
Text item=EventLog14 label="[%s]"
Text item=EventLog15 label="[%s]"
Text item=EventLog16 label="[%s]"
Text item=EventLog17 label="[%s]"
Text item=EventLog18 label="[%s]"
Text item=EventLog19 label="[%s]"
}
}
}
}
I’m not sure what “fix” you mean, but this behaviour hasn’t changed in 2.4 (and I don’t believe it changed in 2.5M2 either, but I do not run that version, so not sure)
I meant the year long behaviour (~openHAB 1.3 - 1.8.3) to always show group items in sitemaps in the exact order of the items in the .item files. This seems to have been totally lost in any of the 2.x implementations of openHAB, so I was wondering if there are plans to implement this very useful behaviour again in future 2.4+ updates to reinstate past openHAB funtionality.
Display of members in a Group widget has never been guaranteed to be in any particular order. There will not be a fix, there is no regression.
It’s not truly random order of course, so you may well observe that doing this or that can affect the order.
I think if you want to try, you can manage the order by creating new Items in an xxx.items file and then never ever edit those Items. (I believe the widget order happens to be by last edited)
In real life, people just move on from using Group widget to using individual sitemap lines. Not just because of ordering, but the Group widget has no way to allow you to use colours or visibility etc.
While I totally disagree here - the order has been guaranteed for years and still is in 1.8.3, to the extend that reordering the items in .items files allows for adjusting the order of group members being displayed in sitemaps. No matter how many other items in these files are adjusted, added or the items themselves being adjusted etc. the ordering for group member items always stays the same and is solid in 1.8.3 - I do however undstand from the comment, there doesn’t seem to be an interest to have this behaviour reimplemented in openHAB2.
It happened that way through chance. Items were newly created at each boot from xxx.items files, so when retrieved they usually came in creation order. It could have been alphabetic or reverse order or most recent update or …
Now in OH2 they are stored in a database which survives reboot. They might be created by PaperUI or read from xxx.items file. If they are already in the database, they might get edited if different. Retrieving Items in a group will now depend on other things than the simple order in xxx.items files.
I think in practice it has to do with editing date, if you want to play with that.
It wasn’t chance in openHAB ~1.3 - 1.8.3, as the behaviour was solidly repeatable over several openHAB installations. It wasn’t the creation order, alphabetical, reverse order or anything, but always the order in which the items appeared in an .items file. Whenever I got a new light in my setup I made sure to add the item in between two other items of the same group (g_Lights in my case) where I would want it to appear in the sitemap when showing the group.
I do understand the with itmes created by PaperUI this would be difficult or impossible to achieve, but getting the same behaviour if all group items are manually definded in an .times file would be the same behaviour as being accustomed to from openHAB 1.
Isn’t Kai’s comment in the thread exactly what I’m stating here, not chance, but …:
“Sitemap sorting is done by order - specifically by the order of items in the items file.”
Thanks, I will follow the issue and see how it progresses.
I believe the current predictable, repeatable, ordering happens to be based (by chance) on editing date in the database. But I’m not sure.
On that basis, inserting a new Item in the middle of an xxx.items list would result in that new Item appearing at one end of Group. First, last, I don’t know.
Making a substantial edit to one of the Items - maybe linking a channel etc. - will promote that one to the end.
All entirely predictable, if we know the rules.
To be truly solved, and to reinstate the capability of having group items appear in the order they are defined in the items file, a final suggestion from @lolodomo in the issue on github
show that the same behaviour as in OH 1.8 can be achieved, but currently ONLY if you define ALL of your items in ONE single file. The order of group items in separate files, even if the groups are kept together in their respective files, does currently not work in OH 2.4/2.5M3.
For anyone else who was plagued by this, this one file solution might be a remedy as well.
