Protokół X3D - dywagacje na temat topologii

  • 0 Odpowiedzi
  • 3274 Wyświetleń

0 użytkowników i 1 Gość przegląda ten wątek.

*

Offline homelogic

  • Moderator
  • ***** 341
  • 11
  • Nazwa i wersja ID: Loxone + Ampio + Delta Dore + Grenton + KNX
Protokół X3D - dywagacje na temat topologii
« dnia: Luty 23, 2018, 12:46:31 pm »
Protokół X_D został stworzony przez Delta Dore. Obecnie obowiązuje wersja 3, stąd X3D. Poprzednia wersja, czyli X2D (lata 90) nie miała topologii mesh i była jednokierunkowa (master -> slave). Na tym chodzi większość standardowych termostatów dostępnych od lat na rynku.

W protokole X3D mamy kilka poziomów zależności master-slave i kilka sieci mesh  (:P).

Podstawowy klocek X3D jest kontrolerem który może obsłużyć do 16 urządzeń o zdefiniowanych funkcjonalnościach (innych kontrolerów ale też tzw. transmiterów). Przykładowo, odbiornik ogrzewania ma 16 slotów do przypisania termostatów, kontaktronów czy czujek ruchu i będzie realizował odpowiednie funkcje w zależności od typu urządzenia z jakim jest sparowany (kontaktron odepnie ogrzewanie po krótkim opóźnieniu, czujka ruchu włączy ogrzewanie itp.). Transmiter to najczęściej urządzenie bateryjne, typu czujka ruchu czy wspomniany kontrakton.
Przy tak zbudowanej sieci (czyli gdy nie mamy żadnej centralki) wszystko działa autonomicznie na zasadzie bezpośredniej komunikacji, nie ma sieci mesh. Jako reapetery wykorzystujemy inne kontrolery. W tym wariancie przypomina to sieć X2D (kontrolery jako mastery, transmitery jako slave) wzbogaconą o funkcje reapetera przez kontrolery i komunikację 2 kierunkową (feedback od urządzeń, np. diodka na pilocie od rolet piknie na zielono jak dostanie "ok" od wszystkich rolet).

Centralka działa jako dodatkowy super-kontroler, a raczej kilka super-kontrolerów. Dla ułatwienia będę je nazywał sieciami.
Każda sieć może być sparowana z 16 kontrolerami w ramach zdefiniowanej funkcjonalności. Topologia mesh występuje w ramach jednej sieci.

W centralce Tydom 1.0 mamy nastepujące sieci:
2 x oświetlenie
2 x rolety
2 x ogrzewanie
2 x inne

Czyli mamy łącznie 8 sieci mesh, do których przypiszemy łącznie 8 x 16 modułów (kontrolerów). Transmiterów nie przypisujemy do centralki, ich stan jest przekazywany (lub nie) za pomocą kontrolera. Przykładowo, odbiornik ogrzewania przekazuje do centralki temperaturę zadaną i aktualną z termostatu naściennego. Dzięki temu zyskujemy pełną autonomię wymienionych funkcjonalności (ogrzewanie działa nawet jak pies zeżre centralkę), ale tracimy na elastyczności (tylko predefiniowane fukcjonalności i logika).
Każdy kontroler przypisany do jednej sieci możemy przypisać do 15 innych. W każdej kolejnej sieci taki moduł będzie działał jako dodatkowy węzeł sieci mesh.


Bardzo ciekawie się robi gdy mamy centralę Lifedomus.....

Na każdą bramkę X3D możemy utworzyć 12 dowolnych sieci, w tym też sieć transmiterów. Czyli mamy pełną dowolność, albo parujemy transmitery z kontrolerami bezpośrednio zyskując na autonomii, albo logika leci przez centralkę. Do wyboru, do koloru :).

I teraz największy bajer - Lifedomus nie ma limitów w ilości obsługiwanych bramek X3D. Co prawda dongli wetkniemy tylko tyle ile jest slotów USB, ale można też wykorzystać Tydom 1.0 który jest traktowany jako bramka IP (również zdalna), zachowując przy tym swoje funkcje i dostęp ze swojej apki :o

Sam Tydom 1.0 natywnie obsługuje 8 sieci, ale przez Lifedomusa obsłużymy 12. Tutaj już można ekstremalnie mieszać. Jeden moduł można przypisać przez apkę Tydoma 1.0 i zasiorbać go importem do Lifedomusa (pod tą samą sieć i wspólny slot). Można go przypisać osobno do Lifedomusa i do Tydoma 1.0 (pod osobne lub jedną sieć). Można przypisać go też tylko przez Lifedomusa, wtedy nie jest widoczny dla natywnego Tydoma 1.0 mimo iż przez niego idzie komunikacja.  :o :o :o.

Ogólnie kosmos. To już przestaje być domotyka, a zaczyna całkiem rozbudowany BMS.