Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Show MAC (needed for identification) #76163

Closed
dedors opened this issue Aug 3, 2022 · 34 comments · Fixed by #76618
Closed

Show MAC (needed for identification) #76163

dedors opened this issue Aug 3, 2022 · 34 comments · Fixed by #76618

Comments

@dedors
Copy link

dedors commented Aug 3, 2022

The problem

I have many Xiaomi BLE sensors. I need a way to identify them, that can probably only be done if I can see the MAC address of the device. Please show the MAC address on the device info panel, as well on the integration page when a bindkey is needed.

Side note: on the integration page, some xiaomi_ble devices appear with the mac address (maybe because of bad connection?), most don't.
And when listed (after adding) on the integration page, it only shows the device type, while other integrations show the name if the device was renamed.

What version of Home Assistant Core has the issue?

2022.8.0

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

xiaomi-ble

Link to integration documentation on our website

https://www.home-assistant.io/integrations/xiaomi_ble

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

@probot-home-assistant
Copy link

Hey there @Jc2k, @Ernst79, mind taking a look at this issue as it has been labeled with an integration (xiaomi_ble) you are listed as a code owner for? Thanks!
(message by CodeOwnersMention)


xiaomi_ble documentation
xiaomi_ble source
(message by IssueLinks)

@roberttco
Copy link

Also when prompted for an encryption key, having the MAC address displayed would help to map the encryption key to the device. I have several thermometers and they all show up with the same name are are asking for an encryption key. I don't know which one to use.

@exen904
Copy link

exen904 commented Aug 3, 2022

Yes please. Also have the issue with the naming in the integration, most of them show the MAC address but some only the device type. Using all of the same devices causes a huge mess here.

@dedors
Copy link
Author

dedors commented Aug 3, 2022

Yes please. Also have the issue with the naming in the integration, most of them show the MAC address but some only the device type. Using all of the same devices causes a huge mess here.

When not added yet, rebooting HA seems to update the name from MAC to the device type. Restarting just the integration had no such effect when I tried.

@exen904
Copy link

exen904 commented Aug 3, 2022

Yes please. Also have the issue with the naming in the integration, most of them show the MAC address but some only the device type. Using all of the same devices causes a huge mess here.

When not added yet, rebooting HA seems to update the name from MAC to the device type. Restarting just the integration had no such effect when I tried.

Well that would be even worse, no way to differentiate then. But actually I had a reboot before and that didn’t change that. Thankfully.

@andrewjswan
Copy link

andrewjswan commented Aug 4, 2022

Mac address is required not only for identification, but also for ESPHome BLE gateway, it would also be nice to see the additional attributes of the sensor, such as:

  • Sensor type - LYWSD03MMC
  • MAC address - A4:C1:XX:XX:XX:XX
  • Firmware - Xiaomi (MiBeacon V5 encrypted)
  • etc

@Jc2k
Copy link
Member

Jc2k commented Aug 4, 2022

Hi everyone, thanks for the ideas.

The sensor type should already be visible on the device info page, under the name of the device and above the manufacturer:

Screenshot 2022-08-04 at 09 53 19

The other stuff is already on my todo list to think about.

@exen904
Copy link

exen904 commented Aug 4, 2022

The sensor type is there, but for example im using 6 LYWSD03, so there are 6 same devices. Only the ones that show up with the MAC are kind of distinguishable. Well, not very intuitive, but they are. Besides those that just show LYWSD03.

@Jc2k
Copy link
Member

Jc2k commented Aug 4, 2022

Hi @exen904, as i said in the reply, the other stuff is on my todo list. Thanks.

@andrewjswan
Copy link

image
Also a lot of the same devices, and almost all with bind key.
It would also be nice to be able to change the bind key without removing the device with the old bind key and rebooting HA.

@Calorian
Copy link

Calorian commented Aug 4, 2022

The sensor type is there, but for example im using 6 LYWSD03, so there are 6 same devices. Only the ones that show up with the MAC are kind of distinguishable. Well, not very intuitive, but they are. Besides those that just show LYWSD03.

My workaround for this is using the PVVX TELink flasher, you can give the devices names that the integration can read. Mine are named ATC_roomx and they appear on the integration as sensor.atc_office_humidity or _temperature etc.

This may only be possible on the custom firmware however.

@andrewjswan
Copy link

My workaround for this is using the PVVX TELink flasher

When using the custom firmware, the sensors disappear from the MiHome, and the custom firmware is not available for all devices.

@Jc2k
Copy link
Member

Jc2k commented Aug 4, 2022

When a bindkey is wrong it will prompty you to enter a new one. You don't need to remove it.

@andrewjswan
Copy link

When a bindkey is wrong it will prompty you to enter a new one. You don't need to remove it.

Over three years of using different sensors, more than once there were cases where the bind key for some reason changed, in the case of BLE monitor, I just changed it in the configuration, there is no such a possibility.

@Jc2k
Copy link
Member

Jc2k commented Aug 4, 2022

If the bindkey is wrong (because you changed it for example) Home Assistant will let you change it, and without restarting anything. This only applies to xiaomi_ble and not ble_monitor. If thats not the case, please raise a bug report for it.

@krazos
Copy link
Contributor

krazos commented Aug 4, 2022

