KNX IoT – programowanie w praktyce

4 sierpnia, 2026

KNX IoT – programowanie w praktyce.

Od teorii do praktyki – wszystko, co warto wiedzieć o konfiguracji, bezpieczeństwie i wdrażaniu KNX IoT.

Klasyczny KNX oparty o medium TP szereg swoich największych zalet, czyli stabilności i niezawodności, zawdzięcza właśnie swojej przewodowej naturze.

Zielona magistrala jest jednak jednocześnie jego słabością, gdyż konieczne jest fizyczne poprowadzenie kabla. Szczególnie uciążliwe jest to w przypadku modernizacji istniejących systemów i retrofittingu.

KNX IoT próbuje rozwiązać ten problem zachowując jednocześnie inteligentną funkcjonalność.

Czym jest, a czym nie jest KNX IoT?

KNX IoT to rozwinięcie standardu w stronę komunikacji IP na poziomie urządzeń końcowych. W klasycznym KNX przyzwyczailiśmy się, że czujniki, przyciski i aktory pracują głównie na magistrali TP lub radiowo w KNX RF.

KNX IoT zachowuje znaną logikę: adresy grupowe, obiekty komunikacyjne, parametryzację i integrację w ETS. Zmienia się przede wszystkim medium komunikacyjne — urządzenia mogą komunikować się przez sieci oparte o IPv6, na przykład Thread lub Ethernet. Urządzenia KNX IoT Point API to certyfikowa-ne urządzenia KNX, które zamiast fizycznej warstwy TP/RF wykorzystują medium komunikacyjne oparte o IPv6. Można więc powiedzieć, że KNX IoT nie zrywa z filozofią KNX, tylko przenosi ją na nowszą infrastrukturę komunikacyjną.

KNX IoT nie jest natomiast kolejną “aplikacją smart home” ani zamiennikiem tanich urządzeń Wi-Fi sterowanych z chmury. To ważne rozróżnienie, bo samo słowo “IoT” bywa kojarzone z konsumenckimi gadżetami, które paruje się

z telefonem i obsługuje przez konto producenta. W przypadku KNX IoT nadal mówimy o standardzie automatyki budynkowej, certyfikowanych urządzeniach i pracy w ekosystemie KNX. Różnica polega na tym, że urządzenia KNX mogą działać bez klasycznej magistrali TP, korzystając z sieci IPv6.

Dwie wersje KNX IoT

Z technicznego punktu widzenia mamy dwie wersje KNX IoT:

1. KNX IoT Point API:

Jest to wersja przeznaczona dla urządzeń obiektowych komunikujących się między sobą, podobnie jak KNX.RF tylko, że korzystając z technologii Thread.

2. KNX IoT 3rd Party API:

Jest to interfejs (API) umożliwiający łączenie technologii KNX z zewnętrznymi deweloperami czy systemami. Dzięki temu informatyk-pasjonat będzie mógł w swoim domu sam napisać fragment kodu czy stworzyć wizualizację na własne potrzeby. Podobnie powinno być z rozwiązaniami od Apple/Google – w teorii będą dawać się łączyć z KNX IoT. Trzeba jednak mieć na uwadze, że to Apple w odpowiada za działanie modułu Thread w telefonach Iphone, więc od tej firmy zależy w jakiś sposób połączą się z KNX.IOT.

W obu przypadkach zachowana jest 100% kompatybilność wsteczna ze znanym nam tradycyjnym KNX’em.

Jak działa IoT i jak współpracują ze sobą Thread, Matter i CoAP?

Zrozumienie współczesnego Internetu Rzeczy (IoT) może przyprawić o zawrót głowy od nadmiaru technicznych skrótów. Spróbujemy po krótce to wytłumaczyć, aby zrozumieć , jak współpracują ze sobą poszczególne technologie (jak Thread/Matter/CoAP).

Thread – czyli bardzo energooszczędna technologia radiowa; fizyczna infrastruktura sieciowa typu „mesh”; nie potrzebujemy głównego routera – urządzenia się widzą bez niego i i ustalają trasy przesyłu bez konieczności jego udziału.

