Slave-Knoten sind Knoten, die aufgrund gewisser Einschränkungen nicht die volle (CAN@home-)Funktionalität besitzen. Sie sind keine vollwertigen Kommunikationsteilnehmer, sondern besitzen einen reduzierten Kommunikationsumfang. Typischerweise binden sich die Slaves an einen vollwertigen Knoten (Master) an und sind somit transparent erreichbar. Der Masterknoten muss hierfür keine besondere Software ausführen, sondern kommuniziert über normale DDOs mit den Slaves. (Details unten).
Der häufigste (bisher einzige) Grund für einen Slaveknoten sind die Zigbeeknoten, die aufgrund der eingeschränkten Zigbeedatenrate (max. 250kBit/s brutto; netto deutlich weniger) und der evtl. nicht durchgängigen Bestromung (Sleepmode; derzeit noch nicht umgesetzt) nicht immer am Bus verfügbar sind.
Hinweis: Dauerbestromte Zigbeeknoten sind über das Zigbeegateway vollwertige Busteilnehmer.
Einbindung Zigbee ins CAN@home-Konzept
Die Verwendung von Zigbee-Slaves eignet sich für die Verwendung für:
- Temperaturmessstellen (z.B. zur Heizungssteuerung)
- Rauchmelder
- nachgerüstete Lichtschalter; sonstige digitale Sensoren, wie z.B. Bewegungsmelder
- Lichtschranken, Impulszähler (Gas-, Wasserzähler)…
Anbindung an den CahBus
Zigbeeknoten erscheinen als normale CahKnoten, die virtuell über CAN erreichbar sind.
Ein Zigbee/CAN-Gateway schickt alle CAN-Botschaften, die an Zigbee-Knoten adressiert sind auf Zigbee raus. (Die Erkennung der Zigbeeknoten gelingt über einen konfigurierbaren Knotennummernbereich: z.B. 50..99).
Alle Zigbee-Telegramme werden als Broadcast verschickt (auf CAN wird auch alles als Broadcast verschickt). Das ZigbeeGateway, das sich für den Absendeknoten verantwortlich fühlt (konfiguriert ist), nimmt das ZigbeeTelegramm entgegen und routet dieses auf CAN durch.
Es können aus Bandbreitengründen nicht alle CAN-Botschaften auf Zigbee geroutet werden, deshalb werden nur die (reduzierte Anzahl an) DDOs und TOs geroutet. BroadcastObjects werden gefiltert. (Einen Bootloader mit Zigbeeunterstützung gibt es (derzeit) nicht. Grund: Speicherplatz im Bootloader ist stark begrenzt; Zigbeetreiber paßt hier nicht mehr rein).
NMOs werden nur in Richtung Zigbeeknoten->CAN-Bus durchgeroutet.
Da ins Zigbee-Netz keine BOs geroutet werden, sollten auch von Zigbeeknoten keine Telegramme (aus Telegrammpool) verschickt werden, da z.B. Nebenbedingungen usw. nicht möglich sind. Der Versand von (Pool-)Telegrammen sollte von einem CAN-Knoten geschehen, der die Rohdaten vom Zigbee-Knoten per Bo-Ddo-Konverter auswertet.
Ein Zigbee-Gateway routet folgende Botschaftstypen an seine angeschlossenen Zigbeeslaves durch:
Die Kommunikation zwischen ZigbeeSlave geschieht grundsätzlich über das ZigbeeGateway. ZigbeeSlave dürfen untereinander keine Nachrichten austauschen, da so die Information darüber nicht auf CAN geroutet werden würde (z.B. für Traces) und nicht sichergestellt ist, dass der Empfänger gerade auch Empfangsbereit ist (Sleepmode).
Remoteapplikationen: Einbindung einer Stromspar-Zigbee-Applikation ins CahBus-Konzept
Aus Sicht eines „außenstehenden“ Knotens soll nicht erkennbar sein, dass eine Applikation (z.B. ein Taster) an einem Zigbeeknoten angeschlossen ist. Die steuernde Applikation soll ganz normal ihre DotParameter (DataObjectTableParameter) zum Beschreiben und Auslesen bereit stellen. Allerdings ist die „öffentliche“ Applikation nicht (nur) im Zigbeeknoten selbst hinterlegt, sondern läuft auf auch dem Zigbeegateway-Knoten (oder sogar allgemeiner auf einem beliebigen Masterknoten). Die eigentliche Applikation auf dem Zigbeeknoten muss hierzu nicht immer aktiv sein, sondern kann sich über längere Zeiträume im Sleepmode befinden. Zwischenzeitliche Abfragen nach DotParametern landen ja im übergeordneten Master-Knoten.
Der ZigbeeSlave teilt per Ddo seinem Masterknoten einen erkannten Tastendruck mit, worauf dieser seine internen Daten aktualisiert. Das DdoWrite adressiert hierfür direkt die Eingangsvariable in der die aktuellen Tasterzustände gespeichert sind. (Im Master ist entsprechend konfiguriert, dass die aktuellen Daten nicht aus der lokalen Hardware einzulesen sind, sondern über DDOs eintreffen werden).
Das folgende Bild zeigt eine Relaisapplikation, die an einem Slave-Zigbeeknoten hängt, aber vom (hier:) Zigbeegateway verwaltet wird. Der Istzustand des Relais gelangt per „normalem“ BO (BroadcastObject) automatisch zyklisch zum Master – die RelaisApplikation soll ja nicht wissen, dass Sie in einem Zigbeeknoten läuft.
Hier noch eine beispielhafte Anbindung eines a.) Sensors und b.) Aktors
Gegenüberstellung CAN-Knoten / Zigbee-Knoten
| CAN-Knoten | Zigbee-Knoten | |
| Updateprogrammierbar | ja | nein |
| DDO | ja | ja |
| NMO | ja | nur sendend |
| vollwertige Applikationen | ja | ja |
| BO-Versand | ja | ja, aber nur sendend (kein Empfang) |
| Transparent am Bus sichtbar (Konfiguration über HomeCentral) |
ja | ja, da eigene CahKnotennummer |