Интеграционни възможности: панел, редактор и сдвояване
Как се описва, редактира и сдвоява една интеграция в 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-ът минава през контролера, избира
OnOffendpoint-а и записва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 (ниво на поддръжка по транспорт).
- Въвеждане на тайни през интерфейса, без те да слизат до таблета.
- Гласов асистент и план на дома не са част от този слой.
Вижте и Ръководството за инсталатора за реда, в който се прави това на обект, и Интеграции и протоколи за описанието на нивата по всеки транспорт.
Имате конкретна инсталация?
Кажете ни кои уредби и по кои транспорти — отговаряме честно за всяко ниво на поддръжка.