I know this isn't the issue that most folks are raising, and I too support improved device identification (e.g., by MAC address) during config flow, because one of the benefits of the Xiaomi temperature and humidity sensors is that they are cheap enough that you can throw one in every room in the house.

That said, in case it is helpful for anyone, you can rename the individual integration config entry once a device has been successfully added for ease of identification:

Rename:

image

End Result:

image

@Amnesia2Bad
Copy link

Could someone help me adding my Mi Nightlights to HA?
The Bluetooth integration asks for a 32 character key, but the tokens I have extracted are 24 characters long, and they won't connect.

Any help would be kindly appreciated, thanks!

@Jc2k
Copy link
Member

Jc2k commented Aug 6, 2022

Hi. On GitHub we use one issue to track one bug. As you question is unrelated to how HA names your device, please start a new GitHub issue if you think you have found a bug, otherwise use the forums to get support from other community members. Thanks!

@Wouter0100
Copy link

I found a workaround on how to get the MAC address. I figured that it should've been stored somewhere to identify the devices.

in config/.storage/core.config_entries you're able to search for the name and find the corresponding MAC address. I added them one-by-one, each time opening this file and matching it to my old list of mac addresses.

@WhimsySpoon
Copy link

Hi @Jc2k, thanks for getting on this so quickly. Will the change also display the device mac address in the device view now?

@Jc2k
Copy link
Member

Jc2k commented Aug 12, 2022

Ah, GitHub closed this automatically when my PR was merged. That PR was more about setting up experience. Right now with just the above PR, when you first add it you'll still be able to identify it by its name - in the discovery, in the config flow, in the name of device it creates. Showing the full MAC on the device info page is still on my radar, but thats more tedious than you would think. There are more rules I have to follow about where it lives etc which means its still a ways off. When I have figured out where it goes, actually adding it will be quick I think.

The project doesn't use GitHub to track feature requests, so i'm going to leave this closed. There are other things that should make it into the next release like showing firmware info on the device info page. MAC will get there when I can. Cheers.

@andrewjswan
Copy link

@Jc2k will it be possible to get a list of MAC addresses in the template?

@Jc2k
Copy link
Member

Jc2k commented Aug 12, 2022

What template do you mean?

@WhimsySpoon
Copy link

thats more tedious than you would think

All the best things usually are!

Thanks for the explanation, and understand the frustration here. If it's easier, could the MAC address be added as a sensor, or even an attribute on one of the existing sensors?

@Jc2k
Copy link
Member

Jc2k commented Aug 12, 2022

It's already captured in the device registry as a connection, so it might just be a UI change to expose that instead, which isn't something I can do. But adding it as a sensor is something that is under consideration. It's not an option i like (as its not a value that changes). But it's something i'd do if i got approval.

Adding it as an attribute is almost certainly not going to happen in core, as it increases the write pressure logging static information with every state machine update. At least with a seperate sensor its only a state machine event per restart.

@WhimsySpoon
Copy link

I agree, the sensor/attribute doesn't feel like the right place, and I never like suggesting hacky solutions.

Adding it to the Device info box seems like the right place eventually.

@andrewjswan
Copy link

What template do you mean?

Like this:

devices: "{{ states.sensor | selectattr('entity_id', 'search', '^sensor.ble_') | selectattr('attributes.mac_address', 'defined') | map(attribute='attributes.mac_address') | unique | sort | join('') | replace(':', '') ~ states.device_tracker | selectattr('entity_id', 'search', '^device_tracker.ble_') | selectattr('attributes.mac', 'defined') | map(attribute='attributes.mac') | unique | sort | join('') | replace(':', '') if is_state('binary_sensor.ble_gateway', 'on') }}"

@Jc2k
Copy link
Member

Jc2k commented Aug 12, 2022

I don't know what that does, but there are no plans to use extended attributes for the mac address, so it definitely won't work as is.

@andrewjswan
Copy link

I don't know what that does, but there are no plans to use extended attributes for the mac address, so it definitely won't work as is.

How do I get a list of Mac addresses for the Esphome BLE Gateway to work? How does it work now in BLE Monitor?

https://custom-components.github.io/ble_monitor/parse_data

custom-components/ble_monitor#978

@Jc2k
Copy link
Member

Jc2k commented Aug 12, 2022

Using ESPHome with the new bluetooth integration is not supported, so getting a list of MAC addresses won't help.

Eventually ESPHome will get native support for proxying data to Home Assistant. AIUI, HA will share the MAC with ESPHome automatically. So there won't be any manual configuration required. I don't have an ETA for this, it's not something I am working on.

@andrewjswan
Copy link

Eventually ESPHome will get native support for proxying data to Home Assistant. AIUI, HA will share the MAC with ESPHome automatically.

Is there somewhere to read about this? Because this function is not currently available in ESPHome. But a lot of people use the Gateway functionality for BLE Monitor, because it extends the BLE coverage and can be used even without the BT adapter in the HA.

@Jc2k
Copy link
Member

Jc2k commented Aug 12, 2022

No, not AFAIK.

If you rely on using an ESP32 to extend coverage, please continue to use BLE monitor.

@bradgyton
Copy link

i dont see what you're describing. Can you confirm the version it has been released in please

@Jc2k
Copy link
Member

Jc2k commented Aug 17, 2022

As it's a feature and not safe to backport it'll be in the September release now.

@github-actions github-actions bot locked and limited conversation to collaborators Sep 16, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.