Multiple Users/Accounts

[bobtosh]

I’d love to have different access for me (admin), and other users/devices, most probably the easiest would be different passwords, or even better - user name and password. Thus the users can belong to user group with given permissions that are set in the configuration beforehand. The story short - I keep expanding the front end and bring awesome (for me) integrations and controls/automation, but not all of them are intended to be used by all family members, also the ipad that is at home should be used as a remote control only and as a notification recipient.

Additionally to user permissions, next step would be tracking of who is currently logged (looking) at the frontend so that proper automations and notifications are sent to that logged users or other user - the admin, etc.

[eschumann (Erik Schumann)]

Just a side suggestion : wouldn’t you be able to achieve most of this by putting an apache in front of Ha? If you do this and provide tailored floor plans in kiosk mode, you can restrict access to these url in .htaccess on a fairly fine grained level with as many users as you want.

[selfisch (Timo)]

Sure, but this is not the goal. There are several third party apps to achive parts of this.
But the main goal is, to have some kind of user management inside HA, instead of fiddling around with external workarounds :-/.

[bobtosh]

Exactly. I want to maintain single application, while at the same time to make it better. HA is great, but user permissions is a common approach that should exist in such powerful platform, not only for security reasons but also for a better usability. My wife simply hate the app on her phone because she doesnt understant and use 95% of the switches and tabs…

[pauloromeira]

My use case: I share an apartment with a few more people and I want to measure individual power consumption depending on which user turned on the equipment (e.g. the electric shower). With user accounts this could be pretty straightforward. Each user would have an energy counter attached to its account.

Just keep in mind that home assistant isn’t just for wife and kids. It could be used in broader situations.

[j.assuncao (Jorge Assunção)]

Why don’t you try MQTT Dash on wife’s phone?

play.google.com

MQTT Dash (IoT, Smart Home)

Warning: This app is for nerds only :) If you don't know what MQTT is, this app is likely not for you. - User forum: https://groups.google.com/forum/#!forum/routix - - With the app you can create dashboards for your MQTT enabled IoT Smart Home devices, applications and Home automation. - Phones and tablets are supported in both orientations - Share metrics among devices via shared topic - Simple and easy to use dashboard-like UI - Designed to run 24/7 (memory efficient, reconnects automatically)...

Free

Just configure it only with what she needs.

[bobtosh]

Reason 1: she has iPhone.
Reason 2: how to display the IP cameras with that?
Reason 3: one more app to setup/launch, support.
Reason 4: actionable notifications sent to ios home assistant app, so still she need the ios app.
Thanks for suggestion, though.

[AndrewBucklin]

Same here. And,

Reason 5: The iOS app for Home Assistant gives location awareness to HA.

[tschmidty (Tod B Schmidt)]

Ugh, the problem is this is a huge undertaking to implement within homeassistant. And at a base level you are talking about things that there are currently workarounds for.

If you back up from the ‘total security’ aspect of it, I suspect simply implementing it on the frontend with multiple users would cover the use cases I see here (family, etc.). Different users being provided a different view. This would cover the app since it just displays the page but would probably need a tweak or two.

Opening the REST API to the world would be better and more easily implemented by setting a proxy with only certain api calls allowed and could have it’s own authentication. It probably wouldn’t be too hard to implement there, but would also break everything that used the REST API so would be a lot of work also.

[AAllport (Adam Allport)]

Logically, I believe a large number of users in the thread are thinking too big. There are essentially 3 things being requested,

1. Separate Authentication
2. Authentication Scoping
3. User Profiles
   2&3 may be more advanced and require a reworking of the frontend infrastructure.
   However, 1 may be more achievable, would people be interested in swapping the single password system to multiple usernames and passwords, this would allow, (in theory) different devices to use a different key (username:password). By doing this, it would be possible to ‘cut’ different devices if compromised.
   Would people be interested in seeing this implemented?

[covrig]

I started a few PRs to enable basic child/guest/wife/husband frontend proofing.
However, it will only be security by obscurity. It can easily be bypassed if you type the correct URLs in the address bar.

How it works:

• Create an input_text with the option mode: password enabled. A PR was started for this mode.
• Optional: Enable in the frontend/themes section the variable display-dev:none. This will hide the Configuration link (if enabled) and the developer tools (Services, States, Events, Templates, Info) - all in the sidebar. A PR was started for this mode.
• Multiple themes are needed if the display-dev:none is used.
• Create some automations (better) or/and some scripts using the value of the input_text (the mode:password is optional) to hide any group you want (group.set_visibility) and the developer tools (if wanted with frontend.set_theme).
• Using the secrets.yaml file would help a bit.

Example:

input_text:
  password:
    name: User management
    initial: Some Text
    mode: password
--
frontend:
  themes:
    admin_theme:
      primary-color: green
    restricted_theme:
      primary-color: red
      display-dev:none
--
User_1:
  trigger:
    platform: state (or template)
    entity_id: input_text.password
    to: 'password'
  action:
    - service: group.set_visibility
      entity_id: group.a
      data:
        visible: True
    - service: group.set_visibility
      entity_id: group.b
      data:
        visible: True
    - service: frontend.set_theme
      data:
        name: admin_theme

User_2:
  trigger:
    platform: state (or template)
    entity_id: input_text.password
    from: 'password'
  action:
    - service: group.set_visibility
      entity_id: group.a
      data:
        visible: True
    - service: group.set_visibility
      entity_id: group.b
      data:
        visible: False
    - service: frontend.set_theme
      data:
        name: restricted_theme

• Another option is to create an automation where the value of the input_text should be compared with the value of anything else (state of another sensor, current time etc.). This way the “password” always changes.

[Tyler_Terzigni]

Would you mind sharing your config for your IP Camera for the Meteoblue? I cant seem to get it working but had no issues with http://www.yr.no image pulling.

[dzungpv (Viet Dzung)]

I think since HA is wide use. This feature is very importance and make HA perfect. OpenHab have plan to add this too, can we study from it?

[BlinkyLights]

I sometimes feel like HA system makers live alone or keep control out of everyone’s hands.

Reasons I want Multi-User:

1. Admin / Myself:

• Full control

2. Wife

• Runs the iOS app for presence detection
• Needs access to Kid control items that have been created (can lockout the TVs and internet for the kids devices)
• Probably doesn’t want to see any of the admin screens just the core views.

3. Kids

• Would love to load the iOS app on their devices but they would gain access to things the wife and I don’t want them to
• Mostly useful for presence tracking.

4. Kiosk / Guest

• Already covered by Kiosk option for the most part.

[claudiopi (Claudio)]

In my case I want to give HA to final end users. I will be in charge of configuring all devices / scenes / automations and that is ok.

But I also need a simple interface where users can at least update their HA password without going to edit a .yaml file (they are end users, not tech-savys as us)

At least to start with…just a single user where you can change the default HA password and recover it using an email account.

Other option I see is to delegate authorization to a third party service such as Auth0, but this requires to be online.

Thoughts / plans for this ?

Thanks,
Claudio

[dzungpv (Viet Dzung)]

I think this feature need to implementation before 1.0 release. Now i want to share HA to my wife, my kids but it risk, they can random on/off, change the script etc…
But HA build with mine for only one people with all the power, so it is hard to add with exist code.

[bratnetwork (Bret)]

I’m going to post in here just for another voice to suggest that this be implemented. I think it would be super useful to be able to give different people access to different features. Access to only certain devices / scripts and restrict access to making changes. Even the idea of using a phone or tablet as a wall mounted controller, would be nice to have restrictions so someone can’t play with it while you’re not there and get into deeper settings and gain access to devices you don’t want them to.

[danielperez505]

I Agree, this is essential for HA, I love the simplicity and all the effort that has been put in this project but this feature is really necessary. Looking forward to see this option soon.
regards

[danielperez505]

I like the idea while the feature is implemented thanks for sharing this

[awarecan (Jason Hu)]

Basic multi-user support already in 0.74 release. More features are on the road.