Datenbus

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 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/livingroom/temperature
  • /space/woodworkshop/temperature
  • /space/meetingroom/temperature
  • /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.

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:

  • Licht → an oder aus
{
//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:

  • Abfrage einer Raumtemperatur
//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:

  • zykliches Übermitteln der Luftfeuchte für Trenddaten
// 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
}
  • wenn Fenster auf oder zu detektiert wird
// 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
}