-
-
Notifications
You must be signed in to change notification settings - Fork 28.6k
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
Comments
Hey there @Jc2k, @Ernst79, mind taking a look at this issue as it has been labeled with an integration ( xiaomi_ble documentation |
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. |
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. |
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:
|
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. |
Hi @exen904, as i said in the reply, the other stuff is on my todo list. Thanks. |
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. |
When using the custom firmware, the sensors disappear from the MiHome, and the custom firmware is not available for all devices. |
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. |
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. |
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:End Result: |
Could someone help me adding my Mi Nightlights to HA? Any help would be kindly appreciated, thanks! |
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! |
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. |
Hi @Jc2k, thanks for getting on this so quickly. Will the change also display the device mac address in the device view now? |
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. |
@Jc2k will it be possible to get a list of MAC addresses in the template? |
What template do you mean? |
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? |
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. |
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. |
Like this:
|
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? |
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. |
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. |
No, not AFAIK. If you rely on using an ESP32 to extend coverage, please continue to use BLE monitor. |
i dont see what you're describing. Can you confirm the version it has been released in please |
As it's a feature and not safe to backport it'll be in the September release now. |
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
The text was updated successfully, but these errors were encountered: