... |
... |
@@ -1,12 +1,11 @@ |
1 |
|
-= Datenbus = |
2 |
|
- |
|
1 |
+(% class="wikigeneratedid" id="HDatenbus" %) |
3 |
3 |
Der Space wird eine Menge von Aktoren, Sensoren und aktuell noch nicht definierte Dinge betreiben. Damit nicht jedesmal ein neues Protokoll zur Kommunikation gelernt werden muss wurde beschlossen mit Dingen über MQTT zu kommunizieren. |
4 |
4 |
|
5 |
|
-== MQTT == |
|
4 |
+== MQTT == |
6 |
6 |
|
7 |
7 |
MQTT ist ein offenes und standardisiertes Protokoll. Die Standardisierung wird durch die Organization for the Advancement of Structured Information Standards geleitet[[http://mqtt.org/]]. Das Format der zu übertragenden Daten, der eigentlich Payload, bleibt dabei dem Anwender überlassen. MQTT regelt hierbei nur den Austausch der selbst definierten Daten. |
8 |
8 |
|
9 |
|
-=== Topics === |
|
8 |
+=== Topics === |
10 |
10 |
|
11 |
11 |
MQTT kann Daten einfach sortieren/kontextualisieren. Dafür werden sogenannte Topics verwendet. Topics bilden Pfade (ähnlich Dateipfaden) in den man Daten veröffentlichen oder von denen man Daten lesen kann (schreiben und lesen wird auch publish und subscribe genannt). So kann man zum Beispiel folgende Struktur erstellen: |
12 |
12 |
|
... |
... |
@@ -22,19 +22,13 @@ |
22 |
22 |
* /space/meetingroom/temperature |
23 |
23 |
{{/code}} |
24 |
24 |
|
25 |
|
-{{code}} |
26 |
|
-* /space/meetingroom/moisture |
27 |
|
-{{/code}} Wenn man alle Temperaturen empfangen will (subscribe) kann man mit Wildcards arbeiten. So kann man im folgendem Beispiel alle defineirten Temperaturen empfangen: |
|
24 |
+{{code}}* /space/meetingroom/moisture{{/code}} Wenn man alle Temperaturen empfangen will (subscribe) kann man mit Wildcards arbeiten. So kann man im folgendem Beispiel alle defineirten Temperaturen empfangen: |
28 |
28 |
|
29 |
|
-{{code}} |
30 |
|
-* /space/+/temperature |
31 |
|
-{{/code}} Will man alle Werte empfangen kann man folgende Definition verwenden: |
|
26 |
+{{code}}* /space/+/temperature{{/code}} Will man alle Werte empfangen kann man folgende Definition verwenden: |
32 |
32 |
|
33 |
|
-{{code}} |
34 |
|
-* /space/# |
35 |
|
-{{/code}} Das # Zeichen darf nur am Ende der Topic Definition eingesetzt werden. |
|
28 |
+{{code}}* /space/#{{/code}} Das # Zeichen darf nur am Ende der Topic Definition eingesetzt werden. |
36 |
36 |
|
37 |
|
-==== Topicstruktur des ZTL ==== |
|
30 |
+==== Topicstruktur des ZTL ==== |
38 |
38 |
|
39 |
39 |
Innerhalb des Spaces wird folgende Struktur für Topics empfohlen: |
40 |
40 |
|
... |
... |
@@ -48,40 +48,32 @@ |
48 |
48 |
* /light/space/livingroom/LedStripe1/debug |
49 |
49 |
{{/code}} |
50 |
50 |
|
51 |
|
-===== Beispiel für Licht ===== |
|
44 |
+===== Beispiel für Licht ===== |
52 |
52 |
|
53 |
53 |
Damit nur die Lampe "LedStripe1" gesteuert wird sendet man Meldungen an |
54 |
54 |
|
55 |
|
-{{code}} |
56 |
|
-* /light/space/livingroom/LedStripe1 |
57 |
|
-{{/code}} Damit alle Lampen im "livingroom" gesteuert werden sendet man Meldungen an |
|
48 |
+{{code}}* /light/space/livingroom/LedStripe1{{/code}} Damit alle Lampen im "livingroom" gesteuert werden sendet man Meldungen an |
58 |
58 |
|
59 |
|
-{{code}} |
60 |
|
-* /light/space/livingroom |
61 |
|
-{{/code}} Damit alle Lampen im "space" gesteuert werden sendet man Meldungen an |
|
50 |
+{{code}}* /light/space/livingroom{{/code}} Damit alle Lampen im "space" gesteuert werden sendet man Meldungen an |
62 |
62 |
|
63 |
|
-{{code}} |
64 |
|
-* /light/space |
65 |
|
-{{/code}} Debug Informationen für Lampe "LedStripe1" |
|
52 |
+{{code}}* /light/space{{/code}} Debug Informationen für Lampe "LedStripe1" |
66 |
66 |
|
67 |
|
-{{code}} |
68 |
|
-* /light/space/livingroom/LedStripe1/debug |
69 |
|
-{{/code}} Debug Informationen für alle Lampen |
|
54 |
+{{code}}* /light/space/livingroom/LedStripe1/debug{{/code}} Debug Informationen für alle Lampen |
70 |
70 |
|
71 |
71 |
{{code}} |
72 |
72 |
* /light/#/#/#/debug |
73 |
73 |
{{/code}} |
74 |
74 |
|
75 |
|
-=== Payload === |
|
60 |
+=== Payload === |
76 |
76 |
|
77 |
77 |
Die später verwendeten Dinge werden unterschiedliche Anforderungen für den Datenaustausch haben. Im folgenden Abschnitt werden diese Anforderungen Kategorisiert. Für die Implementierung soll eine möglichst flache JSON Struktur verwendet werden. Dinge könne mehrere dieser Anforderungen gleichzeitig implementiert haben. |
78 |
78 |
|
79 |
|
-==== Command ==== |
|
64 |
+==== Command ==== |
80 |
80 |
|
81 |
81 |
Der Typ Command wird für Kommunikation benötigt bei der das Ding den Payload nur empfängt und intern verarbeitet. Das Ding wird keine Rückmeldung an den Empfänger senden. Beipiel: |
82 |
82 |
|
83 |
83 |
{{code}} |
84 |
|
-* Licht -> an oder aus |
|
69 |
+* Licht -> an oder aus |
85 |
85 |
{{/code}} |
86 |
86 |
|
87 |
87 |
{{code}} |
... |
... |
@@ -96,10 +96,10 @@ |
96 |
96 |
"g": 255, //Used by the client to set the action green color -> ignored if device can only on/off |
97 |
97 |
"b": 255, //Used by the client to set the action blue color -> ignored if device can only on/off |
98 |
98 |
"w": 255 //Used by the client to set the action white color -> ignored if device can only on/off |
99 |
|
-} |
|
84 |
+} |
100 |
100 |
{{/code}} |
101 |
101 |
|
102 |
|
-==== Request ==== |
|
87 |
+==== Request ==== |
103 |
103 |
|
104 |
104 |
Der Typ Request wird für Kommunikation benötigt bei der der Sender Werte vom Ding anfordert. Beispiel: |
105 |
105 |
|
... |
... |
@@ -129,7 +129,7 @@ |
129 |
129 |
} |
130 |
130 |
{{/code}} |
131 |
131 |
|
132 |
|
-==== State ==== |
|
117 |
+==== State ==== |
133 |
133 |
|
134 |
134 |
Der Typ State wird verwendet damit das Ding selbständig Werte an einen Empfänger senden kann. Beispiel: |
135 |
135 |
|
... |
... |
@@ -167,7 +167,7 @@ |
167 |
167 |
} |
168 |
168 |
{{/code}} |
169 |
169 |
|
170 |
|
-=== Typen === |
|
155 |
+=== Typen === |
171 |
171 |
|
172 |
172 |
Typen definieren die möglichen Aktoren/Sensoren im Netzwerk. Die Datenstruktur wird im jeweiligen Wiki Beitrag gepflegt. Die möglichen Typen werden hier aufgeführt. |
173 |
173 |
|