HAA Raven System Firmware für ESP Geräte

Ich löte nicht gern, weswegen ich auch gern fertige Module kaufe.

Für jene unter uns, die sich so etwas nicht vorstellen können, weise ich mal auf konkrete Produkte hin:

Solid State Relais (ohne Klick-klack) mit Ausgangsschaltungen für bis zu 380V 25A zum Schalten besonders leistungshungriger Elektrogeräte:

Optogekoppelt für weniger leistungshungrige Elektrogerätschaften mit bis zu 250V 10A, dafür gleich 8 Schaltkanäle in 1 Bauteil.

Jeweils mit (deutschen Händler-)Preisen im 1-stelligen Euro-Bereich

Zitat von loonypac

Solid State Relais (ohne Klick-klack)

Die Dinger sind robust und verschleißfrei - aber ohne galvanische Trennung. Daher habe ich sie bislang noch nicht verwendet. Was der Bauer nicht kennt... Außerdem hat das altmodische Klick-klack auch Vorteile. Fachkundige erkennen (wenn mal etwas nicht funktioniert) schon am Geräusch: Aha! Ansteuerung geht, Fehler liegt sekundärseitig oder eben umgekehrt. Und da wir gerade bei Fachkunde sind: Im Mittelspannungsbereich sollten nur jene herumkneten, die das mal gelernt haben. Wer fachkundig ist, weiß aber auch, daß die Shellys, Sonofs und wie sie alle heißen, die beworbenen Stromstärken von >10A nicht auf Dauer schalten werden. Kein Elektrogeselle käme auf die Idee, eine Waschmaschine oder einen Heizkörper mit einem Kleinrelais schalten zu wollen. Da wäre ein Schütz oder Solid State schon die bessere Wahl.

Zitat von loonypac

Optogekoppelt für weniger leistungshungrige Elektrogerätschaften

Hab von denen einen Vierer und mehrere Einer gekauft.

Klappern ohne Probleme.

Hey walta , der Gedanke, den Beitragstitel zu ändern, finde ich grundsätzlich sinnvoll.

Wenn du allerdings außer Edward J. Nately III und meiner bescheidenen Wenigkeit noch weitere HomeKit Freunde und Freundinnen in diesen deinen Beitrag locken willst, würde ich vorschlagen, den Titel etwas „spektakulärer“ zu gestalten. Etwa im folgenden Sinne:

„RavenSystem und ESP – Entwickelt eure eigenen HomeKit Geräte und Funktionserweiterungen!“

Oder so ähnlich

Es macht derzeit auch wenig Sinn, wenn ich das Thema als Konkurrenzveranstaltung mit eigenem Beitrag neu poste. Das würde aus nachvollziehbaren Gründen bestimmt auch nicht geduldet.

Nix für ungut, ist nur so‘n Gedanke

Um meine Homekit-Motorsteuerung umzusetzen, habe ich erst mal nach diesem Vorbild einen Shelly 2.5 nachgebaut. Das sieht bei mir jetzt so aus:

{
  "a": [{
    "t": 45,
    "o": 24,
    "c": 20,
    "f": 70,
    "0": { "r": [{ "g": 15, "v": 1 }, { "g": 4 }] },
    "1": { "r": [{ "g": 15 }, { "g": 4, "v": 1 }] },
    "2": { "r": [{ "g": 15 }, { "g": 4 }] },
    "3": { "r": [{ "g": 15, "i": 0.2 }, { "g": 4 }] },
    "4": { "r": [{ "g": 15 }, { "g": 4, "i": 0.2 }] },
    "f0": [{ "g": 5, "i": 1, "p": 1, "t":0 }],
    "f1": [{ "g": 13, "i": 1, "p": 1, "t":0 }],
    "f2": [{ "g": 5 }, { "g": 13 }]
  }]
}

Das "Rollo" öffnet in 24 sek und schließt in 20 sek

Das Öffnen-Relais hängt an GPIO 4 (Anschluss D2)

