Openhab for Multiple Users

Hi All,
I was searching for the possibility of having multiple users for OpenHab UI.
I am using OpenHab 3.0 and got few links which allowed to create the multiple users via script.
However, I am searching for some solution where we have multiple admins/users and each one of them is having there own set of things, channels, items, etc. Each admin can create there own users which can use the resources created by the admin.

For example:

Group 1

  • Admin 1

  • Thing 1

  • Thing 2

  • Thing 3

  • User 1

  • User 2

Group 2

  • Admin 2

  • Thing 4

  • Thing 5

  • Thing 6

  • User 3

  • User 4

Not sure if this is possible. If yes, then can someone point me to right direction?

Not today, no.

This is quite contrary to the way OH works and IMHO does not make much sense in a home automation context anyway.
OH isn’t a hosted cloud solution. If you want to operate multiple buildings or zones within a house with different access control requirements, then install multiple OH instances.

Thank you for your response.
I will try to change my strategy and try to find some cloud solution for this.

I have a partial implementation of your requirements. It required forking of openHAB core, cause core is not ready for that and it can not be decorated through intercepting calls.
One thing which I do not understand fully is what forces you to keep scoped access to things and more importantly their creation? Are these restrictions bound to thing types or any other root which could be somehow expressed?

Hi @splatch
Could you elaborate on your partial implementation? Did you change the core to become partially ready for multitenant?
As for the use of the multitenant, I can imagine that if you have an apartment building and you want each tenant to operate their own flat, but still you want to run it on one raspberry pi then this could be a nice way to work.
The key thing is to make the part that is common to all instances to be not occupying space more than once and not have to start multiple containers which also has that overhead.

In my opinion, this is an absolute bad idea. If there is an issue with the raspberry or openhab, it will not only affect one tennant but all.

Yes, throwing more hardware and infrastructure at things will improve stability. But in a society where we need to reduce our footprint, thinking about efficient solutions is a good idea. And it is not as if RPIs explode every day


So, with a bit of engineering we can reap the benefits and avoid the downsides.
And be kinder to the environment.

Still interested in the approach of @splatch

There are multiple systems running in modern muliti family buildings which depend on singular components. Whether it is heating source, circulation pump or other thing it is usually not duplicated for economy reasons (there are duplicates and backup systems for large commercial or residential objects). Same thing applies to building management systems which are fairly often deployed on PC class equipment or cheap servers.
These devices are used as a stable base for software and database installations. Its up to us where we draw the line. If someone needs a fail-safe deployment it is possible to run openhab in master-slave (active-standby) mode using a distributed filesystem lock provided by karaf. Its matter of requirements made by the end customer. Reliability of raspberry is questionable but nobody forces you to run a multi family building on SD card.

We have couple of buildings with intel PCs and multiple zone controllers which are based on CAN bus. Thanks to this bus main heating controller knows what is demand generated by apartments, we on other hand can access and remotely write setpoint values. I also have couple of setups working with BaCnet but without multi tenancy, yet in fairly large objects.
I did the multi tenancy work and it works both for items (listing, commandong) and SSE stuff (people do not receive events for items they can’t see). I did also a proof of concept work which allows to limit visibility of pages and widgets (it works, but I don’t have it in production yet). We also made our own proxy service which works independently of openhab cloud, next step will be centralization of user management so we will be able to grant one user access to multiple openhab installations.
Sources are in github. Look at my github profile. For courteously reasons I can’t link it directly.
All these changes are not part of openhab cause there was no consensus if its needed. Hence I run my own fork with fine grained access control.

Absolutely fine, it was just my opinion. I would never rent an apartment with such a shared installation.

Operating multi tenancy installations is always tricky, no matter what sort of software you run.

You could also run multiple instances, one per apartment plus eventually an ‘infrastructure’ one, and have them talk to each other via openhab remote binding where required.
That would work with the existing access control capabilities.
You can even put all of these instances on common virtualized hardware.

2 Likes

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