for the setup of my smarthome I’m kind of struggling with OpenHAB’s concept of groups. I don’t know if I’m just misunderstanding something?! Right now I’m missing any added value because of the limitations I’m experiencing.
Example 1:
Groups cannot be “AND” connected. If I group items in ROOM- and FUNCTIONALITY-Groups (e.g. living room AND heating), I could automagically create a structured sitemap. This seems not to be possible?
Example 2:
If I define an item e.g. for setting the temperature of a thermostate, it doesn’t help me if I put this into a group and then use the group in a sitemap, as the item is represented as a “Number”. In the sitemap, however, I need to define this item as a “Setpoint” in order to be able to actively use it. Which means that I have to manually define every item of this kind in the sitemap in order to be able to use it.
Basically I come to the conclusion that groups really are of no use to help create a sitemap because of this limitations.
So, am I just misunderstanding the concepts, are there reasons for this limitations?! What is the idea behind groups?
Or are there any other ways to add x thermostats (etc.) in a sitemap without manually defining x entries?
As you have expected the answer ist Yes and No and that depends on your use case. You have directly identified thnigs that are not working, but maybe i can give you some examples how to use groups from my point of view.
I have structured all my item in two types of groups. First group is locartion based so i know directly where the item is located, The second group is a context group (if useful). So far we are at the same level, but our use is a little different.
One item in my sitemap is always the root group and all other groups are tree like part of the root group. With this little item i have access to all items and theier values, because each and every item is part of an group.
Items
/*---------------------------------------------------------------------------------------------------------------------
Group: Definition of the root group
---------------------------------------------------------------------------------------------------------------------*/
Group gBasegroup "Group root" <editsettings>
/*---------------------------------------------------------------------------------------------------------------------
Group: Location oriented groups.
---------------------------------------------------------------------------------------------------------------------*/
Group gLocationBased "Loaction based groups" <editsettings> (gBasegroup)
Group gProperty "Property" <editsettings> (gLocationBased) // Code: PR
Group gPR_Garden "Garden" <editsettings> (gProperty) // Code: GD
Group gPR_Terrace "Terrace" <editsettings> (gProperty) // Code: TR
Group gPR_CarPort "Car Port" <editsettings> (gProperty) // Code: CP
Group gOuterWalls "Outer Walls" <editsettings> (gLocationBased) // Code: OW
Group gOW_Roof "Roof" <editsettings> (gOuterWalls) // Code: RF
Group gOW_NorthWall "North Wall" <editsettings> (gOuterWalls) // Code: NW
Group gOW_EastWall "East Wall" <editsettings> (gOuterWalls) // Code: EW
Group gOW_SouthWall "South Wall" <editsettings> (gOuterWalls) // Code: SW
Group gOW_WestWall "West Wall" <editsettings> (gOuterWalls) // Code: WW
Group gBasement "Basement" <editsettings> (gLocationBased) // Code: BM
Group gBM_EntryCellar "Entry Cellar" <editsettings> (gBasement) // Code: EC
Group gBM_LaudryRoom "Laundry Room" <editsettings> (gBasement) // Code: LR
Group gBM_BoilerRoom "Boiler Room" <editsettings> (gBasement) // Code: BR
Group gBM_SupplyCellar "Supply Cellar" <editsettings> (gBasement) // Code: SC
Group gBM_WorkshopCellar "Workshop Cellar" <editsettings> (gBasement) // Code: WC
Group gBM_PassageCellar "Passage Cellar" <editsettings> (gBasement) // Code: PC
Group gGroundFloor "Ground Floor" <editsettings> (gLocationBased) // Code: GF
Group gGF_MainEntry "Main Entry" <editsettings> (gGroundFloor) // Code: ME
Group gGF_Hallway "Hallway" <editsettings> (gGroundFloor) // Code: HW
Group gGF_GuestToilet "Guest Toilet" <editsettings> (gGroundFloor) // Code: GT
Group gGF_Office "Office" <editsettings> (gGroundFloor) // Code: OF
Group gGF_Kitchen "Kitchen" <editsettings> (gGroundFloor) // Code: KI
Group gGF_LivingRoom "Living Room" <editsettings> (gGroundFloor) // Code: LR
Group gGF_DiningRoom "Dining Room" <editsettings> (gGroundFloor) // Code: DR
Group gGF_Bedroom "Bedroom" <editsettings> (gGroundFloor) // Code: BR
Group gGF_Bathroom "Bathroom" <editsettings> (gGroundFloor) // Code: BA
What do i do with these groups. To be honest: “At the moment nothing”
The second branch are the contextual or as you called it functional groups. In these group i collect items for special tasks. Best example from my point of view is the battery group. Typically battery operated devices have one channel that is associated with some kind of battery information. Collected in a group i have all in one place. Putting the group into the sitemap you see all the battery states at once. So this is a sitemap useful group. On the other hand i wrote a rule that checks all the batteries once a day and send me a pushover message if a battery should be replaced. So i iterate trough all the items in the group. Thats easy.
Items
/*---------------------------------------------------------------------------------------------------------------------
Group: Contect oriented groups.
---------------------------------------------------------------------------------------------------------------------*/
Group gContextBased "Context based groups" <editsettings> (gBasegroup)
// Groups to control airing
Group gTriggering "Triggering related groups" <ftswindow2w> (gContextBased)
Group:Contact:OR(OPEN, CLOSED) gAiringTrigger "Trigger group for room airing" <editsettings> (gTriggering)
// Groups to represent battery-related relations
Group gBatteries "Battery related groups" <measurebattery> (gContextBased)
Group gBatteryOperated "Battery operated devices" <measurebattery> (gBatteries)
Group gBatteryStatus "Battery status" <measurebattery> (gBatteries)
// Group for representing different persistence scenarios
Group gPersistence "Persistenz" <edit_settings> (gContextBased)
Group gStandardTimeline "Zeitreihe (Every Update)" <edit_settings> (gPersistence)
Group gMinuteTimeline "Zeitreihe (Every Minute)" <edit_settings> (gPersistence)
Other group i use for iteration purposes are a group with window contacts to check if they are open or not.
One simple example for groups is to show the amount of open windows. Just use the group and the %d and voila the number of open windows ist displayed in the sitemap.
Sitemap
Text item=gAiringTrigger label="Zum Lüften geöffnete Fenster/Türen [%d]" icon="ftswindow2w"
Hope that helps a little bit. Best advice is start slow, build some small thing an expand and ask
This is a fair summary. Because you cannot control how to display group members individually . As a switch or as text, hide or show when that condition, color text when this condition etc.
Thanks for the detailed explanation. The question remaining for me is “why???”
I already have a limited use case for groups for stuff like battery warning etc. These are “read only” items and need no special representation, so here groups mostly work.
If I now could do “and” or “or” with those groups and if I could give a default item representation for an item already in the *.items file, I would be able to cut my sitemap by 90% in size and complexity. The items would simply fall into the right place in the sitemap because of the group memberships.
In my understanding this would be the main rationale behind any group concept.
So I’m wondering if this is a design decision I do not (yet) understand, or something that will hopefully be implemented some time?
The real usefulness of groups is as you already said not in Sitemap as they don’t give you much control but it is in rules and persistence. You can do many things with the availability of the group based rule triggers and so on. @rlkoshak has few great design patterns to give you some inspiration for use cases of groups.
However, from the perspective of somebody not so interested in design philosopies (I know, that design philosophies are important, but…) but in a easy-to-use (maintain/extend) home automation system this seems to waste the potential of groups concerning the easy setup of a graphical interface.
In the context of sitemaps you are correct. There isn’t much value added in using Groups.
This is a reasonable conclusion.
You are kind of misunderstanding the concept of Groups as they really are not there for sitemap or UI creation. They are super useful in all the other parts of OH. But the problem is there isn’t that much that can be done with a Group on a sitemap. When you put a Group on a sitemap you have no control over how it’s members get displayed. The order they are presented in is what ever order they happen to be stored in the Group. The sitemap element that gets use to present the Item will be the default. How could it be anything else? This is rarely what one wants with a UI.
So yes, if you want anything outside of the defaults or want to control the order, then you need to build your sitemap element by element.
You might want to look at the Home Builder add-on (I think it’s under the Misc tab, maybe the UIs tab in PaperUI). You can use that to set up your physical and functional hierarchies and it will create the sitemap and Items for you.
All of the details must be defined somewhere. Since defining such details as whether to show a Number as a Setpoint or a Text is a UI concern, the proper place to define it is on the sitemap. You can’t get away from needing to define this. The work has to be done somewhere. The developers chose to place this work in the .sitemap file which, IMHO, is where it belongs because it is strictly a UI concern.
And move that complexity to your .items files. You are not eliminating the complexity, just moving it.
And let’s assume that we did move that complexity there. Then the sitemap can’t handle use cases like making a control read only (e.g. convert a Switch to Text) when an Item is in a certain state.
You are limiting the Group concept to strictly the UI. Frankly, the only reason why the Group element exists on the sitemap in the first place is probably because it was easy to implement. It was never made to nor intended to be a way to build a customized sitemap.
The main rationale for Groups is it’s use in Persistence and Rules.
In OH 3 the whole sitemap concept is undergoing a complete rewrite. But I wouldn’t expect that you would be able to use Groups in the way you want to use it.
These are not “philosophies”. A Design Pattern is a well reasoned, tested, and practical approaches to solve a specific class of problems.
Let’s take the second link from above. Let’s say you have one set of Items you want to restoreOnStartup, another set you want to chart their value over time, and maybe a third where you want to use historic data. You can set up three Groups, one for each approach and set up your .persist files to save these Groups using the appropriate policies. Now, to control how the Item’s state is stored in the database(s) you just add/remove it from the right Group.
The third link shows how to use Groups to drive behaviors (lighting is in the example) using a state machine and Groups.
When a user says “I want a way to control how my lights turn on based on the time of day” they would look at the Design Patterns to see which/if any apply to how they specifically want to control their lights.
If you are “not so interested in design [patterns]” then you are not so interested in actually build openHAB as a home automation platform. You are just looking for a giant remote control. If you are interested in home automation then the DPs will be your primary dictionary to show you how to do what you want to do in a way that is all but guaranteed to work well.
Clicking on a Group element will reveal a new view showing all group items using the Default element type. …
Attention: There is no way to override the parameters, change the default element type, change the order, use dynamic tags, or insert other elements (e.g. Chart, Image, Webview, etc) in the subframe generated by the Group element.
Group gLights "all lights"
Group gLivingroom "all living room items"
Switch sLivingroomLight "Light [%s]" (gLights,gLivingroom)
and in a sitemap
Group item=gLights
Group item=gLivingroom
which will result in two child pages, one with all lights, the other with all living room items.
As stated before, the real benefit of groups is not the sitemap (in fact, the Group Widget is more a “fast success” thing, you don’t want to use this to build your sitemap).
It’s very likely that upcoming versions of openHAB (3+) will do sitemap configuration in a completely other way.
OK, I got it. Groups are a concept not for sitemaps ;-).
As my workflow is the other way round - I would like to have a user-friendly sitemap for the family first to get the basics covered and do more complex stuff later on - I probably aproached the group concept from the wrong angle.
However, OpenHAB is (for me as a new user) pretty inconsistent here: You have groups with a (IMHO) limited scope. Then you can assign rooms in PaperUI (and HABMin), a “grouping method” completely independent and with another also limited use case only in those UIs. For the sitemap you work with frames.
You also can work with different UIs and text files and all those config options have slightly different possibilities, limitations and philosophies.
Somehow that gets a bit confusing over the time ;-).
As with most open source projects, you are using software that is perpetually in a state of transition. PaperUI is only useful as an administration user interface, but I suspect that the original developer envisioned it to be something more. Unfortunately the original developer has abandoned PaperUI and none of the remaining maintainers know the framework it was built upon. So we are limping along with a half baked UI that doesn’t even support everything necessary to do administration.
Then you have the transition from OH 1.x to 2.x. A ton of new concepts were introduced during that transition like Things and Channels and Links and automatic discovery and exposure of configuration and management of all of this through a REST API. But not everything transitioned over to the 2.x way of doing things. So you have PaperUI which only deals with OH 2.x “things”. But we still have 1.x bindings that are in use and can still be used in OH 2. Important concepts like persistence, transformations, and sitemaps still follow the 1.x conventions and are only now being at least moved to the OH 2.x baselines.
I could go on. But the main point is that OH 2.x is one big years long transition period between 1.x and what I hope will be a more consistent OH 3.x future. Almost all of the inconsistencies I mention above are being addressed in some way for OH 3.x. There will be no more PaperUI and likely no more Sitemaps, at least in the form they have now. The administration UI will be able to configure everything (except for maybe the 1.x bindings which might not be supported). The path is to have just one UI for administration and user’s UI and how it works and what you can do on it will depend on the role you log in as.
But for now, what you see is what we have. We know it is confusing and we do our best to support users through their confusion and help where ever we can on this forum. I don’t want to toot my own horn, but this is one of the most friendly and responsive forums I’ve ever used. There is work ongoing to address the problems. We all use OH too. We are not blind to them.
This is indeed an uncommon though not unheard of approach. In fact, the Home Builder add-on was created to approach it in this way.
Most of us I believe start with what we want to automate, figure out how to do that and build the UI as we go. And in fact, many of us build the automation with the goal to eliminate the need for a UI in the first place. For example, I have a quite extensive sitemap built. But neither my wife nor child uses it. I use it mainly to see if something has gone wrong and to see what state the system it. For the rest the house is either completely automated based on events and state or there is some other more intuitive control (Google Voice, a physical switch or button, etc).
To provide one of my more complicated examples, when I get in the car when I’m home, Tasker on my Android phone will pop up a dialog asking if I want to open the garage. Then 30 seconds later is asks again so I can close the garage after exiting the garage. When I approach the house it pops up that same dialog asking if I want to open the garage. My wife’s phone has the same Tasker profile running. I do have the garage door openers on my sitemap. I can’t remember the last time anyone used them that way.
But other users are all about the UI and have build truly impressive dashboards with wall mounted tablets and such. That’s a perfectly fine approach too but for those users they want more control over what and how everything get’s presented so something like the Group element on the sitemap wouldn’t be useful anyway because they absolutely want full control to customize how each and every element looks and works.
Your history of OpenHAB explains a lot. From reading other threads I had the impression that PaperUI is the future, which seems to be pretty much wrong…
