so, I am pretty sure I know what this is | Home Assistant | Page 1

gleaming cave Feb 2, 2024, 12:26 PM

#

I based it on my own entities

#

which are following the following naming convention:
sensor.<zone name>_<person/device_tracker object id>_distance

#

so that <person/device_tracker object_id> part should be the same as the result for nearest, which is the name of that entity

#

so the slugified name of the entity should not differ from the object id

fading monolith Feb 2, 2024, 12:30 PM

#

maybe i am missing out on where object_id is?

#

still not tracking

#

auh, object id is just the entity name

#

beyond the distance and direct of travel entities, i only have sensor.home_nearest_device so hass is listening for sensors that dont exist? that is what is confussing me

gleaming cave Feb 2, 2024, 12:36 PM

#

the entity_id consists of domain.object_id

restive geyser Feb 2, 2024, 12:37 PM

#

if a device is created, you can access it that way as well by filtering based on device_class

gleaming cave Feb 2, 2024, 12:40 PM

#

found a bug in the integration when I wanted to test something

#

I think the neares_device entity always uses the home zone

fading monolith Feb 2, 2024, 12:46 PM

#

so maybe you are both saying thst {{ direction }}
{{ distance }} should be unknown? or you are saying it is a way to generate different sensors to use in other places? this may just be beyond my understanding?

#

or maybe my example helped you find s bug?😜

gleaming cave Feb 2, 2024, 12:52 PM

#

distance should not be unkown, direction of travel could be

#

I wanted to test something, but found I bug while doing that

fading monolith Feb 2, 2024, 12:54 PM

#

but this is what it is listening for:

#

Entity: sensor.home_k_m_d_direction_of_travel
Entity: sensor.home_k_m_d_distance
Entity: sensor.home_nearest_device

gleaming cave Feb 2, 2024, 12:55 PM

#

so this is the template:

{% set zone = 'thuis' %}
{% set nearest = states('sensor.{}_nearest_device'.format(zone)) | slugify %}
{% set direction = states('sensor.{}_{}_direction_of_travel'.format(zone, nearest)) %}
{% set distance = states('sensor.{}_{}_distance'.format(zone, nearest)) %}
{{ nearest }}
{{ direction }}
{{ distance }}

#

okay

#

that helps

fading monolith Feb 2, 2024, 12:55 PM

#

and the first 2 do not exist

#

i have rhe first line set to home

gleaming cave Feb 2, 2024, 12:55 PM

#

but which entities did it create?

#

the proximity integration that is

fading monolith Feb 2, 2024, 12:56 PM

#

just a direction of travel and distance entity for each device tracker and sensor.home_nearest_device

gleaming cave Feb 2, 2024, 12:57 PM

#

yes, but what is the entity id of the distance entity

#

I can explain with my example

#

I could finally do my test properly

#

So:

I have an device_tracker with entity_id: device_tracker.car and friendly name Auto

#

I created the proxity config entry using that device tracker

fading monolith Feb 2, 2024, 12:58 PM

#

so this, home_k_m_d_direction_of_travel, is grouping object ids of 3 different direction of travel entities

gleaming cave Feb 2, 2024, 12:59 PM

#

wait

fading monolith Feb 2, 2024, 12:59 PM

#

as an example

#

hold on, thats not true

gleaming cave Feb 2, 2024, 1:00 PM

#

Can you tell me this:

the entity_id of the device tracker you used
the friendly name of the device tracker you used

#

ah, I think we're getting there 🙂

#

the problem is, the nearest_device sensor shows the friendly name of the device tracker

#

if that doesn't match the object_id of the device tracker, the template above will fail

fading monolith Feb 2, 2024, 1:02 PM

#

auh, ok, yes, i ised customize.yaml to rename all the entities

gleaming cave Feb 2, 2024, 1:02 PM

#

the entities are created based on the object id

#

wait a sec

#

{% set zone = 'thuis' %}
{% set nearest = states('sensor.{}_nearest_device'.format(zone)) %}
{% set nearest_object_id = states
                            | selectattr('domain', 'in', ['person', 'device_tracker'])
                            | selectattr('name', 'eq', nearest)
                            | map(attribute='object_id')
                            | first
%}
{% set direction = states('sensor.{}_{}_direction_of_travel'.format(zone, nearest_object_id)) %}
{% set distance = states('sensor.{}_{}_distance'.format(zone, nearest_object_id)) %}
{{ nearest }}
{{ nearest_object_id }}
{{ direction }}
{{ distance }}

#

this should work

fading monolith Feb 2, 2024, 1:05 PM

#

to me, it looks like it is substituting the results of the state of sensor.home_nearest_device

gleaming cave Feb 2, 2024, 1:06 PM

#

sensor.home_nearest_device displays the friendly name of the nearest device_tracker/person

#

but the integration uses the object_id of the person/device_tracker entities when creating the entity_ids for the distance and direction_of_travel entities

fading monolith Feb 2, 2024, 1:08 PM

#

that produced the same results except for it capitalized the {{nearest}] and put commas instead of slugifying everything else is unknown

#

maybe it is because i have three differnt entities at home so my nearest is basically three different names

#

so then it generates entities that dont exist

#

K, M, D

gleaming cave Feb 2, 2024, 1:13 PM

#

ah that's it

#

Should have known that, becasue I've noticed that

#

moment

#

{% set zone = 'thuis' %}
{% set nearest = states('sensor.{}_nearest_device'.format(zone)) %}
{% set nearest_object_id = states
                            | selectattr('domain', 'in', ['person', 'device_tracker'])
                            | selectattr('name', 'eq', nearest.split(',')[0])
                            | map(attribute='object_id')
                            | first
%}
{% set direction = states('sensor.{}_{}_direction_of_travel'.format(zone, nearest_object_id)) %}
{% set distance = states('sensor.{}_{}_distance'.format(zone, nearest_object_id)) %}
{{ nearest }}
{{ nearest_object_id }}
{{ direction }}
{{ distance }}

fading monolith Feb 2, 2024, 1:14 PM

#

so if only one person is close to the zone, it should work. it would seem that is a decice tracker had arrived, it wouldnt be part,of newrest

gleaming cave Feb 2, 2024, 1:15 PM

#

that should proably work

#

untested, rebooting

#

tested now

#

seems to work

fading monolith Feb 2, 2024, 1:17 PM

#

all unknown now. if i am helping you, we can continue. if you are just helping me, i was really just trying to see if the template would be useful 🤣

gleaming cave Feb 2, 2024, 1:17 PM

#

just made a change

fading monolith Feb 2, 2024, 1:17 PM

#

in here or in beta or both?

gleaming cave Feb 2, 2024, 1:18 PM

#

here

#

did you add one device tracker in the config of the proximity integration, or did you add 3?

fading monolith Feb 2, 2024, 1:18 PM

#

No first item, sequence was empty.

#

and all unknown

#

i added 5

#

three of which are home

gleaming cave Feb 2, 2024, 1:19 PM

#

okay, and 3 are at home

fading monolith Feb 2, 2024, 1:19 PM

#

so they report in the nearest

gleaming cave Feb 2, 2024, 1:19 PM

#

are you sure you have the version above?

fading monolith Feb 2, 2024, 1:20 PM

#

which again, i think there should really only be one nearest right

#

yes

gleaming cave Feb 2, 2024, 1:21 PM

#

can you screenshot devtools > template for me

fading monolith Feb 2, 2024, 1:21 PM

#

auh, hold on

#

i forgot to change zone to my zone

#

so now it reports

#

K, M, D
k
unknown
unknown

gleaming cave Feb 2, 2024, 1:34 PM

#

okay

#

did the proximity integration create an entity sensor.home_k_distance?

restive geyser Feb 2, 2024, 2:02 PM

#

If this creates a device, that's probably going to be the best route to go.

#

identifiers on the device should contain the original object_id or some indication what zone it's using

gleaming cave Feb 2, 2024, 2:03 PM

#

it creates a service

#

but I don't know if that's the same in the backend

restive geyser Feb 2, 2024, 2:05 PM

#

the proximity integration doesn't create a device?

gleaming cave Feb 2, 2024, 2:05 PM

#

restive geyser Feb 2, 2024, 2:06 PM

#

but it creates entities?

gleaming cave Feb 2, 2024, 2:06 PM

#

But I expect it to be the same thing

#

yes

#

#

it looks like a device

restive geyser Feb 2, 2024, 2:07 PM

#

Yeah, I'm not sure how we can ensure that everything is related. That's a miss-step in my opinion.

#

This should be brought up in the beta channel

#

because now users can't change the entity_id's or relate the entities in any way other than an assumption.

#

even if you use integration entities, you're still SOL when you have more than one proximity set up.

#

Yes i'ts not a physical device, but we have to have a way to relate them via templates.

gleaming cave Feb 2, 2024, 2:08 PM

#

#

I think it's just a device in the backend

restive geyser Feb 2, 2024, 2:09 PM

#

So it does

gleaming cave Feb 2, 2024, 2:09 PM

#

it's just named differently in the frontend

#

because it's not a physical device

restive geyser Feb 2, 2024, 2:09 PM

#

do device_attr('sensor.thius...', 'indentifiers')

gleaming cave Feb 2, 2024, 2:09 PM

#

that's why that whole section is called devices and services

#

which are different services compared to devtools > services

restive geyser Feb 2, 2024, 2:10 PM

#

right, so you're trying to piece together the service, correct?

gleaming cave Feb 2, 2024, 2:10 PM

#

#

well

#

the config entry creates a couple of entities

restive geyser Feb 2, 2024, 2:11 PM

#

did we ever add something to get a config entry attribute?

#

if not, this might be a good time to consider that

#

config_entry then get the original entity_id. Pretty sure that's a field

gleaming cave Feb 2, 2024, 2:12 PM

#

for each device_tracker/person it creates the distance and direction_of_travel entity

#

with naming convention sensor.[slugified name of zone]_[object_id of person/device_tracker]_distance

#

not sure why it uses name for the zone, and object_id for the device tracker

#

but it does

restive geyser Feb 2, 2024, 2:13 PM

#

because other zones would create the same entity_id if we just used the object_id

gleaming cave Feb 2, 2024, 2:13 PM

#

then, for each config entry it has a sensor.[slugified name of zone]_nearest_device

#

in which it has a comma seperated string with the friendly names of the device_trackers/person entities nearest (or in) the zone

#

so, what I tried to do with the template above, is to determine the distance and direction of travel of the device_tracker/person nearest to zone

#

so I take the (first) name of the nearest_device sensor

#

and try to find the matching object id

#

(which potentially could go wrong, as names are not unique)

restive geyser Feb 2, 2024, 2:16 PM

#

you could create regex to filter the zones first

gleaming cave Feb 2, 2024, 2:17 PM

#

#

but if I could the actual device_tracker/persons used for the device attributes, that could improve it of course

#

In my first version I just slugified the name, but that doesn't work if the name doesn't match the object_id

restive geyser Feb 2, 2024, 2:18 PM

#

{% set fmat = '^(' ~ states.zones | map(attribute='name') | join('|') ~ ')' %}
{{ states.sensor | selectattr('object_id', 'search', fmat) }}

#

^ that's what I was saying

#

have @fading monolith put that into his system and look at the list

#

{% set fmat = '^(' ~ states.zone | map(attribute='name') | map('slugify') | join('|') ~ ')' %}
{{ states.sensor | selectattr('object_id', 'search', fmat) | map(attribute='entity_id') | list }}

#

Sry this ^

#

that might shed the light on what's happening

gleaming cave Feb 2, 2024, 2:20 PM

#

your fmat is wrong

#

it will be ^()

restive geyser Feb 2, 2024, 2:21 PM

#

^ starts with, () match anything inisde that. zone_name|zone_nam2..

#

| is or

gleaming cave Feb 2, 2024, 2:21 PM

#

yeah I know

#

but something is wrong 🙂

#

restive geyser Feb 2, 2024, 2:22 PM

#

oh zones, should be zone 🤣

gleaming cave Feb 2, 2024, 2:22 PM

#

that helps

#

#

works for me

restive geyser Feb 2, 2024, 2:22 PM

#

Yah

gleaming cave Feb 2, 2024, 2:23 PM

#

