Datenbus
---Outdated--- wurde mit WLEDs umgesetzt da kein Interesse am Datenbus bestand. Bleibt als Doku für holymoly erhalten
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.
MQTT
MQTT ist ein offenes und standardisiertes Protokoll. Die Standardisierung wird durch die Organization for the Advancement of Structured Information Standards geleitethttp://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.
Topics
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:
* /space/meetingroom/moisture Wenn man alle Temperaturen empfangen will (subscribe) kann man mit Wildcards arbeiten. So kann man im folgendem Beispiel alle defineirten Temperaturen empfangen:
* /space/+/temperature Will man alle Werte empfangen kann man folgende Definition verwenden:
* /space/# Das # Zeichen darf nur am Ende der Topic Definition eingesetzt werden.
Topicstruktur des ZTL
Innerhalb des Spaces wird folgende Struktur für Topics empfohlen:
So kann eine Lampe namens "LedStripe1" im Aufenthaltsraum mit folgender Struktur adressiert werden:
Beispiel für Licht
Damit nur die Lampe "LedStripe1" gesteuert wird sendet man Meldungen an
* /light/space/livingroom/LedStripe1 Damit alle Lampen im "livingroom" gesteuert werden sendet man Meldungen an
* /light/space/livingroom Damit alle Lampen im "space" gesteuert werden sendet man Meldungen an
* /light/space Debug Informationen für Lampe "LedStripe1"
* /light/space/livingroom/LedStripe1/debug Debug Informationen für alle Lampen
Payload
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.
Command
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:
//Command to device
"type": "cmd", //Used by the client to identify type of communication
"device":"name", //Used by the client to check if relevant to this device -> if not set group needs to have a value
"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
"cmd": "light", //Used by the client to identify action
"state": "on", //Used by the client to set the action to the requested state
"r": 255, //Used by the client to set the action red color -> ignored if device can only on/off
"g": 255, //Used by the client to set the action green color -> ignored if device can only on/off
"b": 255, //Used by the client to set the action blue color -> ignored if device can only on/off
"w": 255 //Used by the client to set the action white color -> ignored if device can only on/off
}
Request
Der Typ Request wird für Kommunikation benötigt bei der der Sender Werte vom Ding anfordert. Beispiel:
//Request to device
{
"type": "req", //Used by the client to identify type of communication
"req": "temp", //Used by the client to identify action
"device":"name", //Used by the client to check if relevant to this device -> if not set group needs to have a value
"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
"reqId" "uid" //Device will return this value in the response, Used by sender
}
//Response to sender
{
"type": "resp", //Used by the sender to identify type of communication
"device":"name", //Used by the sender to check if relevant
"group": "name", //Used by the sender to check if relevant
"resp": "temp", //Used by the sender to identify action
"value": 20.5, //Used by the sender to identify value
"unit": "C", //UOM
"reqId" "uid" //Used by the sender to match to request
}
State
Der Typ State wird verwendet damit das Ding selbständig Werte an einen Empfänger senden kann. Beispiel:
// Moisture sended every Minute
{
"type": "state", //Used by the receiver to identify type of communication
"device": "name", //Used by the receiver to check if relevant
"group": "name", //Used by the receiver to check if relevant
"category": "moisture", //Used to define type of measurement
"value": "50", //Value of changed state
"uom": "%" //UoM of value
}
// example when window is closed
{
"type": "state", //Used by the receiver to identify type of communication
"device": "window1", //Used by the receiver to check if relevant
"group": "name", //Used by the receiver to check if relevant
"category": "switch", //Used to define type of measurement
"value": "closed", //Value of changed state
"uom": "" //UoM of value
}
Typen
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.
Typen: