Multiple Users/Accounts

Feature Requests
43

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 :-/.

4 Likes
44

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…

4 Likes
45

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.

2 Likes
46

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

Just configure it only with what she needs.

47

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.

48

Same here. And,

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

1 Like
49

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.

1 Like
50

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?
8 Likes
51

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.

ezgif-1-465f3fea35
ezgif-1-465f3fea35768×479 142 KB

9 Likes
53

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.

55

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?

56

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
  1. 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.
  1. 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.
  1. Kiosk / Guest
  • Already covered by Kiosk option for the most part.
6 Likes
57

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

1 Like
58

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.

59

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.

4 Likes
60

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

61

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

62

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

7 Likes
63

Yes, we finally have multiple user support as of 0.74! Therefore, I’m locking this topic. It was our oldest and most voted for feature request, we finally got around to it :slight_smile:.

7 Likes