Improving bluetooth stability

[EuleMitKeule]

I haven't yet found a reason for the connection issues me and other people are facing especially when using bluetooth proxies.
What I am pretty sure of is that the disconnects seem to occur about every five minutes and last for about 30 seconds.
I am experimenting with a script that monitors BLE device availability to try to confirm this.
Regarding the overall bluetooth connection process, I have found the following article(s) in the Home Assistant Developer Docs which explain how bluetooth connection should be handled. Since the integration currently uses a different process to achieve the connection, I'd like to get your evaluation whether it would make sense to try out the methods described in that article or if they have already been tried out.

[dbuezas]

I started with that and then refined it to make the connection more stable. You could try removing the bells and whistles and check it btproxys react differently

[EuleMitKeule]

I have tried out the bleak and simplepyble libraries under Windows using my mainboard builtin Intel bluetooth adapter and experience the same behaviour as in Home Assistant. The devices disconnect after ~1-2 minutes and reconnect after ~30 seconds. This behaviour seems more and more hardware related to me, maybe the thermostats are disabling their bluetooth connection to save energy or something.

Could you try out the following script on a machine with bluetooth after pairing with one of your thermostats and tell me if you see a similar behaviour? You'll need to do a pip install simplepyble for the script to run.
I'll also try out another PC and thermostat tomorrow.

import logging
from time import sleep

import simplepyble

logging.basicConfig(level=logging.INFO, format="%(asctime)s: %(message)s")


def main():
    adapters = simplepyble.Adapter.get_adapters()

    if len(adapters) == 0:
        logging.info("No adapters found")

    logging.info("Please select an adapter:")
    for i, adapter in enumerate(adapters):
        logging.info(f"{i}: {adapter.identifier()} [{adapter.address()}]")

    choice = int(input("Enter choice: "))
    adapter = adapters[choice]

    logging.info(f"Selected adapter: {adapter.identifier()} [{adapter.address()}]")

    adapter.set_callback_on_scan_start(lambda: logging.info("Scan started."))
    adapter.set_callback_on_scan_stop(lambda: logging.info("Scan complete."))
    adapter.set_callback_on_scan_found(
        lambda peripheral: logging.info(
            f"Found {peripheral.identifier()} [{peripheral.address()}]"
        )
    )

    adapter.scan_for(5000)
    peripherals = adapter.scan_get_results()

    logging.info("Please select a peripheral:")
    for i, peripheral in enumerate(peripherals):
        logging.info(f"{i}: {peripheral.identifier()} [{peripheral.address()}]")

    choice = int(input("Enter choice: "))
    peripheral = peripherals[choice]

    logging.info(f"Connecting to: {peripheral.identifier()} [{peripheral.address()}]")
    peripheral.connect()

    try:
        while True:
            if peripheral.is_connected():
                logging.info("Device is connected.")
            else:
                logging.info("Device is no longer connected.")

            sleep(1)

    except KeyboardInterrupt:
        pass

    finally:
        peripheral.disconnect()
        logging.info("Disconnected from the device.")


if __name__ == "__main__":
    main()

[dbuezas]

Yes, the device goes into Bluetooth sleep after a while. Somewhere in this repo/issues/discussion I suggest to have a scan interval < 1m to keep it connected

[EuleMitKeule]

I just spent the last 10 minutes spamming commands from the Calor BT app every 2 seconds and did not experience any disconnects, the command was applied instantly over the whole 10 minutes. There definetely has to be a way to keep the device awake and connected continuously.

[EuleMitKeule]

What about these other characteristics, could they have such a purpose?

Service: 00001800-0000-1000-8000-00805f9b34fb
    Characteristic: 00002a00-0000-1000-8000-00805f9b34fb
    Characteristic: 00002a01-0000-1000-8000-00805f9b34fb
    Characteristic: 00002a02-0000-1000-8000-00805f9b34fb
    Characteristic: 00002a03-0000-1000-8000-00805f9b34fb
    Characteristic: 00002a04-0000-1000-8000-00805f9b34fb
Service: 00001801-0000-1000-8000-00805f9b34fb
    Characteristic: 00002a05-0000-1000-8000-00805f9b34fb
Service: 0000180a-0000-1000-8000-00805f9b34fb
    Characteristic: 00002a24-0000-1000-8000-00805f9b34fb
    Characteristic: 00002a29-0000-1000-8000-00805f9b34fb
Service: 3e135142-654f-9090-134a-a6ff5bb77046
    Characteristic: 3fa4585a-ce4a-3bad-db4b-b8df8179ea09 (write)
    Characteristic: d0e8434d-cd29-0996-af41-6c90f4e0eb2a (notify)
Service: 9e5d1e47-5c13-43a0-8635-82ad38a1386f
    Characteristic: 347f7608-2e2d-47eb-913b-75d4edc4de3b (upgrade app info)
    Characteristic: 92e86c7a-d961-4091-b74f-2409e72efe36 (upgrade data)
    Characteristic: e3dd50bf-f7a7-4e99-838e-570a086c666b (upgrade control point)

[dbuezas]

I do not know. I suppose some are for pairing. I tried getting something from them with no success

[EuleMitKeule]

I found out what the remaining characteristics are used for:

2024-01-21 17:35:52,280 Service: 00001800-0000-1000-8000-00805f9b34fb (Handle: 256): Generic Access Profile
2024-01-21 17:35:52,280 Characteristic: 00002a00-0000-1000-8000-00805f9b34fb (Handle: 272): Device Name
2024-01-21 17:35:52,280 Characteristic: 00002a01-0000-1000-8000-00805f9b34fb (Handle: 288): Appearance
2024-01-21 17:35:52,280 Characteristic: 00002a02-0000-1000-8000-00805f9b34fb (Handle: 304): Peripheral Privacy Flag
2024-01-21 17:35:52,281 Characteristic: 00002a03-0000-1000-8000-00805f9b34fb (Handle: 320): Reconnection Address
2024-01-21 17:35:52,281 Characteristic: 00002a04-0000-1000-8000-00805f9b34fb (Handle: 336): Peripheral Preferred Connection Parameters
2024-01-21 17:35:52,281 Service: 00001801-0000-1000-8000-00805f9b34fb (Handle: 512): Generic Attribute Profile
2024-01-21 17:35:52,282 Characteristic: 00002a05-0000-1000-8000-00805f9b34fb (Handle: 528): Service Changed
2024-01-21 17:35:52,282 Service: 0000180a-0000-1000-8000-00805f9b34fb (Handle: 768): Device Information
2024-01-21 17:35:52,282 Characteristic: 00002a29-0000-1000-8000-00805f9b34fb (Handle: 784): Manufacturer Name String
2024-01-21 17:35:52,282 Characteristic: 00002a24-0000-1000-8000-00805f9b34fb (Handle: 800): Model Number String

[EuleMitKeule]

have a scan interval < 1m to keep it connected

You were absolutely right. Sending a command or resubscribing to the notify characteristic every 10 seconds prevents disconnects!
I will change the code so that smaller scan intervals can be configured and maybe add a hint message that explains this behaviour.

[dbuezas]

Looking at your code I just realized in my case 1 minute was enough to keep the device snappy. I think (thought?) that the connection was kept open, but maybe it just avoided the eq3 going in deep sleep and taking extra long to connect or something of the sort.

[EuleMitKeule]

maybe it just avoided the eq3 going in deep sleep and taking extra long to connect or something of the sort

This is definetely the case, I have no idea though why for you 1 minute seems to be enough while for me that leads to disconnects. Maybe it's firmware related or it depends on the battery level or bluetooth adapter or something?
Whichever it is, I think it's a good idea to 1. allow the user to increase the scan interval to just a few seconds and 2. make a scan interval of 10 seconds the default value to reduce bug reports related to connection problems in the future.
I changed some of the bluetooth connection logic and now I managed to get a persistent connection.

[dbuezas]

10 seconds may be harsh on the batteries. I have no issues with 1 minute and a usb dongle.
Are you using bt proxies?

[EuleMitKeule]

With 1 minute I get disconnects every 5 minutes for 30 seconds, no matter if I use bt proxies, dongles or internal bluetooth. As you said, it's the thermostat itself which is deactivating its bluetooth radio.