Примерно с августа 2025 года в журнале HA начали выводиться предупреждения:
BleakClient.connect() called without bleak-retry-connector
Как я понял, HA теперь рекомендует использовать establish_connection() из пакета bleak-retry-connector. А pip-пакет tion_btle, используемый интеграцией, подключается напрямую через BleakClient(mac).connect().
После недавнего (майского или июньского) обновления управление бризером у меня вообще перестало работать. После перезагрузки HA пару раз удавалось послать команду бризеру, а потом - всё.
В логе - ошибки типа таких:
Got exception: No backend with an available connection slot that can reach address DE:A7:3B:CF:5F:A5 was found: in connectable history; 1 scanner(s) registered, 1 scanning, 1 connectable; last advertisement 0s ago via hci0 (00:1A:7D:DA:71:13). Will try again
18:55:36 - (ПРЕДУПРЕЖДЕНИЕ) Tion breezer (пользовательская интеграция)
DE:A7:3B:CF:5F:A5: BleakClient.connect() called without bleak-retry-connector.
For reliable connection establishment, use bleak_retry_connector.establish_connection().
See https://github.com/Bluetooth-Devices/bleak-retry-connector
18:55:34 - (ПРЕДУПРЕЖДЕНИЕ) Tion breezer (пользовательская интеграция)
Will delay next check
18:55:00 - (КРИТИЧЕСКАЯ ОШИБКА) Tion breezer (пользовательская интеграция)
Got exception
18:55:00 - (КРИТИЧЕСКАЯ ОШИБКА) Tion breezer (пользовательская интеграция)
В общем, я озадачил этими проблемами ИИ, и он выдал исправленную версию кода интеграции ha_tion_btle и пакета tion_btle (код которого находится тут: https://github.com/TionAPI/tion_python). И вроде как все проблемы с интеграцией ушли (проверял на бризере Tion 4s).
По-хорошему, правленые версии кода интеграции ha_tion_btle и пакета tion_btle надо коммитить на github. Как только "дойдут руки" - сделаю pull request в эти два репозитория. Ну а пока просто выкладываю архив с исправленным кодом:
ha_tion_btle.zip
Установить его просто:
В папке, куда у вас установлен Home Assistant, нужно зайти в папку "homeassistant --> custom_components --> ha_tion_btle" и удалить там все файлы/папки (на всякий случай создайте резервную копию). Затем поместить туда содержимое архива. И потом перезагрузить HA.
Можно это сделать через расширение FileBrowser:
https://community.home-assistant.io/t/home-assistant-addon-filebrowser
PS:
В оригинале, интеграция ha_tion_btle импортирует пакет tion_btle (он загружается с github-репозитория при установке интеграции ha_tion_btle). Т.е. пакет tion_btle надо править в его репозитории, о чём я писал выше - делать pull request, чтобы появилась новая версия, и сослаться на неё в коде интеграции ha_tion_btle. Другой "быстрый" вариант - исправить код пакета tion_btle непосредственно на диске, там, куда его скачал HA (или pip) при установке интеграции ha_tion_btle. Но с этим вариантом у меня тоже не сложилось, т.к. HA установлен в виде HA OS и я не смог даже найти, где там лежат скачанные python-пакеты.
Поэтому я (точнее, ИИ) поступил проще: исправленный код интеграции ha_tion_btle больше не импортирует пакет tion_btle. Вместо этого код пакета tion_btle напрямую встроен в код интеграции ha_tion_btle - см. подпапку "lib" в моём архиве.
PPS: выданный ИИ код я не смотрел, ибо не особо силён в Python и тем более в Bluetooth. Так что сильно "не пинайте" )
ИИ выдал такой анализ:
В библиотеке tion_btle/tion.py:
(а) Прямой BleakClient вместо establish_connection() Оригинальный код (строка 88) создавал BleakClient(mac) напрямую — это было нормально до HA 2025.9, но стало блокироваться в HA 2026.6.
(б) Утечка BLE-подключений через set_new_btle_device() Метод (строки 579–596) создавал новый BleakClient при реконнекте, но старый не закрывал корректно. Каждый такой «сиротский» клиент занимал слот адаптера, который никогда не освобождался.
(в) Счётчик __connections_count без защиты от исключений Если _connect() выбрасывал исключение, disconnect() не вызывался, счётчик не декрементировался. Последующие вызовы connect() видели count > 0 и считали, что подключение уже есть — но реального подключения не было.
(г) Лишний BLE-запрос в set() Метод set() (строка 246) вызывал await self.get(skip_update=True), который при have_breezer_state=False делал полный BLE-запрос состояния. Это удваивало BLE-транзакции и увеличивало нагрузку на адаптер.
(д) Отсутствие таймаута в _get_data_from_breezer() Цикл ожидания (строки 538–576) мог длиться до 10 секунд (10 итераций × 1 сек), блокируя координатор HA.
В интеграции custom_components/ha_tion_btle/init.py:
(е) _delay = 600 секунд (10 минут) При ошибке соединения координатор ждал 10 минут до следующей попытки — слишком долго для устройства, которое может восстановиться через несколько секунд.
(ж) Отсутствие очистки при ошибках При MaxTriesExceededError координатор просто увеличивал интервал, но не вызывал очистку BLE-подключения. «Сиротский» слот оставался занятым.
В интеграции custom_components/ha_tion_btle/climate.py:
(з) Вложенные connect()/disconnect() Режимы HEAT (строки 119–127) и смена preset (строки 174–184) оборачивали вызовы _async_set_state() во внешние coordinator.connect() / coordinator.disconnect(). Но _async_set_state() → coordinator.set() сам вызывает connect()/disconnect(). Это создавало двойные подключения и увеличивало риск утечки слотов.
Примерно с августа 2025 года в журнале HA начали выводиться предупреждения:
BleakClient.connect() called without bleak-retry-connector
Как я понял, HA теперь рекомендует использовать establish_connection() из пакета bleak-retry-connector. А pip-пакет tion_btle, используемый интеграцией, подключается напрямую через BleakClient(mac).connect().
После недавнего (майского или июньского) обновления управление бризером у меня вообще перестало работать. После перезагрузки HA пару раз удавалось послать команду бризеру, а потом - всё.
В логе - ошибки типа таких:
В общем, я озадачил этими проблемами ИИ, и он выдал исправленную версию кода интеграции ha_tion_btle и пакета tion_btle (код которого находится тут: https://github.com/TionAPI/tion_python). И вроде как все проблемы с интеграцией ушли (проверял на бризере Tion 4s).
По-хорошему, правленые версии кода интеграции ha_tion_btle и пакета tion_btle надо коммитить на github. Как только "дойдут руки" - сделаю pull request в эти два репозитория. Ну а пока просто выкладываю архив с исправленным кодом:
ha_tion_btle.zip
Установить его просто:
В папке, куда у вас установлен Home Assistant, нужно зайти в папку "homeassistant --> custom_components --> ha_tion_btle" и удалить там все файлы/папки (на всякий случай создайте резервную копию). Затем поместить туда содержимое архива. И потом перезагрузить HA.
Можно это сделать через расширение FileBrowser:
https://community.home-assistant.io/t/home-assistant-addon-filebrowser
PS:
В оригинале, интеграция ha_tion_btle импортирует пакет tion_btle (он загружается с github-репозитория при установке интеграции ha_tion_btle). Т.е. пакет tion_btle надо править в его репозитории, о чём я писал выше - делать pull request, чтобы появилась новая версия, и сослаться на неё в коде интеграции ha_tion_btle. Другой "быстрый" вариант - исправить код пакета tion_btle непосредственно на диске, там, куда его скачал HA (или pip) при установке интеграции ha_tion_btle. Но с этим вариантом у меня тоже не сложилось, т.к. HA установлен в виде HA OS и я не смог даже найти, где там лежат скачанные python-пакеты.
Поэтому я (точнее, ИИ) поступил проще: исправленный код интеграции ha_tion_btle больше не импортирует пакет tion_btle. Вместо этого код пакета tion_btle напрямую встроен в код интеграции ha_tion_btle - см. подпапку "lib" в моём архиве.
PPS: выданный ИИ код я не смотрел, ибо не особо силён в Python и тем более в Bluetooth. Так что сильно "не пинайте" )
ИИ выдал такой анализ:
В библиотеке tion_btle/tion.py:
(а) Прямой BleakClient вместо establish_connection() Оригинальный код (строка 88) создавал BleakClient(mac) напрямую — это было нормально до HA 2025.9, но стало блокироваться в HA 2026.6.
(б) Утечка BLE-подключений через set_new_btle_device() Метод (строки 579–596) создавал новый BleakClient при реконнекте, но старый не закрывал корректно. Каждый такой «сиротский» клиент занимал слот адаптера, который никогда не освобождался.
(в) Счётчик __connections_count без защиты от исключений Если _connect() выбрасывал исключение, disconnect() не вызывался, счётчик не декрементировался. Последующие вызовы connect() видели count > 0 и считали, что подключение уже есть — но реального подключения не было.
(г) Лишний BLE-запрос в set() Метод set() (строка 246) вызывал await self.get(skip_update=True), который при have_breezer_state=False делал полный BLE-запрос состояния. Это удваивало BLE-транзакции и увеличивало нагрузку на адаптер.
(д) Отсутствие таймаута в _get_data_from_breezer() Цикл ожидания (строки 538–576) мог длиться до 10 секунд (10 итераций × 1 сек), блокируя координатор HA.
В интеграции custom_components/ha_tion_btle/init.py:
(е) _delay = 600 секунд (10 минут) При ошибке соединения координатор ждал 10 минут до следующей попытки — слишком долго для устройства, которое может восстановиться через несколько секунд.
(ж) Отсутствие очистки при ошибках При MaxTriesExceededError координатор просто увеличивал интервал, но не вызывал очистку BLE-подключения. «Сиротский» слот оставался занятым.
В интеграции custom_components/ha_tion_btle/climate.py:
(з) Вложенные connect()/disconnect() Режимы HEAT (строки 119–127) и смена preset (строки 174–184) оборачивали вызовы _async_set_state() во внешние coordinator.connect() / coordinator.disconnect(). Но _async_set_state() → coordinator.set() сам вызывает connect()/disconnect(). Это создавало двойные подключения и увеличивало риск утечки слотов.