wait, an alternative to what I had, is to take all distance sensors, and take the smallest

restive geyser Feb 2, 2024, 2:25 PM

#

you'd still need to match the zone name because I would assume that 2 zones with 2 people could have varying results

#

for a single zone, sure

gleaming cave Feb 2, 2024, 2:26 PM

#

yeah, but that was the idea in the end, to show the distance and direction of the entity nearest to the zone

#

to replicate how it's shown in the old style proximity integration

restive geyser Feb 2, 2024, 2:26 PM

#

how was it shown in the old integration?

#

the 3 values, nearest farthest, etc?

gleaming cave Feb 2, 2024, 2:27 PM

#

state was the name of the nearest entity, and the distance and direction of the nearest entity were 2 attributes

#

no wait

#

state was the distance

#

Marius shared a screenshot yesterday

#

but that was zillions of posts ago

restive geyser Feb 2, 2024, 2:28 PM

#

link?

#

This is where a nice template blueprint would come in handy

gleaming cave Feb 2, 2024, 2:29 PM

#

restive geyser Feb 2, 2024, 2:30 PM

#

sorry to be a pain, but nearest device outputs the object_id?

gleaming cave Feb 2, 2024, 2:30 PM

#

no

#

the name

restive geyser Feb 2, 2024, 2:30 PM

#

ugh

#

this seems poorly thought out

#

I think it needs further discussion

#

it's a major breaking change with little recourse to get old functionality back

gleaming cave Feb 2, 2024, 2:31 PM

#

well, in case 2 entities are both as near (or both _ in_ the zone) it's a comma seperate string with both names

fading monolith Feb 2, 2024, 2:31 PM

#

Sorry. At the gym. And arguing language. Will get back to you

gleaming cave Feb 2, 2024, 2:31 PM

#

yeah I already mentioned that I expect negative feedback from the community

restive geyser Feb 2, 2024, 2:31 PM

#

this will be massive negative feedback

fading monolith Feb 2, 2024, 2:33 PM

#

I really stopped participating in opinion stuff for hass. This one drug me down. That why I try to deal specifically with errors these days

#

Today was a mistake 🤣

#

I appreciate you twos help.

#

Bad English 🤣. But on a treadmill

gleaming cave Feb 2, 2024, 2:41 PM

#

{% set zone = 'thuis' %}
{% set ns = namespace(object=None, distance=None) %}
{% for s in expand(integration_entities('proximity'))
                        | selectattr('entity_id', 'search', 'sensor.'~zone ~'.*_distance')
                        | selectattr('state', 'is_number')
%}
  {% if loop.first or s.state | float < ns.distance %}
    {% set ns.object = s.entity_id | regex_replace('sensor.'~zone~'_|_distance', '') %}
    {% set ns.distance = s.state | float %}
  {% endif %}
{% endfor %}

{{ ns.distance }}
{{ states('sensor.{}_{}_direction_of_travel'.format(zone, ns.object)) }}

#

@fading monolith can you test this when you're back?

fading monolith Feb 2, 2024, 3:07 PM

#

Yes

#

I am not jumping in the beta discussion. I agree with the 2 new nearest entities but is there a way to add logic that says nearest but not in @restive geyser

#

Or we can just template that pretty easy?

restive geyser Feb 2, 2024, 3:25 PM

#

What do you mean? I’m not 100% familiar with old or new versions of the integration

gleaming cave Feb 2, 2024, 3:25 PM

#

the logic for that is the same as for the old one

#

so that's not backwards incompatible

#

you can do it with templates, take a list of device_trakcers/person entites, reject those which are home, and use closest() on the remaining ones

gleaming cave Feb 2, 2024, 3:49 PM

#

{{ closest('zone.home', states.person | rejectattr('state', 'eq', 'home') | map(attribute='entity_id')) }} this will give the state object of the closes person not at home, and none if everyone is at home

fading monolith Feb 2, 2024, 3:51 PM

#

👍

fading monolith Feb 2, 2024, 3:53 PM

#

gleaming cave ``` {% set zone = 'thuis' %} {% set ns = namespace(object=None, distance=None) %...

That worked with an output of:

#

0.0
arrived

#so, I am pretty sure I know what this is