Eigentlich dachte ich mir, dass ich mittlerweile mit der DVG alles erlebt hätte, was man so erleben könnte. Und dann dies heute.
Ich zitiere:
…, da nur 2 Busse zur Verfügung stehen als Straßenbahnersatzverkehr
Immerhin sind sie ehrlich, aber alles was mir dazu ansonsten einfällt, gehört nicht in ein öffentliches Medium. Und nein, dafür habe ich kein Verständnis mehr. Bringt euren Laden endlich in Ordnung.
Für die Heim-Automatisierung stellt sich oft die Frage, ob etwas geöffnet oder geschlossen ist. Neben klassischen Szenarien wie eine Türe oder ein Fenster kann man natürlich auch den Briefkasten, eine Truhe oder ähnliches überwachen.
In den letzten drei Wochen haben ich verschiedene fertige Lösungen getestet. Alle Lösungen brauchen für den Empfang der Nachrichten bestimmte Empfangshardware.
| Model | Batterieart | Funkstandard | Nachrichtenarten | Preis |
|---|---|---|---|---|
| WOFEA 433 MHZ | CR 2032 (nicht enthalten) | 433 Mhz, dekodierbar durch RTL_433 | Open | 4€ |
| VBESTLIFE | AAA (enthalten) | 433 Mhz, dekodierbar durch RTL_433 | Open/Close | 4€ |
| Xiaomi Aqara Window Door Sensor | CR1632 (enthalten) | ZigbeeZigbee2MQTT mit einem geflashten TI-Zigbee-Dongle | Open/Close | 8€ |
Open: Es wird nur eine Nachricht gesendet, wenn der Kontakt unterbrochen wird
Open/Close: Es werden jeweils unterschiedliche Nachrichten gesendet, je nachdem ob der Kontakt unterbrochen wurde oder ob der Kontakt wieder hergestellt wurde.
Alle Modelle auf 433 Mhz senden Nachrichten nur bei Ereignissen (Unterbrechung bzw. Wiederherstellung des Kontakts) . Sie senden nicht in regelmäßigen Abständen ihren Zustand.
Das Zigbee Modell sendet jede Stunde eine Nachricht mit dem aktuellen Stand inkl. Batteriestand.
In den letzten Tage und Wochen habe ich mich etwas mit dem Thema beschäftigt, wie man mit Hilfe von Alexa (*) einen ESP8266 oder ESP32 ansteuern kann.
Da das Thema etwas unübersichtlich ist, hier mein Versuch das Thema zu strukturieren.
Grob kann man zwei Fälle unterscheiden:
| Simulation eines Gerätes | Externer Dienst |
| Vor- und Nachteile: | |
| 👍 Läuft ohne zusätzliche Dienste | 👎 externe Dienste und/oder Skills sind notwendig |
| 👎 Beschränkter Funktionsumfang (An, Aus, Prozent) | 👍 Größerer Funktionsumfang (siehe Funktionsumfang von Alex-Nachrichten) |
| 👍 Einfache Sprachebefehle | 👎 Vor dem Befehl, muss man Alexa mitteilen, welcher Skill genutzt wird “Alexa verwende XXX und …” |
|
Beispiele: |
|
| esp8266-alexa-wemo-emulator oder Fauxmoesp
Diese Lösung simuliert ein Belkin WeMo(*) Gerät. Der ESP kann 16 virtuelle Geräte/Funktionen bereitstellen. Leider nur mit An und Aus Funktionalität. |
Sinric
Diese Lösung erfordert eine Anmeldung und die Installation eines Skills. Danach werden diverse Geräte/Funktionen bereitgestellt. Z.B. können Ein- und Ausschalter, Lampen, Thermostate oder Fernseher bereitgestellt werden und dann über die passenden Sprachbefehle gesteuert werden.
|
| Espalexa
Espalexa simuliert eine Philips Hue Bridge (*). Der ESP kann 20 virtuelle Geräte/Funktionen bereitstellen. Neben An und Aus, unterstützt dieser Anzahl auch Helligkeitsstufen von 0% bis 100%.
|
|
Für mich hat der Funktionsumfang von “Simulation eines Gerätes” nicht gereicht. Ich wollte aber auch nicht neben Amazon noch einen zusätzlichen Dienstleister nutzen.
Ich habe mir also meinen Skill selber zusammengestellt. Da mir die AWS Lambda Function irgendwie nicht gefallen habe, habe ich mich für die Web-Service Variante entschiedenen. Hierbei werden die Informationen vom Skill an den eigenen Server weitergeleitet. Hierfür nutze ich im Moment eine ziemlich gepatchte Version von Alexa-PHP-Endpoint. Ich habe einige der Pull-Requests eingespielt und noch die eine oder andere Änderung vorgenommen.
Da ich Alexa für die Heim-Automatisierung nutze, werden die Daten direkt in MQTT gespeichert.