Wenn du mit 5 und 6 die GPIOs meinst (D1 Mini hat übrigens keinen GPIO 6), probiere:
{"a":[{"t":22,"g":5,"n":3},{"t":22,"g":6,"n":3}]}Wenn du die D1 Mini Beschriftung D5 und D6 meinst, dann:
{"a":[{"t":22,"g":14,"n":3},{"t":22,"g":12,"n":3}]}Wenn du beide Sensoren an einen GPIO anschließen willst (bspw. GPIO 14), dann
{"a":[{"t":22,"g":14,"n": 3},{"t":22,"g":14,"n":3,"u":2}]}Wurde hier schon erwähnt. Ist komplizierter als Raven, dafür nochmal flexibler…
Ja, damit kann man dann tatsächlich ALLES nativ HomeKit machen. Das hatte/hab ich wie gesagt mit den VL53L1X vor.
Zusätzlicher Vorteil ist die Unterstützung der ESP32 Mikrokontroller. Die sind leistungsfähiger und bieten Zusatzoptionen gegenüber ihren Vorgängern, den ESP8266.
Weiterer Vorteil: Sollte man es irgendwann schaffen, die eigene Komfortzone zu verlassen, um auf sowas freundlich winkendes wie z.B. Home Assistant umzuschwenken, kann man den Großteil der ESP-Programmierung übernehmen, um "nur" den HomeKit-Anteil durch ein anderes Kommunikationsprotokoll zu ersetzen.
Ich werde bei Gelegenheit eine Übersicht vorbereiten, in der alle ESP-HomeKit-Projekte zentral aufgeführt sind. Schließlich gibt es neben HomeSpan auch noch das von mir bereits erwähnte ESP-HomeKit-ADK, das ebenfalls ESP32 unterstützt. Daneben auch noch weitere, die mehr oder weniger aufwändige native HomeKit-Programmierungen zulassen. Die können wir dann ja mal sammeln und auswerten.
Außerdem kann ich kein C programmieren und wäre wie ein Scriptkiddie auf copy & paste angewiesen.
Die Programmierung in C ist halb so schlimm (und macht viel mehr Spaß als Terminalbefehle 
). Für die überwiegende Zahl an Gerätschaften gibt es sehr hilfreiche Beispiel-Bibliotheken, die man dann für die eigenen Anforderungen ändert/erweitert.
In der Ardurnio-Referenz findet man außerdem alles, was man für diese Anforderungen so braucht. Immerhin reden wir hier nur von einfachen SmartHome-Schaltungen und nicht von KI-Robotern oder Mars-Sonden.
Auch wenn Du im Setup-Mode zuvor ein Remove WiFi Settings angewählt hast? Ich hatte vermutet, dann könne man das Ding mit jungfräulicher WLAN-Einstellung einfach weitergeben?
Du hast vollkommen recht: Das war natürlich völliger Unsinn meinerseits (Halbwissen rules). Hab’s inzwischen korrigiert. Dadurch werden in der Tat die Zugangsdaten gelöscht und die Default-ID-Adresse 192.168.4.1:4567 wiederhergestellt. 
Hey cool, man lernt doch immer wieder dazu. HomeSpan war mir noch gar kein Begriff. Da muss ich auch mal reinschnüffeln, insbesondere für den eben beschriebenen VL53L1X würde sich das womöglich anbieten 
RavenSystem läuft derzeit nur mit ESP8266. Die sind nicht so leistungsfähig wie die ESP32, für die HomeSpan ausgelegt ist, weswegen ich mich grad frage, wie du das dann mit einem D1 Mini hinbekommen hast 
In RavenSystem gibt es nur vorgefertigte Services, die du dann für deinen Servo "umdenken" müssest. Z.B. könnte Type 40 "Garage Door" oder Type 45 "Window Covering" dich für dein Vorhaben weiterbringen?! Bei Letzterem kann dir sicherlich Edward J. Nately III helfen, der das jüngst erfolgreich für sein Motorsteuerung-Projekt umgesetzt hat.
Was das Weitergeben betrifft, geht das insoweit, als du das Projekt über dein Netzwerk vollenden kannst und dem (vertrauensvollen) Menschen, der das übernehmen soll, mitteilst, dass er im Setup-Mode das "Remote WiFi Settings" Feld aktiviert und sich unter "Search WiFi" sein eigenes Netzwerk einrichtet. Vertrauensvoll deshalb, weil bei der Weitergabe erstmal dein WLAN-Zugang im ESP gespeichert ist.
Edit: Der vorherige Absatz war natürlich kompletter Unsinn, deswegen nachfolgend die Korrektur.
Das Weitergeben eines selbst erstellten Raven ESP an beliebige Dritte kann man sehr gut dadurch einrichten, indem man nach Fertigstellen des Scripts in der eigenen Netzwerk-/HomeKit-Umgebung im Setup-Mode das Feld "Remote WiFi Settings" aktiviert und mit "Save" bestätigt.
Dadurch wird der eigene Netzwerkzugang im ESP gelöscht und derselbe auf seine Default IP-Adresse 192.168.4.1:4567 zurückgesetzt. Der neue Nutzer kann sich auf diesem Accesspoint dann anmelden, um seinen eigenen Netzwerkzugang einzugeben und mit "Save" abzuspeichern.
Es kann zusätzlich zum Auswählen von "Remove WiFi Settings" sicherlich nicht schaden, ebenfalls das "Reset HomeKit ID" zu aktivieren, bevor man einen ESP weitergibt.
Hier ist ein sehr informativer Vergleich verschiedener Radar-Sensoren.
Solch ein Sensor allein wird wahrscheinlich nur begrenzt zielgerichtet funktionieren, da er bspw. auch durch Fensterscheiben detektiert. Die kluge Kombination mit Geräusch- und IR-sensor könnte das gewünschte Schaltergebnis verbessern.
Prinzipiell würde ich auch gerne einen Time of Flight Sensor VL53L1X verwenden nach diesem Prinzip.
Der Sensor liegt hier schon rum, wird leider von Raven nicht direkt unterstützt. Man könnte aber die Steuerung über einen separaten ESP regulär über Arduino IDE vorbereiten, um dann nur noch Zählimpulse für das rauf- und runterzählen auf einen Raven-ESP per GPIOs weiterzuleiten. Ich hab das vor Jahren erfolgreich mit dem Vorgänger-Sensor VL53L0X hingekriegt, den ich in doppelter Anordnung auslesen ließ. Leider ballerten die beiden Sensoren zeitweise zuviel Output auf den ESP, was zu Fehlergebnissen führte. Der VL53L1X kann als einzelner Sensor 2 Messzonen im Sensor auswerten, was den ESP entlasten und die Programmierung enorm vereinfachen sollte.
Als nächstes steht ein kombinierter Sensor aus Temperatur, Luftfeuchte, Licht und Anwesenheit (Radarwellensensor) auf dem Programm. Ist doch super, wenn man sich eierlegende Wollmilchsäue mit geringstem Futtermitteleinsatz selbst züchten kann.
Genau sowas sind u.a. auch meine Anwendungsziele. Mehrere hochwertige Sensoren in einer ESP-Schalte kombinieren und dann eigene neue Ufer betreten, ohne immer warten zu müssen, bis ein Anbieter was rausbringt.
Traumhaft sind in dem Zusammenhang auch die Preise für die einzelnen Komponenten. Ein D1 Mini für schlanke 4,30 €, Doppelradarsensor Mikrowelle 5,45 €, Lichtsensor 4,85 €, 5x Temperaturfühler 6,35 €…
Evtl. hätte ich meinen Post mit mehr Puderzucker versehen sollen.
Bitte mit Sahne oben drauf. Wir sind alle kleine Sensibelchen 
Thema „stören“: Ich habe diesen Thread nicht geblockt. Stört mich auch nicht.
Das freut mich zu lesen
Lese den aber kopfschüttelnd, weil ich das meiste nicht verstehe.
… was jetzt weniger ein Problem des Beitrags, geschweige denn ein Problem des RavenSystem ist. Da gilt wie so oft: Bei Interesse schlau machen und verstehen lernen, bei grundsätzlichem Desinteresse einfach ignorieren und vergessen.
was HomeKit, Homebridge und vor allem Alexa nicht mit wenigen Klicks auch jetzt schon können?
Solch ein verallgemeinerndes Statement ist extrem subjektiv und hilft wenig weiter:
Ein Home Assistantler würde dir/uns bspw. entgegnen, dass er sich hier im Forum (zu recht) kopfschüttelnd die Frage stellt: was eiern die da mit HomeKit, Kurzbefehlen und Homebridge (und RavenSystem) rum, während ich das effizienter und zuverlässiger mit wenigen Klicks in Home Assistant kann.
Zudem ist "vor allem Alexa" in diesem Sinne und in diesem Zusammenhang schonmal doppelt raus. Erstens ist es nicht HomeKit, was nach meinem Verständnis allein aufgrund der obersten Forumsdirektive hier gar nicht rein darf und zweitens ist Alexa alles andere als der heilige Gral unter den zahllosen Smarthome Mitbewerbern (s.o. Stichwort Home Assistant, aber auch Homey, FHEM, Open Hab KNX etc.pp.).
Eine Grundsatzdiskussion darüber, was das Beste, Einfachste und Sinnreichste ist, endet regelmäßig in fruchtlosen persönlichen Überzeugungen und Meinungen mit individuellen Schwerpunkten ähnlich der ewigen Frage, ob Apple oder Windows die bessere Computerwelt eröffnet. 
Ich bin ja für jegliche Spielerei offen, aber was kann ich hiermit erreichen
Um walta s Antwort noch zu ergänzen: Es lassen sich mit besagten ESPs (nicht nur durch RavenSystem) eigene HomeKit-Devices konzipieren und produzieren, sondern (und das ist für meine Anforderungen der springende Punkt) dieselben ESPs sind gleichzeitig auch in der Lage, vielfältigste interne Automationen im Vorfeld zu berechnen, um dadurch einerseits das vergleichsweise ewig träge und launenhafte HomeKit zu entlasten. Um dadurch aber auch komplexe Schaltvorgänge in HomeKit zu integrieren, die dort eben nicht durch ein paar Klicks machbar sind. Ich lass mich gern vom Gegenteil überzeugen.
In den konkreten Anwendungs-Beispielen sowohl von Edward J. Nately III s "Motorenschaltung" als auch Mighty61 "Doppel-Thermostat" lassen sich sowohl weitere Sensoren und physische Schalter integrieren, aber auch Automationen innerhalb der ESPs ausführen. Das Motorenschaltungs-Script etwa könnte durch einen Lichtsensor erweitert werden, der die Relais/Motoren in Abhängigkeit von Luxmessungen selbsttätig steuert. Der Doppelthermostat kann innerhalb des ESP einen Abgleich zwischen den beiden gemessenen Werten machen, um dann daraus Schaltungen in HomeKit auszulösen.
In Homebridge benötigst du für jedes einzelne Device schonmal ein geeignetes PlugIn und musst dann noch eine Möglichkeit finden, die PlugIns miteinander interagieren zum lassen, um sowas vergleichweise zu automatisieren. Und selbst wenn sowas möglich sein sollte, mit wenigen Klicks wird das sicherlich nicht gehen.
Ich selbst habe z.B. mittlerweile sämtliche Zeitautomationen/Zeitdauern aus HomeKit verbannt und lasse diese extrem zuverlässig durch die autarken ESPs ausführen. Solange die Dinger mit Strom versorgt werden, laufen die 24/7 wie ein Uhrwerk – kein Absturz keine Inkompatibiltäten und Reibereien mit Betriebssystem-Problemen, keine Terminal-Rumdoktorei. Alles läuft seit Monaten sehr geschmeidig. Wenn etwas nicht funktioniert, scheitert es an HomeKit, was schonmal enorm bei der Fehleranalyse hilft.
Verstehe das RavenSystem vereinfacht gesagt wie einen gigantischen HomeKit-Baukasten, durch den du selbst zum Entwickler eigener Geräte wirst, ohne erst eine Programmiersprache erlernen und dich mit Betriebssystemen und -konfigurationen auseinandersetzen zu müssen.
Mighty61 Gern geschehen
Mach dich in diesem Beitrag bemerkbar, wenn noch Fragen sind. Wir haben ja jetzt offiziell freie Bahn für einen regen konstruktiven Austausch.
PS: Thema „stören“. Mir war nicht bewusst, dass sich in einem HomeKit Technikforum jemand dadurch gestört fühlen könnte, dass man ausführliche technische Workarounds zum Thema HomeKit vorstellt und diskutiert
All diejenigen, die sich durch diesen Beitrag (warum auch immer) gestört fühlen/fühlten, bitte ich hiermit um Entschuldigung und wünsche denselben weiterhin viel Erfolg mit ihren eigenen HomeKit Lieblingsprojekten.
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)
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"}]}]}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}]damit ich es nicht nur abschreibe, sondern auch kapiere
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 Edward J. Nately IIIHab 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.
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.
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
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.
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:
| PIN | Input | Output | Info |
|---|---|---|---|
| ADC | Analog | X | Pin um analoge Werte zu messen 0-1 Volt |
| GPIO16 | Kein Interrupt | Kein PWM und 12C | Kann binäre Zustände einlesen/ausgeben, Weckt den ESP aus dem Deep-Sleep wenn auf GND gezogen. HIGH beim Booten |
| GPIO5 | OK | OK | Oft für SCL (12C) verwendet |
| GPIO4 | OK | OK | Oft für SDA ) (12C) verwendet |
| GPIO0 | Pull-up | OK | Beim flashen auf GND ziehen, kann so nicht booten |
| GPIO2 | Pull-up | OK | Kann nicht booten wenn auf GND gezogen HIGH beim booten |
| GPIO14 | OK | OK | SPI SCLK |
| GPI012 | OK | OK | SPI MISO |
| GP013 | OK | OK | SPI MOSI |
| GPIO15 | Pull-down | OK | SPI CS Kann nicht booten wenn auf HIGH gezogen |
| GPI03 | OK | RX Pin | Serieller Pin zum Senden von Daten
HIGH beim booten |
| GPIO1 | TX Pin | OK | Serieller Pin zum Empfangen von Daten
Kann nicht booten wenn auf GND gezogen HIGH beim booten |
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.
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.
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.
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
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
Hab mal lose recherchiert. 220 Ohm sollten reichen.
Das war hier schon mal Thema. Sebbo187 hatte Raven für den MagicHome Controller vorgestellt.
Genau den damaligen Beitrag hab ich zu Anfang dieses Beitrags innerhalb der "Skeptiker-Abteilung" als Pro-Argument verlinkt, um deutlich zu machen, dass man auch fertige Produkte umprogrammieren kann. In dem alten Beitrag wird aber lange nicht die Bandbreite der Möglichkeiten deutlich, sondern eher das Prozedere mit nicht weiter vertieftem Code, der explizit für den MagicHome Controller verwendet werden muss.
In derselben Zeit hatte ich mich auch schon mit RavenSystem befasst (kannte besagten Beitrag damals schon), um einen Raumzähler zu entwicklen, um dann jedoch kurz danach ein paar Jahre Pause mit HomeKit zu machen (es gibt auch noch Wichtigeres im Leben). Umso überraschender für mich, was inzwischen alles bei RavenSystem dazugekommen ist.
Das gilt aber nur für die interne LED, oder? Wenn ich zusätzlich noch eine externe auf GPIO2 hänge, verhalten sich die beiden Funzeln genau gegenläufig.
Ja, das sollte bei externen LEDs so sein. Das kannst du jeweils per "v"-Key ausgleichen, solltest du die inter + externe LEDs verwenden wollen.
Mit wieviel mA darf man die Ausgänge eigentlich belasten? Im Netz findet man unterschiedlichste Angaben.
Die Ausgänge werden ja eigentlich nicht "belastet", sondern es werden Geräte daran angeschlossen, die die Arbeitsspannungen von 3.3V bzw. 5V gegen 0V des ESP interpretieren. Der ESP kann dabei schonmal nicht mehr rausschicken, als er selbst an Spannung x Ampere vom Netzteil bezieht, was sich im niedrigen mA-Bereich abspielen dürfte. Wieviel genau das ist, weiß ich schlichtweg nicht.
Andersrum gefragt: Was willste denn anschließen?
Was für ein Reset macht der? Werkszustand oder nur Warmstart?
1x reicht für einen Reboot in Bruchteilen von Sekunden. Das Wiederanmelden in HomeKit kann dagegen mehrere Sekunden benötigen. Wir kennen das von allen WLAN-Gerätschaften, die man kurz stromlos macht.
Also in keinem Fall wird durch den Reset-Schalter irgendwas im Code oder der Firmware zurückgesetzt.
Aah, Freude, Edward J. Nately III macht weiter
Der in meinem Beispiel angegebene Port ist nur beispielhaft im Befehl aufgeführt. Ich hatte dabei ja erwähnt, dass der Port über den Befehl
python3 -m esptool flash_idermittelt werden kann. Das heißt dann im Terminal exklusiv bei mir:
Serial port /dev/cu.usbserial-14230
Die Portnummer wird bei jedem/jeder sicherlich anders sein.
Offensichtlich klappen die Befehle "read" und "write" nach deiner Beschreibung auch ohne Portangaben = Umso besser. Diese Erkenntnis kann ich ja beizeiten nochmal im Beitrag ergänzen.
Ich bin in den letzten Tagen noch weiter in die Materie eingetaucht und habe wieder manches dazugelernt und ratzfatz in die Praxis umgesetzt. Meine Begeisterung über die Möglichkeiten mit dem RavenSystem wächst derzeit stetig. Es ist mir ein Rätsel, dass sich das noch nicht auf breiter HomeKit Front durchgesetzt hat. 
Es geht meines Wissens nur das eine oder das andere.
Sobald ein Bewegungssensor direkt mit der Lampe verbunden ist, kann man nicht gleichzeitig mit dem Gateway koppeln und umgekehrt.
Matter-theoretisch ließen sich die am Gateway angemeldeten Geräte sowohl in Alexa als auch gleichzeitig in HomeKit nutzen, jedoch ohne die Möglichkeit, dass in beiden Welten jeweils die Schaltzustände synchronisiert werden. Das ist aber meinerseits eher unter der Rubrik Halbwissen zu verstehen, da ich niemals 2 konkurrierende SmartHome-Systeme (Alexa schonmal sowieso gar nicht) in dieser Art nutzen würde und von daher keine praktischen Tests durchgeführt habe.