Skip to content
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

BLE Fail-Safe Methods #1351

Closed
SebastianGode opened this issue Jul 7, 2024 · 4 comments · Fixed by #1484
Closed

BLE Fail-Safe Methods #1351

SebastianGode opened this issue Jul 7, 2024 · 4 comments · Fixed by #1484
Labels
prio:high workaround Reduce symptoms of issue

Comments

@SebastianGode
Copy link

Right now the BLE container just fails if the Bluetooth Device isn't responding, moved from HCI0 to HCI2 or whatever.
It doesn't provide any feedback to TSC itself and as a result TSC can't control charging power and doesn't stop the charging process and empties the HomeBattery.

A Fail-Safe for this would be appreciated.

Today I had the following:

[07-Jul-2024 13:18:07.212 VRB TeslaSolarCharger.BleApi.Services.CommandLineExecutionService] Stderr Result: Error: failed to find a BLE device: can't init hci: no devices available: (hci0: can't down device: no such device)(hci1: can't up device: connection timed out)

The BLE Adapter switched again from HCI0 to HCI1 (I don't know why, sometimes just happens) and in that case it errors out.
Output of hciconfig --all:

hci1:   Type: Primary  Bus: USB
        BD Address: F8:63:3F:08:60:F0  ACL MTU: 1021:4  SCO MTU: 96:6
        DOWN
        RX bytes:400941 acl:0 sco:0 events:11758 errors:0
        TX bytes:383148 acl:7266 sco:0 commands:13596 errors:1
        Features: 0xff 0xfe 0x0f 0xfe 0xdb 0xff 0x7b 0x87
        Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
        Link policy: RSWITCH HOLD SNIFF
        Link mode: PERIPHERAL ACCEPT

In order to get it to work again I followed these steps:
https://unix.stackexchange.com/a/602739
I think they require sudo access, but the container has been started with privileged: true anyways. I'd suggest doing this in case the BLE container had 3 failed attempts with such errors.

If that again doesn't help and the CLI for BLE fails again I'd suggest that TSC is stopping the charge through a Fleet-API command just to prevent that the HomeBattery is getting drained.

@pkuehnel
Copy link
Owner

pkuehnel commented Jul 8, 2024

Can you test if the steps if the steps are working when executed in the BLE container?

@SebastianGode
Copy link
Author

I first need to have it in the failed state, then I can try it :)

@pkuehnel pkuehnel added workaround Reduce symptoms of issue prio:high labels Jul 8, 2024
@SebastianGode
Copy link
Author

SebastianGode commented Jul 26, 2024

So for me it worked from the container with privileged privileges (requires some paxkages, I tried it on another container)
However as sometimes the HCI device changes from 0 to 1, sometimes even to 2 you'd need to get a list of the available hci devices first and then run the commands for all interfaces.

As I had the issue last night again that the car drained the battery because my BLE interface went into error mode such a fix would be appreciated! Typically just rebooting the interface with the methods works fine.

@pkuehnel
Copy link
Owner

See #1404 (comment) for detailed information of the fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
prio:high workaround Reduce symptoms of issue
Projects
None yet
2 participants