API

GET /docs/features/api

💻 API

Lichtsteuerung & Wecker

Es gibt eine eigens entwickelte API für die Lichtsteuerung und den Wecker.

Unit-Tests

Die API besitzt eigene Unit-Tests zur Gewährleistung der Funktionalität. Zum ausführen der Tests einfach Das Kommando pytest unterhalb des Verzeichnisses /src/api ausführen.

Endpunkte

GET: /alarm

Liefert ein Array aller gespeicherten Wecker.

[
    {
        "id": 0,
        "hours": 11,
        "minutes": 11,
        "active": 1,
        "sound": 1
    }
]

POST: /alarm

Speichert einen Wecker in der Datenbank. Sollte bereits ein Wecker mit der ID existieren, wird dieser ersetzt. Als Rückgabewert erhält man alle Wecker, die nach dem Speichern in der Datenbank stehen. Folgende Eingabeparameter werden erwartet:

Request Parameter

Key Datentyp Beispiel
id (required) Integer 0
hours (required) Integer 11
minutes (required) Integer 11
active (required) 0 oder 1 1
sound (required) Integer 1

Response

[
    {
        "id": 0,
        "hours": 11,
        "minutes": 11,
        "active": 1,
        "sound": 1
    }
]

DELETE: /alarm

Löscht einen Wecker aus der Datenbank. Als Rückgabewert erhält man alle Wecker, die nach dem Löschen in der Datenbank stehen. Folgende Eingabeparameter werden erwartet:

Request Parameter

Key Datentyp Beispiel
id (required) Integer 0

Response

[
    {
        "id": 0,
        "hours": 11,
        "minutes": 11,
        "active": 1,
        "sound": 1
    }
]

POST: /alarm/stop

Stoppt den Alarm anhand der mitgelieferten ID. Folgende Eingabeparameter werden erwartet:

Request Parameter

Key Datentyp Beispiel
id (required) Integer 0

Response

"success"

POST: /alarm/sound

Setzt den Weckton für einen bestimmten Wecker. Achtung Der Weckton gilt nur für diesen Wecker. Sollte der Wecker gelöscht werden und ein neuer erstellt werden, erhält dieser wieder den Weckton mit dem Wert 1. Folgende Eingabeparameter werden erwartet:

Request Parameter

Key Datentyp Beispiel
id (required) Integer 0
sound (required) Integer 2

Response

"success"

/lights/set

Der Endpunkt erwartet einen POST-Request mit einem JSON Objekt, welcher eine vordefinierte Form haben muss.

{
    "friendly_name": "living_room",
    "payload": {
        "state": "ON",
        "brightness": 255,
        "color": "#55ffaa"
    },
    "feedback": {
        "text": "Okay ich ändere das Licht im Wohnzimmer"
    }
}

friendly_name und payload sind hierbei die erforderlichen Attribute. Die Attribute unter payload sind hierbei frei wählbar.

Aus dem Request wird ein MQTT-Publish auf das Topic zigbee2mqtt/<friendly_name>/set mit der jeweiligen Nachricht, die im payload Objekt definiert ist. Nachdem der Publish ausgeführt wurde, wird ein entsprechender Feedback-Text über Text-To-Speech ausgegeben.

Die Schnittstelle ist sehr flexibel einsetzbar, denn sie ist nicht restriktiv.

/lights/set/raw

Der Endpunkt erwartet einen POST-Request mit einem JSON Objekt, der entsprechend von Rhasspy erzeugt wurde. Wichtig ist hierbei hauptsächlich, dass entities entsprechend den Erwartungen der Schnittstelle entspricht.

"entities": [
        {
            "entity": "room",
            "value": "living_room",
            //[..]
        },
        {
            "entity": "state",
            "value": "on",
            //[..]
        },
        {
            "entity": "brightness",
            "value": 255,
            //[..]
        },
        {
            "entity": "color",
            "value": "#ffffff",
            //[..]
        }
    ]
//[..]

Die Schnittstelle erstellt aus dem Request eine kompatible MQTT-Nachricht, die dann im jeweiligen Topic gepublished wird. Danach wird ein entsprechender Feedback-Text über Text-To-Speech ausgegeben, der den eingesprochenen Text wiederholt.