Das Schließen-Relais hängt an GPIO 15 (Anschluss D8)

Die Taste für das Öffnen hängt an GPIO 13 (Anschluss D7) mit PullUp-Widerstand

Die Taste für das Schließen hängt an GPIO 5 (Anschluss D1) mit PullUp-Widerstand

Das Ganze funktioniert sogar in Homekit aber es gibt (noch) Probleme:

Der D1mini bootet nur, wenn das Relais an D8 nicht angeschlossen ist. Da scheint es Rückwirkungen der Anschlüsse auf das Startverhalten zu geben. Zuppel ich den Draht ab und drücke Reset, bootet er. Dann kann ich den Draht wieder anstecken und die Steuerung funktioniert. Welche GPIOs sind denn intern reserviert und welche kann man für Relais und Taster bedenkenlos verwenden?

Außerdem ziehen die Relais im Ruhezustand an und fallen ab, wenn das Signal kommt. Umgekehrt wäre es mir lieber. Ich vermute, da muß mit "i": 1 noch invertiert werden. Aber wo? Hinter jedem "g"?

Dann noch eine letzte Frage: Bei meinen Shelly-Rollos stoppt der Motor, wenn ich die Tasten loslasse. Hier fährt der Antrieb ohne Halt bis zur jeweiligen Endposition. So braucht es einen extra Stop-Taster, den ich aber nicht einbauen will. Besser wäre die erstgenannte Variante, so daß der Motor nur so lange rödelt, wie man drückt.. Gibt es dafür eine Möglichkeit?

tnx/nately

Kurze Frage Zwischendrin:

Benutzt du für dein Projekt ein Shelly 2.5? Wenn ja, brauchst du das Ganze natürlich nicht mit einem D1 Mini umsetzen, sondern kannst das Shelly selbst umprogrammieren. Das Vorbild-Beispiel tut nämlich genau das.

Zitat von loonypac

Benutzt du für dein Projekt ein Shelly 2.5?

Nein, eben nicht. Der Shelly geht im Roller-Shutter-Modus nur mit 230 Volt. Ich brauche eine Lösung für Kleinspannung, da am Einsatzort der Motoren keine Netzspannung zulässig ist und nur 24V- zur Verfügung stehen. Daher käme mir eine Rollosteuerung per D1mini sehr gelegen. Ich hab für dessen Script nur die Syntax vom Shelly-Beispiel übernommen, um überhaupt erst mal einen Anfang zu finden. Das funktioniert ja auch - bis auf die o.g. Probleme.

Zitat von Edward J. Nately III

Das Ganze funktioniert sogar in Homekit

Was auch sonst Genau dafür ist RavenSystem gemacht

Wie gesagt, habe ich noch keine Motorsteuerung gemacht und kann bei deinem Projekt mehr oder weniger nur raten.

Zitat von Edward J. Nately III

Der D1mini bootet nur, wenn das Relais an D8 nicht angeschlossen ist. Da scheint es Rückwirkungen der Anschlüsse auf das Startverhalten zu geben. Zuppel ich den Draht ab und drücke Reset, bootet er. Dann kann ich den Draht wieder anstecken und die Steuerung funktioniert. Welche GPIOs sind denn intern reserviert und welche kann man für Relais und Taster bedenkenlos verwenden?

Nochmal: Nicht alle ESP8266 haben dieselben Spezifikationen! Das ist wichtig, wenn man Scripte von "fremden" ESPs für den eigenen nutzen möchte.

Genau dafür hatte ich die nachfolgende Tabelle der GPIOs vom D1 Mini als "Bread & Butter" Orientierung aufgelistet. Aus der wird ersichtlich, dass der D1 Mini NICHT booten kann, wenn GPIO 15 auf "high". Entweder du konfigurierst den noch weiter mehr oder weniger aufwändig um, oder wählst gleich der Einfachheit halber statt dessen GPIO 14 (D5), der keinerlei Einschränkungen für In und Out aufweist:

Zitat von Edward J. Nately III

Außerdem ziehen die Relais im Ruhezustand an und fallen ab, wenn das Signal kommt. Umgekehrt wäre es mir lieber. Ich vermute, da muß mit "i": 1 noch invertiert werden. Aber wo? Hinter jedem "g"?

Definiere "Ruhezustand"!

Probiere, wie gesagt, erstmal den GPIO 14 und ob das Relais immer noch standardmäßig eingeschaltet ist.

Zitat von Edward J. Nately III

Dann noch eine letzte Frage: Bei meinen Shelly-Rollos stoppt der Motor, wenn ich die Tasten loslasse. Hier fährt der Antrieb ohne Halt bis zur jeweiligen Endposition.

Nach meinem theoretischen Verständnis sollte das mit dem D1 Mini wie folgt über geänderte State Inputs in deinem Sinne funzen:

"f0":[{"g":5}],
"f1":[{"g":13}],
"f2":[{"g":5,"t":0},{"g":13,"t":0}]

Allerdings musst du dann die Taster bis zum vollständigen Öffnen/Schließen halten, da sie sofort nach dem Loslassen einen Stop-Befehl absenden.

Zitat von loonypac

Entweder du konfigurierst den noch weiter mehr oder weniger aufwändig um, oder wählst gleich der Einfachheit halber statt dessen GPIO 14 (D5)

Hab jetzt GPIO 5 (D1) und GPIO 4 (D2) für die Relais und GPIO 16 (D0) und GPIO 14 (D5) für die Taster genommen.

Damit funktioniert es.

Zitat von loonypac

Definiere "Ruhezustand

Das Relais soll ohne Signal nicht anziehen.

Des Rätsels Lösung lag nicht am D1-mini sondern am Verhalten des 4er-Relais-Moduls. Dessen Relais ziehen bei Low an und nicht bei High. Hab noch nicht herausgefunden warum. Auf der Platine kann man bis auf die Versorgungsspannung auch nichts umjumpern. Nehme ich die 1er-Relais-Module klappt es. Die ziehen bei High an.

Im übrigen sind diese Platinen auf der durchkontaktierten Seite ganz schlecht gelötet. An einem Pfostenstecker waren soger zwei Kontakte gebrückt. Zur Sicherheit werde ich die alle nachbraten.

Zitat von loonypac

Nach meinem theoretischen Verständnis sollte das mit dem D1 Mini wie folgt über geänderte State Inputs in deinem Sinne funzen

...

Allerdings musst du dann die Taster bis zum vollständigen Öffnen/Schließen halten, da sie sofort nach dem Loslassen einen Stop-Befehl absenden.

Nein, den Gefallen tut er mir nicht. Wenn ich die Taste loslasse rennt er weiter, drücke ich erneut, stoppt er und rennt weiter, wenn ich dann wieder loslasse. Das Script sieht jetzt so aus (incl. geänderter GPIOs):

{
  "a": [{
    "t": 45,
    "o": 24,
    "c": 20,
    "f": 70,
    "0": { "r": [{ "g": 5, "v": 1 }, { "g": 4 }] },
    "1": { "r": [{ "g": 5 }, { "g": 4, "v": 1 }] },
    "2": { "r": [{ "g": 5 }, { "g": 4 }] },
    "3": { "r": [{ "g": 5, "i": 0.2 }, { "g": 4 }] },
    "4": { "r": [{ "g": 5 }, { "g": 4, "i": 0.2 }] },
    "f0": [{ "g": 16 }],
    "f1": [{ "g": 14 }],
    "f2": [{ "g": 16, "t":0 }, { "g": 14 ,"t":0 }]
  }]
}

Zitat von walta

Das mit dem Rollladen mit 24V Motor wird im Shelly Forum immer wieder besprochen.

Hab im Forum gefragt und keine Antwort erhalten. Es scheint so zu sein, als ob die Shelly-HK-Firmware für Rollos und Rolläden beim Drehen die Stromaufnahme überwacht um "Obstacles" zu ermitteln. Strommessung geht aber nicht bei Kleinspannung. Daher soll nun der D1-mini Verwenung finden. Außerdem kann ich mit dem gleich vier Relais steuern und dazu noch vier Tasten anschließen.

Zitat von walta

Gibt es in der RavenWiki keine Beispiele für Rollladen?

Ja, gibt es. Ist allerdings für den Shelly 2.5 geschrieben. Kann man als Vorlage für den D1 nehmen, muß nur die GPIOs anpassen (siehe oben).

Zitat von Edward J. Nately III

Hab jetzt… GPIO 16 (D0) und GPIO 14 (D5) für die Taster genommen.

Damit funktioniert es.

Wobei GPIO 16 beim booten auf "high" gestellt wird. Wenn es trotzdem klappt, umso besser.

Ggf. ist da der Key "xa":0 als "Execution of Actions on Boot" von Nutzen, um schonmal beim Booten keinen ungewollten Schaltbefehl auszulösen.

Zitat von Edward J. Nately III

Des Rätsels Lösung lag nicht am D1-mini sondern am Verhalten des 4er-Relais-Moduls. Dessen Relais ziehen bei Low an und nicht bei High.

Das ist prinzipiell für das Script kein Problem. In dem Fall musst du für die Digitalen Outputs der Relais den Key "v" jeweils invertieren. Wir erinnern uns: "v": 0 = "low" | "v":1 ="high", wobei "v":0 ein Standard-Wert ist und im Code weggelassen werden kann bzw. wurde.

Also bspw. für deine Action "0" ergäbe das im "inversen" Sinne:

"0": { "r": [{ "g": 15 }, { "g": 4, "v": 1 }] }

Für alle weiteren Actions bis "4" muss das natürlich entsprechend invertiert werden.

Zitat von Edward J. Nately III

Nein, den Gefallen tut er mir nicht. Wenn ich die Taste loslasse rennt er weiter, drücke ich erneut, stoppt er und rennt weiter, wenn ich dann wieder loslasse.

Ich kann das wie gesagt nicht praktisch bei mir durchtesten, deswegen nächster theoretischer Versuch in der Annahme, dass nach deiner Beschreibung die Öffnen/Schließen-Actions "f0" + "f1" sowie die Stop-Action "f2" jeweils auf Tasterauslöser reagieren, also "t":1, was ebenfalls als Standardwert nicht eingegeben werden muss:

"f0":[{"g":16}],
"f1":[{"g":14}],
"f2":[{"g":16},{"g":14}]

Meine Annahme: Das erste Mal Taster klicken öffnet bzw. schließt je nach Taster. Während des Öffnen-/Schließenvorgangs Taster nochmal betätigen stoppt?!

Alternativ könntest du ausgehend von dem Beispielskript auch die integrierten Pull-Up-Widerstände der beiden GPIOs 0 + 2 für die Tasterschaltung nutzen (wobei die Eigenschaften der beiden GPIOs beachtet werden müssen). Umgesetzt mit dem D1 Mini ergäbe das für die State Input Codes:

"f0":[{"g":0,"i":1,"p":0,"t":0}],
"f1":[{"g":2,"xa":0,"i":1,"p":0,"t":0}],
"f2":[{"g":0 },{"g":2,"xa":0}]

Da der GPIO 2 des D1 Mini ebenfalls "high" beim Booten geschaltet wird, hab ich mal den besagten Key "xa" integriert, der womöglich aber auch weggelassen werden kann, da es ja bei deiner jetzigen Belegung mit GPIO 16 auch keine Probleme zu geben scheint.

Wäre interessant zu wissen, was bei diesem Setup schalttechnisch passiert

Zwei Fragen noch (damit ich es nicht nur abschreibe, sondern auch kapiere):

Wenn das Ereignis "t": 1 bedeutet, daß ein Taster geschlossen wird,

heißt dann "t": 0, daß der Taster wieder geöffnet wurde?

