Home Assistant позиционирует себя как локальную систему. Но я столкнулся с ситуацией, когда локальная функция (Samba) не работает из‑за облачного сбоя. При этом я вообще не использую облако. В статье описываю как обошёл эту проблему за 5 минут, когда за день разобрался в причине.

Мне очень нравится Home Assistant как система управления умным домом, потому что она позволяет не зависеть от облаков и от падений интернета. Это не просто слова — с 2017 года я использую умный дом в обычной двухкомнатной хрущевке, и в основном всё работает. Но это скорее тестовый полигон для меня — я сам там не живу и поэтому очень ценю то что Home Assistant можно настроить один раз и если не обновлять, то несколько лет всё может спокойно проработать. А на этих новогодних каникулах у меня было время и я решил полностью обновить все дополнения и прошивки. Как оказалось зря — паранойя безопасности ломает определение Home Assistant как автономного сервиса, который можно использовать локально.

Небольшая предыстория: весь мой проект начался в 2017 году с идеи удаленного сбора показаний счётчиков квартиры, где я использовал самые доступные по цене решения: ESP8266, MegaD. Потом решил подключить управление светом через дешевые Sonoff с прошивкой Tasmota и OpenHAB. 1000 дней пользовался OpenHAB, а затем перешел на Home Assistant, а в 2024 году провёл ремонт и замену Wi‑Fi реле на Zigbee. И до недавнего времени это работало.

В первых числах января 2026 решил удаленно обновить все зависимости — за несколько раз всё обновилось, но мне ещё понадобилось включить дополнение Samba share, чтобы из под Windows проверить пару конфигов, которые не хотели работать. А я отключил Samba share ещё год назад. Удаленно не смог включить — всё какая‑то ошибка вылазила, хотя все остальные компоненты работают. Пришлось ехать на квартиру и думал что может быть Raspberry Pi 3 2015 года уже старая стала или флешка сдохла. У меня было ещё несколько запасных — прихватил и чистую флешку и новый микрокомпьютер 2017 года и новый блок питания. 

"Стенд проверки"
"Стенд проверки"

Поставил чистую систему — в 2026 году это происходит через Raspberry Pi Imager, хочу с Windows компьютера подключиться, а там та же ошибка Не удалось сохранить конфигурацию дополнения, Unknown error, see supervisor logs. И непонятно из‑за чего.

Ошибка Home Assistant Не удалось сохранить конфигурацию дополнения, Unknown error, see supervisor logs
Ошибка Home Assistant Не удалось сохранить конфигурацию дополнения, Unknown error, see supervisor logs

Только в логах на чистой системе подробно рассмотрел что WARNING (MainThread) [supervisor.utils.pwned] Can’t fetch HIBP data: Timeout

Ошибка Home Assistant WARNING (MainThread) [supervisor.utils.pwned] Can’t fetch HIBP data: Timeout
Ошибка Home Assistant WARNING (MainThread) [supervisor.utils.pwned] Can’t fetch HIBP data: Timeout

Стал разбираться и оказалось что Home Assistant абсолютно все пароли проверяет на скомпромитированность через онлайн сервис, а поскольку мы в России, то этот сервис не даёт ответа видимо из‑за санкций или политики, а в интерфейсе ничего внятного не пишет — просто неизвестная ошибка.

И я в своём полностью локальном Home Assistant не могу к нему по локальной сети подключиться из‑за того что этот онлайн сервис HIBP не отвечает. Сервис HIBP (Have I Been Pwned) проверяет были ли заново создаваемые пароли в утечках данных. 

Но какая‑то нестыковка кажется с заявленной полной локальностью Home Assistant?

Home Assistant

Home Assistant пользуется этим сервисом и это нельзя отключить для проверки безопасности паролей. Но я даже не знал что такая проверка есть, а у сервиса проблемы с доступностью в России из‑за санкций или Роскомнадзора, что вызывает ошибки и блокирует работу всей домашней системы.

Как исправить ошибку WARNING (MainThread) [supervisor.utils.pwned] Can’t fetch HIBP data: Timeout

