Архитектура на HoumeOS: какво къде живее

HoumeOS е построена като три слоя, които си говорят по два ясни контракта. Нищо от логиката на дома не живее в облак и нищо от решението за команда не живее в таблета.

Трите слоя

• Киоск — екранът пред вас: React приложение, което показва състоянието и изпраща команди. Не пази правила, не трупа числа в браузъра и не решава кой има право на какво.
• Сървър в локалната мрежа (bridge) — Node процес в мрежата ви. Поема правилата, режимите на дома, сценарии, помещения, профили с роли и права, журнала и историята, редакцията на интеграциите и сдвояването.
• Уредби — крушки, щори, климатични зони, бойлер, термопомпа, умен контакт, датчици, камери, инвертор и батерия. Те говорят на своя език и стигат до сървъра през контракт за състояние и команди.

Потокът на данните изглежда така: уредбите и контролерите публикуват състояние към сървъра по MQTT темите home/v1/…, Matter възлите минават през matter.js (IPv6, UDP 5540, mDNS откриване), а сървърът в локалната мрежа обединява всичко и го подава на киоска чрез HTTP snapshot и SSE поток. Командите пътуват по обратния път — от екрана към сървъра и оттам към уредбата.

Контрактът между сървъра и екрана

Киоскът пита сървъра за целия дом с GET /api/state при свързване, за да не чака първата публикация, и после слуша GET /api/stream — server-sent events поток, в който всяка промяна идва като запис. При срив връзката се възстановява с backoff от 1 s до 15 s, а ако данните спрат за 15 s, статус чипът показва retrying, не тихо. Готовите серии и страниците от журнала идват с обикновени GET-та: /api/history, /api/events, /api/alerts. Правилата и режимите са под /api/automations* и /api/mode, профили и сесии — /api/profiles и /api/session, сценарии и помещения — /api/scenes, /api/rooms, интеграции и сдвояване — /api/integrations и POST /api/pair.

Автентикацията е с token (Authorization: Bearer, а при SSE като ?token=, защото EventSource не слага headers). След влизането session токенът живее само в драйвера — не в React стейта и не в localStorage — и пътува като x-home-session. Самият поток /api/stream носи данни и не изисква сесия.

Контрактът между сървъра и уредбите

Темите с базов префикс home/v1 описват всяка уредба като състояние, а командите имат свой път: cmd/<тип> (Топики home/v1: пълен списък). Това е единствената дефиниция в кода; отговорността за форматиране е на сървъра, а киоскът не познава нито протокола, нито драйвера.

Какво живее на сървъра, не на таблета

Правилата (тригер, условия, изключения, forMs, cooldown, графици), сценариите, помещенията, профилите с роли и ПИН, журналът и историята, интеграциите и тайните им. Затова рестарт на таблета не променя нищо, а правило с забрана за поливане продължава да важи, дори когато интернетът липсва.

Реални и симулирани уредби

Двата режима са взаимозаменяеми: mock е локална симулация с физика, bridge говори със сървъра. Изборът е VITE_HOME_DRIVER; ако bridge е избран без VITE_HOME_BRIDGE_URL, киоскът пада на симулация с видимо предупреждение в статус чипа — счупен деплоймент не остава невидим. Симулаторът в сървъра върви по същия MQTT път, за да се тества целият поток без хардуер и без broker.

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

• Broker с истински уредби: кодът за свързване съществува, но пакетът mqtt не е в зависимостите и не е тестван с реален broker.
• Драйвери за Modbus, KNX и ONVIF/RTSP — днес транспортите са описани и проверими с реална TCP заявка, без да четат уредбата (Протоколи: ниво на поддръжка по транспорт).
• HTTPS за достъп извън мрежата и внедряване на VITE_* променливите в runtime.