Matter – czyli uniwersalny język komunikacji, korzystający z Thread.

CoAP – protokół komunikacji (używany przez Matter), określający sposób organizacji przesyłania danych – szybki, skuteczny, zużywający małą ilość energii; odpowiada warstwie transportowej.

W komunikacji sieciowej jeden protokół nie odpowiada za wszystkie zadania. Poszczególne mechanizmy są ułożone warstwowo i każdy z nich rozwiązuje inny problem. Można to porównać do wysyłania przesyłki. Jeden standard określa sposób zapakowania zawartości, drugi sposób adresowania, trzeci sposób przewozu, a kolejny zabezpiecza przesyłkę przed odczytaniem lub modyfikacją. Dopiero połączenie wszystkich warstw tworzy działający system.

W przypadku testowanego stanowiska uproszczony stos komunikacyjny wygląda następująco:

Magistrala KNX TP, obiekty komunikacyjne.
KNX IoT Point API – opis surowych danych z magistrali KNX w pakiety zawierające szereg metadanych niezbędnych do późniejszej dekodyfikacji.
CoAP + OSCORE – odczyt, zapis i szyfrowane przesyłanie danych; CoAP korzysta z operacji GET/PUT i Observe, nastomiast OSCORE chroni dane na poziomie aplikacyjnym, a więc niezależnie od proxy, czy routerów. Ochrona obejmuje integralność wiadomości, uwierzytelnienie nadawcy oraz zabezpieczenie przed powtórnym wykorzystaniem wcześniej przechwyconej wiadomości.
UDP + IPv6 – adresacja sieciowa i routing pakietów. UDP zapewnia lekki mechanizm transportu, który nie wymaga zestawiania trwałego połączenia tak jak TCP.
Thread – bezprzewodowa sieć mesh oparta na IPv6 łącząca urządzenia IoT. To warstwa topologiczna umożliwiająca urządzeniom nadawczym optymalne wytyczanie ścieżek komunikacyjnych do bezproblemowej transmisji.
IEEE 802.15.4 – transmisja radiowa – medium transmicyjne.

Thread, CoAP, OSCORE i KNX IoT Point API nie są rozwiązaniami konkurencyjnymi. Są uzupełniającymi się elementami jednego stosu komunikacyjnego. Thread tworzy bezprzewodową sieć IP. CoAP zapewnia lekki sposób komunikowania się z zasobami urządzeń. OSCORE zabezpiecza wiadomości CoAP. KNX IoT Point API nakłada na te technologie model automatyki budynkowej KNX, dzięki któremu urządzenia różnych producentów mogą rozumieć znaczenie przesyłanych danych i wspólnie realizować funkcje budynku.

Istnieją alternatywy dla powyższego rozwiązania, jednak obejmują one głównie podmianę technologii komunikacyjnej. Zamiast Thread możemy użyć Wi-Fi lub Ethernetu – warunkiem jest jedynie obsługa IPv6. Thread jednak jest konkurencyjnym rozwiązaniem głównie ze względu na niewielki pobór mocy (mniejszy niż przy Wi-Fi) i bezprzewodowość (w kontraście do Ethernetu).

Jeśli chodzi o substytut dla warstwy komunikacyjnej, to dedykowany CoAP jest częścią zdefiniowanego stosu komunikacyjnego i rekomenduje się jego użycia. W teorii można zastąpić go MQTT, HTTP lub WebSocket, jednak są to rozwiązania niestabilne.

Sprzęt testowy

Testowy system oparty o KNX IoT zrealizowano w oparciu o Hub KNX IoT i korzysta z pierwszej powyżej opisanej metody, czyli KNX IoT Point API.

Urządzenie umożliwia konfigurację systemu KNX IoT oraz komunikację z KNX Classic i KNXnet/IP. Takie urządzenia mogą mieć przeróżne funkcje dodatkowe, takie jak komunikacja z Matter oraz obsługa Ethernet, PoE, Wi-Fi oraz Thread, a jego konfiguracja i uruchomienie odbywają się z użyciem ETS.

