[SOLVED] Item order in a group

Hello,

i want to use a group element with subitems.

how can i fixing the order of item elements? actually it’s based on state or textcontent and this can’t use for sort order.

Here’s the code:

eventlog.items:

Group gEventLog "EventLog" (All)

    String EventLog00   "[%s]" (gEventLog)
    String EventLog01   "[%s]" (gEventLog)
    String EventLog02   "[%s]" (gEventLog)
    String EventLog03   "[%s]" (gEventLog)
    String EventLog04   "[%s]" (gEventLog)
    String EventLog05   "[%s]" (gEventLog)
    String EventLog06   "[%s]" (gEventLog)
    String EventLog07   "[%s]" (gEventLog)
    String EventLog08   "[%s]" (gEventLog)
    String EventLog09   "[%s]" (gEventLog)
    String EventLog10   "[%s]" (gEventLog)
    String EventLog11   "[%s]" (gEventLog)
    String EventLog12   "[%s]" (gEventLog)
    String EventLog13   "[%s]" (gEventLog)
    String EventLog14   "[%s]" (gEventLog)
    String EventLog15   "[%s]" (gEventLog)
    String EventLog16   "[%s]" (gEventLog)
    String EventLog17   "[%s]" (gEventLog)
    String EventLog18   "[%s]" (gEventLog)
    String EventLog19   "[%s]" (gEventLog)

    Group gEventInternal "Event Vars" (All)
    String  EventLog     " Event[%s]" (gEventInternal)

sitemap:

Frame label="EventLog" {
    Group item=gEventLog
  }

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.

thats strange… there are no other options to see history data?

here an example with current issue:

Group gEventLog "EventLog" (All)

String EventLog00   "001: [%s]" (gEventLog)
String EventLog01   "002: [%s]" (gEventLog)
String EventLog02   "003: [%s]" (gEventLog)
String EventLog03   "004: [%s]" (gEventLog)
String EventLog04   "005: [%s]" (gEventLog)
String EventLog05   "006: [%s]" (gEventLog)
String EventLog06   "007: [%s]" (gEventLog)
String EventLog07   "008: [%s]" (gEventLog)
String EventLog08   "009: [%s]" (gEventLog)
String EventLog09   "010: [%s]" (gEventLog)
String EventLog10   "011: [%s]" (gEventLog)
String EventLog11   "012: [%s]" (gEventLog)
String EventLog12   "013: [%s]" (gEventLog)
String EventLog13   "014: [%s]" (gEventLog)
String EventLog14   "015: [%s]" (gEventLog)
String EventLog15   "016: [%s]" (gEventLog)
String EventLog16   "017: [%s]" (gEventLog)
String EventLog17   "018: [%s]" (gEventLog)
String EventLog18   "019: [%s]" (gEventLog)
String EventLog19   "020: [%s]" (gEventLog)

Group gEventInternal "Event Vars" (All)

result:

your code goes here

Maybe this discussion might help?

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]"					
			}
		}
	}
}

Which gets you back the @lipp_markus post #2 where he gave you the solution.
Please tick the solution post, Thanks

Hi all,

does anybody have any idea if this regression from openHAB 1.8 is up for a fix in openHAB 2.4+?

Thanks

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)

1 Like

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.

Maybe next release it could change again.

Here’s an open issue about it

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.

1 Like