Issue of the topic: Just wanting to hear experiences and advice from other users.
Hey everyone if this post belongs elsewhere or if this topic has been covered, please tell me as much. I’ve been using openHAB for about a year now. It’s been a ton of fun, and I’ve learned a lot. I’ve tinkered with various configurations of my semantic model, and one thing I’ve never managed to get right is network items. I have 30 things, and 300 items registered. Maybe 10% of those have a non-semantic tag, “network.” The idea is that I could use that tag to pull together my host device metrics, pi-hole device metrics, RSSI values for various things, mostly as a pass-through for tracking via InfluxDB, but also to give my wife some quick easy switches she can use when my sysadmin LARPing causes an issue. A switch item connected to a script which turns off pi-hole for 5 minutes, for example.
Another thing I want to do is create some switch items connected to simple cron rules so we can keep track of whether a chore has been done for the day. For example, when one of us give the dog her pill, we flip the switch. Later, if either of us are unsure we could check to see if the switch has been flipped. I have about 20 chores like this I would like to implement daily, weekly, monthly, etc. What I don’t know is how i would even begin to tag and categorize these switches. I assume they would not belong anywhere in the semantic model, as they aren’t physical things or connected to any equipment? But I would still want them robustly organized and ready for scale, in keeping with my philosophy.
Has anyone done something like this within openHAB? What is your approach, both to building/configuring these things, and keeping them organized? Thanks in advance and its great to be here.
For the network stuff, I would model the physical device only when it is useful to see it as equipment: one group per host/device, then points below it for online state, RSSI, blocked queries, a Pi-hole disable switch, etc. If a metric is only there for InfluxDB, it does not need semantic metadata; a plain group like gNetworkMetrics plus your custom network tag is enough.
For chores I would not try too hard to make them look like real equipment. I would create a separate group hierarchy such as gChores, gChoresDaily and gChoresWeekly, then Switch items like Chore_DogPill_Done. Reset them with a small rule at the schedule boundary. If you want them in Main UI, build a page/card from those groups instead of relying on the semantic model.
The key is: use semantics where the item represents the home; use groups, tags and pages where the item represents your workflow. That keeps the model from becoming a junk drawer but still scales.
A very wise approach. I have the same set up for AdGuard Home. Some of the block lists are too aggressive and block pages we really do need to get to.
Maybe, maybe not. I’ve put my AdGuard Home Switch in the the model.
It is important to remember that the semantic model’s primary use is to build the Locations, Equipment, and Properties tabs of the Overview page. Alexa, HomeKit, Google Home, Matter, et. al. currently do not use the semantic model.
So your semantic model is first and foremost a model of the physical layout of your home automation from the perspective of your home’s users.
So first one asks, as a user of this home, where would I expect to find that control? For example, even if the relay to control the kitchen lights is on a bus in some utility closet somewhere, the user would expect to find the controls for the light in the kitchen. So that is where it goes in the semantic model, in the kitchen.
Where do Items that just represent some statistics saved somewhere that wouldn’t really be exposed to the users of the home? They should be excluded from the semantic model. These are not exposed to the end users of your home so they shouldn’t be shown to them.
But where does something like control of Pi Hole go? That is something you want to expose to the users of the home. For my family they expected it to be under the “house” at the top level of the hierarchy instead of being placed in a room somewhere because it affects the network of the whole house. So that’s where I put it (next to weather and the whole house energy meter).
What about the chores? It depends on how you and your family want to interact with them. Think “if a guest came to my home, where would they look to find this control?” That’s where you put it. Or perhaps you don’t put them into the model in the first place and use an oh-repeater-card on the Layout page of the Overview. That first tab is a “freeform” page you have to build and I recommend using that page to bring up to the top those controls that are most commonly used and certain status fields which might be important to the users of the home.
And of course, if you are not using the automatically built tabs of the Overview Page at all, then you will really get limited benefit from the semantic model in the first place. In that case, it doesn’t really matter how you organize it as the semantic model effectively has no impact on anything at all.
My rule-of-thumb is only about 80-90% of your Items really should be in the semantic model. Anything there mainly to record information only used by rules or used by you as the administrator do not belong in the semantic model. Anything users of your home do not need or care to see nor interact with should be in the semantic model or set to invisible for the user role. And if you are not using the Overview tabs, the semantic model doesn’t do much of anything for you at all.
For a concrete example here is how I model my AdGuard Home switch:
I’ve not spent a lot of time on the overall layout here obviously. Everyone mainly uses this on their phone where it’s configured to have one widget per row.
But this is the information and set of controls my home’s users need the most or need to know the most. But this shows how you can present stuff outside the semantic model or aggregate a summary where it’s important. For example, the lights widget shows a different number of switches when “Tis the Season” is ON. The battery status only shows Batteries that are below 50%. The services widget only shows those that are offline.
Most of these widgets are on the marketplace.
Having said all that
That’s up to you. What would make these the easiest for you and users of your home to make use of these Items? What would they expect and in your UI where would they first look to find them? The answers to those questions will drive your answers.
Don’t forget you can add a custom semantic tag (MainUI → Developer Tools → Semantic Tags) so you could create a “chores” tag if that makes the most sense for you. Or you could exclude these from the model and only have them appear on the main Overview layout page or a custom page. All of these are are valid.
And as @relaynest513 mentions, you are not limited to the semantic tags for organization. You also have other custom tags or Groups to organize your Items.
And now that OH has drag-and-drop support in the Model view, if you change your mind later it’s really easy to move stuff around. So you don’t need to get this right first try.
It depends on how you and your family want to interact with them. Think “if a guest came to my home, where would they look to find this control?” That’s where you put it. Or perhaps you don’t put them into the model in the first place and use an oh-repeater-card on the Layout page of the Overview. That first tab is a “freeform” page you have to build and I recommend using that page to bring up to the top those controls that are most commonly used and certain status fields which might be important to the users of the home.