Поскольку у меня уже был физический доступ к SD карте — раз я приехал на удаленную квартиру, на которой установлен Home Assistant, то решил через физическое подключение к Linux провести все манипуляции, потому что функция PwnedConnectivityError блокирует абсолютно всё.

SD карта, подключенная к Linux
SD карта, подключенная к Linux

Нашёл проблему в файле pwned.py, он файл лежит внутри контейнера Supervisor, в моём случае по адресу admin:///media/mike/hassos‑data/docker/overlay2/0e05ec32ffef35caed1b7184eefcfdda5eb1a35ad60e68e5d14f3a73996b18ea/diff/usr/src/supervisor/supervisor/utils.

Картридер в Ubuntu
Картридер в Ubuntu

Но у вас будет другой пу��ь, надо искать внутри внутри контейнера Supervisor: /usr/src/supervisor/supervisor/utils/pwned.py

Файл /usr/src/supervisor/supervisor/utils/pwned.py
Файл /usr/src/supervisor/supervisor/utils/pwned.py

Вот оригинальный файл pwned.py с проблемой:

"""Small wrapper for haveibeenpwned.com API."""

import io
import logging

import aiohttp

from ..exceptions import PwnedConnectivityError, PwnedError, PwnedSecret

_LOGGER: logging.Logger = logging.getLogger(__name__)
_API_CALL: str = "https://api.pwnedpasswords.com/range/{hash}"

_CACHE: set[str] = set()


async def check_pwned_password(websession: aiohttp.ClientSession, sha1_pw: str) -> None:
    """Check if password is pwned."""
    sha1_pw = sha1_pw.upper()

    # Chech hit cache
    sha1_short = sha1_pw[:5]
    if sha1_short in _CACHE:
        raise PwnedSecret()

    _LOGGER.debug("Check pwned state of %s", sha1_short)
    try:
        async with websession.get(
            _API_CALL.format(hash=sha1_short), timeout=aiohttp.ClientTimeout(total=10)
        ) as request:
            if request.status != 200:
                raise PwnedError(
                    f"Pwned service response with {request.status}", _LOGGER.warning
                )
            data = await request.text()

        buffer = io.StringIO(data)
        for line in buffer:
            if not sha1_pw.endswith(line.split(":")[0]):
                continue
            _CACHE.add(sha1_short)
            raise PwnedSecret()

    except (aiohttp.ClientError, TimeoutError) as err:
        raise PwnedConnectivityError(
            f"Can't fetch HIBP data: {str(err) or 'Timeout'}", _LOGGER.warning
        ) from err
Файл /usr/src/supervisor/supervisor/utils/pwned.py
Файл /usr/src/supervisor/supervisor/utils/pwned.py

Вот моя изменненная версия pwned.py с полным отключением проблемного в России сервиса Have I Been Pwned (HIBP):

"""Small wrapper for haveibeenpwned.com API."""

import io
import logging

import aiohttp

from ..exceptions import PwnedConnectivityError, PwnedError, PwnedSecret

_LOGGER: logging.Logger = logging.getLogger(__name__)
_API_CALL: str = "https://api.pwnedpasswords.com/range/{hash}"

_CACHE: set[str] = set()


async def check_pwned_password(websession: aiohttp.ClientSession, sha1_pw: str) -> None:
    """Check if password is pwned."""
    return None
    
    """
    sha1_pw = sha1_pw.upper()

    # Chech hit cache
    sha1_short = sha1_pw[:5]
    if sha1_short in _CACHE:
        raise PwnedSecret()

    _LOGGER.debug("Check pwned state of %s", sha1_short)
    try:
        async with websession.get(
            _API_CALL.format(hash=sha1_short), timeout=aiohttp.ClientTimeout(total=10)
        ) as request:
            if request.status != 200:
                raise PwnedError(
                    f"Pwned service response with {request.status}", _LOGGER.warning
                )
            data = await request.text()

        buffer = io.StringIO(data)
        for line in buffer:
            if not sha1_pw.endswith(line.split(":")[0]):
                continue
            _CACHE.add(sha1_short)
            raise PwnedSecret()

    except (aiohttp.ClientError, TimeoutError) as err:
        raise PwnedConnectivityError(
            f"Can't fetch HIBP data: {str(err) or 'Timeout'}", _LOGGER.warning
        ) from err
    """

