Ръководство за инсталатора

Това е работният ред, по който пуснахме системата на обекти и по който я тестваме без хардуер. Не е списък с обещания: всяка стъпка казва какво се вижда на екрана, когато е минала.

1 · Оглед и документи

Преди кабел: кои уредби, в кои стаи, по кои транспорти, какви сценарии искате. За KNX — проектът на инсталацията с груповите адреси; за Modbus — регистърната карта от документацията на уреда; за камерите — марки, модели и дали има RTSP; за мрежата — дали LAN-ът има IPv6 (за Matter) и дали рутерът държи клиентска изолация. Моделите се потвърждават тук, не от уебсайт.

2 · Пускане в симулация

VITE_HOME_DRIVER=mock (по подразбиране) дава локална симулация с физика: соларна крива, енергиен баланс, таймери за зони, уредби, които се променят на всеки 3 s. На този режим се проверяват интерфейсът, правилата, сценариите и правата — без сървър и без уредби. Сървърният симулатор (bridge/simulator.mjs) върви по същия MQTT път, затова контрактът се тестира и без хардуер.

3 · Сървър в мрежата

node bridge/server.mjs с PORT (по подразбиране 8787) и BRIDGE_TOKEN. Машината е с постоянен IP или вътрешно DNS име — авто-откриване няма. За автономен старт: две systemd услуги с Restart=always на Linux, задача в Task Scheduler на Windows; рецептите са описани, но не са изпълнявани на реално устройство. Проверката е GET /api/health и след това GET /api/state с токена.

4 · Киоск към сървъра

VITE_HOME_DRIVER=bridge + VITE_HOME_BRIDGE_URL=http://<IP>:8787 + VITE_HOME_BRIDGE_TOKEN. Променливите са build-time — след промяна dev сървърът се рестартира, а production билдът се преизгражда. Ако bridge е избран без адрес, киоскът пада на симулация с видимо предупреждение в статус чипа: счупен деплоймент не остава невидим. После: manifest + standalone на таблета, киоск режим, автозаключване след 3 минути.

5 · Профили и права

При първи старт bridge-ът създава bridge/users.json от KIOSK_ADMIN_PIN, KIOSK_USER_PIN и KIOSK_GUEST_PIN — те се използват само при създаването на файла, после ПИН-овете се сменят през /api/users (зад право config). Ролите: администратор, жилище (без config и debug), гост (светлини и сценарии). Проверете четирите отговора: 401 без сесия, 403 без право, 409 за критично без confirm: true, 429 след 5 грешни ПИН-а.

6 · Уредби, помещения, сценарии, правила

Регистърът на уредбите пази име, вид, помещение, производител, протокол, наличие и критичност. Помещенията (bridge/rooms.json) и сценариите (bridge/scenes.json) са конфигурация на сървъра, не на таблета. Правилата живеят в bridge/automations.json — тригер, условия, изключения, forMs, cooldown и графици; екранът „Автоматизации“ ги редактира, а изпълненията се виждат в журнала с обяснение. Тест: правило, което гаси светлините в конкретен час, и забрана, която държи бойлера извън нощния прозорец.

7 · Интеграции и сдвояване

Интеграцията се описва с POST /api/integrations (право config): етикет, транспорт и публични настройки като host и порт; тайните се пазят, но не се връщат обратно и не се въвеждат на таблета. Стъпковото сдвояване към POST /api/pair минава „тип мрежа → уредба → тестова заявка → резултат“: Matter връща 201 и сдвоява реално, Modbus/KNX/ONVIF/HTTP връщат 200 с paired: false, защото това е водачи с TCP проверка, а не готово четене (повече).

8 · Финална проверка

„Готово“ за нас означава едно: уредбата е променила състояние от киоска. Проверете GET /api/history?period=day&metric=energy за почасови точки; спрете сървъра и вижте дали чипът минава във „Възстановяване…“ с маркирана давност; оставете проба да мълче и очаквайте telemetry-silent, а при спрял транспорт — transport-down; спрете интернет и потвърдете, че правилата продължават. Журналът трябва да покаже всяко влизане, отказ и изпълнено правило.

Какво още не се инсталира: реален broker с уредби, драйверите за Modbus/KNX/ONVIF, HTTPS и тайни през интерфейса.