Обратно към документацията

Локална работа и сигурност

Платформата обновена на 2 ноември 2026 г.

Как HoumeOS работи само в локалната мрежа и как пази достъпа: две нива автентикация, ПИН с scrypt на сървъра, роли и права по вид действие, потвърждение за критични неща, журнал и политика на офлайн черупката. Какво още не е готово.

HoumeOS е локална система. Правилата, състоянието на уредбите, историята и правата се пазят и изпълняват на сървър във вашата мрежа. Командите не напускат LAN-а, а прекъсването на интернет не спира нито правилата, нито графиките.

Две нива на достъп

  • Мрежово — BRIDGE_TOKEN: кой изобщо може да говори със сървъра. Заявките тръгват с Authorization: Bearer; при SSE токенът върви като ?token=, защото EventSource не слага headers. Ако е празен, няма автентикация — това е за разработка, не за експлоатация.
  • Човешко — сесия след влизане с ПИН: кое име има право на какво. Токенът на сесията пътува като x-home-session и живее само в драйвера — не в React стейта и не в localStorage. Потокът /api/stream не изисква сесия, защото носи само данни.

ПИН-ът не е в bundle-а на киоска (променливата VITE_KIOSK_PIN е премахната). Той се проверява на сървъра: bridge/users.json пази само хешове, изчислени със scrypt и сол, сравнението е constant-time, а след 5 грешни ПИН-а настъпва пауза (отговор 429). Сесиите са с плъзгащ се 30-минутен срок, а киоскът се заключва след 3 минути без докосване.

Роли, права и критични действия

Трите роли са ясни: администратор — всичко; жилище — всичко без config и debug; гост — осветление и сценарии. Правата се гледат по вид действие, не по екран: всяка команда се картомира към действие и минава през checkCommand(). Отговорите са 401 без сесия, 403 без право, 409 за критично действие без confirm: true, 429 при пауза.

Критични са door.set, door.all, cover.set, alarm.set и всяка уредба с critical: true в регистъра. Киоскът пита човека през диалог, преди да изпрати командата, а сървърът я изисква независимо кой пита. Редакцията на интеграции, правила, сценарии, помещения и профили е зад право config.

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

Какво остава в мрежата и какво се пази на сървъра

Историята е на сървъра: проба всяка минута, почасови и дневни агрегации, retention 7 дни сурови проби · 31 дни журнал · 13 месеца агрегации. Киоскът пита за готовите серии, вместо да трупа числа в браузъра. Офлайн черупката (PWA manifest и service worker, написан на ръка) пази HTML, JS, CSS и шрифтовете, но никога данни: заявки към /api/, с authorization или мутации не се кешират. Без сървър таблетът показва интерфейса и „Няма връзка“ с маркирана давност — кеш на числата е отказан изрично, защото остаряла температура, представена като жива, е по-лоша от липсваща.

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

  • HTTPS в мрежата. Днес service worker-ът и PWA инсталацията съществуват само на localhost или зад собствен TLS терминатор; извън тях офлайн черупката на таблет в LAN изисква и двете.
  • Доставка на известия извън дома — SMTP, push и webhook чакат решение; докато го няма, вестите остават на екрана и в журнала.
  • Устойчивост на сесиите. Сесиите са в паметта на сървъра — рестарт ги изтрива и киоскът отново иска ПИН. Трайно съхранение на токени няма и не е предвидено.
  • Охраната е по-лека от сертифицирана система: няма зони, няма история на режимите и няма заобикаляне на отделен сензор; критичните аларми работят независимо, а safety.mute не изтрива тревогата от екрана.
  • Извън LAN-а няма облак мост и няма авто-откриване на уредби — адресът на сървъра се задава ръчно и затова трябва да е постоянен (изисквания към хардуера).

За какво се следи: telemetry-silent (без нито една проба от 60 s), transport-down (broker извън линия над 30 s), devices-offline, matter-down и command-failures (3 отказа за 120 s) — първите две са критични, останалите са предупреждения.

Имате конкретна инсталация?

Кажете ни кои уредби и по кои транспорти — отговаряме честно за всяко ниво на поддръжка.

Интеграции и протоколи