Solved: cannot_connect / MQTT code 5 on newer VIDAA firmware — pass MAC explicitly (Docker can't ARP) + disable protocol auto-detect

[kushnirpasha-lang]

Controlling a "too-new" Hisense VIDAA TV from Home Assistant — SOLVED

(Управление «слишком новым» телевизором Hisense VIDAA из Home Assistant — РЕШЕНО)

🇷🇺 Кратко для русскоязычных: если ваш новый Hisense VIDAA «не подключается» к Home Assistant (ошибка cannot_connect / MQTT code 5), дело почти наверняка НЕ в прошивке. Три причины: (1) сменился IP телевизора, (2) сломан авто-детект протокола, (3) динамический пароль считается из MAC, а Docker не видит MAC телевизора. Ниже — полное решение на английском; прогоните через переводчик/ИИ.

TL;DR: People keep reporting that newer Hisense VIDAA TVs "can't be controlled" from Home Assistant — the vidaa_tv / hisensetv MQTT integrations fail with cannot_connect or MQTT CONNACK code 5 (not authorized), and everyone blames "firmware too new". In our case it was not the firmware. It was three separate, fixable problems stacked on top of each other. After fixing all three, we got full native control — power, keys, state, and app launch (YouTube) — with a persistent token, on a TV that had refused every previous attempt.

Tested on: Hisense 55E7LE, VIDAA, software V0002.09.09B.P1001. Library: vidaa-control 1.1.0 (used by the ha-vidaa-tv custom integration). Home Assistant in Docker (Colima on macOS).

---

Symptoms we saw (probably the same as you)

• HA integration config flow → cannot_connect.
• Manual vidaa / hisensetv connect → Connection failed with code: 5 (MQTT not authorized), repeated.
• Log line: Failed to fetch protocol info: <urlopen error timed out> → Could not detect protocol. Using modern auth.
• Earlier attempts (older tools) even showed the TV saying "update the app to the latest version" — which everyone reads as "firmware locked it down". It isn't.

The three real root causes

1. The TV's IP had changed (DHCP) — we were probing a dead address

The integration/tool connected fine "yesterday" and then just stopped. The TV had simply got a new DHCP lease. Probing the old IP gives an incomplete ARP entry / "host is down" / filtered ports — which looks exactly like "the service is gone".

Fix: don't hardcode the IP. Discover the current one via mDNS (the TV advertises _hap._tcp HomeKit with a name like Hisense 55E7LE-XXXXXX), or — better — set a DHCP reservation for the TV so its IP never changes.

2. Protocol auto-detection times out → wrong auth path

vidaa-control tries to GET http://<tv>:38400/MediaServer/rendererdevicedesc.xml to read transport_protocol and pick the auth method. On our TV port 38400 is filtered (only 36669 is open), so this times out, and the lib falls back to a guess that fails.

Fix: disable auto-detection and set the auth method explicitly:
auto_detect_protocol=False, auth_method=AuthMethod.MODERN (MODERN = transport ≥ 3290; try MIDDLE/LEGACY if MODERN gives code 5).

3. CONNACK code 5 = the dynamic MQTT password needs the TV's MAC — and Docker can't ARP it

Newer VIDAA firmware uses dynamic MQTT credentials computed from the TV's MAC address (reverse-engineered in credentials.py). The library resolves the MAC via ARP from the host running HA. Inside a Docker/NAT setup (Colima, HAOS supervised, etc.) the container cannot ARP a device on the physical LAN, so it gets no MAC → can't compute the password → CONNACK code 5.

Fix: get the MAC from a machine that IS on the LAN (arp -a | grep <tv-ip>) and pass it explicitly as mac_address="AA:BB:CC:DD:EE:FF".

Bonus gotcha: the pairing code lives ~25 seconds

async_start_pairing() shows a 4-digit code on the TV that expires in ~25 s and changes on every call. If your read→type→submit loop is slower than that, you'll never land a valid code. We used a small script that auto-re-requests the code every ~20 s and reads the PIN from a file, so the code is always fresh and gets injected the instant it's read.

---

The working recipe

import asyncio
from pathlib import Path
from vidaa import AsyncVidaaTV
from vidaa.protocol import AuthMethod
from vidaa.config.storage import TokenStorage

TV_IP  = "10.0.0.9"                 # discover via mDNS; set a DHCP reservation
TV_MAC = "AA:BB:CC:DD:EE:FF"        # YOUR TV's MAC: arp -a | grep <TV_IP>  (run from a host ON the LAN)

tv = AsyncVidaaTV(
    host=TV_IP, port=36669,
    auto_detect_protocol=False,     # fix #2: :38400 is filtered
    auth_method=AuthMethod.MODERN,  # try MIDDLE / LEGACY if code 5
    use_dynamic_auth=True,
    mac_address=TV_MAC,             # fix #3: required, container can't ARP it
    enable_persistence=True,
    storage=TokenStorage(Path("/config/.vidaa_tv_tokens.json")),
)

async def pair():
    await tv.async_connect(timeout=8)        # connects (authenticated=False on the very first run)
    await tv.async_start_pairing()           # a 4-digit code shows on the TV (~25 s!)
    await tv.async_authenticate("1234")      # enter it FAST
    # token is now saved; future connects reconnect with authenticated=True, no code

asyncio.run(pair())

After pairing once, a token is stored (keyed by MAC). Reconnects are authenticated automatically — you still pass mac_address (the CONNECT password is derived from it), but you never need the on-screen code again.

Verified working afterwards: async_get_state, async_get_apps, async_launch_app("YouTube") → True, power, async_send_key, navigation, volume, source.

---

If you're using the Home Assistant ha-vidaa-tv custom integration

Its config flow resolves the MAC with get_mac_from_ip(), which returns nothing inside Docker/NAT, so the flow dies at cannot_connect before it can pair. Until the integration lets you enter the MAC manually, pair once with the script above (writing the token to /config/.vidaa_tv_tokens.json) — or patch the flow to accept a MAC. (Maintainers: a "MAC address (optional)" field in the config flow would fix this for every Docker/HAOS user.)

Summary

It's almost never "the firmware locked it". Check, in order: (1) is the IP current? (2) disable protocol auto-detect + set auth method, (3) pass the TV's MAC explicitly (Docker can't ARP), and beat the ~25 s pairing window. All three together got a supposedly "unsupported, too-new" Hisense fully controllable.

Как взять под контроль «слишком новый» Hisense VIDAA из Home Assistant — РЕШЕНО

(Controlling a "too-new" Hisense VIDAA TV from Home Assistant — solved)

Коротко: повсюду пишут, что новые телевизоры Hisense VIDAA «невозможно» подключить к Home Assistant — интеграции vidaa_tv / hisensetv (MQTT) падают с cannot_connect или MQTT-ошибкой CONNACK code 5 (не авторизован), и все винят «слишком новую прошивку». В моём случае прошивка ни при чём. Виноваты три отдельные, решаемые проблемы, наложенные друг на друга. После того как я починил все три, получился полный нативный контроль — питание, кнопки, статус, запуск приложений (YouTube) — с постоянным токеном, на телевизоре, который до этого отказывал во всех попытках.

Проверено на: Hisense 55E7LE, VIDAA, ПО V0002.09.09B.P1001. Библиотека: vidaa-control 1.1.0 (её использует кастомная интеграция ha-vidaa-tv). Home Assistant в Docker (Colima на macOS).

---

Симптомы (наверняка те же, что у вас)

• Мастер настройки интеграции → cannot_connect.
• Ручное подключение через vidaa / hisensetv → Connection failed with code: 5 (MQTT «не авторизован»), повторяется.
• В логе: Failed to fetch protocol info: <urlopen error timed out> → Could not detect protocol. Using modern auth.
• Старые инструменты вообще показывали на телевизоре «обновите приложение до новейшей версии» — что все читают как «прошивка всё закрыла». Это НЕ так.

Три настоящие причины

1. У телевизора сменился IP (DHCP) — вы стучитесь в мёртвый адрес

Ещё «вчера» всё работало, а сегодня перестало. Телевизор просто получил новый IP по DHCP. Пинг/порты на старом адресе выглядят как «сервис пропал» (incomplete ARP, «host is down», порт «filtered»).

Решение: не хардкодьте IP. Определяйте текущий через mDNS (телевизор светит _hap._tcp HomeKit с именем вида Hisense 55E7LE-XXXXXX), а лучше — сделайте телевизору резервирование IP (DHCP reservation) на роутере.

2. Авто-определение протокола зависает → выбирается неправильная авторизация

vidaa-control пытается получить http://<tv>:38400/MediaServer/rendererdevicedesc.xml, чтобы прочитать transport_protocol и выбрать метод авторизации. На моём телевизоре порт 38400 закрыт/filtered (открыт только 36669), поэтому запрос зависает по таймауту, и библиотека уходит в неверную догадку.

Решение: отключить авто-детект и задать метод явно:
auto_detect_protocol=False, auth_method=AuthMethod.MODERN (MODERN = transport ≥ 3290; если code 5 — попробуйте MIDDLE / LEGACY).

3. CONNACK code 5 = динамический MQTT-пароль считается из MAC телевизора, а Docker не видит ARP

Новые прошивки VIDAA используют динамические MQTT-учётки, вычисляемые из MAC-адреса телевизора (алгоритм реверс-инженерен в credentials.py). Библиотека получает MAC через ARP с той машины, где крутится HA. Внутри Docker/NAT (Colima, HAOS supervised и т.п.) контейнер НЕ может сделать ARP устройству в физической локалке → нет MAC → нельзя вычислить пароль → CONNACK code 5.

Решение: возьмите MAC с машины, которая реально в локалке (arp -a | grep <ip-телевизора>), и передайте его явно: mac_address="AA:BB:CC:DD:EE:FF".

Бонус-грабли: код спаривания живёт ~25 секунд

async_start_pairing() показывает на телевизоре 4-значный код, который истекает за ~25 секунд и меняется при каждом вызове. Если ваш цикл «прочитал → ввёл → отправил» медленнее — вы никогда не попадёте валидным кодом. Я сделал скрипт, который сам перезапрашивает код каждые ~20 секунд и читает PIN из файла, чтобы код всегда был свежий и вводился мгновенно.

---

Рабочий рецепт

import asyncio
from pathlib import Path
from vidaa import AsyncVidaaTV
from vidaa.protocol import AuthMethod
from vidaa.config.storage import TokenStorage

TV_IP  = "10.0.0.9"                 # определить через mDNS; сделать DHCP-резервирование
TV_MAC = "AA:BB:CC:DD:EE:FF"        # MAC ВАШЕГО ТВ: arp -a | grep <TV_IP>  (с машины В локалке)

tv = AsyncVidaaTV(
    host=TV_IP, port=36669,
    auto_detect_protocol=False,     # причина №2: порт 38400 filtered
    auth_method=AuthMethod.MODERN,  # если code 5 — попробуйте MIDDLE / LEGACY
    use_dynamic_auth=True,
    mac_address=TV_MAC,             # причина №3: обязательно, контейнер не видит ARP
    enable_persistence=True,
    storage=TokenStorage(Path("/config/.vidaa_tv_tokens.json")),
)

async def pair():
    await tv.async_connect(timeout=8)        # подключается (authenticated=False на самом первом запуске)
    await tv.async_start_pairing()           # на ТВ появляется 4-значный код (~25 секунд!)
    await tv.async_authenticate("1234")      # вводите БЫСТРО
    # токен сохранён; дальше подключения авторизуются сами, код больше не нужен

asyncio.run(pair())

После первого спаривания токен сохраняется (привязан к MAC). Последующие подключения авторизуются автоматически — MAC всё равно передаём (из него считается пароль для CONNECT), но код с экрана больше никогда не нужен.

Проверено после спаривания: async_get_state, async_get_apps, async_launch_app("YouTube") → True, питание, async_send_key, навигация, громкость, выбор источника.

---

Если вы используете кастомную интеграцию ha-vidaa-tv для Home Assistant

Её мастер настройки берёт MAC через get_mac_from_ip(), который внутри Docker/NAT возвращает пусто, поэтому мастер умирает на cannot_connect ещё до спаривания. Пока в интеграции нельзя ввести MAC вручную — спарьтесь один раз скриптом выше (он сохранит токен в /config/.vidaa_tv_tokens.json), либо пропатчите config flow, чтобы принимал MAC. (Мейнтейнеру: поле «MAC address (optional)» в мастере починило бы это для всех, кто на Docker/HAOS.)

Итог

Почти никогда это не «прошивка всё закрыла». Проверьте по порядку: (1) актуален ли IP? (2) отключите авто-детект протокола и задайте метод авторизации, (3) передайте MAC телевизора явно (Docker не может ARP), и успевайте в окно кода ~25 секунд. Все три вместе сделали «неподдерживаемый, слишком новый» Hisense полностью управляемым.

[Baeumert]

Root cause for the cannot_connect / CONNACK 4 → 5 pattern here, plus two things that make it much worse for TVs that are not permanently powered.

Short version: the access token has a 2-day lifetime while the refresh token is valid for 30 days. The integration never redeems the refresh token — it keeps sending the expired access token as the MQTT password. And because the token cache survives deletion of the config entry, re-adding the integration silently reuses the dead token, skips pairing, shows no PIN, and reports cannot_connect.

Environment

Integration	v1.1.1
Home Assistant	core-2026.8.1, HAOS 18.2
TV	Hisense PL2 laser TV
Firmware indicator	Server: NRDP/2024.1.6.0-… (the TV's own HTTP service on port 9080)

What the token cache shows

/config/.vidaa_tv_tokens.json — values redacted, only lifetimes:

Field	Value
access_token_time → access_token_expires_at	2 days
refresh_token_time → refresh_token_expires_at	30 days
protocol_version	null
auth_method	modern

Pairing succeeded and control worked. Two days later the access token expired. From then on, every connection attempt sends the expired token as the MQTT password — which is exactly CONNACK code 4 (bad username/password), followed by the legacy fallback returning code 5.

The refresh token is not used, even when it could be

This is the core finding. Router-based device tracking gives an exact record of when the TV was on the network, and it shows a continuous 10 hour 27 minute window (day 9 to day 10 after pairing) during which:

• the TV was reachable the entire time,
• the access token was 7 days past expiry,
• the refresh token was still valid for another 21 days,
• and the media player entity stayed unavailable for the whole window — not a single state change.

A second, shorter window the next day behaved identically: two hours of reachability, and every connection attempt went straight to MQTT with the dead access token → code 4 → fallback → code 5 → All authentication methods failed.

The integration had everything needed to refresh, had more than ten hours of connectivity to do it in, and never attempted it.

Why this hits unattended / power-cycled TVs especially hard

This is a serious problem for anyone who does not leave the TV permanently powered.

The refresh can only be performed against the TV itself — the MQTT broker and control API run on the device, and the cache stores its LAN address, not a cloud endpoint. So if the TV is off, no refresh is possible by definition.

With a 2-day access token, that means:

• A TV switched off over a long weekend comes back to a dead token.
• A TV that is powered only for viewing (here: mains/standby cut unless an activity is running, so it is off the network for days at a time) will lose its token essentially every time.
• The 30-day refresh token would cover exactly this case — a TV that returns within a month could refresh silently and keep working. That is precisely what is not happening.

In this installation the TV was on the network for 74 minutes total between pairing and token expiry. The integration then stayed broken for 8 days, including periods where the TV was reachable again.

So the 2-day access token is not by itself the problem; the missing refresh-on-reconnect is.

Why re-adding the integration does not help

Deleting the config entry does not remove /config/.vidaa_tv_tokens.json. A "fresh" setup loads the stale tokens, considers itself paired, skips the PIN step entirely, and fails identically at MQTT auth. The config flow reports cannot_connect and no PIN ever appears on the TV — which naturally sends people looking at firewalls, VLANs and TV settings instead of at an expired credential.

That missing PIN is the clearest diagnostic signal: if no PIN appears, the library believes it already has tokens.

Workaround that restored control

mv /config/.vidaa_tv_tokens.json /config/.vidaa_tv_tokens.json.bak

then add the integration again. The PIN appeared immediately, pairing succeeded, all entities returned (including volume control and app launching), and entity IDs were preserved so automations kept working.

One practical note for anyone scripting the config flow: the PIN on the TV expires after roughly 25 seconds and a new one is generated per request, so any step that takes tens of seconds before submitting the PIN will always fail.

Possible user-side mitigation (untested)

For TVs that are normally powered down, an automation could keep the token alive by waking the TV inside the 2-day window — e.g. a nightly job that sends a power-on command (here via a Harmony hub, which HA can trigger), waits for the TV to appear on the network, lets the integration reconnect, then powers it off again.

This only helps if the library refreshes proactively while connected and the access token is still valid. I have not verified that it does. What is verified is that it does not help once the token has expired: the 10.5-hour connectivity window described above produced no recovery at all.

So this workaround would have to run reliably inside every 2-day window and never miss one — a holiday, a Home Assistant restart or a network hiccup would still leave the user with a dead token and a manual re-pairing. Sharing it in case it helps others, not as a recommendation.

Protocol detection

protocol_version is cached as null, and every start logs:

WARNING [vidaa.protocol] Failed to fetch protocol info: <urlopen error timed out>
WARNING [vidaa.client] Could not detect protocol. Using modern auth (will try fallback if fails)

This issue notes detection GETs http://<tv>:38400/MediaServer/rendererdevicedesc.xml. On this model 38400 is closed. A full TCP scan shows:

2012  3366  3367  4635  7000  9080  11669  11679  16669  18400  36669

18400 and 3366 do serve HTTP but return 404 for /apps, /protocol, /api/protocol, /devicedescription, /remoteControl. 38400 and 39986 are not open.

If the refresh call also goes through that endpoint, the closed port would explain both the missing protocol version and the missing refresh.

For completeness: the MQTT broker on 36669 requires a TLS client certificate — a client without one gets TLSV13_ALERT_CERTIFICATE_REQUIRED, and plain MQTT is reset. Since the integration does receive CONNACK responses, its certificate is accepted; only the credentials are rejected.

Suggestions

1. Redeem the refresh token on connect. If the access token is expired but the refresh token is still valid, refresh instead of attempting MQTT with a dead credential. This alone would make the integration survive any outage shorter than the refresh-token lifetime, which is the normal case for a TV that is switched off between uses.
2. Remove or ignore the token cache when the config entry is deleted. Otherwise re-adding the integration cannot recover, and the user gets no PIN and no actionable error.
3. Distinguish the error. cannot_connect for an expired credential costs a lot of debugging time. Something like "stored credentials expired, re-pairing required" would point straight at the fix.

For anyone seeing this appear "suddenly": both the integration and vidaa-control have been unchanged since 2026-02-22, so it is not an update — it is the 2-day token expiry.

Happy to run further probes; this TV is available for testing, and I can report back on whether the connection survives past the next token lifetime.