-
Notifications
You must be signed in to change notification settings - Fork 2
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
Unable to send key - Error: failed to find a BLE device #91
Comments
The What hardware do you use (board & BT adapter)? You could also try to configure the bluetooth_LE_tracker or iBeacon integration and see if those allow you to pick your BT adapter. |
Hi @baylanger, thanks for your reply. I have an Intel NUC NUC10I3FNH2, which runs proxmox -> HA. This is the first time I have tried to use Bluetooth in my setup, so Im not sure what works and not. Does that suggest the Bluetooth adapter is accessible, or is there a fundamental difference in receive vs send? |
It's interested to see Intel has a page dedicated for Bluetooth issues. I doubt you fall into that category. It still puzzle me to see that hci0 adapter. The error Can you turn on debugging mode, it's accessible via the "optional settings". Perhaps we'll get a little more info. Do you have Advance SSH installed? If not we might need it to go log into the container like this:
Before doing that, lets take a look at debug level. |
So I guess not much help here? Yes, I have SSH installed, so I can ssh to the instance. What do you need me to do? |
True not much in those logs. Just to make sure, for ssh I refer to the Advance SSH add-on to ssh to HAOS using, by default, username hassio. Inside the container run the following;
|
Could you have too many BLE devices configured in your car?
|
Do you restart the system from time to time? @trygve Additionnal info: in another thread, somebody had similar issue... Just running And then in the terminal run the above command: I wonder... How did you install Homeassistant on the NUC? HA OS? Container? Supervised? Core? This will have an impact on the available devices in Home Assistant, especially the "Container" mode @trygve The option on more than 3 devices might be relevant to look at. First hand Tesla purchase? No other tool (like TeslaKee) or similar gadget that connects to the car? |
moved to #93 |
@Gates1234 issue moved here: #93 as it is different |
Good news, I was able to reproduce the original issue posted by @trygve
Snippet from the error:
Currently tesla-control doesn't allow to specify an adapter via cli nor does it try to find an available adapter if hci0 doesn't exist.
[EDIT] a reboot of my NAS brought back the device to hci0 ! |
@baylanger
After Proxmox and HA reboot
Btw, I had to reboot twice, so no guarantee that it will connect to hci0. @baylanger Do you have a link to the tesla-control issue? Do you think it would be beneficial to comment there with a link to this issue? The more ppl with this problem, the higher the chance for a fix :) |
Here's the Tesla issue There's already a PR in draft to improve BLE. I could be wrong but I think this is an initiative from an outsider, if so we don't know if it will ever get merged. I personally tend to avoid writing something like "Me too I have this problem" as it creates noise, unless I have something to bring. I have found multiple people complaining on the fact the adapter resets and jumps from hci0 to hci1 and vice-versa. For the kernel to reset the adapter, fine but it's very likely there's a racing condition between the thread that detects a new device and the one resetting it. That would explain the jump, the thread detecting is adding the device before the thread that did the reset finishes the work. Feel free to put comments if not, there's a subscribe button on each of the page (Issue & PR). In the meantime, I'm not a Go developer but I did start to try adding the missing functionality to tesla-control. My colleague and I will try to pursuit this avenue 🤞 |
Sounds reasonable. My setup is however back to hci1. Seems like whenever I issue the "deploy key" command, this triggers the bug. 2024-07-17 22:57:11.846 ERROR (MainThread) [habluetooth.scanner] hci0 (**************): Error stopping scanner: [org.freedesktop.DBus.Error.UnknownObject] Method "StopDiscovery" with signature "" on interface "org.bluez.Adapter1" doesn't exist
2024-07-17 22:57:16.865 WARNING (MainThread) [bluetooth_auto_recovery.recover] Could not determine the power state of the Bluetooth adapter hci0 [**************] due to timeout after 5 seconds
2024-07-17 22:57:16.869 WARNING (MainThread) [bluetooth_auto_recovery.recover] Could not cycle the Bluetooth adapter hci0 [**************]: [Errno 16] Resource busy
2024-07-17 22:57:16.869 WARNING (MainThread) [bluetooth_auto_recovery.recover] Bluetooth management socket connection lost: [Errno 22] Invalid argument
2024-07-17 22:57:21.870 WARNING (MainThread) [bluetooth_auto_recovery.recover] Could not reset the power state of the Bluetooth adapter hci0 [**************] due to timeout after 5 seconds
2024-07-17 22:57:23.893 WARNING (MainThread) [bluetooth_auto_recovery.recover] Closing Bluetooth adapter hci0 [**************] failed: [Errno 9] Bad file descriptor
2024-07-17 22:57:25.396 ERROR (MainThread) [habluetooth.scanner] hci0 (**************): Failed to restart Bluetooth scanner: hci0 (**************): Failed to start Bluetooth: adapter 'hci0' not found; Try power cycling the Bluetooth hardware.
Traceback (most recent call last):
File "src/habluetooth/scanner.py", line 310, in habluetooth.scanner.HaScanner._async_start_attempt
File "src/habluetooth/scanner.py", line 310, in habluetooth.scanner.HaScanner._async_start_attempt
File "src/habluetooth/scanner.py", line 313, in habluetooth.scanner.HaScanner._async_start_attempt
File "/usr/local/lib/python3.12/site-packages/bleak/__init__.py", line 203, in start
await self._backend.start()
File "/usr/local/lib/python3.12/site-packages/bleak/backends/bluezdbus/scanner.py", line 178, in start
self._stop = await manager.passive_scan(
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/bleak/backends/bluezdbus/manager.py", line 513, in passive_scan
self._check_adapter(adapter_path)
File "/usr/local/lib/python3.12/site-packages/bleak/backends/bluezdbus/manager.py", line 209, in _check_adapter
raise BleakError(f"adapter '{adapter_path.split('/')[-1]}' not found")
bleak.exc.BleakError: adapter 'hci0' not found
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "src/habluetooth/scanner.py", line 509, in habluetooth.scanner.HaScanner._async_restart_scanner
File "src/habluetooth/scanner.py", line 267, in _async_start
File "src/habluetooth/scanner.py", line 354, in _async_start_attempt
habluetooth.scanner.ScannerStartError: hci0 (**************): Failed to start Bluetooth: adapter 'hci0' not found; Try power cycling the Bluetooth hardware.
2024-07-17 22:57:46.848 WARNING (MainThread) [bluetooth_auto_recovery.recover] Could not determine the power state of the Bluetooth adapter hci0 [**************] due to timeout after 5 seconds
2024-07-17 22:57:46.849 WARNING (MainThread) [bluetooth_auto_recovery.recover] Could not cycle the Bluetooth adapter hci0 [**************]: [Errno 16] Resource busy
2024-07-17 22:57:46.850 WARNING (MainThread) [bluetooth_auto_recovery.recover] Bluetooth management socket connection lost: [Errno 22] Invalid argument
2024-07-17 22:57:51.851 WARNING (MainThread) [bluetooth_auto_recovery.recover] Could not reset the power state of the Bluetooth adapter hci0 [**************] due to timeout after 5 seconds
2024-07-17 22:57:53.880 WARNING (MainThread) [bluetooth_auto_recovery.recover] Closing Bluetooth adapter hci0 [**************] failed: [Errno 9] Bad file descriptor
2024-07-17 22:57:55.454 ERROR (MainThread) [homeassistant] Error doing job: Fatal error: protocol.data_received() call failed. (None)
Traceback (most recent call last):
File "/usr/local/lib/python3.12/asyncio/selector_events.py", line 1017, in _read_ready__data_received
self._protocol.data_received(data)
File "/usr/local/lib/python3.12/site-packages/bluetooth_auto_recovery/recover.py", line 147, in data_received
and (response := btmgmt_protocol.reader(data))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/btsocket/btmgmt_protocol.py", line 1055, in reader
cmd_params = event_frame.decode(evt_params)
^^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'decode'
2024-07-17 22:57:55.461 WARNING (MainThread) [bluetooth_auto_recovery.recover] Bluetooth management socket connection lost: 'NoneType' object has no attribute 'decode'
2024-07-17 22:58:00.453 WARNING (MainThread) [bluetooth_auto_recovery.recover] Could not reset the power state of the Bluetooth adapter hci0 [**************] due to timeout after 5 seconds
2024-07-17 22:58:00.956 WARNING (MainThread) [bluetooth_auto_recovery.recover] Could not cycle the Bluetooth adapter hci0 [**************]: [Errno 114] Operation already in progress
2024-07-17 22:58:00.956 ERROR (MainThread) [bluetooth_auto_recovery.recover] Could not reset the power state of the Bluetooth adapter hci0 [**************]
Traceback (most recent call last):
File "/usr/local/lib/python3.12/site-packages/bluetooth_auto_recovery/recover.py", line 618, in _execute_reset
return await _execute_power_on(adapter, name, power_state_before_reset)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/bluetooth_auto_recovery/recover.py", line 638, in _execute_power_on
await adapter.set_powered(True)
File "/usr/local/lib/python3.12/site-packages/bluetooth_auto_recovery/recover.py", line 295, in set_powered
response = await self.protocol.send(
^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/bluetooth_auto_recovery/recover.py", line 160, in send
assert self.transport is not None # nosec
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError
2024-07-17 22:58:02.980 WARNING (MainThread) [bluetooth_auto_recovery.recover] Closing Bluetooth adapter hci0 [**************] failed: [Errno 9] Bad file descriptor
2024-07-17 22:58:02.982 WARNING (MainThread) [bluetooth_auto_recovery.recover] Adapter with mac address ************** has moved to hci1
2024-07-17 22:58:04.484 ERROR (MainThread) [habluetooth.scanner] hci0 (**************): Failed to restart Bluetooth scanner: hci0 (**************): Failed to start Bluetooth: adapter 'hci0' not found; Try power cycling the Bluetooth hardware.
Traceback (most recent call last):
File "src/habluetooth/scanner.py", line 310, in habluetooth.scanner.HaScanner._async_start_attempt
File "src/habluetooth/scanner.py", line 310, in habluetooth.scanner.HaScanner._async_start_attempt
File "src/habluetooth/scanner.py", line 313, in habluetooth.scanner.HaScanner._async_start_attempt
File "/usr/local/lib/python3.12/site-packages/bleak/__init__.py", line 203, in start
await self._backend.start()
File "/usr/local/lib/python3.12/site-packages/bleak/backends/bluezdbus/scanner.py", line 178, in start
self._stop = await manager.passive_scan(
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/bleak/backends/bluezdbus/manager.py", line 513, in passive_scan
self._check_adapter(adapter_path)
File "/usr/local/lib/python3.12/site-packages/bleak/backends/bluezdbus/manager.py", line 209, in _check_adapter
raise BleakError(f"adapter '{adapter_path.split('/')[-1]}' not found")
bleak.exc.BleakError: adapter 'hci0' not found
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "src/habluetooth/scanner.py", line 509, in habluetooth.scanner.HaScanner._async_restart_scanner
File "src/habluetooth/scanner.py", line 267, in _async_start
File "src/habluetooth/scanner.py", line 354, in _async_start_attempt
habluetooth.scanner.ScannerStartError: hci0 (**************): Failed to start Bluetooth: adapter 'hci0' not found; Try power cycling the Bluetooth hardware.
2024-07-17 22:58:11.847 WARNING (MainThread) [bluetooth_auto_recovery.recover] Adapter with mac address ************** has moved to hci1
2024-07-17 22:58:14.457 WARNING (MainThread) [bluetooth_auto_recovery.recover] Adapter with mac address ************** has moved to hci1 As a sidenote, it is enough to reboot HA from shell with "ha host reboot" to reset back to hci0. I dont have to reboot the VM hostsystem. |
It looks like you have either iBeacon and/or bluetooth_le_tracker configured, is this true? It's hard to tell by the error, it shows "HaScanner" and there's no such integration by that name. It's possible HAScanner is a lower level service that iBeacon & le_tracker uses to access the BT adapter and thus, can manage to handle concurrent request to the adapter. If you do have eBeacon/le_tracker enable, perhaps you can disable and see if it works better. If it does, the solution might be to have a dedicated BT adapter for tesla-control and 1 for the HA BT tracking.
That's what I do as well. Something that might be faster; remove the BT adapter in the VM config and assign it back. What I tried before was to physically remove the BT adapter and plug it back but then it needs to be reassign it to the VM. |
@trygve after a few hours of the integration running my BT drops off hci0 to hci1. I believe I have a similar wifi/BT chip to you and am running HASS on Proxmox (Lenovo M710q). Mine is 8087:0a2b. Blacklisting btusb, bluetooth, btintel followed by "update-initramfs -u" on the host seems to extend the duration before it drops off hci0 to hci1, and I believe this is because the controller looks like it's disconnecting power momentarily sometimes while issuing commands and if it hits a power cycle at the wrong time enough times it will error out. I've ordered an external BT adaptor to try that out as there's countless threads spanning years discussing the intel BT+wifi chips being problematic on linux and HA. I am also experimenting with extending the duration between actions/commands issued from 5 seconds to 9 seconds and slowing down the frequency I send commands to the car over BLE as a interim solution. My BT controller seems to be stable until I start issuing commands to the car, then it starts doing this: Instead of looking like this when it's not issuing commands to the car: Note that earlier in the day I had the host a lot closer to the car (RSSI ~-60) and these issues were present. |
Very interesting feedback, thanks. We are investigating this issue... But the device constantly switching is difficult to track and looking for the latest available device might not solve the issue by itself. Few elements around though: I had very similar issues with my RPi 4b with device turning off or becoming inaccessible. Two things helped:
Home assistant community is recommending "high performance" BT chips:
Reading again through issue 27, I realize these are all the errors we are seeing now. Short story: tesla_ble_mqtt v0.1.0 or above and efficient BT chip cooling... |
I picked up a CSR based one (ASUS BT400) but it won't be here for a couple days. I can adjust the bios on the computer to a more aggressive cooling mode, I'll give that a go - we're currently in a heat wave and ambient temps in the garage are ~23-27C. Overnight while this was not issuing any commands it seems to have ran completely fine, and then as the sun began rising it started to have errors pop up: Server started at 00:24 and ran without errors on hci0 until 05:39, where errors started popping up, at 06:28 it bumped to hcl1.
Here's the entire HA log. 2024-07-19 002400.681 WARNING (Sync.txt Edit: After disabling wifi in the host (via rfkill block 0) and opening the computer case to let the BT/wifi module breathe a bit better this has been running flawlessly for about 7-8hours. |
This comment was marked as off-topic.
This comment was marked as off-topic.
@PedroKTFC Please continue conversation in #97 |
After rebooting the device is back to hci0 and it works flawlessly again, so nothing regarding to overheating (in my case). |
I have installed the integration with a Realtek RTL8761BU adapter. I could agregate the key to the car and it seems that all works correctly for a while. But suddenly it stops working and says "teslaCtrlSendCommand; Error: failed to find a BLE device: can't init hci: no devices available: (hci0: can't down device: no such device". The device is working on hci0 . Rebooting sometimes works and others not. |
It looks like the device name for your BLE adapter is changing (probably from hci0 to hci1). Many people (including myself until I changed hardware) have experienced this issue. It seems to happen sometimes randomly or more likely when multiple commands are being sent in fairly quick succession. Whilst presence detection seems to continue working, it is not possible to send further commands when this happens. I found I needed to reboot to fix it which is not a satisfactory solution. I was originally using a RPi1b with a third party USB BLE adapter. In the end I changed device to a RPi3b+ and the problem has gone away. Others have reported success with RPi4. I am running the docker version of this project, though I believe this problem occurs whichever version you are using |
I have changed the BT adapter. The new one is more simple and it is too on the HA tested devices list : Now the problems have disappeared. It seems that HA has problems with the drivers of Realtek RTL8761BU. So if you have problems like this change de BT USB adapter. I have buyed it on Amazon. |
I think it's a more general Linux driver issue rather than HA. I will check what BLE adapter driver was being used in my case when it didn't work well. Maybe it's a RTL8761BU What kernel driver does the new device use? |
We don't know why this happens but it does for some bluetooth adapters. Only solution we know is to use a different bluetooth adatpter. @aalllop please provide the URL for the 'HA tested devices list' that you used to find an adapter that worked for you |
Thx i already ordered an compatibel bt device yesterday 😑 i was to fast with giving a reaction on this topic. In 3 days i know the result 💪 |
|
The list of Bluetooth adapters is on the HA webpage: |
@Genesisfm any good news? :) |
Yes it works with a new BT dongle, im using the Sabrent 4.0 |
@aalllop I thought you had fixed it but it seems not unfortunately. I did notice from your original image that you are running HA inside a Oracle Virtualbox virtual machine - is that right? I'm not aware that this causes a problem, but it might be another factor affecting control of the bluetooth device which we know is fussy about hardware |
You are right... I'm using Oracle Virtual Box. The integration works with my BT device but sometimes is working well and sometime it fails . If there is too much fails then HA broke and I have to reset all HA. I think I will try to use another usb bt dongle. Is not possible to use a BT proxy with this integration? I have tried Shelly 1 Plus who has BT proxy integrated but this integration says that no BT device is installed. |
I am using a RPi3b+ which runs the docker version of this project (and nothing else). Home Assistant runs on another device. Works without issues. There are people who are using RPi4 successfully with this add-on version. https://github.com/tesla-local-control/tesla_ble_mqtt_docker |
I'm using proxmox with any "hang" issues, maybe you have a problem with a "hardware" setting in the Oracle Virtual box ? |
Thanks for sharing your experience, it sounds like it is now working for you. Regarding having the code send a wake command if the required command fails; I have had several requests for this on the https://github.com/tesla-local-control/tesla_ble_mqtt_docker project. I agree it would be useful as it avoids having to add code in HA automations (several times in my case). I'd probably send a wake after the first failure of this type, as it will have the required effect more quickly and not work the BLE more than necessary. Also make it selectable in the config as some users might not want it. @baylanger @raphmur what do you think - shall we look at implementing this for v0.2.2? |
@iainbullock could be nice yes.
|
OK I think we can close this issue. Let's have the conversation about how best to implement in the projects section |
This is closed but FYI .... Please see last comment in #125 that I just posted. |
[23:25:51] NOTICE: Attempt 5/5 to delivery the public key to vin ************* [23:25:51] ERROR: teslaCtrlSendKey; Error: failed to find a BLE device: can't init hci: no devices available: (hci0: can't down device: no such device) [23:25:51] ERROR: Could not send the key; Is the car awake and sufficiently close to the bluetooth adapter?
I can see that the cars presence is detected in the addon, so that means it should be in rage?
The car is approximately 5 meters away from my HA server which has a bluetooth antenna (Intel NUC).
How can I go about troubleshooting this?
The text was updated successfully, but these errors were encountered: