Presently, a person entity has a state of ‘home’ or ‘away’ to start, and this can be enhanced by adding zones whose names will show up in the entity state value when the linked device detects it is in those zones.
To enable this, a person entity can have a location-enabled device under the device_tracker domain, which in turn can have a linked geocoded_location entity under the sensor domain.
I would propose that the person entity have a setting that would enable preferentially using a linked geocoding sensor’s state over the default ‘away’ status. Obviously you can do this with custom sensors, but having it already working ‘out of the box’ without any manual changes to configuration.yaml when hardware is changed would be far more convenient.
I am now curious as to how (and why) you would have your person.x entity state linked to your coffee pot power cord. It defaults to what map zone your linked location source is in, with ‘home’ if you are near the home location you set during initial setup, and ‘away’ if you’re not there and not in any other zones you may have added. No coffee involved.
I see nothing wrong with my explanation, and if you do you’re going to have to be far more clear about what YOU mean.
And linking to the guidelines? Wow. Passive-aggressive much? If you were trying for an unpleasant interaction with another enthusiast, you managed to achieve that.
Unless I’m also not understanding what you mean then I fail to see how this would help your situation.
I believe all geocoded location entities will also have the status of home or away just like the person entity does. so preferentially selecting a specific location entity would still only show home, away or a possibly a zone.