Evolution of the functional/semantic model

Development Misc
1

Edit: please note - this discussion was originally part of [wiki] Getting Started with OH3: rewriting the tutorial - 6. Model your home with Items & link Channels but was split away from it to keep the original thread on-topic. -@ysc

@ysc I don’t want to steal the thread with this, but it might be a useful question for others as well.
OH3 seems a lot more structured, easier to manage than OH2, which is really welcomed at least for me, because as smart home devices grow, it is a lot harder to maintain this.
What kind of migration we could expect from OH2? Existing Items and Groups will be migrated to this (what about textual configs) ui’s database and you can manage from there and maybe fine tune your structure from here, like adding Locations and Equipments?

Or this would need to start from a scratch?

Hope this makes sense and thanks for your answer!

2

Locations, Equipments & Points are just items, only tagged with the semantic tags. The UI helps you to build a proper hierarchy but if you have your items defined in files, chances are you already defined groups representing rooms, floors and so on (it was done like in the OH2 demo package). In that case you can tag the items in the files and they will appear on the model. See HABot Walkthrough (2/n): Semantic Tagging & Item Resolving for examples with textual configuration. You can also check the “show non-semantic” box to see all items including those which aren’t tagged.
You’ll also have the opportunity to copy-paste the contents of .items files in the UI to add them in bulk to the internal database, if you want to move from file-based configuration to UI-managed items, where you can then alter their semantic classification.

1 Like
3

Thanks that’s great!
I think this will be the point where I will move to a UI based setup, this looks a great UI for management!

4

I been thinking of management of item organization and I have some thoughts. These are free observations which I acquired over time. Please feel free to counter argument these either here or in separate topic. Since scope of official changes for OH3 is secret to me, due to lack of visibility of github project board for non-maintainer folks, I will try to strike here.

I do believe that usage of group items to organize visualization is far from a optimal solution.
Lets start from beginning. Item is something which is linked via link to a thing. Location is not a thing and unlikely will become one in above design. Usage of groups for making UI, from my point of view, is an attempt to squeeze as much as possible from existing OH model. The sad reality is that grouped items are kind of special-care. Existing design of OH attempts to hide that by embedding them deply in core, but they are still a special care. Their responsibility is not clear and they sometimes do too much.

I believe that proper way of solving this puzzle is complete separation of locations and building model into a separate resources. First of all, it will allow to make that part independent of the items, will separate duties and will let people model their buildings independently of groups.

I think that making a semantic model is very relevant, but since Location evolved into its own root “type” which does not have any direct relation to a Thing, Item, Link nor any other domain element OH hosts, it is a good candidate to constitute own sub-domain. When I see other elements from the above diagram, it directly or at least indirectly fits into existing model. That’s why we can have item-channel-property, item-channel-point, equipment-thing.
I’m not sure if existing model allows to mark things with “equipment” taxonomy. Would it make a sense to mark a boiler as HVAC equipment?

I do think that we also need a second thought, at least for a moment on the Property. We have now a QuantityType which can reflect a Energy, Power, Pressure and such. However we can’t do much about it, because QuantityType is again squeezed into existing model and pretend to be a Number instead of Energy, Current, Pressure and so on. These are valid item types both for UI and for the bindings to feed them in!

Ok, that would be all for now. That’s my thought on what could be further improvement in OH3 or OH4. My point is not to criticize anybody’s work, but to seek for best software design possible.

Cheers,
Łukasz

2 Likes
5

I kind a join your observations regarding locations. I think we should implement proper handling for Locations, Persons and Equipments. This could help maintenance and organization of a proper modeling. Bending everything in groups is very generic.

6

That would have been a very public discussion on ESH’s GitHub from 2 years ago. Apart from draft security advisories and the very occasional private message on Slack there’s nothing “secret” in the architecture and engineering decisions, you just have to be there at the right place and the right time, if you want to participate.
Could we please go back on-topic which is to document the existing.

1 Like
7

I have to say that agree with you. It seems like it was an an expedient solution at the time, but maybe now there is an opportunity to do something cleaner with 3.0? In any case, this isn’t the best place to discuss it. Starting a new thread or opening a github issue would be the best approach.

1 Like
8

Well, it is a very public thing from two years ago buried down in ESH issues which are archived. It described how to do things in ESH which is clearly the past, in the model which was relevant for OH2, with mechanisms available in OH2. Because past, is the past and I have no indication what future is, I posted my view on the things here.
Obviously I have a bad luck of not being in right place and the right time back then, hence I raised my idea here. If its wrong place, please guide me to another one where I could wait for a “right time”. Please spare me a github where nothing happens unless gets acceptance from the man holding a BFDL position in the project.
As there are more people than just myself, who thinks that groups might not be perfect for discussed topic I believe my concerns are valid and deserve normal discussion.

1 Like