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

Интеграционни възможности: панел, редактор и сдвояване

Интеграции обновена на 2 ноември 2026 г.

Как се описва, редактира и сдвоява една интеграция в HoumeOS — панелът на оборудването, каталогът на транспортите, редакторът зад право config, реалната TCP тестова заявка и политиката за тайни. Какво е готово и какво предстои.

Интеграциите се управляват от екрана „Интеграции“ — панел на оборудването, който живее в същия визуален език като регистъра на уредбите и не въвежда нов интерфейс. Той отговаря на три въпроса: какви транспорти познава платформата, какви интеграции са описани и дали нещо мълчи.

Какво показва панелът

  • Обобщение — брой интеграции, уредби, на линия и без връзка.
  • Карти на интеграциите — транспорт, посока, производители, брой уредби по наличност, последно обновяване, причина за грешка и зависимости. Картите са подредени по тежест: това, което мълчи, е най-отгоре.
  • Филтър „Всички / На линия / С проблем“.
  • Каталог на транспортите — MQTT, Matter, Zigbee, Modbus, KNX · BACnet, ONVIF, REST, с живостта на всеки.

Редът разделя две неща, които обикновено се бъркат: status е състоянието на уредбата, link е живостта на транспорта. Непознат протокол оставя транспорта null, вместо платформата да гадае.

Как се редактира

От края на октомври 2026 редът не само се докладва, а и се редактира: надпис, бележка, избор на транспорт от каталога и карта на публичните настройки. През GET/POST/DELETE /api/integrations с право config; POST с id в тялото замества или създава. Сливането е като на сървъра: стойност замества, null трие ключа. Екранът за профили и редакторът светват само когато сесията има право — решението винаги е на сървъра, а отказът е 403.

Какво се сдвоява реално

Стъпковото сдвояване минава през четирите стъпки тип мрежа → уредба → тестова заявка → резултат към POST /api/pair (пак право config):

  • Matter сдвоява наистина — bridge-ът минава през контролера, избира OnOff endpoint-а и записва matter-devices.json; оттам уредбата влиза в регистъра с произход „интеграция“ (отговор 201).
  • Modbus, KNX, ONVIF и HTTP са водачи — стъпката „тестова заявка“ е реален TCP конект с 3 s изчакване (tcpProbe), а уредбата изчаква драйвера (отговор 200 с paired: false).

Сървърната валидация е чиста и огледална в киоска: id като slug, име до 80 знака, код от 11 цифри за сдвояемите транспорти, host и порт 1–65535 за тестовите. Отказът е 400 с човешки полета details, липсващ Matter контролер е 503 с причина. 11-цифреният код се въвежда на таблета, използва се веднъж и не остава в състояние, журнал или localStorage; при неуспех сървърът го замества с …, преди записа.

Тайните

Етикетите и публичните настройки се редактират от таблета, но адресите и тайните не се въвеждат на киоска — тайна, въведена на таблета в хола, не е тайна. Настройките на интеграциите се пазят на сървъра в bridge/integrations.json с атомен запис; GET показва останалите полета, а запазената тайна никога не се връща обратно. Редакторът подсказва, когато сървърът крие стойността.

Какво предстои

  • Истинските драйвери зад каталога — Modbus, KNX, Zigbee и ONVIF/RTSP (ниво на поддръжка по транспорт).
  • Въвеждане на тайни през интерфейса, без те да слизат до таблета.
  • Гласов асистент и план на дома не са част от този слой.

Вижте и Ръководството за инсталатора за реда, в който се прави това на обект, и Интеграции и протоколи за описанието на нивата по всеки транспорт.

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

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

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