Jest to jednocześnie KNX IoT router oraz może pełnić funkcję KNX IoT MQTT proxy. Huby są więc pewnego rodzaju bramami łączącymi KNX IoT z klasyczną instalacją TP.

Elementami wykonawczymi mogą być dowolne manipulatory w technologii KNX IoT. Funkcjonalnością nie odbiegają one od klasycznych rozwiązań przewodowych. Ich nieodzowną zaletą jest oczywiście możliwie maksymalna bezprzewodowość – wymagają zwyczajowo jedynie podpięcia zasilania.

Programowanie

Uruchomienie linii KNX IoT wymaga nieco innego podejścia niż w przypadku klasycznej magistrali KNX TP. Oprócz urządzeń końcowych potrzebny jest ETS w wersji co najmniej 6.3, infrastruktura sieciowa oparta na IPv6 oraz urządzenie pełniące funkcję routera zarówno w sieci Thread, jak i KNX IoT.

Jeśli urządzenia IoT mają współpracować z istniejącą instalacją KNX TP, potrzebny jest również router KNX IP, a podstawą całej topologii staje się sieć KNXnet/IP. W ETS dla urządzeń IoT tworzy się osobny obszar lub linię o medium IoT.

Sam proces uruchomienia składa się właściwie z dwóch etapów. Najpierw w interfejsie hubu należy utworzyć sieć Thread i dołączyć do niej urządzenia. Odbywa się to za pomocą indywidualnych kodów QR zawierających dane po-trzebne do bezpiecznego przekazania urządzeniu parametrów sieci. Dopiero gdy urządzenie pojawi się w topologii Thread, można przejść do jego progra-mowania w ETS.

Istotnym zagadnieniem podczas pracy z KNX IoT jest odpowiednie zaprojekto-wanie warstwy sieciowej. Jako iż zarówno Thread, jak i Wi-Fi działają w paśmie 2,4 GHz niewłaściwie dobrany kanał lub umieszczenie hubu w pobliżu silnych punktów dostępowych może negatywnie wpłynąć na komunikację. Warto wykorzystać analizatory zajętości kanałów, często zawarte w oprogramowaniu hubów, aby wybrać odpowiednie pasmo dla projektowanej sieci.

W drugim etapie dodaje się aplikację produktu, wczytuje certyfikat urządzenia, umieszcza je w linii IoT, konfiguruje parametry i łączy obiekty komunikacyjne z adresami grupowymi. Konfigurację można następnie pobrać m.in. na podstawie numeru seryjnego, bez konieczności ręcznego włączania trybu programowania.

Niepodważalną zaletą KNX IoT jest to, że poza konfiguracja sieci mesh dalsza praca bardzo przypomina działanie z klasyczną siecią KNX. Zarówno urządzenia IoT, jak i TP mogą korzystać z tych samych adresów grupowych, dzięki czemu możemy uniknąć kładzenia zielonego przewodu w ścianach i sterować urzą-dzeniami wykonawczymi bezprzewodowo. Jest to szczególnie ważne przy mo-dernizacji istniejących instalacji.

Bezpieczeństwo

Bezpieczeństwo KNX IoT jest realizowane wielowarstwowo. Na poziomie sieci radiowej Thread nowe urządzenie nie może po prostu połączyć się z dostępną siecią. Podczas commissioningu jest ono uwierzytelniane przez uprawnione urządzenie, a następnie otrzymuje dane dostępowe sieci. Transmisja Thread jest zabezpieczana mechanizmami kryptograficznymi opartymi na AES-CCM, zapewniającymi szyfrowanie oraz kontrolę integralności przesyłanych wiadomości.

Drugi poziom zabezpieczeń dotyczy właściwej komunikacji KNX, które jest nam już dobrze znane z klasycznych rozwiązań. Pozwala on zabezpieczyć wiado-mości pomiędzy urządzeniami końcowymi, niezależnie od samej ochrony zapewnianej przez medium Thread. Dzięki temu bezpieczeństwo komunikacji nie opiera się wyłącznie na jednym wspólnym zabezpieczeniu sieci radiowej – również dane aplikacyjne KNX są szyfrowane i chronione przed nieautoryzo-waną zmianą.

