Топики home/v1: пълен списък

home/v1 е базовият префикс на темите, с които уредбите говорят със сървъра. Контрактът е дефиниран веднъж в кода (bridge/protocol.mjs) и се оглежда навсякъде другаде — в панела, в симулатора, в проверките. Префиксът се променя с променливата BASE_TOPIC. Всяка уредба е описана с три неща: състояние, команда и събитие.

Теми за състояние

• <base>/state/solar, …/battery, …/grid, …/load, …/boiler, …/heatpump, …/weather, …/alarm, …/mode — състоянието на глобалните подсистеми на дома.
• <base>/state/room/<id> — помещение; …/light/<id> — осветление; …/zone/<id> — климатична или поливна зона; …/door/<id> — врата или достъп; …/camera/<id> — камера; …/cover/<id> — щора.
• <base>/state/switch/<id> — умен контакт с {on, power?, energyToday?}. Консуматорът зад него носи право energy, защото може да е конвектор от 1.5 kW; критичност му се дава само през critical в регистъра на уредбите.
• <base>/state/vacuum/<id> — робот прахосмукачка с {state, battery, fan, room?, program?}.
• <base>/state/safety/<id> — аварийни датчици с {name?, kind, state, room?, battery?, lastTestAt?}.
• <base>/state/device/<id> — наличието на уредбата: available или съобщението за срив (LWT), което ражда „offline“.
• <base>/state/mode — глобалният режим на дома (off/home/away), задържан, за да го вижда всеки нов клиент веднага.

Събития и команди

• <base>/event — събитие с полета ts, kind, deviceId, message. От него се ражда журналът на сървъра.
• <base>/cmd/<тип> — аргументите на командата към уредбите.

Командите, които киоскът изпраща: light.set, light.all, room.set, room.all, zone.set, zone.all, door.set, door.all, alarm.set, cover.set, cover.position, cover.stop, cover.autoshade, safety.test, safety.mute, switch.set, boiler.set, heatpump.set, scene.run, home.mode.set и telemetry.debug (само в симулация). От тях home.mode.set не стига до уредбите — сървърът я поема сам, а scene.run се разгръща до действията си на сървъра, всяко от които минава през правата.

Как се чете съобщението

Четенето е толерантно към реалния хаос в мрежата: число като "3.3" се приема, Buffer се разкодира, двойно кодиран JSON се разплита, схемата се проверява спрямо дефиницията. Недостоверен ред не се брои за нула — той просто не влиза в числата, които виждате на екрана.

Какво трябва да пази един driver

Публикувайте състоянието на уредбата си в съответната state/… тема и приемайте команди от cmd/<тип>. За производители без обратен път съществува режим „само за четене“: уредбата се показва, но командите не се обещават. Добавянето на нова уредба не изисква промяна в екраните — телеметрия с непознат id създава свой запис.

Какво още не е готово

• Реален broker. Кодът за свързване съществува, но пакетът mqtt не е в зависимостите и не е тестван с брокер; днес пътят се минава с вградения симулатор, който говори същите теми. За свой broker се задават MQTT_URL (напр. mqtt://192.168.1.20:1883) и MQTT_USER / MQTT_PASS, а SIMULATE=1 връща симулатора въпреки зададения MQTT_URL.
• Преводът от Zigbee, Modbus, KNX и ONVIF към тези теми — това е работата на липсващите драйвери (ниво на поддръжка по транспорт).
• Достъп извън локалната мрежа: контрактът е LAN контракт, без облак мост.

Двете неща, които вече работят, са контрактът и панелът: той показва същите теми, за да не търсите документация другаде, а симулацията вече минава по същия път, затова правилата, журналът и правата са тествани спрямо контракта. Детайлите за връзката на екрана със сървъра — в Архитектурата.