Diese Seite beschreibt die APIs & Datenformate, mit denen mit den Geräten über den smart-home-control Server kommuniziert werden kann. Für die allgemeine socket.io API siehe smart-home-control.

Table of Contents

smart-home-control selbst

Der smart-home-control Server hat ein paar spezielle Funktionen, hauptsächlich um Geräte/Services zu starten/stoppen und deren Status zu erfahren.

Daten

Auf dem Kanal status wird je Gerät der Gerätestatus ausgegeben, z.B.: 

"status": {
    "mikrofon": {
        "verfuegbar": true,
        "status": "an",  // "an", "aus", "startet", "stoppt"
        "msg": null,  // optional
    },
    // ...
}

Events / Funktionen

  • Geräte, die den Status false haben, können mit status:anschalten und dem Gerätenamen als Argument gestartet werden.
  • Geräte, die den Status true haben, können mit status:ausschalten und dem Gerätenamen als Argument gestoppt werden.
  • Mit status:update und dem Gerätenamen sowie neuen Status kann der Status geupdated werden.
  • neustart (noch nicht implementiert) veranlasst das Neustarten aller zentralen Komponenten im Smart Home
  • herunterfahren (noch nicht implementiert) fährt alle Geräte im Smart Home (soweit möglich) herunter

In dem zu einem Gerät gehörenden Kanal können nur dann Events gesendet oder empfangen werden, wenn das Gerät den Status true hat, also eingeschalten ist.

Mikrofon (Sprachsteuerung)

Das Mikrofon läuft als eigener User-Level Service auf dem gleichen Raspi wie das smart-home-control.

Daten

"mikrofon": {
    // Die Satz-ID zählt die von der Spracherkennung erkannten "Sätze" hoch, um
    // zu erkennen wenn ein neuer Satz begonnen hat.
    "satz_id": 0,
    // Spracherkennungs-Text des aktuellen Satzes
    "text": "",
    // true falls ein Befehl im aktuellen Satz erkannt und ausgeführt wurde.
    // Das dient dazu, dass Dinge nicht mehrfach ausgeführt werden.
    "ausgefuehrt": false,
}

Events / Funktionen

  • mikrofon:ausgefuehrtSetzen mit der Satz-ID als Argument setzt den aktuellen Satz auf 'ausgeführt' (falls er überhaupt noch aktiv ist)

Shellies (Steckdosen + vllt. mal Thermostat)

Weil die Shellies alle sehr ähnlich über MQTT gesteuert werden, gibt es einfach ein Service, der alle Shelly Geräte bündelt (ob Steckdosen oder Thermostat) und zu Socket.io bridged. Bekannte Geräte können anhand ihrer Hardware-ID/MAC erkannt werden, und haben dann einen praktischeren Namen. Welche das sind, wird in der Shelly Bridge Config festgelegt.

Daten

Die Daten zu Steckdosen werden im Kanal steckdosen gebündelt: 

"steckdosen": {
    "meine-shelly-steckdose": {
        "name": "Steckdose Küche (mit Strommessung)",  // Wird in der Bridge Config gesetzt
        "mac": "98CDAC2FF800",  // bei unbekannten Geräten wird die MAC als Kanalname genommen
        "ip": "192.168.178.49",
        "bekannt": true,  // Falls die MAC bekannt ist
        "verbunden": true,
        "an": false,    // Ob Strom an der Steckdose eingeschalten ist
        "leistung": 0,  // Falls verfügbar die aktuelle Leistung in Watt
    },
    // weitere Steckdosen
}

Der Status der MQTT Bridge wird im status Kanal unter shellies zur Verfügung gestellt.

Events / Funktionen

  • steckdosen:anschalten mit der Steckdosen ID als Argument schaltet eine Steckdose ein,
  • steckdosen:ausschalten mit der Steckdosen ID als Argument schaltet eine Steckdose aus.

Achtung: Mit status:anschalten/ausschalten "shellies" (siehe oben), startet/stoppt man nur die WebSocket/MQTT Bridge zu den Shellies.

SensFloor

SensFloor Events werden über einen eigenen User-Level Service auf dem gleichen Raspi wie das smart-home-control empfangen und verarbeitet. Außerdem steuert dieser Service den SensFloor über dessen API (ein/ausschalten).

Daten

{
    aktivitaet: true,  // Ob Personen auf dem SensFloor sind
    sturzalarm: true,  // Ob gerade eine gestürzte Person erkannt wird
    // Für verschiedene Bereiche des SensFloor, ob dort eine Person ist / steht
    bereiche: {
        irgendwo: true,
        kueche: false,
    },
    verbunden_care_api: true,  // Ob mit der Care API verbunden (eher allgemeine Dinge)
    verbunden_room_api: true,  // Ob mit der Room API verbunden (Positionen von Personen, Sturzalarme etc.)
}

Die Bereiche lassen sich über den SensFloor Service konfigurieren.

