According to the docs, there is a "user_id" property for the "person" entity.
What is this property for?
Can anyone share some use-cases for this property?
You can use it in automations for instance. I use it in Node-RED automations, to decide to open/close curtains, turn on/off lights, fans etc. If you turn of the light through the UI, it will send the user_id in the event_state. Which allows you to see if either a user turned off the light or not. When you turn it off through Node-RED, it sends the user_id of Supervisor/Hass.io. When triggering using external ways (like a curtain remote that operates directly with the curtain) it sends an empty user_id. Though I see that some components (like Scheduler Component) also sends an empty user_id.
In my case: my curtains will only open on motion, if it was closed by an automation prior to it. If a user has closed the curtains it will send the user_id then the automation will not trigger on motion (since it sees the user_id). By saving and restoring the user_id, I created nodes that either go route A or B depening on the user_id. You can apply this to many automations and create automation concepts where you want to decide wether or not to take action, depending on who triggered something before.
I have noticed however that curtain entities sometimes do not send the user_id (either when a user opens/closes or automation), it’s inconsistent. This has to be a bug, so I’m gonna report that (I have figured a way around it for now using input_booleans right after service call automations).
It’s a unique ID assigned to the user that, for example, comes in the context for an event indicating which user triggered the event. You can also translate it into a username with a template like this:
{{ states.person|selectattr("attributes.user_id", "==", "mylonguserid")|map(attribute="attributes.friendly_name")|first }}
1 Like
I think these cases are not about a person - these are about a user who initiated an event.
Surely "user_id" is useful for automations to describe “who made it”.
But I do not see any reasons to associate a USER with a PERSON.
I have a list of person entities associated to device_trackers, I can see where my people are; I can create automations like “open the gate when a person arrives” etc.
I do not see any need to know user_id of some person.
I use it in our Waze share.
When you share a Waze drive we just share it with Home Assistant and the user_id determines who should get the notification.
So if I send it then it goes to her and vice versa.
And if that person is home then it’s also spoken out in the speakers.
You can link a person to a user, that’s when a USER is associated to a PERSON. This is exactly how it’s explained in the docs you read:
The user ID of the Home Assistant user account for the person. user_id (aka ID) of users can be inspected in the “Users”/“Manage users” screen in the configuration panel.
It’s an optional feature, for those that want link a person to an exisisting user through YAML (you can create and link a new user when creating a person through GUI). Why would you do this? Well if a person and user are linked, and you login using the mobile app, it knows: this USER logged in, which is linked to this PERSON. So let’s set this MOBILE DEVICE as tracker for that PERSON. (Since you can only login by user and not person).
This is a non-automation use case that is only possible by linking a person to a user. Sure you can do it manually, but by linking you won’t need to. And in order to link it through YAML, you need to fill in the user_id at the person integration.
I believed that:
- device_tracker is created automatically by MobileApp integration when some user is logged in from HA mobile companion app;
- this device_tracker is NOT linked automatically to this user; it is created for a DEVICE like “iPhone 99S”;
- to link the device_tracker to the person, it is required to define it in the config:
person:
- name: XXXXXXXXXXXXXXXXXXXXXXXXX
id: ildar
user_id: "XXXXXXXXXXXXXXXXXXXXXXXXX"
device_trackers:
- device_tracker.life360_ildar_iphone_5s
- device_tracker.iphone_5s
Am I right?
Yes. Because you can’t link a device_tracker to a user but to a person. So if you don’t fill in the user_id of the user in the person integration, you need to set the device_tracker to a person yourself, either through GUI or YAML.
But if you DO create a person that is directly linked to a user, you won’t need to. The only reason to fill in the user_id in the person integration, is to they are linked together. If you create a new person through GUI, you can automatically create a new user (which links it) so that person can login using the user(name).
And the reason why you would want them to be linked (as a use case) is so you don’t have to set a device_tracker for a user manually. This is mostly usefull if you set up a new person through GUI, since this allows you to also create a new user and link them in one go. If that person then logs in using their username, the device_tracker will be automatically used for the person.
So as you say:
I do not see any need to know user_id of some person.
In this case you don’t ‘need’ it. It works regardless since you already set up device_trackers to the persons yourself. If you like doing this manually you can. However, for other people that just like using the GUI to create a person, it’s a nice feature. Just create a person, select ‘allow to login’ option, which then sets up the user and link them. If that person than starts the mobile app, logs in using their username, it will set the device_tracker to the person automatically.
Also, when you loging using you username and it sees the person, it will show the user picture on the bottom of the sidebar.
Yes, I prefer to define all settings manually; btw, I dislike the new approach of setting integrations only via GUI, prefer using yaml.
Right, this is a useful feature.
Thank you very much for your detailed answers!
1 Like
Agree (though I do understand they need to if they want to attract more users). As long as core can always be done through YAML, it’s fine by me. I tried creating some input_selects through GUI. Yes it’s easy. But terrible if you want to add some extra options in the input_select at a later point, since it’s not possible. Or if you want to re-arrange the options. You have to delete all the options and put them back in one at a time. I’ll just stick with YAML where I can edit them anytime I want and keep the options in the input_select in alphabetical order.
I don’t know what led you to that conclusion but it is possible (and easy).
Add a third option to an existing input_select:
Third option added:
What isn’t possible is to easily re-order the options. Which is why I still tend to configure them in YAML.
I was a little too fast on the keyboard. I meant saying that adding stuff is a pain, because you cannot re-order them unless you delete everything.
Yes, that’s very true and a definite shortcoming of the UI method. You also can’t modify an existing option.
Altogether, it’s serviceable for simple input_selects but when there’s a need for many options that may need modification, the YAML version is (currently) more flexible. Perhaps these features will be added in the future.
1 Like
Big thanks ! it worked !
Here is how I solved my case