После того как внёс изменения и вставил SD карту обратно в Raspberry Pi все пароли стало успешно сохранять и работоспособность полностью восстановилась.

Работоспособность сохранения паролей восстановилась
Работоспособность сохранения паролей восстановилась

Масштаб проблемы

Судя потому что я нашёл через поиск эта проблема существует уже несколько месяцев. Вот например похожий пример, когда человек пытался с ней справиться осенью 2025 года.

Мне кажется подобные решения очень сильно бьют по новичкам, которым реально сложно разобраться в подобных системах и ещё больше вопросов вызывает то что Home Assistant всегда был полностью локальной автономной системой, которую можно было настроить даже на даче и тут вылазит такая фишка.

Вообще мне кажется что стремление к безопасности — это хорошо, но вот делать зависимость от внешнего API для базовых локальных функций — это архитектурная ошибка.

Автор: Михаил Шардин
? Моя онлайн‑визитка
? Telegram «Умный Дом Инвестора»

6 января 2026

Комментарии (38)


  1. d3d11
    06.01.2026 03:54

    "Театр безопасности"


    1. randomsimplenumber
      06.01.2026 03:54

      Цирк безопасности даже.


      1. Wesha
        06.01.2026 03:54

        Ага. «Graceful degradation»? Не слышали!


  1. ky0
    06.01.2026 03:54

    Нельзя ли им PR с решением куда-нибудь отправить? Что починили - круто, но проблему имеет смысл решить глобально, добавив фоллбэк и вменяемое сообщение в лог.


    1. empenoso Автор
      06.01.2026 03:54

      На их форуме уже несколько месяцев переписка болтается. Боюсь мне недостучаться. Только так - через общественное мнение если


    1. Goron_Dekar
      06.01.2026 03:54

      Накинул ещё на вентилятор во внутреннем чате части разрабов HA. Следить не буду - там на плохом английском много личной хераборы, но авось поможет.


    1. Ilya_JOATMON
      06.01.2026 03:54

      Это вообще опционально должно быть, причем явно и выключено по умолчанию.



  1. andybiiig
    06.01.2026 03:54

    Логичнее было бы поправить только три последние строки, чтобы при недоступности сервиса делалась запись в лог, но проверка считалась пройденной. У кого доступно - пусть проверяется


    1. randomsimplenumber
      06.01.2026 03:54

      Логичнее всего - отключить и не включать. Хочется чего то проверять - проверять локально. Cracklib в помощь


      1. Goron_Dekar
        06.01.2026 03:54

        Вообще идея посылать чего-то личное в какое-то облако не спрашивая - охрененно плохая, так то.


        1. Jubilus
          06.01.2026 03:54

          Справедливости ради, HIBP использует k-anonymity: отправляются только первые 5 символов SHA 1 хеша. Сервер не знает ваш пароль, он возвращает список всех хвостов, а клиент уже сам ищет совпадение

          Но да, без явного согласия пользователя такие запросы делать моветон


  1. rPman
    06.01.2026 03:54

    .


  1. NeiroNx
    06.01.2026 03:54

    Это вообще очень подозрительно, возможно сервис просто создает базы хешей по адресам.


    1. Ilya_JOATMON
      06.01.2026 03:54

      Как в старой притче.

      Мастер, я погуглил - такого пароля в интернете нет!

      Теперь - есть.


      1. randomsimplenumber
        06.01.2026 03:54

        Ну, лично мне хешей от автогенеренных паролей не жалко. Могу и поделиться ;)


        1. FSS1989
          06.01.2026 03:54

          На ваш хэш может найтись более одной строчки с паролем. А далее, дело за малым, можно просто подставить совершенно другую строку в качестве пароля и войти в ваш сервис не зная оригинаььного пароля.


          1. randomsimplenumber
            06.01.2026 03:54

            Я и пару миллионов хешей могу пожертвовать на хорошее дело ;)


  1. seryoga77
    06.01.2026 03:54

    Заведите issue в репозитории supervisor на GitHub. Сейчас там всего 40 открытых, похоже что их разгребают.


  1. tigreavecdesailes
    06.01.2026 03:54

    Сам не проверял (!) , но быстрое гугление показывает, что штатное отключение существует уже давно:

    И в коде (https://github.com/home-assistant/supervisor/blob/5ebd200b1eea3a50997754c8ce123db92a8eff9d/supervisor/security/module.py#L47), вроде, это подтверждается:


    1. germn
      06.01.2026 03:54

      Спасибо за ссылку и скрины, добрый человек!

      Похоже, этот вариант уже не работает. Проверил у себя только что (не сработало) и нагуглил свежий репорт:

      https://github.com/home-assistant/core/issues/157529


      1. negaft
        06.01.2026 03:54

        Да, я проверял это в конце года и всё, что меняется - пропадает одна из двух ошибок в логах. Кроме того, мне попадался совет с редактированием pwned.py, но либо я что-то делал не так, либо разработчики что-то изменили, но после перезапуска системы файл восстанавливался и проверка снова работала.



  1. FreeSkif
    06.01.2026 03:54

    Пользуюсь HA лет так 4-5, очень сильно выручал в условиях "живем в тайге, интернет только спутниковый и дорогой".

    Пришлось уехать на время - супруга через день стала говорить, что "умный дом" зависает, то свет вовремя на улице не включит, то в курятнике термостат не сработает. Вернулся, стал проверять - все работает.

    И только сейчас подумал, а ведь HA мог стучаться в инет, в ответ получать "заглушку" от провайдера с редиректом на страницу авторизации и через *цать запросов ложиться намертво. Потому что пока я дома и инет подключен - кроме сбоев по питанию ничего умный дом не ложило.

    Спасибо, натолкнули на мысль.


  1. Jonikus
    06.01.2026 03:54

    Это должно быть галочкой в настройках я считаю, а по умолчанию выключено.


  1. NutsUnderline
    06.01.2026 03:54

    за что боролись... накрутили 100500 багофич, типа все остальное уже работает, вендронезависимость, работает без интернета. Если ЭТо изначально не пускать в интернет то и паролю будет некуда утекать. Но нам же жизнено нужны свежие автообновления ..


  1. TatianAmoroZ
    06.01.2026 03:54

    Не проще ли эту проблему решить с помощью VPN зайдя, так сказать, с другой стороны?


    1. GT_Volk
      06.01.2026 03:54

      Настоящая проблема тут в том что подобные вещи должны быть опциональными и по умолчанию отключенными, поэтому и решать проблему нужно соответствующим способом, а не подключая VPN к автономному умному дому.


    1. vvzvlad
      06.01.2026 03:54

      А завтра VPN ляжет, и что? Все повторится же. Или сам провайдер ляжет


    1. negaft
      06.01.2026 03:54

      С этим тоже интересно. Если настраивать ВПН на Home Assistant так, как это рекомендуется, через аддоны, то эти аддоны не заведутся из-за той же ошибки. Не проверял на других ВПН, но в конфигах аддонов для wireguard поле для закрытого ключа имеет тип password и, соответственно, при сохранении настроек или при запуске аддона система пытается проверить ключ на HIBP, проверка падает и ВПН не поднимается.


      1. empenoso Автор
        06.01.2026 03:54

        Замкнутый круг


  1. LF69ssop
    06.01.2026 03:54

    Почему то кажется что если файл в докере то и править правильнее докер файл.


    1. endoftime
      06.01.2026 03:54

      Если брать ha в докере, там такой проблемы нет. Она есть только в версии с супервайзером, то есть на текущий момент в ha os. А там может быть все что угодно, а не только проверка пароля...


  1. Jubilus
    06.01.2026 03:54

    Система для локального умного дома требует интернет, чтобы проверить, не украли ли ваш пароль от локального умного дома - рекурсия паранойи) Видимо разработчики HA считают, что у каждого пользователя в подвале стоит хакер, который брутфорсит его зигби-лампочки через HIBP


  1. texbez
    06.01.2026 03:54

    Блин только собрался купить малинку и освоить home assistant! Получается что лучше не надо палить деньги и остаться на спруте и iobroker?


    1. empenoso Автор
      06.01.2026 03:54

      Кто знает