diff --git a/family/plans/t610-home-automation.md b/family/plans/t610-home-automation.md
index 0682e142..5c61d595 100644
--- a/family/plans/t610-home-automation.md
+++ b/family/plans/t610-home-automation.md
@@ -736,7 +736,10 @@ modbus/sensors/bedroom/humidity      36.0
 
 > **Задача сессии (Alex):** «Что дальше по плану?» → далее по ходу: «Датчик есть. Что с ним??» → «Ок. Делай. Меняй правила caddy на truenas чтобы указывали на t610».
 
-### 5-кватер-А. Датчик столовой: причина найдена — шина отвечает нулём, bridge отбрасывает
+### 5-кватер-А. ❌ Датчик столовой: «шина отвечает нулём» — ПРОМЕЖУТОЧНАЯ ГИПОТЕЗА, ОПРОВЕРГНУТА
+
+> 🔴🔴 **ОПРОВЕРГНУТО ПОЗЖЕ ТОЙ ЖЕ СЕССИЕЙ (§5-кватер-Д): датчик НЕ отдаёт ноль.** Прямое сырьё прослушивание шины (bridge остановлен) поймало **валидный ответ с данными** — `01 03 0E 03 1A 00 0E …` (CO2=794 и т.д.). А `= 0 [00 00]` в логе bridge — это `sniff:dining_temperature` (значение, которое bridge **подставляет из своей таблицы**), а НЕ то, что вернул датчик. Раздел сохранён как урок: **лог bridge ≠ ответ датчика** (см. ниже, почему `slave 1 / reg 100` — тоже неверная трактовка).
+> **Правильная цепочка:** реальный датчик гостиной = **slave 1, base_register 2, quantity 7** (запрос `01 03 00 02 00 07`), ответ 14 байт. Регистр 100 — это **виртуальный** slave 101, который bridge отдаёт ZONT'у. См. §5-кватер-Д.
 
 **Alex подтвердил: датчик в столовой физически ЕСТЬ.** Значит ветка «чистить мусор» отпала — идём чинить источник.
 
@@ -749,24 +752,21 @@ modbus/sensors/bedroom/humidity      36.0
   → Response: 1 register(s) from 100 (sniff:dining_temperature) = 0 [00 00]
 ```
 
-**Расшифровка (ключевой факт):**
+**Как это трактовалось тогда (❌ ошибочно):**
 
-| Наблюдение | Значение |
+| Наблюдение | Трактовка того момента (❌) |
 |---|---|
-| `Slave: 1` | Столовая = **slave 1** (совпадает с картой: Гостиная=1) |
-| `CRC OK: True` | Кадр целый — **проводка и обмен в порядке** |
+| `Slave: 1` | Столовая = slave 1 (совпадает с картой: Гостиная=1) |
+| `CRC OK: True` | Кадр целый — проводка и обмен в порядке |
 | `Func: 0x3` | Чтение holding-регистра |
-| `from 100` | Регистр **100** (температура) |
-| `= 0 [00 00]` | 🔴 **Датчик отвечает ЗНАЧЕНИЕМ 0**, а не молчит |
-| опрос каждые 5 с, стабильно | Не «иногда», а **постоянно ноль** |
+| `from 100` | Регистр **100** (температура) — ❌ на самом деле это **виртуальный slave 101**, регистр 100 |
+| `= 0 [00 00]` | 🔴 «датчик отвечает ЗНАЧЕНИЕМ 0» — ❌ **опровергнуто: ноль подставляет bridge** |
 
-> 🔴 **ВЫВОД: ZONT датчик ОПРАШИВАЕТ (slave 1, reg 100, каждые 5 с), датчик ОТВЕЧАЕТ — но отдаёт ноль.** `modbus-bridge` считает `0` невалидной температурой → **не публикует** в `modbus/sensors/dining/*` → HA-сущности остаются `unknown` → `dining_summary` падает в `unavailable`. **Проблема НЕ в HA и НЕ в проводке/обмене, а в самом датчике или его регистрации в ZONT.**
+> ❌ **Вывод того момента («ZONT опрашивает, датчик отвечает нулём») — ОПРОВЕРГНУТ** прямым прослушиванием шины (§5-кватер-Д). Реально: **ответ датчика на шине есть и содержит данные**; bridge их не доводит до публикации. Ошибка трактовки: `= 0` в логе bridge — это **значение из внутренней таблицы bridge** (не прочитанное с шины), а `from 100` — ответ **виртуального** slave 101, не физического датчика.
 
-**Дополнительное наблюдение (зацепка):** в логе для столовой виден **только** `sniff:dining_temperature` (reg 100). Сущности CO2/влажности/TVOC/PM на датчик завязаны, но **ZONT эти регистры для столовой не читает** → значит либо датчик только-температурный, либо в ZONT он заведён частично.
+**Дополнительное наблюдение (зацепка, частично подтверждено):** в логе для столовой виден только `sniff:dining_temperature` — потому что ZONT читает гостиную как **1 регистр под slave 101**, а реальные 7 регистров идут по slave 1 / reg 2 (см. §5-кватер-Д).
 
-**Почему `|default(0)` — по-прежнему НЕ фикс** (подтверждено): он дал бы `0° 0ppm`, что совпало бы с реальным «нулём» и замаскировало бы поломку. **Правильно — найти, почему датчик отдаёт 0**: не откалиброван / не сконфигурирован в ZONT / просело питание по шине (485-датчики питаются от линии).
-
-> 📌 **Не путать с §5-тер:** там зафиксировано, что `modbus/sensors/dining/*` не публикуется. Здесь — **почему** (датчик отвечает нулём), после того как Alex подтвердил наличие датчика.
+> 📌 **Не путать с §5-тер:** там зафиксировано, что `modbus/sensors/dining/*` не публикуется. Здесь — промежуточная (ошибочная) версия «почему». **Действующее объяснение — §5-кватер-Д.**
 > ⛔ **Alex переключил внимание на план миграции** — задачу по датчику столовой **не доделывали** (не чинили ZONT, не трогали реестр). Остаётся в бэклоге как отдельная задача.
 
 ### 5-кватер-Б. Развязка Caddy — архитектура и подготовленная правка