Private BLE wont find iphone #101116
Comments
|
Hey there @Jc2k, mind taking a look at this issue as it has been labeled with an integration ( Code owner commandsCode owners of
(message by CodeOwnersMention) private_ble_device documentation |
|
I'm going to have to see your IRK to fix that. You can send it on discord privately if you don't want to paste it here. If you hit that code it doesn't think it's base64 encoded, but if you follow the docs it should be valid base64. |
|
thx, I dmd you to be sure of the right channel |
|
some succes, had to go up to the Ble dongle directly and connect (which is a bit of a bummer, as that is in the attic ;-) ) and it wouldn't kick in on the proxies I have scattered in the house 
seems a bit flakey still but at least all is populated now. its not reliable yet for in room presence which is what I had hoped to use it for.. Maybe I need some fine-tuning or setting on the iPhone to change. |
|
#101254 should fix the traceback, which is caused by an invalid IRK being entered. No idea why your proxies can't see this device:
If your iPhone wasn't transmitting at all then then i'd not expect the bluetooth dongle to pick it up either. And if your proxies weren't working, your other devices should be having problems. The next step here is to try and isolate the problem to a particular component. To do that we want to find the current MAC address of your phone, then try and see that MAC address at a proxy. We need to do this without involving private_ble_device, so that we can either prove it is or is not my bug. We have the complication that this MAC address will change frequently, but we don't know how often or when the change will happen. As discussed on discord, you can see the current MAC address as an additional attribute on the device tracker. This will only work if the device tracker is in the "Home" state. To see a list of MAC addresses a proxy currently see's, go to the esphome integration (e.g. In that file, you should be able to find the MAC address you can see in the home assistant UI. You can do the same process to get a diagnostic for the bluetooth dongle, just by going to the bluetooth integration rather than the esphome integration. Ideally we'd put a proxy and a usb dongle next to each other and take a screenshot of the device tracker extra attributes, download diagnostics for both dongle and proxy, and then another screenshot of the device tracker extra attributes (to prove address rollover had not happened). However, taking screenshot, running from usb dongle to proxy, waiting for 30s to a minute, running back to usb dongle, getting both diagnostics and taking another screenshot could also work. |
|
Oh, there was more discussion in discord that it was now not even visible by attic USB dongle. Because I am remote and not able to observe exactly what is and isn't happening, all I know for 100% certainty is that the IRK must be valid for some device you currently have, because the chances of having IRK match another random device even once is very tiny. Multiple times is just unplausible. And at some point during beta it has been close enough to your network of proxies and dongles to be detected. I know that the device is probably a Phone, Apple watch or Apple Mac (these are the only devices i've seen in icloud keychain). Let's approach this from another angle. If you go into Keychain, are there other devices you can get the IRK for? Can you add those? Can you pair any other iphones to your Mac? Failing that, all i've got is to take diagnostic files for your bluetooth dongle and all your proxies and manually try them with your IRK. That would be of limited diagnostic value. |
|
at least Ive just been able to re-add it once more, and now the entities seem to indicate it is much nearer than before, so I have hopes it now is connecting over the BT proxy I am sitting next to: 
next step would be identifying the source which is listed in the attributes: 
am I right the top one Current address is the actual device I am holding and the Source is the BT proxy is currently is connected to? I would seem to be able to deduce that from that diagnostics file I pulled from it just now |
|
Yes, current address is the one your iPhone is currently using. Source is the current proxy. Looking at the core bluetooth code, it looks like diagnostics from the bluetooth integration include diagnostics for all scanner endpoints. Which is a bit easier than having to pull diagnostics from each proxy individually. |
|
right, so it is expected that the current address changes, as it cycles bt addresses? cause that is what changed, and the other entities did change somewhat. |
|
Yes, that should change fairly frequently. I'm not too worried about "source" being a bit sticky as long as it doesn't go away unexpectedly when you are in your house and it does go away when you leave. While ideally source would always (quickly) represent the physically nearest proxy, just the difference between the antennae's in your proxy |
|
The away is like this, the other entities are supposed to go unavailable ?
If yes, I'll check when I get home and update (hopefully close too ) |
|
Yes. It's not pretty but it is expected. |
|
cool. I'll close now, thanks for you relentless support, much appreciated! |
|
@Jc2k please allow me this, afterburner, my apologies: I just realized that in the diagnostics of the main Bluetooth adapter, all proxies Mac addresses are listed, alongside their name in HA. Like: this allows the user to create a template and map those names. wouldn't it be super useful if the attribute on the device_tracker also showed this, so we dont need to write those templates? Id be happy to write a FR if you would think it feasible. Wrote it up here ;-) btw, now that it's working alright, I can see the source change quite often, toggling between the main dongle and a proxy. much more rapidly than checking that single attribute would make you believe. I did add the atom-echo, but I am not sure it even has the bt capability, so that might be useless. saving the list of adapters as a custom_template and some more use of the this variable allows for easy config copying: ofc this still is a bit of a workaround, support from core would be much better |
|
As I said elsewhere (discord?) It's something I'd like to do for sure. The information wasn't obviously attached to the incoming ble broadcast payload. The diagnostics page has different performance characteristics to these sensors, so it's not a big deal for it to interrogate all the scanners. If there's a cheap way to do it, it'll get done. IBeacon doesn't do this currently AIUI? I'd probably like to follow what that does or update that as well. |
The problem
and config flow errors with
with ==
without ==
All steps in https://rc.home-assistant.io/integrations/private_ble_device#on-macos are successfully executed and the Remote IRK is c&p from the xml file into the config flow
device is on, and near (within 1 meter) of a BT proxy and the main HA device (less than 10 meters) which has a fast BT dongle on a cable.
What version of Home Assistant Core has the issue?
2023.10.0b2
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
private_ble_device
Link to integration documentation on our website
https://rc.home-assistant.io/integrations/private_ble_device
Diagnostics information
No response
Example YAML snippet
No response
Anything in the logs that might be useful for us?
Logger: aiohttp.server Source: /usr/local/lib/python3.11/site-packages/aiohttp/web_protocol.py:403 First occurred: 17:42:15 (1 occurrences) Last logged: 17:42:15 Error handling request Traceback (most recent call last): File "/usr/local/lib/python3.11/site-packages/aiohttp/web_protocol.py", line 433, in _handle_request resp = await request_handler(request) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/aiohttp/web_app.py", line 504, in _handle resp = await handler(request) ^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/aiohttp/web_middlewares.py", line 117, in impl return await handler(request) ^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/components/http/security_filter.py", line 85, in security_filter_middleware return await handler(request) ^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/components/http/forwarded.py", line 100, in forwarded_middleware return await handler(request) ^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/components/http/request_context.py", line 28, in request_context_middleware return await handler(request) ^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/components/http/ban.py", line 80, in ban_middleware return await handler(request) ^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/components/http/auth.py", line 236, in auth_middleware return await handler(request) ^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/components/http/headers.py", line 31, in headers_middleware response = await handler(request) ^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/components/http/view.py", line 148, in handle result = await handler(request, **request.match_info) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/components/http/decorators.py", line 63, in with_admin return await func(self, request, *args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/components/config/config_entries.py", line 177, in post return await super().post(request, flow_id) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/components/http/data_validator.py", line 72, in wrapper result = await method(view, request, data, *args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/helpers/data_entry_flow.py", line 110, in post result = await self._flow_mgr.async_configure(flow_id, data) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/data_entry_flow.py", line 293, in async_configure result = await self._async_handle_step( ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/data_entry_flow.py", line 387, in _async_handle_step result: FlowResult = await getattr(flow, method)(user_input) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/homeassistant/homeassistant/components/private_ble_device/config_flow.py", line 44, in async_step_user irk_bytes = binascii.unhexlify(irk) ^^^^^^^^^^^^^^^^^^^^^^^ binascii.Error: Non-hexadecimal digit foundAdditional information
key is in this format:
because the trailing
==seem to be part of the xml, I also tried it without these, to get the second screenshotThe text was updated successfully, but these errors were encountered: