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
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
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.