Events / Funktionen

  • sensfloor:service-anschalten schaltet den SensFloor Service (der zuständig für die Events ist) ein,
  • sensfloor:service-ausschalten schaltet den SensFloor Service aus.
  • (sensfloor:anschalten schaltet den SensFloor selbst über dessen API an,)
  • (sensfloor:ausschalten schaltet ihn über dessen API aus.)

Die letzten beiden Events sind in Klammern, weil man die auch über status:anschalten "sensfloor" aufrufen kann (was etwas einheitlicher zur restlichen API ist).

Fenstersensor

Um das Fenster kümmert sich ein simples Python Skript, das auch auf dem smart-home-control Raspi als Skript läuft.

Daten

"fenster": {
    // null heißt, das (noch) nicht bekannt ist, ob das Fenster
    // offen ist, oder ob der Schalter überhaupt angeschlossen
    // wurde. Nur wenn das Fenster zu ist (Schalter geschlossen)
    // kann gleich beim Start erkannt werden, dass der Schalter
    // verbunden ist.
    "offen": null,  // sonst: true, false
},

Events / Funktionen

keine (außer ein/ausschalten über status:fenster wie ganz oben beschrieben)

Sturzkamera

Die Sturzkamera läuft auf einem anderen Raspi, der oben an der Decke befestigt ist, aber auch dort als Service. Mithilfe von der KI PoseNet kann die Kamera Personen und deren Pose erkennen.

Daten

"sturzkamera": {
    "bild": "/cache/sturzkamera-posenet.jpg",  // Der Pfad zum Abrufen des aktuellsten Bilds
    "bildPoseNet": "/cache/sturzkamera-posenet.jpg",  // Der Pfad zum Abrufen des aktuellsten Bilds mit überlagerter PoseNet Erkennung
    "letzter_timestamp": null,  // (Unix) Timestamp der letzten Aufnahme in Millisekunden
    "fehler": false,  // Ob bei der letzten Aufnahme ein Fehler aufgetreten ist
},

Events / Funktionen

  • keine

Wärmekamera

Die Wärmekamera läuft aktuell auf dem gleichen Raspi wie die Sturzkamera und filmt aus der gleichen Perspektive (allerdings mit einem anderen Öffnungswinkel).

Daten

"waermekamera": {
    "bild": null,  // Der Pfad zum Abrufen des aktuellsten Bilds
    "letzter_timestamp": null,  // (Unix) Timestamp der letzten Aufnahme
    "T_max": 25.3,  // Temperatur des wärmsten Pixels in der letzten Messung
},

Events / Funktionen

  • keine

Kühlschrank

Der Kühlschrank ist nochmal ein wenig komplizierter, weil dort gleich drei Raspi Zeros sind. Nur einer davon hat ein Sensor, um den Tür Öffnungswinkel zu messen. Deswegen werden die einzelnen Felder von verschiedenen Skripten unabhängig geschrieben.

Daten

"kuehlschrank": {
    // Vom "Winkelsensor"-Skript geschrieben
    "offen": true,
    "winkel": 30,  // Geschätzte 30° Öffnungswinkel
    // Von den Kameraskripten geschrieben, die jeweils beobachten wie sich der Winkel ändert
    "bilder": {
        // Jeweils: Pfad zum Abrufen und Unix Timestamp der letzten Aufnahme
        "innen_unten": { pfad: "/cache/kuehlschrank_innen_unten.jpg", timestamp: 16... },
        "innen_oben": { pfad: "/cache/kuehlschrank_innen_oben.jpg", timestamp: 16... },
        "aussen": null,
    },
    // Vom Bilderkennungsskript geschrieben
    "bilderkennung": {}  // tbd
}

Events / Funktionen

/

Sturzalarm

Der Sturzalarm ist wie eine Art "virtuelles Gerät", das als Plugin läuft, und sich um das Senden von Sturzalarmen kümmert. Es ist kein Teil vom SensFloor, damit es ein eigener Kanal ist, und um die Logik dahinter etwas zu trennen (Der SensFloor erkennt Sturzalarme, aber dieses Plugin kümmert sich um das Senden).

Daten

"sturzalarm": {
    "alarm": false,
}

Events / Funktionen

  • sturzalarm:ausloesen ohne Argumente löst ein Sturzalarm aus, falls noch keiner ausgelöst wurde,
  • sturzalarm:beenden ohne Argumente beendet den aktuellen, falls noch einer aktiv ist.

Web-Push

Web-Push ist wie der Sturzalarm auch eine Art "virtuelles Gerät", das als Plugin läuft, und sich um das Senden von Push-Benachrichtigungen kümmert. Aktuell betrifft das nur den Sturzalarm.

Daten

Keine

Events / Funktionen

  • push-api:senden sendet eine Web-Push Benachrichtigung an alle bekannten und berechtigten Geräte mit dem Sturzalarm,
  • push-api:aufheben updated bei Bedarf die Benachrichtigungen, falls der Sturzalarm aufgehoben wurde.