Każde urządzenie KNX IoT posiada indywidualne dane bezpieczeństwa zapisane w postaci kodu QR. Kod zawiera między innymi numer seryjny i dane uwierzytelniające potrzebne do rozpoznania urządzenia przez ETS. Po zeskanowaniu certyfikatu ETS może zweryfikować urządzenie i przeprowadzić Secure Commissioning. Z tego względu, kody QR urządzeń należy przechowywać w bezpiecznym miejscu wraz z dokumentacją instalacji.

Ocena z perspektywy instalatora

Czy uruchomienie było intuicyjne?

Do kompleksowego uruchomienia urządzeń KNX wymagana jest wiedza z zakresu sieci oraz technologii Thread. Może to stanowić problem dla mniej wprawionych instalatorów. Niemniej jednak pozostała część procesu była niezwykle intuicyjna i bezproblemowa.

Czy reakcja urządzeń była porównywalna z TP?

Czas reakcji urządzeń warto oceniać w rzeczywistych warunkach instalacji. W prawidłowo zaprojektowanej sieci różnice względem KNX TP nie powinny być istotne podczas typowego sterowania oświetleniem, roletami lub scenami. Trzeba jednak pamiętać, że komunikacja bezprzewodowa zależy od jakości sieci Thread, rozmieszczenia urządzeń, poziomu zakłóceń w paśmie 2,4 GHz oraz poprawnej pracy Hubu i infrastruktury IP. W przypadku KNX TP medium transmisyjne jest bardziej przewidywalne, ponieważ opiera się na dedykowanym przewodzie magistralnym.

Czy dodatkowa infrastruktura IoT jest uzasadniona?

Dodatkowa infrastruktura KNX IoT jest uzasadniona przede wszystkim wtedy, gdy jej zastosowanie rozwiązuje konkretny problem projektowy. Największą korzyścią jest możliwość instalowania urządzeń bez doprowadzania do nich przewodu magistralnego KNX. Może to znacząco ułatwić modernizację istniejących budynków, rozbudowę gotowej instalacji lub montaż manipulatorów w miejscach, w których wykonanie nowych tras kablowych byłoby trudne, kosztowne albo niemożliwe.

W jakim projekcie zastosować KNX IoT?

KNX IoT zastosowałabym przede wszystkim w modernizowanych budynkach, w których klasyczna instalacja KNX TP już funkcjonuje, ale konieczne jest dodanie nowych czujników lub manipulatorów bez ingerencji w wykończone ściany. Technologia może być również atrakcyjna w obiektach modułowych, lokalach często zmieniających aranżację oraz instalacjach rozwijanych etapami. W takich przypadkach możliwość bezprzewodowego dołączania urządzeń przy zachowaniu konfiguracji w ETS stanowi realną przewagę.

W jakim przypadku pozostać przy KNX TP?

Przy KNX TP pozostałabym natomiast w nowych budynkach, w których przewód magistralny można ułożyć bez większych trudności. Dotyczy to szczególnie urządzeń odpowiedzialnych za podstawowe i krytyczne funkcje instalacji, dla których najważniejsze są przewidywalność komunikacji, prostota diagnostyki i niezależność od sieci radiowej oraz infrastruktury LAN. KNX IoT to w mojej ocenie nie zamiennik, czy następca, KNX TP, lecz uzupełniające medium, które rozszerza możliwości klasycznej instalacji.

Podsumowanie: KNX IoT łączy dwa światy

Ostatecznie największą siłą KNX IoT jest połączenie dwóch światów: elastycznej, bezprzewodowej sieci IPv6 oraz dobrze znanego sposobu projektowania instalacji KNX. Proces pierwszego uruchomienia jest bardziej złozony niż w przypadku TP, ale po jego zakończeniu urządzenia stają się pełnoprawną częścią projektu ETS, bez potrzeby tworzenia osobnego systemu automatyki czy stosowania zamkniętej aplikacji producenta.