Add option to choose the controller in case there are more than one

[BogdanDIA]

I created an ESP32 implementation that adds a new BT controller on the host by connecting over IP to an ESP32. Basically it is a generic BT proxy that offer full stack. Without checking sources for the reason, I observed that tesla-local-control always uses the first controller even though bluetoothctl always sets the last added controller as default. See below:

sudo hciconfig hci1: Type: Primary BD Address: 08:3A:F2:13:35:C2 ACL MTU: 1021:9 SCO MTU: 255:4 UP RUNNING RX bytes:7809687 acl:0 sco:0 events:369222 errors:0 TX bytes:5040449 acl:26036 sco:0 commands:292446 errors:0

hci0: Type: Primary BD Address: D8:3A:DD:C2:67:D7 ACL MTU: 1021:8 SCO MTU: 64:1 UP RUNNING RX bytes:7213 acl:0 sco:0 events:592 errors:0 TX bytes:69142 acl:0 sco:0 commands:561 errors:0

id@raspberrypi5:~ $ bluetoothctl [bluetooth]# list Controller 08:3A:F2:13:35:C2 raspberrypi5 #2 [default] Controller D8:3A:DD:C2:67:D7 raspberrypi5 [bluetooth]#

It is showing also in HA and can be used by other APPs.

I consider tesla-local-control a good complement for my ESP proxy as it can be updated easily when vehicle-command package is updated by Tesla instead of a GATT implementation like https://github.com/yoziru/esphome-tesla-ble I will release my implementation as soon as I clean it.

Thanks

[iainbullock]

This is very useful, thanks for sharing. It will be interesting to see your final implementation.

Did you find a way to get vehicle-command to grab the required controller (hc0, hc1 etc) repeatably?

[BogdanDIA]

I did not spend much time on this but for sure there was no cmd line param for that. So for my tests I just modified the source to use hci1:

go/pkg/mod/github.com/go-ble/ble@v0.0.0-20220207185428-60d1eecf2633/linux/hci/hci.go // NewHCI returns a hci device. func NewHCI(o ...ble.Option) (*HCI, error) { h := &HCI{ id: 1, ...

Maybe Tesla will accept a request to add such an option.

[iainbullock]

Very useful. I'm thinking we could provide a modification like this in the build with environment setting for the user to specify the adapter.

Which file did you change in the repo https://github.com/teslamotors/vehicle-command ?

Thanks

[BogdanDIA]

The change is in go-ble package that is downloaded by go commands as prerequisite before building vehicle-command. Probably the go-ble package has an API call to set the controller and it needs to be used inside vehicle command.

[iainbullock]

OK got it. https://github.com/go-ble/ble/blob/master/linux/hci/hci.go

I will try it out to see if I can force use of hc0

Thanks

[dettofatto]

I'm on supervisor, and I've disabled on my nuc the internal Bluetooth with: "....

First find the idVendor and idProduct for the USB device you wish to disable by running lsusb and locating the right line. Eg, on my system this is the matching line for the adapter I wanted to disable:

Bus 004 Device 006: ID 0b05:179c ASUSTek Computer, Inc. Bluetooth Adapter So then put the following into /etc/udev/rules.d/81-bluetooth-hci.rules, note the 0b05 and 179c values from above:

SUBSYSTEM=="usb", ATTRS{idVendor}=="0b05", ATTRS{idProduct}=="179c", ATTR{authorized}="0"

...."

Chmod +x, then reboot

[iainbullock]

@dettofatto I assume from your last post on https://github.com/tesla-local-control/tesla-local-control-addon/issues/116 that disabling the built in bluetooth didn't work?

I have three suggestions:

1 - can't you use the NUC built in bluetooth instead of the external USB? You may have already tried it 2 - You could leave the built in bluetooth enabled, but force use of hc1 by hacking the go-ble code as per @BogdanDIA comments above 3 - This is getting rather messy and I'm sure consuming a lot of your time. You might try a different device e.g a Raspberry Pi (with built in bluetooth) running the Docker version of the project