Multiple Users

I am new to OpenHAB. Currently I am looking for an automation platform for our smart office project. OpenHAB seems interesting to me. However, in order for my project to work, I need it to support multiple users configuration, i.e. different users will have different access to the “things” in the office. And also I should be able to configure automation rules based on different users login/detection.

For example, user A walks into the office and his/her office light and the aircon will be turned on. If user B walks into the office, his/her table lamp will be turned on.

Is this user based framework already available in OpenHAB? Or someone has started working on it already? If not, what will be a best way to implement this?

Thanks.

1 Like

There is no built in way to give fine grained access to different things based on user. You can have multiple users but they all have the same access to everything.

There is no way to determine who is logged in.

I’ve thought a little bit on this and without massive work changing OH itself, I would set up a reverse proxy which handles the logins and forwards to a custom sitemap that only has the things that user can control on it.

i want coding for user level authentication and which language and tools will i use ? thank you.

If you want to use a reverse proxy see ngnix or apache programs. If you want to add something to OH itself, head on over the Eclipse SmartHome project as that is likely where the changes would need to take place.

Something new within the last 12 month about this topic?
I need different users witch have different access to the “things” as well

No change.

Follow these issues on Eclipse Smarthome to keep up to date with any progress.

It’s so sad that openhab is lacking of this feature.
Will the administrators add it in near future?

Why don’t you create a habpanel locally on a specific device, giving access to items that is not given to the habpanel or sitemap hosted on the OH server?

Well that’s a little nuisance when unnecessarily expanding your system.
I’ve a plan to implement OH2 in my very apartment, which has 4 guys.
To think about each user must have a specific device => that would cost a lot. And what would happen if some more new guys move to my apartment? What is the thing should do then?
Just my thought, I hope you can suggest some solutions

Looking at it from another perspective. Imagine a system which is using for example a multi room audio like sonos. You would expect that each user has access only to a limited number of speakers. So OH would not only need tho limit that per item, it would ned to limit possibility to group all boxes. However that is a function from within sonos, in other words the connected system.
I’d say for such a system of systems a complete multi user functionality can only be integrated up specific limit.

There are no administrators. OH development is not directed. All development on OH is done on a volunteer basis so it will get implemented when someone volunteers to add it.

But, like opus indicates, it is not an easy thing to implement.

Well I have a very clumsy idea to start, but since I’m not a developer so I dont know how to do it.
My idea also similar to one of the comments above. We creat multiple .sitemap files on our OH2 server (demo.sitemap, demo1.sitemap…). Then we can use something like nginx to redirect our web browser to one of those sitemaps based on the priority level of our account. For example, I enter user name like admin or root, the password might be anything on earth, the browser will redirect me to demo.sitemap with the display of full items. On contrary, others account will lead me to other sitemaps with less items on it.

But I dont know how to configure it with nginx, please show me how?

If anyone has a better idea, please enlighten me

There is a fork claiming it uses groups for authentication…

haven’t tried it myself since I need some futures from snapshot release… thoe it seems like an interesting way to cope with multiple users without much change to OH itself…

sadly the authors did not submit pull request to OH or ESH, so we don’t have it merged…

Maybe someone can take upon the idea and implement it?

Best regards,
Nejc

I would caution on that fork that it appears to be an academic project and the developers appear to have lost interest in it since publishing their paper. I would be very cautious in adopting that fork as it is already almost seven months out of date and will only continue to become more so over time.

It really was unfortunate that they did not try to integrate their solution into the baseline, though there are aspects of their approach that, at least to me, feel a little hacky and not consistent with a good longterm solution that fits with the OH and ESH architecture. But that is based more on a feeling and less on concrete examination of the code. If the authors are on this forum and see this, I’d love to talk about it.

Yeah… I wish they were… I tried contacting them on their github, but seems like they are ignoring it… :frowning: