Specify minimum BT version

[raphmur]

          @dettofatto That's good news. We will note that the minimum spec is >4.0 (we don't know what exactly). I think we should recommend >=5.0

I believe @guyank has got it working.

I will keep the thread open for now as I think @HiFuGa still has issues.

Originally posted by @iainbullock in tesla-local-control/tesla-local-control-addon#116 (comment)

[BogdanDIA]

I just see now this topic and probably it is late for the answer but I had the same issue at the time when it appeared. Did wrote to
teslamotors/vehicle-command#269 the reason why BLE 4.x is not working. Changing from 2 to 0 allos using BLE versions under 5.0.

[iainbullock]

I appreciate the update and link to the Tesla update thanks. Looks like 5.0 is the minimum

[BogdanDIA]

I appreciate the update and link to the Tesla update thanks. Looks like 5.0 is the minimum

5.0 zero is minimum since August '24 just because Tesla changed in vehicle-command/pkg/connector/ble/device_linux.go
ScanningFilterPolicy: 2 instead of ScanningFilterPolicy: 0. I don't see a reason for doing that change.
For those who still want to to use older version (e.g. 4.x version) just change back to ScanningFilterPolicy: 0 and recompile tesla-control. It will work for newer versions like 5.x as well.
I am using this change with my 4.2 adapter since August and works the same as an 5.x adapter including for the latest commands added in tesla-control.

[raphmur]

Thanks @BogdanDIA and nice find.

Recompiling vehicle-command on the fly might be difficult for this module. I suggest finding a way to force supported bluetooth version > 5.0 for the device.

@iainbullock what do you think about recompiling? Not sure if worth the hassle, or maybe just a note in the readme and suggesting to manually adapt the Dockerfile

[BogdanDIA]

Hi @raphmur,
I started uploading my work for esp32-proxy on github and corresponding scripts I'm using. I had the functionality ready as standalone since August but decided to create add-ons for each. Still need to test the addons and write docs.
My esp32-proxy is BT 4.2 and for it I patch vehicle-command during building add-on. Patch is actually done in just one file for two reasons:

1. Adding support for changing the controller. This is obtained by adding an env var (HCINUM=x) so that, when defined, it will make use of controller x. Maybe for this we can convince Tesla to add official support.
2. Support for BT4.x. Not yet done but will do the same as above by defining BTVER env var.

Files to check:
/~https://github.com/BogdanDIA/tesla-ble-addon/blob/main/tesla-ble-c/Dockerfile
/~https://github.com/BogdanDIA/tesla-ble/blob/4ba6e12ad03b0d36fc67d71458f5d38cc7cccb20/patches/vehicle-command/device_linux.go

Happly New Year

[iainbullock]

I think we could compile these changes into vehicle-command during the build; everyone would get ScanningFilterPolicy = 0. To have it as a setting in Dockerfile is also possible but it's something most people won't do.

My RPi3b+ is using BT4.2 and seems to still work fine without changing ScanningFilterPolicy to 0. @BogdanDIA do you know what ScanningFilterPolicy does and what happens if it's set to 2 with a BT<5.

[BogdanDIA]

@iainbullock I have seen people mentioning that it works on rpi3, don't know why, maybe the controller has some early implementation from 5.x.
For all BT4.x adapters I tested, the connection stops with ScanFilterPolicy=2. That's because the HW controller does not recognize the value 2 which is an extended command added from 5.x. The controller returns an error and bluez closes all operations. This behavior is easily seen with btmon.

ScanFilterPolicy sets the rules for getting the scan advertising data from the car. Value 2 refers to directed advertising directly to the host but I don't see the car sending this kind of directed advertising. It just sends undirected advertising which is enough for having ScanFilterPolicy=0

[iainbullock]

Thanks for the explanation. I will try your approach to patching during the build via the Dockerfile and report back

[iainbullock]

I managed to incorporate your patch into the build, thanks for sharing. As I'm on a RPi3b+ I can't actually test it as things already work for me. I will experiment with the ability to set the hci number

_docker#patch-vehicle-command

/~https://github.com/tesla-local-control/tesla_ble_mqtt_docker/tree/patch-vehicle-command

[iainbullock]

I have implemented improvements into v0.4.3b-dev which is on DockerHub, including the patch to allow bluetooth <5.0. Main changes are robustness improvements, see the CHANGELOG. /~https://github.com/tesla-local-control/tesla_ble_mqtt_docker/blob/iain-dev/CHANGELOG.md