Beacon Transmitter / Monitor - Ability to advertise and get additional attributes such as the name
See original GitHub issueIs your feature request related to a problem? Please describe.
It’s possible to set a name on BlueCharm beacons. This name is retrieved by the HA Core Integration.
This information is retrieved from the service_info.name
in the HA Integration.
Describe the solution you’d like Would it be possible to set and broadcast this information using the mobile app? It would be more user friendly.
I am not sure about the requirements for this parameter. In Bluecharm documentation, its says “16 or less ASCII characters”, but on the mobile application itself, it says “17 or less ASCII characters”
Describe alternatives you’ve considered, if any Just use UUID / Major / Minor as the unique identifier. Rename the device and the sensors in HA, but this applies only to HA, no to other beacon scanners that could benefit from name reading.
Additional context Would it be relevant to also request the retrieval of this information using the Beacon Monitor? At this stage, I am not sure how this information should be retrieved. I think we are hitting the limits of the current implementation of the Beacon Monitor. I agree with the new consensus about the ID format, but how can we get additional attributes with this format in the app?
a92ee200-5501-11e4-916c-0800200c9a66_12555_14421: 9.94
a92ee200-5501-11e4-916c-0800200c9a66_11475_24820: 11.43
Today it’s about the “name” but tomorrow, users could also request TLM attributes to get battery level, temperature, ADV count, time since the beacon is up… Maybe I am pushing too far for TLM since it’s another protocol. Still, I think it’s relevant for the name. We could also break down each part as an attribute. May I suggest to format the beacons as a list of UUID_Major_Minor with attributes?
(Screenshot of the KBeacon app that retrieves information from a Bluecharm beacon)
icon: mdi:bluetooth
friendly_name: Téléphone Julien Beacon Monitor
beacons:
- id: 13370000-4368-6172-6d42-6561636f6e74_1000_1001
distance: 0
name: Julien
uuid: 13370000-4368-6172-6d42-6561636f6e74
major: 1000
minor: 1001
- id: 13370000-4368-6172-6d42-6561636f6e74_1000_1002
distance: 2.4
name: Dog
uuid: 13370000-4368-6172-6d42-6561636f6e74
major: 1000
minor: 1002
Since we are still breaking things right now, maybe we can also change the format for something more future proof.
I could split the issues for the Beacon Monitor and Transmitter.
Issue Analytics
- State:
- Created a year ago
- Comments:8 (8 by maintainers)
Top GitHub Comments
There is already a breaking change because of the added major/minor values, so in my opinion better to break more before the next stable release and get something that is future proof than multiple small breaking changes.
Indeed, in this case it would be best to clearly state the associated attribute for the beacon.
I still like the idea of having a list of beacons grouped by their ID. It feels less messy.
I saw this kind of grouping for other attributes in a few sensors, for instance,
weather
.However, I understand there is the problem of the breaking change, and it’s less intuitive to get to the point in the automations. Something equivalent to this to get a value of the list (please let me know if I can do it shorter…):
{{ state_attr('sensor.telephone_julien_beacon_monitor', 'beacons') | selectattr('id','eq', '13370000-4368-6172-6d42-6561636f6e74_1000_1001') | map(attribute="name") | first }}
or{{ (state_attr('sensor.telephone_julien_beacon_monitor', 'beacons') | selectattr('id','eq', '13370000-4368-6172-6d42-6561636f6e74_1000_1001') | first)["name"] }}
vs{{ state_attr('sensor.telephone_julien_beacon_monitor', '13370000-4368-6172-6d42-6561636f6e74_1000_1001_name') }}