what about then for my wife? when she logs in with her person which has a user, the device tracker will associate with her person. so now she needs a separate user login for the device that shouldn’t have its tracker attached to a person, and still has her own person/user for devices that should.
The summary is corrected I think. The point is that this service (expecially if you use Person Tracking with Home Assistant) is not intended to be used with a single log-in.
That’s simple and adding a new account will not make things more complicated.
Just to prove that you’ll have one and only one, here are screenshots:
1 person.
They cannot log in.
I create 1 user.
I now have 1 user, that is not associated with the person. That displays my correct dashboard based on my user.
1 Like
You can create a user per each person + one generic user for all of those devices to be left “separated” from the Person Tracking feature.
So:
1x Person + User for you
1x Person + User for your Wife
1x User for “Generic Devices”
That’s one way to do it, but that’s not what he wants. I’m trying to show him how to do it but he’s not reading my responses. Or he doesn’t understand that users and people are not the same.
well, its the wrong way around if you ask me… its instructing users to think about the way things are programmed, instead of its being programmed the way users use the app. This isnt the only spot.
Person has other flaws though, but Ive learned to live with those… We have been able to mitigate those flaws (losing the lat/long when connected over wifi as the biggest of issues) to have Person entities use eg only a single Composite Integration tracker to which we feed the individual tracker, instead of feeding those trackers to Person directly. CC Composite does track those individual devices in a more useful way, and the better tracking result is then used by Person.
Ofc, that is not taking into account the (new) auto adding of other trackers, which kills that whole idea.
Back to the current OP: in my usecase, I only need the location to be tracked on my Mobile phone, or, put differently, my mobile phone is the most reliable predictor of my location. 
Dont need it to track my other iPads or Laptops. If I travel, just track the phone.
So, If I can fix this issue by disabling tracking on those devices, that would be simplest, and in all honesty, most logical
1 Like
And you can do that. That’s why I offered it as the original solution. It’s the least amount of work in order to get it to work the way you want. If there are issues with this path, then that is a bug.
1 Like
I understand I can create a person and uncheck the box allowing said person to login. Then I need to create a user for this person individual to login. That now disassociates a person and a user but allows me to manually assign a device tracker to the person and no tracker entities will automatically be added to the person when I login. I now have to do the same thing for my wife because she has different dashboards she uses than I do, but she still has a device that should track her location. So now I have two person entities and two user entities which are not associated to allow for logging into devices which should not be tracked but keep the device tracker enabled for use in other automations and allow each user login to have different dashboards visible and then manually assign a device tracker to the person.
You do realize when I create a new user I will get a new user_id and because one of my dashboards is YAML built, I now have to change all the views to be visible to the new user. But I have to delete the current user associated with the user before creating a new user of the same name or some how disassociate it from the person without deleting it which would be ideal then I’m not having to change user_id in the YAML dashboard.
Again, a simple question on user login to a new app would be the ideal user experience. Sure it may not be the easiest to code, but from a UI or usability standpoint it seems to be the cleanest.
No.
Edit your current wifes person that already has the device tracker attached. Uncheck “allow this user to log in”, this will delete the user. Go to the user page and recreate the user.
Yes, you will have to update the id’s in the visible field for your views.
Not really. There are better ways to handle this other than a confirmation box, like a setting. But then again, this isn’t a feature request, this is a support thread.
You confirmed everything I said. I have to create new users which creates new a user_id which forces me to edit my dashboards from the frontend and YAML. And for some, that’s not really user friendly unless you love to muck around a bit in YAML, and backend stuff. For me personally, I’ve shifted from tinkering to functionality and usability. And a question on registering a new mobile app is more usable than jumping through hoops just to disassociate a device and person.
Fair enough. I don’t need support on this because I have my own work around which keeps things more manageable and cleaner from a usability, maintenance, and UI standpoint (1 person with associated user login per individual). I just have to be vigilant in checking to make sure no device trackers have added themselves to a person without prompting.
And you’re proposing that we add a confirmation box for this. So lets paint that picture real quick to show you why this is a bad idea.
Current behavior: When you log into the mobile app, it adds the device tracker to your person if it’s not there. Logins occur after the app goes to sleep and is woken back up. Logins occur when you refresh the page.
You’re proposed behavior: When you log in, a confirmation appears to add this device to the person.
So to be clear, every refresh, every awake from sleep, every time you close the app and open it back up, you’ll get this prompt.
And before you say “well it should be stored and only displayed once”, the frontend only holds cache. If you clear the cache, the message will appear again. So even at the best case scenario, you’ll still get this message more than you want it.
So, are you sure you just want a simple confirmation box? I’d wager that the answer is no. Because no one likes constant pop ups.
Uh, that party was going on without me 
I have to admit, as I don’t use this feature, I didn’t had the correct way to set this up on my mind. 
Sorry for that!
I’ll have to take my comment from above back, it seems, I wasn’t aware of the correct setup.
I sure wish I wasn’t the ‘owner’. That’s annoying now…
@petro What is the right way to actually rename the owner anyway? Do we just create a new admin user, edit the .storage/auth somehow and restart ha? Then need to create a new user with hte same name as the original owner…
What I am proposing and will eventually create a feature request for is to edit the behavior of the onboarding of a new mobile app integration. currently if a person with associated user logs into the app and that app has never been connected to that user or HA instance before (therefore no token for that user_id or device exists), it assigns the device tracker to that person without prompting or even so much as a notice of “hey we did this thing”. So on the edit person screen you see all device trackers associated with said person. The JSON of the person file in the .storage folder shows this:
{
"version": 2,
"minor_version": 1,
"key": "person",
"data": {
"items": [
{
"device_trackers": [
"device_tracker.b_iphone"
],
"id": "d82f########################46a6",
"name": "B",
"user_id": "d86b########################5943",
"picture": "/api/image/serve/feae9048########################/512x512"
},
...
what would be nice is on initial onboarding which configures the mobile app integration, it asks “Should this device be used for Person X tracking?”. A check box, a toggle, or a “yes” or “no” and it places the device tracker entity under either an include or exclude heading under the device trackers for the person. Kind of how the include or exclude of the recorder is formatted. then every time the frontend of the app refreshes or this “login” occurs, the backend can check if the device tracker exists under the person (regardless if it is included or excluded) and if it does, don’t change anything because it’s already been decided. If this isn’t the right place, then maybe a new heading in the mobile_app file under the .storage folder.
EDIT: Feature request created. Go vote people if this is something you want to see. Include/Exclude device tracker on mobile app integration onboarding/setup
2 Likes
I’m sure this was lost in the fray above but the very easiest way to solve the problem is to just configure the person via yaml. I’ve never seen it happen to me and it’s likely because I configure the persons via yaml.
I know but that’s not what you said. You said everyone. So “everyone” was being told that “everyone” just likes to argue.
Where did I take offense anywhere except to point out that you shouldn’t make a blanket statement toward all users when you said everyone just wanted to argue?
I didn’t even take offense then because I know that unless I agree with you and don’t try to explain my position then you start getting testy and saying that kind of thing. So I have come to expect it. You were the one who got obnoxious with us.
There was no “argument”. I was literally just stating the obvious - the behavior wasn’t obvious and it is undocumented and it is unexpected. In my book that doesn’t seem to be good design and I stated why with an example.
You just seem incapable of acknowledging that HA can make mistakes and not everything is perfect. As it is in this case. I’m obviously not the only one that feels this way from the way this has taken off.
And if you remember way up there I offered to bow out but you drug me back in again.
as to the issue at hand do you really think that needing to do all of that stuff you said to do to avoid the situation would be easy to figure out for the “target audience”?
I just see the inexperienced user trying to figure out why their automations don’t work then finding out it’s because the person entity isn’t acting as expected and having no way of even knowing how to troubleshoot it or what to do to fix it.
A notification pop-up and documentation would go at least a little ways in letting users know what to expect.
As you said, it’s not rocket science.
I read most of the post above explaining at length how you we prevent HA from automatically linking a device location to a person. It is nice that there are ways, but please let me explain why I think all of them are workarounds and why I think the current the design is flawed:
- It is nice to trace locations of devices and I do not want to turn that off to fix person locations.
- It is nice to trace locations of persons even more. Persons use many devices, but usually only one (maybe two) travel with the person all time time. iPads for example rarely qualify as good person trackers.
- There’s a dialog to tell HA which trackers should be used to establish the location of a person. HA should not overrule what I entered there without notice.
- Automatic linking a device to a person also happens to me when the device is already known, and was already before manually removed from the person dialog. This keeps me doing it over and over.
- I should not be required to remember to use different user names on each device I own to prevent HA from identifying me as a certain person. I don’t want multiple logins for the same person.
I also happen to think it would be useful anyway to ask: hey, it looks like you’re logging in to a new device, do you want me to start using it for location tracking? It is what other apps like Tado do. HA trying to be smart and failing some of the time isn’t helping anyone, judging from the length of this discussion.
4 Likes
I’m not sure, I’ll have to get back to you on this. I haven’t tried it yet.
Edit: it’s gonna be a day or so, camping atm
1 Like
I’m not even going to read this because I know you’re just trying to argue like usual. Have fun, putting you on ignore again.
If a question to lautomatically link a device is hard to implement, would it be an idea toadd a list of device trackers to ignore/exclude from automatic linking.