Multiple Users/Accounts

Feature Requests
#1

As posted at Multiple Users/Account.

I want to put a tablet at my living room so that my family members can control the switches, arm/disarm the alarm, see the weather, etc… but cannot access certain switches such as those in my room. I also want to let my other family members to control the switches of their own room using their phone.

Here’s the Pivotal Story tracking this request.

EDIT: Added Pivotal link

8 Likes
How to give different (less access) on a user base
Multiple Users/Account
Multiuser setting
Multiple users + API-keys
Support for multiple API keys
User logins
Lock Down the UI
Implimination of a user base login exploiting Custimize
Anyway to Hide developer tool section? in the HA frontend
Multi user with their own lovelace UI yaml?
User UI - purpose?
Add multi user concept to hassio
Native User Manager w/User Logins/Views/Access Control
#2

This would also be useful to limit access to the api. Especially where you want to update a state from a remote system that you don’t have exclusive access to.

#3

I would like to see something like this also. Either multiple users/accounts, or some way to add groups to the UI that don’t have the tabs showing the other groups or hamburger menu.

#4

Per-device frontend would be useful when putting multiple tablets into kiosk mode that would show the date and time as well.

#5

I’ve thought about this before. It would be great to be able to limit what users can do, the kids being a prime example, allow them to control their own devices but not turn the TVs off and lights on when you’re watching a film.
This would also be useful when creating room specific devices, I’m thinking about mounting a tablet in each room, as you can get them for the price of a light switch now! Each device would have a custom screen with its rooms configuration.

1 Like
#6

I have downvoted the thread in order to make room for threads I want to vote.

#7

I live in a multi-story building and want to do automation both in my apartment, internally, and in some “public” areas of the building (staircase lights would be an example). I want to give access to Home Assistant to the rest of the tenants (family) of the building, but not to private systems inside my apartment. Moreover, I want to make sure that I only allow anyone but myself access to finished items in Home Assistant and not to my test devices/scripts etc.

So a multiple users/accounts feature would be extremely useful for my case and others’ I assume.

Thanks!

#8

First post, forgive my ignorance. Never ran Home Assistant although that is likely to change today.

I want this feature and am discovering it is missing from almost every open and commercial platform.

Could I simply run 2 instances of Home Assistant with interfaces on different ports? One instance has only the devices I want group A to see and another instance has the devices I want group B to see?

I understand the limitations of only one application “owning” a Z-Wave stick but in general, I should be able to share access to network controlled things (like a vera), right?

What is the flaw in this plan (before I go try to set it up)?
David

#9

Your post made me think…
I think Eventstream Component can provide seperate interface and views. You can run multiple seperate instances, on same device and different ports in desired.

Admin interface = master
Secondary users would be slaves setup to view. View only can be provided by creating MQTT sensor or similar showing state but not providing interface.

Biggest issue is Dev tabs.

#10

Just an idea on how to implement this: use a concept similar to Linux-DAC. Entities by default have a 744 mask, which may be modified by specifying another mask via customization.
I guess we wouldn’t really need read + write + execute, since writing would result in being able to execute. But at least the concept would initially be familiar for the users konwing their way around OSs with a smiliar permission-system, and it’s pretty straightforward to comprehend.
So to really make use of this we would additionally need some implementation for groups and users, which would be affected by the 44-bits in the 744 scenario.

#11

This is something I would love to see added as well and would be particularly useful when guest come to visit the home. The ability to restrict what they can see and do would be a huge benefit.

#12

Any progress here? I’m interested in paying for development of this or putting up a bounty? Anyone else care to join? Can anyone suggest a developer who might be interested.

(Off-Topic) Can't Open "Multiple Users/Accounts" Thread
#13

As part of this I would also like to see multiple http api_passwords if possible

#14

I think the easiest way to implement this would be in two parts. It wouldn’t give all the features everyone is requesting, but it would represent something usable for most of the desired cases.

PART 1 (easy?):
We already have “tabs” (groups with view: yes). If Home Assistant provided a URL to a tab view with no sidebar, and no developer tools, this would, at least in the view, limit the abilities of that particular page.

