Aufbau der Botschaften

Diagramm: Botschaftsaufbau (am Beispiel CAN)

DirectDataObject (DDO)

DirectDataObjects werden verwendet, um Daten von einem Knoten zu einem anderen Knoten zu übertragen. Die Datenflußrichtung kann dabei lesend („Read“) oder schreibend („Write“) sein. DDOs sind die praktisch häufigste anzutreffende Telegrammart bei CAN@home. Hierüber läuft die ganze gesteuerte Hausautomation eigentlich ab.

Ein DirectDataObject adressiert im Zielknoten eine bestimmte Funktionalität oder einen Parameter. Diese Funktionalitäten oder Parameter sind in einer DataObjectTable in jedem Knoten abgelegt. Ein Eintrag in dieser Tabelle (DOtable) nennt sich DataObject (DO). Ein DataObject läßt sich eindeutig bezeichnen/adressieren durch Angabe von:

• DataObjectType (DOType)
• DataObjectMainIndex (DOMainIndex)
• DataObjectSubIndex (DOSubIndex)

DOType spezifiziert die grundsätzliche Funktion, die angesprochen werden soll. Der DOTyp 0x00 (Knotenspezifische Parameter) muß von jedem Knoten umgesetzt/implementiert werden. Hierin sind Informationen/Parameter enthalten, die den Knoten als solches näher beschreiben. Andere DOTypen (z.B. 0x12 für Rolladen; 0x13 für Lampen/Dimmer) sind implementations- und applikationsabhängig.

Enthält eine Knotenhardware/-software mehrere gleiche Applikationen (z.B. mehrere Relais oder Dimmer…) so ist durch den DOMainIndex bestimmt, welches Ziel davon adressiert werden soll. (z.B. Dimmer4 innerhalb dieses Knotens).
DOSubIndex wiederum spezifiziert welcher Parameter dieses DOMainIndex jetzt angesprochen werden soll. Beispielsweise ist der „Dimmwert in %“ oder die „Softstartzeit in ms“ ein Parameter für die Funktion/Applikation „Dimmer“.
Jedes DataObject ist also innerhalb eines Knotens eindeutig durch DOType, DOMainIndex und DOSubIndex adressierbar.
Busweit eindeutig wird diese Zuordnung durch Einbeziehung der Knotennummer. Hier kommen dann auch die DirectDataObjects ins Spiel, die ja an einen bestimmten Knoten gerichtet sein müssen (Ausnahme: Busweite DDO-Broadcasts; Kennzeichen: Empfängeradresse=0xFF).

Beispiel für den schreibenden Zugriff auf ein DataObject
Knoten 03 möchte Knoten 20 mitteilen, daß dessen vierte Lampe jetzt auf 50% gedimmt werden soll. Dazu wählt Knoten3 den dafür passenden Parameter „Dimmwert“ aus der DOtable aus. Daraus ergibt sich dann, daß DOType 0x13 (für Lampe), DOMainIndex 0x04 (vierte Lampe; hm…) und DOSubIndex 0x00 (Dimmwert in %) zu wählen ist.

Das zugehörige Can-Telegramm sieht dann so aus:

CanId 0x0B032013 Daten 0x04 0x00 0x32
0x0A: Kennung für DdoRead
0x0B: Kennung für DdoWrite

Die maximale Größe eines DOtable-Eintrags bzw. eines DataObjects ist auf 6Bytes begrenzt – mehr kann ein DDO-Telegramm nicht transportieren. Sollen längere oder komplexere Parameter verwendet werden, so müssen diese auf mehrere DoTable-Einträge aufgeteilt werden. Um die DoTable übersichtlich zu halten, wird diese nach DoTypen getrennt geführt und bei der Beschreibung der einzelnen Applikationen gelistet. Nachfolgend der Teil der DOtable, der den DOType 0x00 („KnotenspezifischeParameter“) zeigt:

<<todo: Tabelle Knotenspezifische Parameter>> Ausschnitt aus DoTable.xls

Diagramm: Schematische Darstellung DataObjectTable als Datenaustauschpunkt zwischen Bus und Applikationssoftware

Lesende Zugriffe auf ein DataObject funktionieren prinzipiell genauso wie die schreibenden Zugriffe. Allerdings muß der adressierte Knoten seine Antwort noch an den anfragenden Knoten schicken. Dabei bedient er sich der DataObjectResponse, die im nachfolgenden Kapitel genauer beschrieben wird.

Der CanTelegramm-Aufbau eines DDO-Requests entspricht dem Format des schreibenden DDOs. Beide unterscheiden sich nur im gelöschten „Write/Read“-Bit und daß keine Nutzdaten übertragen werden. D.h. der CanDlc kann kürzer ausfallen. Ein konkretes Beispiel für den lesenden Zugriff findet sich in anschließenden Kapitel.

DataObjectResponse (DOR)

Ein DataObjectResponse Telegramm trägt die Antwort auf ein zuvor an diesen Knoten gestelltes DDOread (Request) Telegramm. Formal unterscheiden sich die Nachrichtentypen DDO und DOR ausschließlich in ihrer Nachrichtenkennung. (0x0Cnnnnnn statt 0x0A|Bnnnnnn). Der inhaltliche Aufbau kann also dem Abschnitt DDO entnommen werden.

Beispielkommunikation zwischen zwei Knoten zur Abfrage der verwendeten Softwareversion(snummer) im adressierten Knoten:

Anfrage: (DDOread) Knoten 53 fragt Knoten 05 nach dem Softwaretyp (DOtype: 0x00; DOMainIndex: 0x00; DOSubIndex: 0xF0):

CanId 0x0A530500 Data 0x00 0xF0
0x0A: Kennung für DirectDataObjectRead (DdoRead)

Antwort: (DOR) Knoten 05 antwortet Knoten 53:

CanId 0x0C055300 Data 0x00 0xF0 0x46 0x54 0x4B 0x31 0x33 0x31 (Ascii-Nutzdaten: „FTK131„)
0x0C: Kennung für DataObjectResponse (Dor)

BroadcastObject (BO)

Mittels BroadcastObject teilt ein Knoten dem Bus häufig benötigte Informationen mit, um eine ständige Anfrage (und somit Buslast) zu verringern.

Die Zusammenstellung der BOs wird aufgrund der häufig angefragten Daten aus der DoTable zusammengestellt. Vorteil: z.B. ein Display muß nicht ständig nach der Position der Fensterkontakte fragen, um eine Übersicht der offenen Fenster ausgeben zu können. Dadurch wird Buskapazität und Softwarelaufzeit in jedem Knoten eingespart.

Jeder DoType darf mehrere BOs (unterteilt nach BoIndex) versenden. Praktisch reichen pro DoType (entspricht meist einer Applikation bzw. KnotenSoftware) ein bis zwei BOs (BOIndex 0x00+0x01…). Hinweis: Die Liste der BOs die eine Applikation versendet wird in der Doku zusammen mit der Applikation beschrieben.

Beispiel: Die Applikation „Rolladen“ (entspricht DOType 0x12) verschickt folgende BOs:

DoType	Beschreibung	BoIndex	Beschreibung	Zykluszeit
0x12	Rolladen	0x00	Positionen/Parameter	2000ms

Die Nutzdaten der Botschaft sind so aufgebaut:

Byte0	RolladenZielposition (0%: offen; 100%: geschlossen)
Byte1	Rolladenposition (aktuell)
Byte2	Rolladenfunktionsstatus; Bitfeld (siehe zugehörigen Dotp) (In Begrenzung; Im Nachlauf; KipplüftenAktiv…)
Byte3	RolladenProfil (aktuell)

TransportObject (TO)

Verwendung, um größere Datenmengen zu übertragen. Momentan einzige Verwendung für Updateprogrammierung (neue Knotensoftware über Bus aufspielen).

Weitere Details zu den transportierten Kommandos siehe Bootloaderdoku.