feat: Add Nearest scanner entity_id sensor

[ashabala]

This adds an additional sensor that tracks the entity_id of the nearest scanner. Having the raw entity_id allows you to perform downstream tasks on the scanner entity, such as retrieve all associated labels, get state attributes, etc.

Most of my scanners are Shelly 1 Plus relays controlling light switches. The switch location is not always the same area as the lights it controls (e.g. inside switch controlling outside lights). Exposing the raw entity_id of the nearest scanner lets be use custom attributes or labels in my dashboards.

I've added a custom attribute (switch_location) to each Shelly device, and am instead using this in my dashboards:
Phone is near {{ state_attr(states(entity), 'friendly_name') }} ({{ state_attr(states(entity), 'switch_location') }})

Alternatively, the same can be done using Labels (I've used a prefix "switch_location_[VALUE]"):
Phone is near {{ state_attr(states(entity), 'friendly_name') }} ({{ (labels(states('sensor.phone_nearest_scanner_entity')) | select('match', '^switch_location_.*') | first).replace('switch_location_', '') }})

[agittins]

Hi Ashabala, and thanks for your contribution!

I have some thoughts about this some of which are a bit wider in scope, so I'll start with the TL/DR:

We have an existing "Nearest Scanner" sensor, and since it is sort of "the same meaning conveyed differently" I think my preferred option would be to add an attribute to that entity for "scanner entity id", rather than creating a whole new sensor. It's a bit of a shame there isn't an "entity sensor" that is specifically for displaying entities, that would be ideal! So your templates etc would access the attribute of the "Closest Scanner" rather than the displayed value. For that matter, perhaps the "native value" for the sensor should be the entity_id, and the display value should be the entity name - I haven't looked into that but does that sound sensible?

Also I think the entity_id should be in the devices data dict, and if not it should probably be added there, that way the sensor doesn't need to consult the device registry etc.

The rambling bit...

With regards to Shellys in particular (but any proxy that does other things) the device area does not have to be the same as the entity areas. So you can have a Shelly device in the lounge, but the switch entity on it has an area of "bathroom" if that's the outlet it controls. I'm not saying "you should do this" but just bringing it up in case you weren't aware - I appreciate that there can be good reasons for wanting to treat the entire device based on the things it controls, just offering it as an option in case it hadn't occurred.

I completely agree that having easy access to the entity_id for automating/scripting is a great idea - it's only the implementation that I'm having thoughts about. :-)

What do you think about making it an attribute (or maybe the native value) of the exsiting sensor?

[ashabala]

I've reimplemented the feature as an attribute in BermudaSensorScanner, and shifted the entity_registry lookup to the _refresh_scanners call in the coordinator.