Like others, I’m in the process of completely reworking my openHAb installation and organizing it a little bit differently. One of the tasks in the reorganization is the restructuring of the groups. I have given some thought to this and would like to hear your opinion.
Here’s the result of my deliberations::
Thing Groups
Different items belong to a thing and are grouped together in a corresponding thing group. All items belonging to a thing can be easily displayed in a Basic Sitemap for debugging. If there are only virtual items, i. e. without thing, a corresponding thing group is defined on the basis of the items, since there are usually several.
Group gGF_LR_MyThing "My Thing" <my_icon> (gMyLocation, gMyContext)
Item GF_LR_MyThing_State "My Thing State" <my_icon> (gGF_LR_MyThing, gOtherRequiredGroups)
Item GF_LR_MyThing_Battery "My Thing Battery" <my_icon> (gGF_LR_MyThing, gOtherRequiredGroups)
Item GF_LR_MyThing_Unreach "My Thing Unreach" <my_icon> (gGF_LR_MyThing, gOtherRequiredGroups)
Group Hierarchy
Groups are organized hierarchically starting from a root (gRoot - I don’t like gALL). There are three main structural groups:
- Location-based groups (gLocation) in which the thing-groups are assigned according to their location
- Context-related groups (gContext) in which the thing groups are assigned according to their main context
- Persistence groups (gPersistence) in which items are assigned to different types of persistence
As with the Thing Groups, a simple mapping in a Basic Sitemap for debugging purposes is easy to implement. All items can be displayed in a structured way by embedding gRoot in a sitemap.
Location-related groups
The location-based groups should be self-explanatory. So typically the floors, rooms, etc… In my case, this is what it looks like:
Context-related groups
In addition to the location-related groups, there are context-related groups. In these groups, the thing groups are assigned to a group according to their main function. I have defined the following groups, but they can also be extended:
- gIllumination - Everything related to lighting. Switches, socket outlet switches, lamps, LED strips,…
- gSurveilence - Everything related to surveillance. Motion detectors, door and window contacts, cameras,…
- gEnvironment - Everything related to environmental data. Temperature, Humidity, Weather data,…
- gHeating - All things to do with heating; Thermostats, thermostats,…
- gControl - Everything that basically has to do with the subject area of control and is not already arranged elsewhere. Washing machine control,…
- gInformation - Everything related to information. Battery status, fuel prices,…
- gMultimedia - Everything related to multimedia. TV, Sonsos,…
Persistence Groups
The third of the main groups is the persistence group, which controls persistence for individual items. For me I currently see two subgroups. Once persistence via a mapdb e. g. to perform a restore at startup and on the other hand the persistence for the influxdb with which nice graphics are made via Grafana.
Functional Groups
In addition to the groups, there are the functional groups (Switch, Contact,…) and dynamically filled groups. These are assigned to the corresponding context groups. For example, the functional group with the status of all batteries fgBatteries is assigned to the context groups gInformation or the cascaded lighting groups of the context group gIllumination.
Based on the statements made so far, each thinggroup has at least two group memberships (place and context). Each item has at least the assignment to the Thing Group and can have further group memberships such as functional or persistence groups.
In total, the whole thing looks like a mindmap as follows.
So much for my considerations. I would be happy to receive any additions and comments.
Thomas