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.
2 Likes
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.
2 Likes
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.
1 Like
you can have a button which calls an automation or service, can’t you?
BTW I’ve read about 100+ unread post and it’s sad how some users defend missing rbac or even disregard some other’s users legit use-cases just for sake of justifying this shortcoming.
3 Likes
So, I have tried to collect some thoughts and thinking into what a really good access control integration for Home Assistant might look like… Everyone’s house has a door right? So this is something that would be used by many and I think would offer a great improvement to the Home Assistant Core if there was a unified system architecture for access control built into the HA Core…
I think rather than homebrew solutions, it would be good to try and have an access control solution in Core that was based around interacting with off-the-shelf devices. It could be expandable and provide an architecture that home-brew solutions could feed in to, but I think there are a good few off-the-shelf locks that offer a lot of performance for modest investment, and trying to develop a unified solution to Access Control, rather than just manufacturer specific integrations would be a worthy goal.
A good example of a HACS extension to serve as a starting point is Keymaster. and evolution of Lock Manager. In the lockmanager documentation, it mentioned the inspiration of rBoyApps Smart Things Lock User Manager, and there is a good table that compares the features of a range of Z-Wave locks on the market:
Massive kudos to @ptdalen for Lock Manager Zwave Lock Manager and it’s evolution by @FutureTense because KeyManager truly is an awesome thing of awesomeness. GitHub - FutureTense/keymaster: Home Assistant integration for managing Z-Wave enabled locks
Shouts outs also to @nalipaz @hejman08 @firstof9 @petro who are all mentioned as having put development work into this.
I think that this provides a smashing framework for integrating access control into Home Assistant, and it would be good to see this adapted and developed into a permanent part of the Core and maybe augmented with some more UI thinking…
Sketching out an idea…
Some really good work towards this has been done by @mang0 but using button cards to bring up a dialogue box, see here… KeyMaster Z-Wave lock manager and scheduler - #1775 by mang0 I just wonder whether this could be made into a more compact grid such as the above that would work with large numbers of users / doors.
Within Keymaster, there are already a range of conditions that can be used to set when a lock can be accessed, Usage · FutureTense/keymaster Wiki · GitHub, but I think that this could be made part of a really slick UI/UX given work.
Support For Different Types of Tokens
So my understanding is that Keymaster supports PIN entry, but some locks come with different types of token, RFID e.t.c. You could even imagine a building scenario with different types of lock according to different types of application, and needing to assign multiple different types of token to the same user depending on the lock type - so being able to manage different types of access token and assign to different types of lock could be useful.
An Event Log With The Ability To Filter
So having a log of different access events, who has tried to enter and exit the building when and where at what time e.t.c. and the ability to go into the log and filter it and interrogate it in an easy way.
Some interesting info on how Paxton’s interface works here: https://www.paxton-access.com/wp-content/uploads/2019/03/AN1058-US.pdf
Access Control for Elevators
Looking at other use-cases that are in the market, Loxone for example also give an example of how their Access Control Module might be used in Elevators. It isn’t my use case, but good to see how well-rounded acess control integrations figure in other Home Automation systems:
Generate Roll Call
So this idea comes from the software of a commercial firm, Paxton, and could be more value added for making a smart system truly smart - generating a roll call… so a list of when users last entered the building (exits I guess wouldn’t be tracked though)… but could be useful to generate in the event of a fire status e.t.c. In turn, the red exclamation icons can be clicked to turn them into green ticks to mark users as safe.
These are just some ideas, I hope that this turns into a rolling thread where people can discuss and refine what an integrated approach to access control in the HA Core might look like. I hope it is a good conversation starter.
An interesting thread. I am trying to set up a simple one-door access system, but even for that I have stumbled at finding a commercially available solution. There are plenty of boxes that will read PIN and NFC or RFID and output the details over a Wiegand (wired serial) interface, but it needs something like an Arduino to decode that and send it via WiFi, Zigbee, ZWave or Bluetooth to HA. Have you seen such a unit available commercially?
I had implemented that kind of mechnism using HA, NodeRED and NVR,
Once the NVR notifies someone is identified (specific threshold) - NR is getting the event, checks if the face is registered as a user with permission in HA (custom attribute),
Based on the camera position, it opens the door.
Averge processing of face is less than 80ms, so it’s working pretty fast.
on top of that, I have set a dashboard of Grafana to monitor processing time and number of identification vs. failures per camera.
you can change do the same with NFC tags instead
1 Like
Hello, Can you please tell me more about this.
For example
https://www.ebay.co.uk/itm/394824898511
https://www.ebay.co.uk/itm/373514502503
https://www.ebay.co.uk/itm/203165441827
My solution uses the last of these combined with a custom ESP32 relay board programmed with ESPHome. I found some Wiegand code on GitHub that I included but have not yet tested.
Since my FR was closed as Duplicate, I just wanted to add my thoughts and concept here, too… It might be already there in one of the comments - at least, in a similar way… but anyway…
ok, I am still not sure how I should describe this Request… it is a bit difficult to explain - and this request will be more of a description how I could imagine the user profiles should work in the future, rather than a specific request of a single functionallity… so I will just try it to explain…
With the recent change on how the login ‘should’ work and the resulting complains about a possible security breach, the requirement of a real and well designed user-management system should be considered.
In my opinion, HA should come with a default Administration account that will be created during installation.
Within this Admin profile, you should have to create new User Profiles to work with.
-
Installing integrations:
- when you install an integration, you can do this from the Admin Account *
- You should be able to decide, if an integration should be available for all user accounts, or only for specific users.
- especially, if the integration is cloud based and works with specific user logins.
this would allow to have integrations that can run within the user-context of a specific profile and only this particular user could use the integration.
-
There should be a setting, what a user is allowed to do:
- for example: is the user allowed to change settings on a thermostat or is the user only allowed to see the current thermostat settings.
this should be possible on integration level, device level and MAYBE even on entity level - if a User is allowed to install integrations, they should only be available within the user context of the user that has installed the integration.
- This can be changed within the admin account
- for example: is the user allowed to change settings on a thermostat or is the user only allowed to see the current thermostat settings.
This would allow to have profiles for other family members, but you would prevent that someone can modify your task list, your calendar, or that your child could change settings of a specific device.
Decide, which user profiles should be visible in the login page (the now reverted, new login screen) - and if this user should be exposed on remote computers or onyl within the local network (only the local network, not just “private subnet”)…
→ The Admin Account should NEVER be exposed in this way.
On a User-Level:
Use Auto-Logout after x-Minutes
This would allow users with a Wall-Tablet to login into their account… after x minutes, the system should log out the current user and then show the login page again.
The LogBook should show, what device / state changed by which user:
→ User A has switched on the Light xyz / → System has switched on the Light ABC
→ User B has changed the Thermostat gde to 123… and so on. (seems to be already available)
I know, that such changes are a big refactoring of the current user-profile system - and would also be a big “breaking change” for existing installations.
But in my opinion, the User-Privileges and User Profile system is something, that is not “state of the art” for a couple of years now - and should get more focus with a growing user base - and becomes more and more important compared to design changes (which I still like [at least most of them] 
)
1 Like
RBAC is so critical. In my opinion HA is near perfect, it simply lacks access control. In a perfect world this wouldn’t be necessary, but it would be nice to not have to grant guests and kids full access to everything, instead of being able to limit them via RBAC simply to the devices/rooms/UI required.
1 Like
IMO, we should split the RBAC rules on an entity level, because permissions may not suffice on a device level. For example multi-channel relays, where each channel may control one room. (…and I’m confident that children figure out how to control the light of their siblings if they had write access to the whole device. )
1 Like
Just a bit of an update: I merged a Month of "What the heck?!" with a Feature Requests. Partly a mistake on my part because I didn’t realize a FR already existed. Sorry about that.
1 Like
this definitely.
hopefully this is one added to the roadmap.
Once again, RBAC is discussed in the “month of WTH” - to everybody wanting this feature for a long time, let’s also vote for it here: WTH no access control - #20 by InventoCasa
Maybe this time we will get enough attention!
1 Like
Yes! This is my number 1 missing feature! I would love to only expose certain entities to my kids. They don’t need to be able to open gates and garage doors or even unlock doors.
My oldest has figured out that by using CarPlay he can see everything whereas before I only allowed him to see a specific dashboard.
+1
Control on entities sounds great. I am also looking for more control to UI actions, i.e., allow users to enable disable automations, but perhaps not view them.
HA has the opportunity to capture both the home consumer and ‘enterprise’ home automation markets. As an ‘installer’, hoping to give users a different level of control.
1 Like
Thank you for the link to the vote.
I just wanted to chime in – I live with a few friends, and the reason they tell me they avoid using our home automation controls is that it’s too easy to change something they don’t intend to or feel they shouldn’t have access to, like a light in someone else’s bedroom. Conversely they end up keeping devices in those rooms unconnected to automation so that no one else can toggle them.
As a systems administrator and cloud engineer, running multiple HA instances for each member of the household is anathema. RBAC controls around who can access what would solve this reluctance problem completely.