openhab-core
openhab-core copied to clipboard
openhab
Sub-Equipment tagging on Channel Groups?
In https://github.com/openhab/openhab-addons/pull/18585 @pgfeller suggested that Channel-Groups could be candidates to have sub-Equipment tags on them. And I would like to ask our tagging expert group @jimtng / @mherwege / @lsiepel / @jlaur / @rkoshak if you have any thoughts on this?
Those channels are part of a group Not sure if that group should be modelled as a sub-equipment; or what's the best structure to use here.
@pgfeller many thanks for the feedback. Your suggestion about Channel-Group being a candidate for having a sub-equipment-tag does indeed make logical sense (at least to me). However currently the OH tagging schema only foresees a) equipment tags on Things (applied directly or via Thing-Types), and b) Point+Property tags on Channels (applied directly or via Channel-Types). And by contrast semantic objects for Channel-Group neither exist in OH Core nor in OH UI. So there is currently no mechanism to adopt your suggestion at the moment. However I would like to open up this discussion to our tagging experts so I will create a new Issue from this comment.
Originally posted by @andrewfg in https://github.com/openhab/openhab-addons/issues/18585#issuecomment-2925132167
Would the Channels be linked to a Group Item? While not wrong, it's unusual to have an Equipment that is anything other than a Group Item.
I think the model allows one to apply an Equipment tag to non-Group Items but I don't think they will be rendered properly in the Overview tabs. The Equipment Items are rendered as headings, not as widgets you can interact with (e.g send command to).
I think the better approach would be to either not apply a semantic tag at all and keep these Items out of the model entirely, or apply a Point/ Property tag for a Channel so it shows up in a usable way in the UI.
As a concept it might make sense. It would also be very specific to certain groups.
IMHO I prefer to to see alll current tagging efforts in effect before I’m ready to comment in detail.
The main use of having an equipment tag on a thing is the automatic creation of the equipment group item when you use the 'Create Equipment from Thing' function in the UI on the thing channels page. This creates a 2 level item structure: for the thing, a group item gets created, tagged by default with the equipment tag from the thing. For each channel (selectable) an item is created tagged as a point with point and property tags that default to the channel type tags.
There currently is no creating of an intermediate level for channel groups. So to make this work, the channel groups should translate into a group item as well, child of the thing level group item and parent of the items created from the channels in the group. Channel groups should carry a default equipment tag to translate to the channel group level group item.
While all of this seems to be feasible, I do have a few concerns:
- It was never intended for the channels groups to represent anything else than a logical grouping. In the binding I use and for which I did some development, these channel groups do not represent a device, but some logical grouping. It allows to easily colapse the channels by group in the UI. E.g. in the systeminfo binding, channels groups are used to group CPU, memory, network... readings. While you could argue these are all subdevices, I think this would be stretching it too far. For the weather bindings, there are groups representing forecast on D, D+1, ...
- This adds a whole new layer to the UI item creation from things. This is already a complex part in the UI (not just from a code perspective, but specifically from the user perspective). Going from a 2 layer to a 3 layer structure makes it even more complex.
While an interesting idea, I am not convinced we should try this for OH 5.0. To me, this looks like too big a change and it stretches the channel group concept beyond what it currently is used for.
Would the Channels be linked to a Group Item?
Not as such. But they would be linked to the group item associated with the outer Thing..
The main use of having an equipment tag on a thing is the automatic creation of the equipment group item when you use the 'Create Equipment from Thing' function in the UI on the thing channels page. This creates a 2 level item structure: for the thing, a group item gets created, tagged by default with the equipment tag from the thing. For each channel (selectable) an item is created tagged as a point with point and property tags that default to the channel type tags.
This makes sense and I'd be for that approach. But that isn't my understanding of what is being discussed here. Here my understanding is we have a Channel that represents more than one device, but it would still be linked to a single Item, not create an equipment of equipment hierarchy in the model.
If the Channel is linked to a single Item, then an Equipment tag is going to break the Overview tabs (I just helped someone on the forum who tried to do this with Lightbulb and the results were wrong). If the Channel creates a Group and an equipment of equipment hierarchy I think that's a great idea and am for it, assuming a solution could be found for the technical issues you bring up and that it's overridable by the end user.
I totally agree there probably isn't time to get this into OH 5.0. I also wonder if it shouldn't be implemented outside of trying to misuse Channels.
tl;dr, MainUI won't know what to do with a non-Group Item with an Equipment tag.
But that isn't my understanding of what is being discussed here. Here my understanding is we have a Channel that represents more than one device, but it would still be linked to a single Item, not create an equipment of equipment hierarchy in the model.
That wasn't my understanding. Probably worth linking back to the original post with the question: https://github.com/openhab/openhab-addons/pull/18585#pullrequestreview-2866935340. I got from that the idea to model a channel group as an equipment which is a child of the equipment created from the thing. But the individual channels are still inside that group and therefore represent the points. The channel group item should therefore be a group.
I also see the questions in the forum about tagging a non-group item as an equipment. While possible, I don't think that's the thing to do. I believe HABot copes well with it, but the automatic UI pages don't.
It feels wrong to model this as a Channel from the end user's perspective. You would never be able to link this Channel to anything, right? How is this Channel going to behave for users who choose not to use the semantic model?
I'm not sure what the right way to do it would be but Channels to do this feels like a hack instead of good design and it could lead to confusion to the end users.
@rkoshak there was never a proposal to model a channel group as a channel.
The proposal was to tag a channel group as a sub Equipment. The essence is that Things (which have Equipment tags) normally contain Channels (which have Point+Property tags). And in some cases the Channels are sub structured within those Things by means of one or more channel groups. Such groups are often related to a sub functionality of the Thing e.g. the Thing may have channel groups for (say) lighting and (say) hvac. In other words a channel group is hierarchically "below" the Thing but hierarchically "above" the Channels (or respective Items). So the suggestion to apply sub Equipment tags at channel group level has a certain logic to it. However channel groups are rather slippery conceptual entities not actually represented by real objects in Java. So the counter argument (which I also understand) is to avoid tagging such slippery entities. At least for the time being..
Unless some new insights come along, I would be against tagging channels groups with sub-equipment. If a Thing exists of multiple sub devices, I think it is wrongly modelled and should have been split.
Unless some new insights come along, I would be against tagging channels groups with sub-equipment. If a Thing exists of multiple sub devices, I think it is wrongly modeled and should have been split.
After the upgrade to version 5.0 the new consistency check reported many problems in my semantic model/tagging - which underlines that I am not an expert in that topic; but also that it was not very intuitive until now. With the new UI support introduced for tagging for me this is not an issue any more. The interface helps to find the appropriate tag and create a consistent model (the info tool-tip is a top idea).
I still believe, there would be room for improvement - but the resources are better invested elsewhere in my opinion; as 5.0 is a huge improvement and I do not see a priority/problem here anymore.
Thanks for the great work done with the consistency check and UI support and the effort taken to retrofit the tags to the existing bindings!
Main credits should go to @andrewfg for his efforts on this. Please share the desired improvements even though they are low priority.
I will, and also many thanks to @andrewfg for the great improvements - not only in that area.
The feedback will take some time, as I have to understand the improvements first and also how they affect binding channel definitions.