More than one Semantic Models possible to manage in one OH3 instance?

I don‘t know where to place this question nor is that a total stupid one? I have in my house two different sections where different persons live and shoud have the ability to have its seperate oh-site for control their own „smart home“.
It was easy to manage with different site maps in OH <3.0, but I don‘t know how to create two independent semantic models and run them separately?
I will prevent to need two oh3 installations on two hardware devices.
Would be nice to get a hint!
Thank you very much

Well that’s ok but your post shows a somewhat lack of understanding how OH works in principle.
I suggest you take another course through the docs next.
You need not (must not, actually) create two OH instances or semantic models but you can create two (or more) UI pages and/or two sitemaps.

Thank you for your quick reply.
I have just tryed to find a solution as I would like to have it look like, but I have not got it with the UI pages.
As I know now that this is the way to realize my design I will dive deeper and hopefully I will understand to use the features right.


There is only one model. So you can’t create two models.

Therefore your options are:

  1. Use the visibility properties on widgets to only show certain pages/widgets to non-admin users and others to only admin users.

  2. One person uses MainUI and the other uses Sitemaps/HABPanel only.

  3. Two separate instances of openHAB.

That makes it now more clear for me how I have to proceed with creating my complete sematic model as it is not possible to create two ones. Currently I use OH3 only as admin user and I will try to add an additional user to get the additional possibilities. But as far as I have seen from some discussions this is not possible within the main UI, isn’t it? Is that to manage via the oh console or is there another possibility?

For now you can only manage users through the Karaf Console. I don’t have the command handy and my OH instance is down due to a hardware failure so I can’t look it up right now. Hopefully it should be easy to find through a forum search.

Helpful link found:

Your requirement falls off the mainline openHAB hence it will be quite difficult to get functionality you asked for. I guess primary reason is due to fact that most of houses are set with one family and role based access to pages is sufficient.
Long time ago when I did work on openHAB (in fact Eclipse SmartHome R.I.P) security concept I put few key concepts in there:

  1. Separation of credential extraction (cookie, token, user + password)
  2. Creation of security context
  3. Evaluation of access controls based on security context

Current security implementation living in OH does all above, yet in fairly limited way. The credential extraction is now mostly gone, security context works only with roles and access evaluation is limited to roles alone in semi static manner (its delegated to security mechanism of REST framework). While there is technical possibility to achieve more its not yet there.
I did my own experiments and I do have currently a running solution deployed in multi family building. Modifications I made allow to filter out items so different people will see and be able to command only subset of elements available in the system. This wast a bit of work. It did require quite a bit of modifications in OH itself. This is due to fact that “item” access must be pushed from user storage mechanism through authentication down to authorization. For authorization to be consistent changes are required in handling of events and also items rest api. Whole thing works without any modifications to user interface, since it gets only information it should get.
I ran into situation where widgets are shared between contexts. Technically speaking web browser of an user will subscribe to item which is visible only for technician. In return user gets - as an answer which I use to show and hide elements on the display.


The difficulty in this is about finding the sweet spot of efforts to put in.
Usually there’s little point in fully separating access to components / ‘protecting’ family members from each other. Most are fine with individualized UI landing pages.
OTOH if you really want strict separation, it’s worth considering individual instances, that’s often a lot easier than to try separating by users/roles/… .

o.k. that is now what I will check how it behaves and does it provide to realize what I would like to get.
To find out that all and play around will take a while. Next winter seems to be just round the corner :slightly_smiling_face:

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.