OK, it’s clear from the responses by @petro and @daywalker03 that there likely isn’t any interest in addressing this issue going forward, so I guess I will again give up on HA as a base platform and go off in search of something else.
Tragic, because it really is a nice base to work from and has a lot of the features I want, but this one defect is a deal breaker for me.
If there was hope for it to get resolved, it’d probably be worth sticking it out, but since there’s clearly no interest whatsoever from the developers in addressing it and a strong preference, instead, to tell people what they should or shouldn’t want, meh, you all have fun with that.
I don’t want to further divert the context of this thread, but just quickly: Actually you can control lights with circuit interrupting devices in terms of on/off/brightness, just not colour. In my case I don’t even need to speak and lights turn on/off and have the correct brightness for the time based on me simply walking into a room and only if it’s dark enough to require the light to be on.
I get your frustration with this, but I think you misunderstand the situation. I think even HA developers agree that we should have role based access control, as they have implemented first steps toward this system already several years ago. Plenty of people voiced support for the idea here as well. It’s just not finished and other things seem to take priority for now.
Also, on a side note - a light switch on the wall really does not have to be circuit breaker. It could be either a smart light switch or dumb one connected to a smart relay in the wall behind it.
As it was said above… authorization is hard.
And I agree.
Not everyone finds itself or the needs in a concept. RBAC there, ACLs here, CBAC (context based access control) somewhere else.
Would it be acceptable, to leverage a framework that specializes on authorization?
In my eyes, this could provide the flexibility of authorization models while providing a solid backend.
Several templates for HA setups could be provided in a drop down - like “family with children” or “office” or even provide the case of a user defining the access controls themselves.
Even Integrations and Addons can serve their own declarations to be integrated in HA. So a complex integration can serve own authorization structures, without upping the main complexity in HA.
Providing sensors for CBAC would be great - like “only allow user X to view camera Y if rain sensor Z has status = true”
As I was setting up my home assistant I got to a stage where I was going to start adding users and selecting what kind of access each has… only to find out that whoops. controlling access is not a thing.
This completely cripples home assistant, without restrictions home assistant is only suitable for a bachelor living alone.
This is because it was designed initially to react to input from sensors and automate repetitive actions, not as a means to remotely control lights and other things.
This is really a major problem and cripples HA to a point where it is hard to consider it for anything other than us nerds playing around.
This flaw renders HA useless for any applications, where you would have to give selective access to people (children, people with limited tech-knowhow, elderly people, gardener, cleaning, elderly care etc.) - so basically anything other than a bachelor-pad.
Just having the ability to hide “Logbook”, “Energy”, “History”, “Media”, “To-Do List” or the auto-populated "Overview” for non-admin would solve this, since within Dashboards you actually CAN set the acessibility by user! It can’t be this hard…?
I see that some work on user management is on the 2024 Roadmap under “later” - but if this curcial feature is included in that work and if later means “later in the year” or “later, after 2024” is kinda unclear.
I have now built a dashboard with fully custum button-based navigation while hiding the sidebar and header bar with browser-mod. (Header would be great for navigation, but there is the useless search-feature, that enables any user to control every entitiy!)
But even with hidden header and sidbar this is far from a secure solution: Even if you restrict the visibility of individual views to certain user, they can still access all dashboards and views with the URL / a direct link.
This really needs working on to make HA a secure frontend for multi-user homes. Right now it is not.
None of these are real RBAC solutions. that should be implemented natively, but to hide the search (or other elements) you could use kiosk-mode. It is not an RBAC solution but just something that could impede family/kids/spouse snooping around.
Yes, with browser-mod you can actually make different Dashboards default for specific users and hide sidebar and header bar - on a UI level that works fine. But its not RBAC by any means.
I understand the concept of RBAC and find it interesting that there isn’t one in HA.
In my home setup I don’t really have an “alarm” in the classic sense. We don’t have an alarm panel that we turn on/off. Instead I have set up different automations that are always on.
This weekend I was out for half a day, and my gfs dad was working on the planter that happens to be in the small porch area where the main entrance is. Every minute and a half all of the Alexas in the house would say “there is someone at the front door” and it drove anyone (except me since I wasn’t home) nuts! They ended up having to turn down the volume in all the Alexas.
When I got home and was told about the issue, I told my gf she should have just turned off the automation, and that is when I realized since she is a regular user she has no access to the automations so she can’t even enable or disable them.
Figured I could easily add automation access to all users, but that is not the case. I either make them all admins with full access or they stay as users.
I plan to find a work around tomorrow, plan b. I know I can create buttons to run scripts, so looks like at worst I would have to set up two scripts for each automation I want them to be able to turn on/off. One script would be to turn off the automation, and the other would be to turn it back on. Being able to create a switch directly to turn automation on/off would be even better, but not sure if that is possible.
That said, for my home setup, doing this work around isn’t really a big deal, but I could see how it would be MUCH better if users could be created with RBAC.
Since you are open to workarounds, make an input boolean that you check for being on in your automations or scripts. You can put that entity on a dashboard. Much simpler.
Thanks for your feedback. I actually got sidetracked today so couldn’t play with it much, but it seems I can set up a “button” card to turn on/off automations similar to how I am able to do with scripts. So will probably end up creating a new tab where I can have a list of automations my family might want to turn on/off on demand.
This nice thing about input booleans vs buttons is that you can easily see if they’re on or off. I have an automation that resets a bunch of “disable” booleans for the notifications each day at midnight.