send ATT request failed: io: read/write on closed pipe every 30 seconds

[LubosD]

Are there any details on how to keep the BLE connection open for long time?

I tried Ping()ing the vehicle every 5 seconds, but it seems the connection is always lost after 30 seconds:

2024/06/02 14:39:16 Trying to connect to VIN XP7YGCELXNB015325
2024/06/02 14:39:17 VIN XP7YGCELXNB015325 connected over BLE!
2024/06/02 14:39:19 Session started
2024/06/02 14:39:25 PING OK
2024/06/02 14:39:30 PING OK
2024/06/02 14:39:35 PING OK
2024/06/02 14:39:40 PING OK
2024/06/02 14:39:45 PING OK
2024/06/02 14:39:49 VIN XP7YGCELXNB015325 disconnected
2024/06/02 14:39:49 OperateConnection returned: send ATT request failed: io: read/write on closed pipe
2024/06/02 14:39:49 Connect failed: send ATT request failed: io: read/write on closed pipe
2024/06/02 14:39:50 Trying to connect to VIN XP7YGCELXNB015325
2024/06/02 14:39:50 VIN XP7YGCELXNB015325 connected over BLE!
2024/06/02 14:39:52 Session started
2024/06/02 14:39:58 PING OK
2024/06/02 14:40:03 PING OK
2024/06/02 14:40:08 PING OK
2024/06/02 14:40:13 PING OK
2024/06/02 14:40:18 PING OK
2024/06/02 14:40:22 VIN XP7YGCELXNB015325 disconnected
2024/06/02 14:40:22 OperateConnection returned: ATT request failed: input channel closed: io: read/write on closed pipe
2024/06/02 14:40:22 Connect failed: ATT request failed: input channel closed: io: read/write on closed pipe

[sethterashima]

If you have other BLE devices (phone keys, keyfobs) connecting to the vehicle, it's possible that vehicle BLE endpoint is dropping one connection to accommodate another.

Are you using car.Ping(ctx) with a fixed 30-second ctx? A minimal working example of the code might help with debugging.

[LubosD]

Hi, I've uploaded my code here: /~https://github.com/LubosD/hass-tesla-vc
I don't use a 30-second ctx, I use a background ctx and then I run Ping() every 5 seconds.

I was far away from the car with my phone key, so that can't be it.

[sethterashima]

I was able to run that code without issue (with the mtqq stuff gutted out). It's possible the issue is within the BLE stack itself; unfortunately, the relevant Go packages are not very well maintained. Are you able to reproduce with a different BLE device? What OS/hardware are you using?

[LubosD]

I'm using a "Raspberry Pi 4 Model B Rev 1.5". I ran hcidump and I see this when the disconnect happens:

< ACL data: handle 64 flags 0x00 dlen 27
    ATT: Write req (0x12)
      handle 0x0008 value  0x00 0xb7 0x32 0x02 0x08 0x03 0x3a 0x12 0x12 0x10 0xa2 0x0f 0xa9 0xb6 0x77 0xf8 0x95 0xb3 0xe6 0xee
> HCI Event: Number of Completed Packets (0x13) plen 5
    handle 64 packets 1
> HCI Event: Disconn Complete (0x05) plen 4
    status 0x00 handle 64 reason 0x08
    Reason: Connection Timeout

[sethterashima]

I'll try to repo on a Pi 4 next week, but it's looking like a BLE library/driver/hardware issue. Unfortunately I don't have the bandwidth to run those down.

[iainwhyte]

@sethterashima - what BLE hardware are you testing on and runs without issue? I also have a Pi 4 does the same thing, and so do several BT4 and BT5 dongles. Usually you get:

Error: ble: failed to enumerate device services: ATT request failed: input channel closed: io: read/write on closed pipe

With the telsa-control tool, but only every 2nd, 3rd call.

[sethterashima]

I've been doing my testing on a Pi 3B and a Macbook.

I was able to reproduce using a BLE dongle.

[BogdanDIA]

I get the same errors from time to time and that is why my script tries each command several times (6 times max). Usually after 1 or 2 retries it gets success.

I found out that using an rpi5 with 5Ghz wifi connection make the connection better compared with rpi3/4 on 2.4Ghz wifi where both BLE and wifi share the same band.

[iainwhyte]

It does appear to be range related. If I jury-rig RPi4 very close to the car, it's a lot more reliable - only fails in 1 in 10 calls. There is no way you can have a RPi with your command EC key stationed outside the house though, might as well leave the keycard sitting on top. Im so close to done with all of this. Restricted API, no way to buy more calls, flakey BLE support. Shouldn't be this hard... WTF Tesla.

[sethterashima]

Work in progress: #269

Improvement on an Ubuntu box with with a BLE dongle, but needs more work and validation in different environments. Please feel free to comment on the PR on whether you see an improvement or not and, if not, what hardware and vehicle model+year you're using.

[iainwhyte]

Work in progress: #269

Improvement on an Ubuntu box with with a BLE dongle, but needs more work and validation in different environments. Please feel free to comment on the PR on whether you see an improvement or not and, if not, what hardware and vehicle model+year you're using.

Thanks @sethterashima will comment on the PR, but for this thread: seems significantly improved.

[BogdanDIA]

Tested today the new code with several adapters I have. It works a bit faster for BT 5.0 adapter but it broke the BT4.x support. That is due to using the Extended Adv features that were introduced starting with BT 5.0.

vehicle-command/pkg/connector/ble/device_linux.go

var scanParams = cmd.LESetScanParameters{
LEScanType: 1, // Active scanning
LEScanInterval: 0x10, // 10ms
LEScanWindow: 0x10, // 10ms
OwnAddressType: 0, // Static
ScanningFilterPolicy: 2, // Basic filtered <- this should be 0 for Basic Filtered.
}

Here are the possible values:
0x00 Basic unfiltered scanning filter policy
0x01 Basic filtered scanning filter policy
0x02 Extended unfiltered scanning filter policy
0x03 Extended filtered scanning filter policy

[LubosD]

When I created this issue, I was using Raspberry Pi 4. Problems didn't get solved with the PR, and things got even worse after some system updates. I'd get system hangs and would be forced to reboot the device by power cycling.

Then I switched to Raspberry Pi Zero 2 W, because I needed that RPi4 for something else. I put the old SD card into the new device and all problems have disappeared.

So if you're looking for a BLE-enabled device to control your Tesla, go for Zero 2 W.

[rtega]

On the Pi 4 disabling the wlan0 interface solved this for me. Of course you need to have connection via ethernet while disabling this remotely.
sudo ip link set wlan0 down

For a more permanent solution edit /etc/dhcpcd.conf.