Auch aus einem anderen Beschreibungstext werde ich nicht schlau:

Zitat

"p": 1 - the internal pull-up resistor is enabled

Genau genommen heißt das doch, man muß mit dem Setzen dieses Wertes den entsprechenden GPIO gar nicht mehr mit einem externen Widerstand beschalten? Derzeit habe ich noch PullUps zu 10k an den Eingängen hängen. Daß es da auch internen Widerstand gibt, hab ich bislang geflissentlich überlesen. Oder verstehe ich das nur wunschdenkend?

Zitat von Edward J. Nately III

damit ich es nicht nur abschreibe, sondern auch kapiere

1. Press Type

So wie ich’s verstehe, löst der "t":1 (als im Skript weglassbarer Standardwert) über einen physikalischen Taster den berühmten "Single Press" aus, den wir ja aus zahlreichen HomeKit-Schaltern seit Jahren kennen. Dabei ist es egal, ob ich den Taster halte oder ihn loslasse. Ausschlaggebend für den Schaltbefehl ist über eine festgelegte kleine Zeitspanne ein "high" Impuls am GPIO.

Der Sonderfall des "t":0 ist leider nicht weiter erklärt als durch den Hinweis "Single press, opposite to 1", was also beim Loslassen des Tasters vermutlich den "low"-Impuls als Gegenteilschaltung sozusagen interpretiert bzw. toggled, was bei klassischen Schaltern mit Ein-/Aus-Status Sinn macht und was ich in meinem LED-Beispiel nochmal praktisch erklärt habe.

Die Press Type Sonderfälle 2 bis 5 "interpretieren" nur wie lange der Taster auf "high" gehalten wird. Je nach Halte-Länge wird das Ergebnis "Long Press", "Very long Press" und "Hold press during 8 seconds" für die jeweiligen definierten Schalträume als Schaltbefehl ausgegeben. Beim "Double" Press" vermute ich die Auswertung von 2 "high"-Impulsen innerhalb eines kurzen Messintervalls.

2. Interner Pull-Up Widerstand

Bei der recht knappen Dokumentation lässt der Hinweis "Depending on the hardware" zusammen mit dem Zusatz "Internal" vermuten, dass damit tatsächlich die internen und zwar NUR diese Widerstände in der Schaltlogik mit dem Key "p" de-/aktiviert werden können. Ein selbst wie auch immer angebrachter Widerstand lässt sich nach meiner Einschätzung durch diesen Key NICHT de-/aktivieren. Aber das könnte ein Versuch mit einfacher Schaltung genauer klären.

Zitat von loonypac

was also beim Loslassen des Tasters vermutlich den "low"-Impuls als Gegenteilschaltung sozusagen interpretiert

Hatte ich auch vermutet. Passt aber nicht zum Verhalten bei

"f2": [{ "g": 16, "t":0 }, { "g": 14 ,"t":0 }]

da will er bei Tastendruck bis Endposition fahren, was sich aber mit einem erneuten Schalten für die Dauer des Tastendrucks unterbrechen lässt. Also:

erster Tastimpuls - nimmt Fahrt auf in Richtung Endposition

zweiter Tastendruck - Pause und beim Loslassen Weiterfahrt

noch ne Tasterbedienung - dito

bis Endposition erreicht

Mit Deinem Vorschlag, also ohne "t": 0

"f2":[{"g":16},{"g":14}]

fährt er nach Tastendruck bis Endhaltestelle ohne sich durch weiteres Tasten noch irgendwie beeindrucken zu lassen.

Zitat von loonypac

Ein selbst wie auch immer angebrachter Widerstand lässt sich nach meiner Einschätzung durch diesen Key NICHT de-/aktivieren.

Klarer Fall, die kann man dann nur weglassen. Frage ist halt, ob denn der D1-mini interene PullUps verfügbar hat, um sie mit "p": 1 aktivieren zu können.

***********************************************************************************************

Edit: Ich habs!

So muss es aussehen:

    "f0": [{ "g": 16, "t":0  }],
    "f1": [{ "g": 14, "t":0  }],
    "f2": [{ "g": 16 }, { "g": 14 }]

Das ist schon merkwürdig und ist nur durch eine eigene Schaltlogik für den Window Covering Service zu erklären.

Was passiert, wenn du die Stopp-Action versuchsweise mit Doppelklick Press Type "t":2 festlegst? Immerhin sind dann Öffnen/Schließen und Stoppen mit grundsätzlich anderen Press Types definiert.

Wie bereits mehrfach beschrieben und in der Tabelle ersichtlich, hat der D1 Mini besagte interne Pull-Ups bei den GPIO 0 + 2.

Es bleibt also noch der besagte Versuch, das Original-Skript für Shelly 2.5 auf D1 Mini umzusetzen oder ein Umweg über virtuelle (Zwischen)Schalter, die die besagten State Inputs des Scripts auslösen und ihrerseits mithilfe der bereits mehrfach vorgestellten "Service Notifications" aus meinen Beispielen über deine Taster geschaltet werden.

Sehe ich grad erst:

Für deinen Fall bieten sich statt "f0", "f1" und "f2" vielleicht eher die Toggle-Varianten "f3" und "f4" an?!

Das könnte mit besagten Press Types 1 und 0 in deinem Sinnen funzen?!

"f3":[{"g":5},{"g":5,"t":0}],
"f4":[{"g":13},{"g":13,"t":0}]

Siehe späteres Edit im letzten Posting.

Es funktioniert jetzt! (hüpf... jubel...)

Hab es so ähnlich geändert, wie in Deinem zweiten Vorschlag.

Super!

Das mit den PullUps ist nur noch zweitrangig. Ich lass erst mal die externen Widerstände dran.

HomeKit hält sich einen Wachhund und begrüßt und verabschiedet beliebige Netzwerkteilnehmer

Wer schon immer mal Automationen in HomeKit ausführen lassen wollte, die durch die Netzwerk-Präsenz bzw. Nicht-Präsenz beliebiger Netzwerkteilnehmer sowohl ausgelöst als auch bedingt werden, kann im Folgenden erfahren, wie dies sehr unaufwändig in wenigen Minuten durch ein RavenSystem Script in HomeKit "eingebaut" werden kann.

Eine von vielen Spezialitäten des RavenSystems sind seine ICMP Ping inputs, die durch ihren Namen richtigerweise vermuten lassen, dass damit etwas im Netzwerk angepingt werden kann.

Für die Erscheinungsform des Hundesteuer befreiten HomeKit-Wachhunds und für seine Abrichtung, wann er anschlägt, müssen wir lediglich einen geeigneten Service Type auswählen und ihm entweder die IP-Adresse(n) der zu beobachtenden Gerätschaft(en) oder – falls verfügbar – alternativ deren DNS Namen mitteilen.

Ich fange wieder mit einem minimalen Ausgangsscript an:

{"a":[{"t":1}]}

Den damit erzeugten simplen An-/Aus-Schalter hatten wir ja bereits mehrmals. Diesmal soll er sich wie von Geisterhand selbsttätig einschalten, wenn sich ein bestimmter Netzwerkteilnehmer im lokalen Netz anmeldet, um sich gleichermaßen automatisch auszuschalten, nachdem derselbe Teilnehmer sich wieder abgemeldet hat.

Zuvor muss ich in der Regel im benutzten heimischen Router einmal nachschauen, welche Geräte sich da so im LAN und WLAN tummeln, um eine Auswahl zu treffen, auf welches Schätzchen wir unseren Wachhund scharf machen.

Am Beispiel einer Fritz!Box finde ich unter Heimnetz -> Netzwerk eine geeignete Übersicht, aus der ich mir mal meinen Samsung TV heraussuche. Derselbe kann über 2 Wege vor die Nase des Netzwerk-Wachhundes gehalten werden: Einerseits über seine IP-Adresse (also bspw. 192.168.178.36) oder über seinen in der Übersicht angegebenen (DNS)Namen (also bspw. "Samsung-TV").

Nun muss ich dem ESP mitteilen, was er wann macht, also wann er sich ein- und ausschalten soll, um dadurch in HomeKit seinerseits Automationen auszulösen. Die Keys "p0" + "p1" tun genau dies in der folgenden Form:

{"a":[{"t":1,"p0":[{"h":"Samsung-TV","r":0}],"p1":[{"h":"Samsung-TV","r":1}]}]}

Die Keys "r" bestimmen die Netzwerkantwort des TV also: TV antwortet nicht = "r":0 oder TV antwortet = "r":1. Da letzterer Wert wiederum ein Standardwert ist, kann er aus dem Code entfallen:

{"a":[{"t":1,"p0":[{"h":"Samsung-TV","r":0}],"p1":[{"h":"Samsung-TV"}]}]}

Wie man gut erkennen kann, habe ich mich für den DNS-Namen entschieden, was den folgenden Vorteil hat:

Sollte der Router seinen Teilnehmern IP-Adressen dynamisch vergeben, können die sich natürlich willkürlich verändern und damit unseren Wachhund austricksen, der dann nicht mehr anschlägt, während der Name davon unabhängig bestehen bleibt.

Ich entscheide mich dennoch für die Eingabe von IP-Adressen und vermeide diese Adressen-Veränderung über die Möglichkeit, dem Router ein für alle mal mitzuteilen, dass er dem ausgewählten Netzwerkteilnehmer "immer die gleiche IPv4-Adresse zuweist", was ohnehin zumindest für alle SmartHome Gerätschaften dringend zu empfehlen ist. Dadurch kann ich besonders auch jene Geräte überwachen, die sich ohne Weiteres über einen (DNS)Namen nicht anpingen lassen, wie z.B. die geliebeten iPhones, iPads dieser Welt.

Genau dies habe ich nun für mein Samsung TV festgelegt, sodass ich den Code nun mit gleicher Funktion in eine IP-Adresse ändern kann:

{"a":[{"t":1,"p0":[{"h":"192.168.178.36","r":0}],"p1":[{"h":"192.168.178.36"}]}]}

Den HomeKit-Schalter selbst kann ich dann natürlich vielsagend benennen bspw. in "Samsung TV LAN", um nicht jedesmal raten zu müssen, welche IP welchem Gerät entspricht.

So, der Wachhund ist somit auf mein Samsung TV abgerichtet und schaltet immer brav den Schalter ein, wenn sich das Gerät im Netzwerk anmeldet und genauso brav aus, wenn sich der Fernseher für eine gute Nacht aus dem Netzwerk abmeldet.

Nun könnte man im Fall des TV, der ohnehin an einer smarten Steckdose hängt, auf eine Netzwerküberwachung verzichten und den Schaltzustand der Steckdose für Automationen nutzen. Es soll aber tatsächlich noch Menschen geben, die ihre TVs im Standby-Modus belassen und schon macht unser Wachhund wieder Sinn.

Des Weiteren kann ab sofort jedes netzwerkfähige Gerät vom Laptop bis zum Drucker, egal ob per LAN oder WLAN verbunden, in HomeKit verschiedenste Automationen auslösen oder bedingen, was die Möglichkeiten der Hausautomation in HomeKit doch beträchtlich bereichern kann.

Zudem kann man die Automationen soweit präzisieren, dass bestimmte Verbindungen unterschiedlich schalten. Ist mein iMac bspw. sowohl mit LAN als auch mit WLAN, dies noch dazu wahlweise im 2,4 oder 5 GHz, verbunden, kann jede einzelne Verbindung mit separatem Schalter überwacht werden – alles durch 1 kleinen ESP! Wie wir wissen, können wir die Wachhund-Abrichtung auf spezifische Netzwerkteilnehmer in Form weiterer Schalter dadurch schnell erweitern, indem wir den Grundcode für den ersten Schalter kopieren und durch Kommatrennung jeweils anhängen, um letztlich nur noch die Adressen für die einzelnen Teilnehmer zu ändern.

Somit sollten die wichtigsten, um nicht zu sagen alle Netzwerkgerätschaften direkt in der Home App mit ihrem jeweiligen Status angezeigt werden können und beliebige HomeKit-Automationen auslösen.

Ich bleibe bei dem Einzelschalter-Beispiel für mein TV und erweitere das Script um die Funktion, dass der ESP über seine eingebaute LED den Status des Fernsehers anzeigen und aufleuchten soll, sobald der Fernseher online ist.

Hierfür habe ich bereits in meinem Beitrag zur selbstgebastelten HomeKit-Lampe alles Nötige erklärt, weswegen ich gleich den vorherigen Code wie folgt ergänze:

{"a":[{"t":1,"0":{"r":[{"g":2,"v":1}]},"1":{"r":[{"g":2}]},"p0":[{"h":"192.168.178.36","r":0}],"p1":[{"h":"192.168.178.36"}]}]}

Aufmerksam Lesende stellen sich vielleicht die Frage: Zwar habe ich einen automatisch schaltenden Schalter, nichtsdestotrotz kann ich denselben sinnloserweise weiterhin auch manuell schalten und "verfälsche" dadurch womöglich ungewollt den tatsächlichen Status?!

Ich würde entgegnen: Das stimmt, kann passieren, dafür hast du auf der anderen Seite auch eine schnelle Möglichkeit, deine HomeKit-Automationenen zu testen, ohne jedesmal die einzelnen Netzwerkteilnehmer umständlich an- und abmelden zu müssen.

Wer trotzdem keinen Wachhund in Schalterform haben möchte, sondern die Einweg-Variante vorzieht, nur Schaltbefehle auszugeben, ohne manuelle Inputs zu haben, kann sich nun einen geeigneten Service Type in diesem Sinne erwählen.

Ich persönlich halte dafür den Kontaktsensor "t":5 als geeignet. Noch dazu lässt dieser Popup-Messages zu, die zwar nicht unbedingt mit einer Nachricht wie bspw. "TV Samsung: geöffnet" die Realität widerspiegeln, sprachlich Begabten dennoch einen überschaubaren Interpretationsraum bieten – zumal in der Erkenntnis, dass man von Netzwerkaffinen Wachhunden nicht auch noch sprachliches Feingefühle erwarten kann {dies noch dazu in Apple HomeKit}.

Der Kontaktsensor ist prinzipiell nichts anderes als ein Spezialschalter, weswegen in RavenSystem nahezu die identischen Codes gelten und wir für ein Wachhund-Outfit in Sensor-Anmutung einfach nur das "t":1 durch ein "t":5 ersetzen müssen, das war’s schon:

{"a":[{"t":5,"0":{"r":[{"g":2,"v":1}]},"1":{"r":[{"g":2}]},"p0":[{"h":"192.168.178.36","r":0}],"p1":[{"h":"192.168.178.36"}]}]}

Zitat von walta

Bei mir laufen, über Raven, 5 Stück 18b20er auf einem Pin - mehr hatte ich gerade nicht da zum probieren

Walta

Hallo,

was ist Raven? und wie hast Du über Homebridge in Apple HK gebracht?

Hm, eigentlich hatte ich dir Mighty61 eine Antwort gegeben, wie du deine Sensoren mit RavenSystem in HomeKit einbindest. Die Antwort wurde offensichtlich (warum auch immer) gelöscht

Also nochmal: du musst deinen ESP umflashen und dann das Beispielscript mit dem von dir benutzten GPIO umändern. Fertig!

Alles Grundsätzliche kannst du hier in diesem Beitrag nachlesen. Ich habe mir die Mühe gemacht, vieles zum Thema möglichst ausführlich zu dokumentieren (siehe auch meine Signatur)