Is there a way to export all my Things into a file, with information on the available channel UIDs?
Background: I am just starting to model my complete system in openHAB. My plan was to create the Things via the UI from the automatic scans. However, the Items I’d prefer to create via the “Add Items from Textual Definition” feature, and for that I need the channel UID of the Thing. If I could export all the things I could do some automagic that would safe me a lot of UI clicks.
If you really want to save some work, use the “create equipment from thing” option to create your Items in bulk automatically situated in the semantic model and linked to the Thing’s Channels. That’s the fastest and requires the least amount of work and clicking to get managed Items defined.
The “add items from textual definition” feature is more for cases where you already have the Items defined in a .items file. In that case, when you discover and add the Things you will have a one time option to set your own UID for the Thing. Make sure to match the UID that was used for that Thing previously and you won’t have to change anything on the Items at all when you import them. The Channel IDs will be the same so the links will work.
But if it’s too late, you can use the developer sidebar. Press alt-shift-d to bring it up. you can search for your Things by name and pin them there for reference. It shows the Thing ID there and you can click through to get to the Thing’s page.
I am not so happy with the way the “create equipment from thing” option creates the equipment. I prefer the Equipment itself to be a group of a certain type (e.g. Switch, Rollershutter) and link to the main channel of the Thing that controls the device. Somehow that seems to me more intuitive and practical than having that main channel linked as a point under the equipment. However it requires a lot of clicks on the UI to set it up that way.
The items will use the same beginning thing ID with just the specific channel info being different. If creating many of the same type of things you could just duplicated the channels and replace the thing ID though I’m not sure if that fits what you are looking for or not.
You can’t link a Channel to a Group, unless this is something that has fairly recently changed. I’m not sure what it would mean to link a Channel to a Group. When a Group has a state at all, it’s the aggregation of its members. A Group doesn’t have it’s own independent state so what’s the Channel going to do?
Yes, you are right, I was wrong about them being Groups.
So what I want to do is create Equipments of Type Switch, linked to the switch channel of the corresponding Things. In a few cases there will still be Points under the Equipment representing other sensors or functions, but the majority of our Things only has one Switch channel. Those Equipments would look like this:
You can’t do that either. The only way to put something under something in the model is through Group membership. If your Equipment isn’t a Group, it cannot have anything under it.
The Idea seems reasonable but it cannot be supported by OH. A Location is a Group with a Location tag. Points and Equipment are put into a Location by adding them to the Location Group as members.
Equipment works the same way, with the only difference being a regular Item can be an Equipment, not just Groups. However, if it’s a regular Item, there can be nothing “under” it. That one Item represents the entire Equipment. The only way to have Points and Sub-Equipment is if the parent Equipment is a Group Item because, again, the hierarchy is managed by Group membership.
And, as already discussed, you can’t link a Channel to a Group Item. So your use case is not possible.
I have created this structure already and it seems to work fine. I have Groups/Locations, under those are Equipments, which are linked to a Channel but have Points under them.
Here is a screenshot of such an Equipment. The Location is “Wohnzimmer”, the Equipment is “Couchtisch”, which is linked to a channel of Thing “EG WZ Couchtisch” and has the Points “Current, Input/Button”, “Power” etc. under it.
But does it? What’s the state of the Group? Does it reflect the value sent from the Channel? When you send a command to it, does that command get forwarded to all the members of the Group?
All things considered, the fact that you were able to link a Channel to a Group at all is most likely a bug. Groups have very specific behaviors that make them unsuitable to link Channels to. @rossko57, IIRC we were both involved in some threads that discussed adding the ability to link Channels to Groups. Nothing came of those though, right?
Yes, the state of those Equipments does reflect the value sent from the Channel. Not sure if the command gets forwarded, since the Points below it are of different type and would not really change their state.
Hmmm, yes, interestingly I cannot link the Channel when going through the Item page but it does work when going through the Thing/Channel page. I thought it was the other way around and not being able to link it via the Item page is the bug. Raised it here:
If I remove the Channel from the Equipment, how would the Equipment gets its status? is there a way I can have the Equipment reflect the status of the Switch Point below it? Or should that Equipment be stateless?
Edit: Also I am wondering how the system would behave if their are multiple Switch Points below the Equipment. For example our Shelly plugs have a Switch “Power” which switches the device on and off, but also Switches for “Disable Power LED” and “Disable Status LED”. If I send a command to the Group, how would it know to only switch “Power” but not the others?
Typically, when a Group has a state at all, it’s based on an aggregation of its members. If you set the state of the Group to Switch and carefully constructed the aggregation function it would probably work.
But I’m not sure it does you a lot of good. The Semantic Model, right now, pretty much has only two uses:
add enough information to Items for HABot to translate NLP requests to interactions with Items (e.g. “turn off the lights in the kithen”).
to construct the locations, equipment, and points tabs of the overview page in MainUI.
In the first one, I believe Groups with an Equipment tag are presumed to be stateless (based on a couple of short experiments).
In the second one, Equipment that are a Group appear in the cards as a gray inert bar, even when it has a state. You can’t interact with it.
Issue #1: if an Equipment has multiple Points of type Switch, how to limit group commands coming down to only one of them.
For that, having a Channel associated with the Equipment makes even more sense to me - that way I could send commands to elements of the semantic Location structure, decide myself which Channel of an Equipment should get the command, but still have the other Channels as Points under the Equipment.
The alternative would be to create a parallel, non-semantic structure that contains only those Points that should receive the command, but that seem much less elegant.
Issue #2: group commands seem to work only for one device type
I think we touched it already previously. In my testing, commands get send down to group members only if the Member Base Type is set, and it seems then only those commands that fit to that type. So for example, if I set the Member Base Type=Switch then ON/OFF commands get send down, but not UP/DOWN commands. If I set the Member Base Type= Roller Shutter, then UP/DOWN commands get send down, but not ON/OFF commands. If I set Member Base Type=None, then no commands get sent down at all.
So it seems to me, if my use case is to send commands to different levels of the location model, e.g. to floors or rooms, I have to create a separate location structure, semantic or non-semantic, for each device type, which seems awfully redundant.
Or is there something I am missing? I think when we talked about this before you mentioned it may be a bug - is there any way I can confirm that it is?
It’s not less elegant if the first way does’t work though.
This mixing of Group Item behaviors (which haven’t changed as far as I’m aware since OH 1.x in this regard. A Group will always forward cpmmands sent to it to all it’s members. That’s one of the things Groups were made for in the first place.
But I still don’t really understand this approach of wanting to link Channels to Groups in the first place. Even if this worked as expected, it doesn’t buy you much.
You can’t interact with the Equipment at all from the semantic tabs of the overview page. They will just be gray lines in the list. It makes no more sense to command a Point Item than it is to command a Group Item from a Rule.
You could achieve the same result you are after by setting the Default Widget metadata on the Equipment Group and have it just command the members as desired. I believe this was already shown on the other thtead.
So the only place where this helps at all is on the semantic model page, whose purpose is to create your semantic model, not command and control your home automation.It’s an administration screen, not a user interface screen.
Correct, this is how they’ve always worked and how they are designed to work.
Perhaps it’s in understanding what the semantic model is for and what it does. It’s the physical layout of your home automation from an end user’s perspective, nothing more. It’s not intended to capture this sort of commanding structure.For that custom widgets, and in rare cases, a parallel Group structure outside the semantic model, or even custom rules would be used if you want to do some preprocessing on the commands before they are forwarded…
Maybe that is where much of the confusion comes from - my main use case for openHAB is as integration platform and not as UI. So I have been working only in the admin UI and a few basic pages for testing. Still, I wanted to use the semantic model to support any later use of openHAB UIs. But right now, it is the glue that brings together our controls (BTicino, Shelly, Alexa) and our devices (BTicino, Shelly and Sonos)…
That’s the part I am still struggling with, my issue #2.
My expectation/hope was also that groups will send commands to all members, and then the member decides if they want to use it. So I can send ON/OFF to a group, and its Switch members will process it, but its OpenLevel members will ignore it. If I send UP/DOWN, the OpenLevel members will process it but the Switch members will ignore it.
But that does not seem to work. In my testing, the commands are only forwarded if I set the Member Base Type of the group OR if the group only contains members of one type. Maybe I am doing something wrong, but I could not get it to work otherwise.
So, instead of having one group structure to send commands to, I’d need to create one structure per device type, further complicating the data model.
It would help me solve issue #1, to tell the system which Channel to send the command to, in case there are multiple Points of the same type. So e.g. again the Shelly switches have multiple points of type Switch. If I put the Equipment to type Switch and associate the Power Channel with it, the Equipment would process the command, send it to the Power Channel and NOT forward it to the Points, which is my intention.
Custom widgets won’t help me because I am not working with the UIs right now, and it also seems a parallel, non-semantic group structure would at least have some of the same limitations as the semantic model. That leaves me with a custom script, which I have written this morning.
However, I’d still be interested to get this to work without scripting, for which I’d have to solve at least my issue #2.
That is, as I understand it, how Groups are designed to work.
Perhaps. If you are not using the UI, you are frankly getting very little out of the semantic model. So don’t use it. It’s optional. If it’s structures and limitations do not work for you and you are not getting the benefit out of the semantic model anyway, ignore it and model your Items as best fits for you. You can add a semantic model later if you decide to use the UI.
But it is pretty typical to have a Group structure outside the model because there are many cases where the semantic model doesn’t fit. For example, a Group to turn off all the lights in the house. Something like that doesn’t easily fit into the semantic model but it’s really easy to just create a Group outside the model.
So why not just send the command to the Item linked to the Power Channel in the first place? That’s part of my point. You are chasing your tail to send commands to an Equipment Group when you can and should just send the command to the Item you want.
Also note, not all the Channels in a Thing make sense to be in the semantic model. The model is used to present your Items to the end user in a way that makes intuitive sense. Your end users are highly unlikely to care if there is a firmware update available for the Shellys so you wouldn’t put that Item into the semantic model. It’s an admin thing.
Since you don’t have end users, you are not getting much if any benefit out of the semantic model in the first place so create your functional model (which is more inline with what you want) and ignore the semantic model. Then it becomes no problem to have Groups that only have one type you can send commands to and aggregation functions that create meaningful states for your Group Item themselves.
It’s not solvable. That’s how Groups work and changing that would be a huge breaking change.
Yes, true if I want to switch a single Equipment, but my point was more about commands being passed on from Group level. Of course that point is moot if I‘d have non-semantic structures with only the Points I want to command.
Yes, I can see that now. The last few days have been a huge learning experience for me, getting into openHAB and understanding its design and capabilities.
I tested now both the approach via recusive scripting based on data from the semantic model and working with non-semantic group hierarchies. Both work well and do what I expect them to do. The non-semantic groups are more effort on the data modelling side, but that is by and large a one-time job. Both approaches seem equally flexible. Not sure which is more future proof and will be easier to migrate to newer openHAB versions, a script or those elaborate group hierarchies.
Anyway, I am in no hurry to decide, right now I have rules running with both approaches and will see if there are any hidden issues coming up in the next days.
Groups are one of the core features in OH. They change very little over time because major changes impacts pretty much every user. You can rest assured that the behaviors of your Group Items will not change significantly for the foreseeable future. They’ve remained largely unchanged for the past decade and I don’t see them changing much in the future.
Also keep in mind that they are not mutually exclusive approaches. Most users have parallel Group hierarchies, one to build the UI (semantic model) and another functional functional collection of Groups.
Though most of these additional Groups tend to be less structured. Need a way to turn off all the lights? Create a Group. Want to track the minimum batter level? Create a Group. These Groups tend to be stand alone rather than put into some sort of hierarchy or structure.