Zum Inhalt springen

Wiki-Quellcode von Datenbus

Zuletzt geändert von holymoly am 2023/05/09 18:11
Zeige letzte Bearbeiter
1 (% class="wikigeneratedid" %)
2
3
4 (% class="wikigeneratedid" %)
5 ~-~--Outdated~-~-- wurde mit WLEDs umgesetzt da kein Interesse am Datenbus bestand. Bleibt als Doku für holymoly erhalten
6
7
8
9 (% class="wikigeneratedid" id="HDatenbus" %)
10 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.
11
12 == MQTT ==
13
14 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.
15
16 === Topics ===
17
18 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:
19
20 {{code}}
21 * /space/livingroom/temperature
22 {{/code}}
23
24 {{code}}
25 * /space/woodworkshop/temperature
26 {{/code}}
27
28 {{code}}
29 * /space/meetingroom/temperature
30 {{/code}}
31
32 {{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:
33
34 {{code}}* /space/+/temperature{{/code}} Will man alle Werte empfangen kann man folgende Definition verwenden:
35
36 {{code}}* /space/#{{/code}} Das # Zeichen darf nur am Ende der Topic Definition eingesetzt werden.
37
38 ==== Topicstruktur des ZTL ====
39
40 Innerhalb des Spaces wird folgende Struktur für Topics empfohlen:
41
42 {{code}}
43 * /typ/space/room/nodename/debug
44 {{/code}}
45
46 So kann eine Lampe namens "LedStripe1" im Aufenthaltsraum mit folgender Struktur adressiert werden:
47
48 {{code}}
49 * /light/space/livingroom/LedStripe1/debug
50 {{/code}}
51
52 ===== Beispiel für Licht =====
53
54 Damit nur die Lampe "LedStripe1" gesteuert wird sendet man Meldungen an
55
56 {{code}}* /light/space/livingroom/LedStripe1{{/code}} Damit alle Lampen im "livingroom" gesteuert werden sendet man Meldungen an
57
58 {{code}}* /light/space/livingroom{{/code}} Damit alle Lampen im "space" gesteuert werden sendet man Meldungen an
59
60 {{code}}* /light/space{{/code}} Debug Informationen für Lampe "LedStripe1"
61
62 {{code}}* /light/space/livingroom/LedStripe1/debug{{/code}} Debug Informationen für alle Lampen
63
64 {{code}}
65 * /light/#/#/#/debug
66 {{/code}}
67
68 === Payload ===
69
70 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.
71
72 ==== Command ====
73
74 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:
75
76 {{code}}
77 * Licht -> an oder aus
78 {{/code}}
79
80 {{code}}
81 {
82 //Command to device
83 "type": "cmd", //Used by the client to identify type of communication
84 "device":"name", //Used by the client to check if relevant to this device -> if not set group needs to have a value
85 "group": "name", //Used by the client to check if relevant to a group it belongs to -> if not set device needs to have a value
86 "cmd": "light", //Used by the client to identify action
87 "state": "on", //Used by the client to set the action to the requested state
88 "r": 255, //Used by the client to set the action red color -> ignored if device can only on/off
89 "g": 255, //Used by the client to set the action green color -> ignored if device can only on/off
90 "b": 255, //Used by the client to set the action blue color -> ignored if device can only on/off
91 "w": 255 //Used by the client to set the action white color -> ignored if device can only on/off
92 }
93 {{/code}}
94
95 ==== Request ====
96
97 Der Typ Request wird für Kommunikation benötigt bei der der Sender Werte vom Ding anfordert. Beispiel:
98
99 {{code}}
100 * Abfrage einer Raumtemperatur
101 {{/code}}
102
103 {{code}}
104
105 //Request to device
106 {
107 "type": "req", //Used by the client to identify type of communication
108 "req": "temp", //Used by the client to identify action
109 "device":"name", //Used by the client to check if relevant to this device -> if not set group needs to have a value
110 "group": "name", //Used by the client to check if relevant to a group it belongs to -> if not set device needs to have a value
111 "reqId" "uid" //Device will return this value in the response, Used by sender
112 }
113 //Response to sender
114 {
115 "type": "resp", //Used by the sender to identify type of communication
116 "device":"name", //Used by the sender to check if relevant
117 "group": "name", //Used by the sender to check if relevant
118 "resp": "temp", //Used by the sender to identify action
119 "value": 20.5, //Used by the sender to identify value
120 "unit": "C", //UOM
121 "reqId" "uid" //Used by the sender to match to request
122 }
123 {{/code}}
124
125 ==== State ====
126
127 Der Typ State wird verwendet damit das Ding selbständig Werte an einen Empfänger senden kann. Beispiel:
128
129 {{code}}
130 * zykliches Übermitteln der Luftfeuchte für Trenddaten
131 {{/code}}
132
133 {{code}}
134
135 // Moisture sended every Minute
136 {
137 "type": "state", //Used by the receiver to identify type of communication
138 "device": "name", //Used by the receiver to check if relevant
139 "group": "name", //Used by the receiver to check if relevant
140 "category": "moisture", //Used to define type of measurement
141 "value": "50", //Value of changed state
142 "uom": "%" //UoM of value
143 }
144 {{/code}}
145
146 {{code}}
147 * wenn Fenster auf oder zu detektiert wird
148 {{/code}}
149
150 {{code}}
151
152 // example when window is closed
153 {
154 "type": "state", //Used by the receiver to identify type of communication
155 "device": "window1", //Used by the receiver to check if relevant
156 "group": "name", //Used by the receiver to check if relevant
157 "category": "switch", //Used to define type of measurement
158 "value": "closed", //Value of changed state
159 "uom": "" //UoM of value
160 }
161 {{/code}}
162
163 === Typen ===
164
165 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.
166
167 Typen:
168
169 {{code}}
170 [[projekte:licht|Licht]]
171 {{/code}}