Since the web interface actually calls the API, the entire set of devices would still be available, however, the view of them on the presented web page would be limited.

PART 2 (harder?):
Allow different API passwords for each tab view. The API calls would have to allow for more than one password, and if the master password was not used, the entity IDs being acted on would have to be cross referenced with the entities available to the api password as identified by the “tab”. Only a single level of permissions checking would be needed. If a tab has access to a script, but not a light, and the script controls that light then, through the script ONLY, that password has access to that light. An exception should be made for groups, where, if a group is part of the tab, the entities in that group would be included in the permissible entities.

#15

In the last days I implemented, as a proof of concept and discussion base, basic support for multiple API users; allowing to restrict (write) permission for the switch/command_line component (in the backend only, and only for the command_line component as of now).

If logged in as a user that does not have 'w’rite access to a switch/command_line entity then the state will not be set in the backend, even if the GUI currently allows to toggle the state.

You can find the permissions_feature branch at https://github.com/k-laus/home-assistant/tree/permissions_feature; for more details (example configuration, …) please look at the checkin comment https://github.com/k-laus/home-assistant/commit/fc18173f519e88f3e03c6eeddca986a98e9c3f37

Any suggestions/feedback welcome.

Next steps:

  • move the has_perm() method and contains_perm() function from components/switch/command_line.py to a better place - an own Permissions class or just to the Entity class?
  • generalize, to support ‘permissions’ configuration/attribute for all components, starting with those that are more likely to be restricted.
  • does it make sense to store the permissions info, i.e. which user can access which entity, in a central place - inside the “State” class? E.g. on accessing the state via API from a remote HA instance, the permission info could be used to completely deny access to certain components, those where api user does not even have 'r’ead access; and could deny changing the state if api user does not have 'w’rite access. * In the frontend components without at least 'r’ead permission could/should be hidden.

Kind regards,
Klaus

1 Like
#16

I changed my mind on having multiple users or account.

Why?

After having smart home for almost a year now, I realize one thing; nobody wants to walk up to a wall to control the lights.

The best thing to do that is already in our hand; smartphones.

But then, nobody likes to open up another app to do just that. It takes time (even few seconds can be frustrating) and interrupt the user experience flow. Since everyone in the house is already receiving notifications to their phone via Telegram, it only make sense if they can control the house from the same place.

With HASS Telebot, I can do just that. From this, I manage to modify the code and have this…

Each members will have different keyboards/options.

So with this, I don’t need multiple users anymore.

6 Likes
Google Allo Integration
#17

How about optional passwords on group tabs.

#18

A feature I would also love to see added so that kids can only control their room and select communal ones. Could also be used in a workplace to prevent everyone access to say the server room lighting or managers office lighting. A simple MySQL db with tables that link devices/groups to users should be possible??? The users can then save their password on their device so that logon is easier if they choose.

#19

Here is a Component in development: Person Component (Users)

1 Like
#20

You can accomplish the multi-user with various passwords and limited controls with what is already available. Say you want two (or more) setups for parents and kids. You can do it with the following:

  1. Setup two (or more) instances of HomeAssistant in two different vert environments (or on different computers) and setup an MQTT server.

  2. For MQTT components, you can just setup both with different configuration.yaml files for the different passwords and controls that you want each to have. For the parent, you can keep discovery on and the kids one you can turn off the discover and put all the desired components in the yaml files.

  3. For non MQTT components, it gets a bit trickier as some devices will only write to one instance or receive from one instance and then you need to setup that device to mainly be controlled by the parent instance.

  4. To setup communication, send messages back/forth from/to the child instances to communicate with the parent instance. In those cases you setup automation in both (or all) instances so when you receive sensor data on the parent instance, it will trigger an MQTT notification (which you can hide so it won’t be seen on the control screen) to be sent out to the child instances. Likewise, for control components, you can set them up so they also trigger a MQTT message (like the kids turning on a switch) so it will send a message to the parent instance and trigger the appropriate component.

  5. Each instance of HA will have its own configuration.yaml file with its own password and available components. So until a component comes along that does a better job, you can run everything through the MQTT server.