Протоколи: ниво на поддръжка по транспорт

Интеграционният каталог на сървъра събира в един ред всеки транспорт, който платформата познава: MQTT, Matter, Zigbee, Modbus, KNX · BACnet, ONVIF и REST/облак. Редът казва посоката, средата, уредбите зад транспорта и дали необходимата зависимост е налична. Това е реален запис на сървъра, не маркетингов ред — и точно затова показва и какво липсва.

Нивата, с които работим

• Готово — пътят работи и е проверен: уредбата променя състояние от екрана.
• Описано и проверимо — транспортът е в каталога, панелът дава водачи с адрес и порт и прави реална TCP тестова заявка към уреда. Уредбата още не се чете и не се командва.
• Предстои — липсващият елемент е ясен: драйвер, координатор или broker.

Не представяме предстояща интеграция като налична. Конкретните модели уредби се потвърждават при оглед на обекта; не обявяваме съвместимост, която не сме проверили.

По транспорти

• Matter — готово. Контролерът на matter.js работи по IPv6 (UDP порт 5540) с mDNS откриване и се вдига само при MATTER=1. Сдвояването е реално: стъпките „тип мрежа → уредба → заявка → резултат“ минават през POST /api/pair с право config, минават през OnOff клъстера и записват matter-devices.json, откъдето уредбата влиза в регистъра с произход „интеграция“. Сдвоените устройства с metering дават и измерената енергия. Изискване: IPv6 в LAN-а — без него контролерът стартира, но не вижда възела.
• MQTT — контрактът е готов, broker-ът предстои. Темите home/v1 са дефинирани веднъж в кода, а панелът и симулацията ги говорят (Пълен списък на топиките). Кодът за връзка с реален broker съществува, но пакетът mqtt не е в зависимостите и не е тестван с брокер.
• Zigbee — само през шлюз. Платформата няма собствен radio layer: 2.4 GHz уредбите (Zigbee 802.15.4, Bluetooth LE, Wi-Fi контакти) влизат през координатор или шлюз, който превежда радиото в MQTT. Липсват изборът на координатор и интеграционният модул, който пълни home/v1 темите от реален шлюз.
• Modbus — описано и проверимо. Modbus TCP и RTU/RS485 са в каталога; панелът дава водачи и реална TCP заявка. Четенето на регистрите е работата на драйвера, който предстои — нужно е за инвертори и електромери.
• KNX · BACnet — описано и проверимо. KNX е водачи с групови адреси в каталога и TCP проверка на интерфейса; driver-ът, който чете и пише по шината, предстои. От обекта ни трябва проектът на инсталацията.
• ONVIF и камери — частично. Екранът „Охрана“ показва движение, последен кадър и време на последната промяна, а журналът се води на сървъра. Пътят (ONVIF откриване, RTSP приемане, NVR) е описан в каталога, но предстои; live изглед и запис не се обещават. (HoumeOS и камери)
• REST / облак API — описано и проверимо. За производители без обратен път има режим „само за четене“: уредбата се показва, командите не се обещават.

Какво виждате на панела е полезно и само по себе си: списъкът разделя състоянието на уредбата от живостта на транспорта — уредбата може да е online, а връзката да е retrying, и обратното.

Радио хигиена, която решава повече от кода

• Клиентската изолация (AP isolation) в рутера блокира киоск → сървър и трябва да е изключена.
• Адресът на сървъра е постоянен IP или вътрешно DNS име — автоматично откриване на уредби в LAN-а няма.
• Zigbee каналът да е различен от този на точките за достъп (например 15/20/25 срещу 1/6/11).
• Антената на координатора — далеч от USB 3.0 портове и контролери, които шумят в 2.4 GHz лентата.

Връзка към страниците за всеки протокол

KNX · Modbus · Zigbee · MQTT · Соларни инвертори · Термопомпи · Камери и ONVIF. Всяка описва нивото на поддръжка, ограниченията и какво ни трябва от вашата инсталация.