I've been using Jim Duda's Android app for a week now, and loving it.
However, I noticed that the objects within groups are not sorted alphabetically.  This is due to Groups.pm having a naive view of data.  The list method ends with:

    return sort @$memberList;  # Hmmm, to sort or not to sort.

which attempts to sort the type+hash value.  This should have been coded as

    return sort {$a->get_object_name cmp $b->get_object_name} @$memberList;  # Sort by external name

More importantly, the inclusion of objects in superior groups is driving me bonkers.  With the smallish screen of the tablet and the number of "rooms" in my house, I have organized my groups as

GROUP Floor1, Property    # navigation
GROUP Floor2, Property    # navigation

GROUP Kitchen, Floor1    # rooms
GROUP Games, Floor1
GROUP Garage, Floor1

GROUP MasterBedroom, Floor2
GROUP Bathroom, Floor2
GROUP Landing, Floor2

GROUP HVAC, Property    # navigation
GROUP Thermos, HVAC    # function
GROUP Valves, HVAC        # function

IEB1, 0/1/2, RangeSpotLight, All_Lights|Kitchen

The idea being that Items are connected to room groups and function groups.  The groups that are right under Property have no objects, only subgroups:  Property, Floor1, Floor2 and HVAC would be "organisation" or "navigation" groups that have no Items (objects).  In the Android app I would love to put the 3 or 4 navigation groups on the Main menu; when you select Floor1, you would see the rooms (groups) that are part of Floor1 but *not* the 50 or so objects that are in the rooms.  Then when you select a room (group), you would see the objects.

This concept fails because:
a. The list method in Groups.pm notices when a group has a subgroup in its member list, and recurses into the subgroups.  So Property shows all objects in the whole house, etc.
   There is a flag "$no_child_members" but that is not used by xml_server.pl.
b. AndriodApp does shows all groups in one alphabetical list, and shows only the objects (not the subgroups) when you select a group.

So I wonder, is there room for structuring or grouptree navigation in the mh data model?  Should I build a "navigation" (or "no_child_members") property into the GROUP item, to stop the collection of objects from all subgroups (i.e., imply use of the $no_child_members flag) ?  This means a "set $Floor1 OFF" has no effect, but "set $Kitchen OFF" would work (I think).