HAA Raven System Firmware für ESP Geräte

Zitat von walta

Ganz oben gibt man das MEPLAA Skript ein. Hab mal das auf der Seite angegebene Beispiel - {"a":[{"t":1},{"t":2}]}) - eingegeben und auf Safe gedrückt.

Bis hierhin hat nun alles geklappt. Nach dem Anklicken von Safe habe ich etwas gewartet, komme jetzt aber nicht mehr über 192.168.1.175:4567 in den HAA-Setup-Mode. Die FritzBox meldet das Gerät unter der IP jedoch als aktiv und in Homekit haben sich unter 021-82-017 tatsächlich ein Schalter und eine Steckdose anmelden lassen.

Nately scheint also einen Schritt weiter gekommen zu sein, jedoch erheben sich neue Fragen:

• Wie kommt man nun wieder aufs Gerät, um etwa ein anderes MEPLHAA Script einzugeben?
• Wie lassen sich andere Homekit-IDs vergeben, wenn man mehrere HAA-Devices ins Rennen schicken will?
• Hat schon jemand Erfahrungen mit der HAA Home Manager - App sammeln können?
• Wo kann ich die Signale für o.g. Schalter und Steckdose am Board abgreifen?

Und Dank auch an loonypac und walta für's Anfixen

Edward J. Nately III Glückwunsch schonmal für die ersten erfolgreichen Schritte

Ich werde in der nächsten Woche meinen „kleinen“ Exkurs fortsetzen. Stelle grade fest, dass es noch seehr viele hilfreiche Tipps zu erwähnen gibt, was entsprechend aufwändig wird.

Kurz zu deinen Fragen:

Den Setup-Mode zum Editieren der JSON kannst du über mehrere Wege aktivieren, das werde ich dann nochmal konkretisieren.

Beim derzeitigen Stand der Dinge geht das, indem du recht schnell den generierten Schalter ein- und ausschaltest, um genau zu sein ist der Systemstandard bei 8x, was man natürlich alles noch ändern kann. Du erkennst schnell, wann der Setup-Mode aktiviert ist, weil dann in der HomeKit App derselbe Schalter seine Funktion sichtbar verliert und als unerreichbar angezeigt wird. Bedenke, dass du zusätzlich zur IP des ESPs immer den Port :4567 an die Adresse anhängen musst.

Ich weiß nicht genau, was du mit HomeKit ID meinst. Vermutlich aber den Eingabecode 0218-2017?! Der ist für ALLE ESPs identisch (und darf zudem laut Lizenz auch nicht verändert werden), was den Anmeldevorgang einigermaßen vereinfacht.

Die HAA Homemanager App war bereits ganz zu Anfang meine erste Investition in diesem Projekt, da sie die Bedienung und Pflege der ESPs enorm vereinfacht – meine wärmste Empfehlung Du kannst dann sehr bequem darüber neben vielen anderen Annehmlichkeiten den Setup-Mode schalten.

Das Thema GPIO werde ich am Beispiel einer HomeKit-Lampe samt Schalter im Sinne der ersten selbstgebastelten HomeKit-Hardware erklären. Das Schöne am D1 Mini ist die integrierte dimmbare blaue LED, die man dafür sehr anschaulich und unaufwändig nutzen kann. Gib mir etwas Zeit!

Zitat von loonypac

Glückwunsch schonmal

tnx

Zitat von loonypac

Ich werde in der nächsten Woche meinen „kleinen“ Exkurs fortsetzen.

Sehr gern. Bin gespannt. Wenn das alles so funktioniert, wie erhofft, wäre HAA für mich ein Game-Changer in Sachen Homekit.

Zitat von loonypac

Du erkennst schnell, wann der Setup-Mode aktiviert ist, weil dann in der HomeKit App derselbe Schalter seine Funktion sichtbar verliert und als unerreichbar angezeigt wird.

Aha! Also entweder Setup-Mode oder das Ding arbeitet aktiv als Accessory?

Zitat von loonypac

Bedenke, dass du zusätzlich zur IP des ESPs immer den Port :4567 an die Adresse anhängen musst.

Das ist sowei klar.

Zitat von loonypac

Ich weiß nicht genau, was du mit HomeKit ID meinst. Vermutlich aber den Eingabecode 0218-2017?

Ja, den meinte ich.

Zitat von loonypac

Der ist für ALLE ESPs identisch (und darf zudem laut Lizenz auch nicht verändert werden), was den Anmeldevorgang einigermaßen vereinfacht.

OK - das heißt, wenn andere Geräte hinzukommen, verwendet man genau diesen Code eneut.

Zitat von loonypac

Die HAA Homemanager App war bereits ganz zu Anfang meine erste Investition in diesem Projekt, da sie die Bedienung und Pflege der ESPs enorm vereinfacht – meine wärmste Empfehlung

Hab ich soeben installiert. Das HAA-Device wird gefunden. Der Setup-Mode lässt sich hier also einschalten. Überhaupt scheint sich der Entwickler viel Mühe zu geben. Der Obulus für die App ist sicher angemessen und gerechtfertigt.

Zitat von loonypac

Das Thema GPIO werde ich am Beispiel einer HomeKit-Lampe samt Schalter im Sinne der ersten selbstgebastelten HomeKit-Hardware erklären.

Super.

Fernziel für mich: Eine doppelte Steuerung für zwei Motoren, die sich unter Homekit als je ein Window-Covering zu erkennen geben.

RavenSystem – Installationshilfen und Grundsätze der HomeKit Integration

Bevor ich mit Skripten weitermache und im Grundsatz erkläre, wie man physische Schalter und sonstige Hardware-Gerätschaften wie Sensoren, Relais, Ventilatoren, etc. mit dem ESP per GPIO verbindet, gebe ich mal ebenso grundsätzliche Tipps für das Aufsetzen der Firmware samt gewonnenen Erkenntnissen, was die HomeKit Integration der ESPs betrifft. Das soll helfen, Zeit und Nerven zu sparen.

Wie inzwischen mit mir gerechnet offensichtlich 3 Personen in diesem Beitrag festgestellt haben, ist die RavenSystem Installation auf einem ESP trotz recht überschaubarer Anleitung mit einigen Fragezeichen versehen. Insbesondere der zweite Teil nach der Eingabe des WLAN-Netzwerkzugangs für den ESP auf dessen eigener orangefarbener Einrichtungs-Webpage mit der vorübergehend generierten IP 192.168.4.1:4567 hat bei mir am Anfang einige Irritation erzeugt, da man zwar den Hinweis erhält, ungefähr 10 Minuten zu warten, in dieser Zeit allerdings keinerlei ermutigende Statusmeldungen oder LED-Blinks oder gar Success-Mitteilung bekommt.

Tatsächlich musste ich mitunter weitaus länger warten als die besagten 10 Minuten, sodass dieser entscheidende erste Installationsschritt grade beim berühmten Erstenmal zum Geduldsspiel werden kann, bei dem man verunsichert den ESP neustartet oder resettet, was allerdings den Vorgang nicht unbedingt beschleunigen hilft. Ich vermute im gesunden Halbwissen, dass beim Abbrechen einer unvollständigen Installation dieselbe immer wieder von vorn beginnt und den Zeitzähler jeweils auf mindestens 10 Minuten zurückstellt.

Deswegen mein erster Tipp für alle Anfangenden: Gebt dem ESP genügend Zeit, und zwar durchaus auch mal mehr als 10 Minuten. Am besten ist eine vorgeplante Ignoranz, was den Installationsvorgang betrifft, die man dadurch erreicht, dass man den ESP nicht vor sich legt und auf den magischen Augenblick der Finalisierung wartet, sondern denselben außer Sichtweite platziert und am besten sofort eine konzentrationsfordernde andere Tätigkeit an den Tag legt, um irgendwann festzustellen: Ach, da war ja noch was.

Der ESP erhält vom Router seine letztgültige IP. In den meisten (Fritz!Box)Fällen wird das die berühmte lokale Adresse 192.168.178.xx sein, wobei xx eine eindeutige 1- bis 3-stellige Zahl ist. Die vielsagende Namensbezeichnung HAA- plus einem 6-stelligen, zufällig anmutenden Code generiert der ESP hingegen selbst abgeleitet aus einem Teil der ESP-eigenen Mac-Adresse. Beides lässt sich im Nachhinein am Router wieder ändern.

Sobald solch ein jungfräuliches ESP im Router auftaucht, heißt das allerdings lange noch nicht, dass der ESP mit der angezeigten Adresse im Browser ausgewählt werden kann. Im Gegenteil, der Router zeigt den ESP sogar sehr schnell, während dieser in aller Seelengemütlichkeit seine Installationsroutinen durchführt und unansprechbar bleibt.

Es kann nicht schaden, die IP des ESP schonmal in den Browser einzutragen. Dabei ist wichtig, an dieselbe Adresse den für das RavenSystem reservierten Port anzuhängen, also 192.168.178.xx:4567. Ohne diese Portangabe wird man auch fertig aufgesetzte ESPs nicht erreichen. Nach den 10 Minuten immer mal wieder einen Reload der Seite wagen, bis dann irgendwann die weiße Setup-Webseite des ESP für weitere Editierungen geladen wird.

Manche Irritation brachte am Anfang meiner Experimente übrigens auch Safari mit sich, das mitunter "freundlicherweise" die ursprüngliche Adresse durch ein vorangestelltes "www." zu komplettieren meint, ohne dass dies großartig angekündigt wird und in’s Auge fällt. Da das Adressfeld dieses "www." grundsätzlich ausblendet, glaubt man die richtige Adresse durch einen Reload auszulösen und feuert statt dessen in diesem Sinne ergebnislos in die Unendlichkeit des Internetzes statt ein lokales WLAN-Gerät anzufunken.

Apropos Fritz!Box und damit gleichzeitig auch alle Router, die eine Sperre für neue Mac-Adressen aktiviert haben. Da die ESPs in überwiegender Regel WLAN-Geräte sind, besitzen sie naturgemäß eine eigene unveränderliche Mac-Adresse, die bei der Erstanmeldung derart konfigurierter Router sinnigerweise geblockt werden. Und so rätselte ich ganz am Anfang, wieso sich der ESP einfach nicht am Router anmelden ließ: Einzig deshalb, weil ich genau diese Sperre schlichtweg vergessen hatte. Um dies zu vermeiden, kann man eins der beiden folgenden Prozedere durchführen:

1. Vorübergehende Entsperrung der Mac-Adress-Sperre beim Router. Natürlich sollte nach anschließender erfolgreicher Anmeldung des ESP am Router dieser anschließend wieder gesperrt werden.
2. Vorab-Anmeldung der Mac-Adresse des ESP am Router. Hierfür muss die Mac-Adresse des ESP in Erfahrung gebracht werden, was ich gleich erkläre.

Und nun zur guten Nachricht:

Die nervige Einstiegs-Installation mit 10-minütiger Wartezeit lässt sich nach einmaligem Einrichten des ersten ESP vermeiden, sodass man nach einem einfachen Terminalbefehl und einigen Sekunden Wartezeit direkt mit der weißen Setup-Website beginnen kann. Dazu gleich.

Ich benötige derzeit 4 Terminalbefehle, durch die ich derzeit alles für mich Wesentliche erledigen kann:

Grundsätzlich vor allen Installationen lösche ich zunächst das frische ESP mit dem auch in der Installation genannten Befehl:

python3 -m esptool erase_flash

Um alle wichtigen Spezifikationen (inkl. MAC-Adresse) auszulesen, dienen folgende zwei Befehle, die sich im Ergebnis nicht unterscheiden:

python3 -m esptool flash_id

python3 -m esptool read_mac

Der nächste Befehl ist extrem hilfreich, da man durch ihn ein vollständiges Backup des ESPs in Form einer bin-Datei erstellen kann - sehr hilfreich für Shellys und Konsorten, wodurch man den Werkszustand der ESPs problemlos wiederherstellen kann, aber auch zum Klonen, Dublizieren bietet sich dieser Befehl an. Die notwendige Portangabe als auch die Speichergröße (im Beispiel 4MB) erhält man übrigens über die beiden vorherigen Befehle:

python3 -m esptool --port /dev/cu.usbserial-14230 read_flash 0 0x400000 /Verzeichnispfad-fürBackup/HAA-Backup-Name.bin

Nachtrag: Nach mehreren Tests hat sich bei mir zumindest für den D1 Mini ergeben, dass die Portangabe im Befehl auch weggelassen werden kann. Es reicht zum Auslesen also:

python3 -m esptool read_flash 0 0x400000 /Verzeichnispfad-fürBackup/HAA-Backup-Name.bin

Was man ausgelesen hat, will man natürlich früher oder später wieder in einen ESP schreiben, was folgender Befehl erreicht:

python3 -m esptool --port /dev/cu.usbserial-14230 write_flash 0 /Verzeichnispfad-fürBackup/HAA-Backup-Name.bin

Nachtrag: Nach mehreren Tests hat sich bei mir zumindest für den D1 Mini ergeben, dass die Portangabe im Befehl auch weggelassen werden kann. Es reicht zum Schreiben also:

python3 -m esptool write_flash 0 /Verzeichnispfad-fürBackup/HAA-Backup-Name.bin

Womit wir zur erwähnten Zeitersparnis beim Installieren neuer ESPs kommen:

Das ist ganz einfach dadurch zu erreichen, dass wir denn allerersten "zu Fuß" eingerichteten ESP, bevor wir ihn mit einem Script ausstatten und bevor wir ihn in HomeKit anmelden, im Status der weißen Setup-Webpage über den 3. Terminalbefehl auslesen und die entstehende bin-Datei abspeichern. ALLE ESPs, die wir später in unser System einbinden, können dann sehr bequem über diese bin-Datei als Ausgangs-ESP geklont werden, um sie dann nach den eigenen Vorstellungen zu editieren. Wir sparen also die erste zeitaufwändigste Installationsphase.

Womit ich genau an dieser Stelle zur HomeKit-Integration umschwenke:

Wie in vorherigen Beiträgen bereits erwähnt, werden SÄMTLICHE ESPs mit ein und demselben Code 0218-2017 in HomeKit angemeldet. Dieser Code ist also NICHT für eine Individualisierung bzw. ein Wiedererkennne des in HomeKit angemeldeten Devices verantwortlich, HomeKit erkennt den ESP und damit jedes Service-Device innerhalb eines ESP mitnichten am Anmelde-Code, genausowenig wie an der IP oder Mac-Adresse. Es muss dies eine anderer Wert in einem HomeKit-Device abgespeichert sein, der genau diese essentielle Zuordnung eines Gerätes in HomeKit zulässt. Welcher Wert das ist, kann ich nur raten. Es scheint sich um den bspw. in der HAA-Manager-App angezeigten sogenannten "Identifier" zu handeln, der zumindest beim augenscheinlichen Vergleich tatsächlich unique zu sein scheint. Vielleicht haben einige HomeKit-Spezis dazu konkretere Infos?!

Wie dem auch sei, ist die Vorstellung nicht unbedingt vertrauenserweckend, dass wir durch das reine Klonen der Ausgangs-ESPs womöglich Irritationen in HomeKit dadurch erzeugen, dass wir verschiedene ESPs mit völlig unterschiedlichen Service-Devices einbinden, die für HomeKit aus dem genannten Identfier-Grund eigentlich ein und dasselbe Device darstellen soll.

Um von Vornherein solch eine Fehlkonfiguration auszuschließen bringen wir das im Setup-Mode wählware Feld "Reset HomeKit ID" in’s Spiel, das eben nicht den genannten Zugangscode zurücksetzt, sondern den ESP zu einem neuen, eigenständigen ESP macht. Deswegen erwähnte ich, dass der Ausgangs-DSP nicht in HomeKit angemeldet werden sollte. Es reicht also, besagte bin-Datei auf einen neuen ESP zu schreiben, sein Script einzutragen, einen Haken an "Reset HomeKit ID" zu machen, um dann einen für HomeKit neuen und vor allem eindeutigen ESP anzumelden, der nicht in Konflikt mit anderen gerät.

Was im vorherigen Fall schädlich für neu aufgesetzte ESPs sein könnte, erweist sich im Sinne eines Backups als segensreich. Tatsächlich kann ich jeweils in Betrieb befindliche ESPs VOR allen umfangreicheren Editierungen als bin-Clone sichern, um im schlimmsten Falle das Backup auf denselben Code oder einen anderen ESP zurückzuschreiben. Dies ist sehr beruhigend für den Fall, dass der Original-ESP beispielsweise abraucht. Ich habe solche Clones bisher ausschließlich mit baugleichen ESP probiert, ob unterschiedliche ESP in diesem Sinne funzen, kann ich zu diesem Zeitpunkt noch nicht bestätigen.

Ein Letztes zu möglichen Editierungen von in HomeKit angemeldeten ESPs:

Sobald man bspw. 1 ESP mit diversen Service-Devices wie Schalter und Lampen angemeldet hat, kann man nach meiner Erfahrung die Codes am Ende durch weitere Services erweitern. Brauche ich noch mehr Schalter, schreibe ich die zugehörigen Codes an den Anschluss der letzten Services, sodass HomeKit diese brav komplettiert. Problemreich wird eine vollständige Umdefinierung bereits komplexerer Scripts, also etwa, wenn ich mit mehreren Schalter beginne, um diese später in Lampen zu verwandeln. Meine Experimente in diesem Zusammenhang brachten HomeKit aus dem Gleichgewicht, ob die Schuld dabei am ESP oder an HomeKit liegt, ist dabei für mich nicht zu klären. Also bitte immer vorsichtig solche Service-Veränderungen vornehmen! Zusatzkeys und Zusatzfunktionen innerhalb der unveränderten Services sind hingegen unproblematisch.

Möchte man zahlreiche identische Services, wie z.B. 8 virtuelle Schalter, in HomeKit integrieren, muss bedacht werden, dass HomeKit beim Einfügen der neuen Services nicht der Reihe nach wie im Script vorgeht, sondern das sehr willkürlich und tagesformabhängig macht. Ich weiß also in solchen Fällen nicht, welcher Schalter in HomeKit welchem Schalter im Script entspricht, was solange egal bleibt, solange alle Services im Script identisch bleiben. Sollen im Nachhinein ausgewählte Schalter individuelle Funktionen erhalten, beginnt spätestens jetzt das Rätselraten, an welcher Stelle das Script verändert werden muss. Vermeiden kann ich sowas dadurch, dass ich die zunächst gleichen Schalter nicht mit einem Mal als Code erstelle und in HomeKit anmelde, sondern den mühsamen Weg wähle, jeden Schalter einzeln zu generieren und dann einzeln in HomeKit anzumelden bzw. nach jedem einzelnen Schalter den Setup-Mode per "Save" abschließen, warten bis der neue Schalter in HomeKit auftaucht, um dann den nächsten Schalter per Setup-Mode zu generieren.

Mithilfe der in der Home App aufgeführten "Seriennummer", insbesondere durch das dort schließende numerische Anhängsel "…-x" lassen sich solche identischen Services sehr gut im Nachhinein identifizieren und vielsagend umbenennen.

Zitat von loonypac

Ohne zu wissen, wie du was genau schalten willst, sollte dein Vorhaben möglich sein.

Es sollen mit Getriebemotoren zwei Hebevorrichtungen (auf und ab incl. Endschalter) gesteuert werden. Als HK-Device bietet sich (leicht zweckentfemdet) das Rollo an, da man hier die Höhe in Prozent als Sollwert vorgeben kann. Per Shelly geht das leider nicht, weil am Ort des Geschehens nur 24V- zur Verfügung stehen. Wäre also nen Fall für einen ESP über HAA. Bin schon am MEPLAA-Knobeln. Ist ein wenig wie LEGO für Homekit. Das wird den Erleuchteten sicher auch noch begeistern. Der will ja statt zu löten, lieber seine Tasten schinden.

Zitat von loonypac

Sobald solch ein jungfräuliches ESP im Router auftaucht, heißt das allerdings lange noch nicht, dass der ESP mit der angezeigten Adresse im Browser ausgewählt werden kann. Im Gegenteil, der Router zeigt den ESP sogar sehr schnell, während dieser in aller Seelengemütlichkeit seine Installationsroutinen durchführt und unansprechbar bleibt.

Gut zu wissen. An dem Punkt war ich schon drauf und dran, zu verzweifeln: Ich seh ihn, aber er will nicht mit mir spechen!

Zitat von loonypac

Was man ausgelesen hat, will man natürlich früher oder später wieder in einen ESP schreiben

Der Tip mit dem Backup ist super!

Zitat von loonypac

Problemreich wird eine vollständige Umdefinierung bereits komplexerer Scripts, also etwa, wenn ich mit mehreren Schalter beginne, um diese später in Lampen zu verwandeln. Meine Experimente in diesem Zusammenhang brachten HomeKit aus dem Gleichgewicht

Wenn ich jetzt das Testscript durch ein komplett neues MEPLAA-Konstrukt ersetze - dann doch sicher erst alle über HAA angemeldeten Devices aus Homekit entfernen? Oder kommt HK danach auch noch ins Schleudern? Und noch eine Frage: Die Beispielscripte sind ja oft zwecks Übersichtlichkeit strukturiert dargestellt. Muß man Tabs, CR und Leerzeichen mühsam von Hand tilgen oder schiebt Onkel Raven die Syntax von selbst zusammen?

Zitat von loonypac

Vermeiden kann ich sowas dadurch, dass ich die zunächst gleichen Schalter nicht mit einem Mal als Code erstelle und in HomeKit anmelde, sondern den mühsamen Weg wähle, jeden Schalter einzeln zu generieren und dann einzeln in HomeKit anzumelden

Aha! Die Frage ploppte bei mir schon auf und ist hiermit also bestens beantwortet.

tnx

&

keep on rockin'

Zitat von Edward J. Nately III

Es sollen mit Getriebemotoren zwei Hebevorrichtungen (auf und ab incl. Endschalter) gesteuert werden. Als HK-Device bietet sich (leicht zweckentfemdet) das Rollo an, da man hier die Höhe in Prozent als Sollwert vorgeben kann. Per Shelly geht das leider nicht, weil am Ort des Geschehens nur 24V- zur Verfügung stehen. Wäre also nen Fall für einen ESP über HAA. Bin schon am MEPLAA-Knobeln.

Das liest sich spannend

Ich habe leider mit Motorensteuerungen noch nichts gemacht, aber dein Ansatz über den RavenSystem Window Covering scheint mir tatsächlich geeignet, dein Projekt damit umzusetzen. Intuitiv würde ich mal behaupten, dass dabei die Wildcard Actions von enormer Wirkung sein könnten. Diese gestatten innerhalb des ESP sozusagen Wenn-Dann-Automationen, wodurch beliebige Werte der Motoren-Höhensteuerung ihrerseits Schaltungen auslösen.

Nach meinem Geschmack rechtfertigt dein Projekt einen eigenen Beitrag, um diesen hier nicht zu sehr ausufern zu lassen. Darin sollten dann alle Anforderungen genau beschrieben werden. Also was sollen die Motoren unter welchen Bedingungen wann machen. Dies als Ausgangsvoraussetzungen, um die notwendigen Einzelkeys für den ESP zusammenzustellen.

Ich habe festgestellt, dass es schwierig wird in diesem Beitrag, einen roten Faden zu erhalten, je mehr dieser mit unsortierten Infos aufgefüllt wird. Das wird u.a. auch dadurch erschwert, dass Beiträge von Moderatorenseite wohlwollend zusammengefasst werden, die als Einzelbeiträge jedoch sinnvoller sind, da man diese direkt verlinken könnte, um ganz zu Anfang dieses Beitrags eine Art Inhaltsangabe zu pflegen, was dabei hilft, "Erstbesuchende" nicht durch die anfängliche endlose Off-Topic-Kontroverse abzuschrecken. Soweit ich das sehe, sind auch keine HTML-Anker in Forum möglich?!

Zitat von Edward J. Nately III

Ist ein wenig wie LEGO für Homekit.

… oder wie die klassischen Kosmos Elektrobaukästen der 70er.

Zitat von Edward J. Nately III

Wenn ich jetzt das Testscript durch ein komplett neues MEPLAA-Konstrukt ersetze - dann doch sicher erst alle über HAA angemeldeten Devices aus Homekit entfernen? Oder kommt HK danach auch noch ins Schleudern?

Das ist eine Möglichkeit. Wenn du alle angemeldeten Devices aus HomeKit entfernst, meldest du damit den ESP komplett aus HomeKit ab. Das gleiche erreichst du, wenn du die "Reset HomeKit ID" im Setup aktivierst, wie von mir beschrieben. Einziger Unterschied ist dann, dass die bereits angemeldeten Devices als nicht erreichbar in HomeKit verbleiben und du sie hinterher löschen musst. In beiden Fällen musst du den ESP in HomeKit wieder neu anmelden.

Zum Verständnis: Der ESP beinhaltet für HomeKit eine "Bridge", die standardmäßig aus dem ersten HomeKit-Service abgeleitet wird (das kann auch verändert werden). Löscht du also sämtliche Devices, löscht du damit immer auch die Bridge und meldest damit den ESP aus HomeKit ab.

Es sollte grundsätzlich vermieden werden, dass 2 oder gar mehr ESPs mit einem identischen Identifier in HomeKit angemeldet werden, was durch das beschriebene Klonen ohne Änderung der HomeKit ID unweigerlich der Fall sein würde.

Zitat von Edward J. Nately III

Und noch eine Frage: Die Beispielscripte sind ja oft zwecks Übersichtlichkeit strukturiert dargestellt. Muß man Tabs, CR und Leerzeichen mühsam von Hand tilgen oder schiebt Onkel Raven die Syntax von selbst zusammen?

Onkel Raven und Tante System machen das nicht von selbst. Du solltest auch unkomprimierte Codes samt Leerzeichen und Zeilenumbrüchen im ESP abspeichern können, was allerdings den Speicherplatz des ESP unnötig befüllt.

Ich selbst nutze einen Code-Editor (Sublime Text), in dem ich durch Suchen und Ersetzen die überflüssigen Zeichen relativ schnell eliminiere. Alternativ gibt es zahlreiche JSON-Online-Formatter (e.g. https://jsonformatter.curiousconcept.com), die so etwas mit einem Klick lösen und gleichzeitig die Syntax überprüfen.

Zitat von Edward J. Nately III

keep on rockin'

Sowieso und zwar regelmäßig

Zitat von loonypac

Ich habe festgestellt, dass es schwierig wird in diesem Beitrag, einen roten Faden zu erhalten, je mehr dieser mit unsortierten Infos aufgefüllt wird.

Stimmt einerseits. Andererseits kann ich nachvollziehen, daß die Modmins ein Ausufern von Randthemen nicht zulassen wollen. Allerdings sind Topics, wie Raven, Rojers Shelly-Hacks oder Homespan extrem interessant, wenn es darum geht, das Homekit-Universum nach eigenem Gusto zu erweitern. Die herstellerseitige Entwicklung bleibt ja leider etwas träge. Auch Homebridge ist letzlich eine ähnlich segensreiche Bastelei, um irgendein exotisches Lieblingshaustierchen ins gelobte Biotop zu bekommen - zwar "homebrewed" aber eben auch Homekit at it's best!

Vielleicht könnte ja eine eigene Rubrik für DIY-Gerätschaft helfen, Raum für Experimente zu gewähren, ohne Struktur und Übersicht einzubüßen? Bislang haben die Heimwerker drei Eskalationsstufen (bitte um Ergänzung falls etwas Wichtiges fehlt oder Korrektur wenn was flasch ist):

• Shelly-Homekit - eine HK-Firmware für bestimmte Produkte aus dem Hause Shelly - von Rojer - Zugriff und Anpassung über Web-Oberfläche - letztlich auch ein ESP-Hack
• HAA - ein Homekit-System für ESP8266 bzw. ESP8285 - von Raven System - Zugriff und Anpassung mittels JSON-config über Web-Oberfläche oder iOS-App
• Homespan - eine Homekit-Library für Arduinos vom Typ ESP32 - Anpassung mittels Arduino-IDE und kleinen C/C++ Programmen

Mit absteigender Reihenfolge nehmen Flexibilität, aber auch die Schwierigkeitsgrade zu.

Um’s kurz zu machen: Absolut d’accord und auf dem Punkt

Wobei ich für HAA nachvollziehbar vermute, dass dies erst bei den Forumbetreibenden relevant wird, wenn sich außer dir und mir eine erkleckliche sprich relevante Anzahl von Forumsteilnehmenden interessiert. Bleibt’s beim Duo bzw. im einstelligen Interessentenbereich, wird’s fast sinnvoller ein eigenes Forum in’s Leben zu rufen. Als u.a. Webentwickler wäre das zumindest technisch kein Problem.

RavenSystem – Wir basteln uns eine HomeKit LED Lampe

Nach der anfänglich vorgestellten Schaltgruppe, die bislang ausschließlich in der und für die "innere" HomeKit-Infrastruktur wertvolle Zusatzfunktionen wie besagte Speicherplätze, Timer oder die Fähigkeit zu Zählen bereitstellt, will ich heute mal mit einfachsten Mitteln aus einem ESP8266 eine dimmbare Lampe basteln, die noch dazu von "außen" per beliebigem physischen Schalter bedient werden kann. Dies, um prinzipiell die Outboard-Möglichkeiten des ESP einführend vorzustellen, durch die eine Vielzahl an Hardware (Sensoren, Schalter, Motoren, Relais etc.) für den Bau eigener HomeKit Gerätschaften mit dem RavenSystem genutzt werden kann.

Dabei soll wiederum in erster Linie die Nachvollziehbarkeit des Scripts für Anfangende im Vordergrund stehen, um eigene Projekte anzuregen. Über eine praktische Verwendungsmöglichkeit der im Beispiel behandelten, vermutlich "kleinsten" HomeKit-Lampe der Welt darf jeder für sich fantasieren.

Wenn ich ESP8266 schreibe, meine ich den hier im Beitrag von allen derzeitigen Teilnehmern unabgesprochen erwählten konkreten Kandidaten (Wemos) D1 Mini, der praktischerweise bereits viel Nützliches an Board hat, das uns für alle möglichen (und unmöglichen) Projekte direkt zur Verfügung steht. Tatsächlich gibt es zahlreiche andere ESP8266 in unterschiedlichsten Baugrößen und mit mehr oder weniger Erweiterungen, dies sowohl in der im folgenden beschriebenen Anleitung als Einzelmodul als natürlich auch in fest verbauter Form fertiger, käuflich zu erwerbender Produkte wie den allseits bekannten Shellys.

Im besagten D1 Mini stehen uns zur Verfügung:

• 1x integriertes Wireless Local Area Network oder kurz WLAN nach IEEE 802.11.b/g/n
• 1x 10-Bit-Analog-Digital-Umsetzer
• 11x General Purpose Input Output Pins oder kurz GPIOs
• 1x I2C Schnittstelle
• 1x SPI Schnittstelle
• 1x asynchrone serielle Schnittstelle (UART)
• 1x Status LED (blau)
• 1x Reset Schalter
• 1x Micro USB Anschluss

Die Pin-Belegung ist im folgenden Bild übersichtlich beschrieben. Insbesondere die Zuordnung der GPIOs wird damit nachvollziehbar, denn die eigentliche Board-Beschriftung schweigt sich dazu aus bzw. zeigt eine eigene Logik. Diese GPIO-Belegung ist essentiell für die richtige Wahl der gewünschten Pins, die im RavenSystem Script korrekt angegeben werden müssen.

Der Vollständigkeit halber zeigt die nachfolgende Tabelle zudem alle Besonderheiten der einzelnen Pins inkl. Übersicht, wofür diese speziell im D1 Mini genutzt werden können. Es wird u.a. ersichtlich, dass bestimmte Pins in verschiedener Weise verwendet werden können.

Ich beginne mal mit dem Ausgangsscript für RavenSystem, das eine einfache Lampe definiert ("t":30), die in diesem Fall allerdings keine virtuelle, sondern eine reale Lampe in Form der im ESP verbauten Status LED werden soll. Um dies zu erreichen, wähle ich als erstes also den Type "ty":1. Wir erinnern uns, der Type "ty":0 definierte die Lampe im Schaltgruppen-Beispiel zur virtuellen Leuchte, die ausschließlich in der Home-App leuchtet. Diesmal soll eine Lampe bzw. LED zusätzlich auch die wirkliche Welt "erleuchten".

{"a":[{"t":30,"ty":1}]}

Das tut sie allerdings in diesem Stadium noch nicht, allein weil wir dem ESP erst noch mitteilen müssen, was ihn dazu bewegt, seine aufgelötete LED an- und auszuschalten.

Ich hole für das Verständnis noch etwas aus. Zwar ist die LED wie gesagt auf dem ESP verlötet, dennoch ist sie über einen für sie reservierten GPIO im Sinne eines Outs ansprechbar. Hätte ich einen ESP ohne aufgelötete LED, würde ich das gleiche Ergebnis erhalten, wenn ich eine separate LED an denselben anlöte. Beim D1 Mini ersparen wir uns also den Kauf einer solchen separaten LED samt Anbringungsprozedere per Lötung oder per Steckfeld. Beim D1 ist der für die verbaute LED entscheidende GPIO = 2, und zwar mit einer zusätzlichen Besonderheit: Die LED leuchtet auf, wenn dessen GPIO Zustand "low" ist. Was heißt das nun wieder?

Kommen wir zum grundsätzlichen Prinzip, Schaltungen per GPIOs auszuführen. GPIOs sind – allein schon namentlich erahnbar – frei definierbare Pins, die wahlweise als digitale Ausgänge (bspw. um Relais oder Lampen zu schalten) oder als digitale Eingänge (bspw. um mit Schaltern, Sensoren Aktionen auszulösen) definiert werden können. Dem ESP kann man den gewünschten Schaltbefehl u.a. physisch dadurch mitteilen, dass man den Zustand des GPIOs ändert. Je nach Ausführung eines GPIOs verfügt derselbe entweder über einen sogenannten Pull-Up- oder einem Pull-Down-Widerstand oder gar keinen Widerstand. In obiger Tabelle ist dies für den D1 Mini in der Spalte "Input" ersichtlich. Besagte Widerstände wirken sich auf die Grundzustände der GPIOs aus, was in erster Line für Inputs relevant wird, um u.a. stabile Zustände zu erreichen. Die GPIO Zustände werden dadurch im ESP erkannt, dass entweder eine Spannung (3,3V) am ESP anliegt = "high" oder die Spannung komplett abfällt = "low". Wer sich zum Thema schlauer machen will, kann hier detaillierte Infos zu den GPIO-Zuständen erhalten.

Ich komme zurück zur LED auf dem D1 Mini. Ich merkte eben noch an, dass diese verbaute LED aufleuchtet, wenn ihr reservierter GPIO 2 den Zustand "low" hat, umgekehrt erlischt sie in dem Moment, da der Zustand auf "high" wechselt. Übersetzt auf das Script benötige ich nun also einen Key, der genau diese Zustände auslöst und GPIO 2 als Output definiert. Hierfür sieht RavenSystem die "RGBW GPIO Channels" mit dem Key "g" vor, die je nach LED auch mehrere GPIOs für mehrkanalige Regelungen zulässt. Da wir die einfachste Form einer 1-kanaligen LED im Beispiel verwenden, reicht also die Angabe der GPIO Nummer 2. Die Besonderheit, dass die LED im Zustand "low" also quasi invers einschaltet, kann durch einfache Addition der GPIO mit der dafür definierten Zahl 100 erreicht werden, in unserem Fall also 102:

{"a":[{"t":30,"ty":1,"g":[102]}]}

Der ESP ist somit zum vollwertigen HomeKit Lampen-Device umgewandelt und kann nun über die Home App oder Siri sowohl ein- und ausgeschaltet als auch gedimmt werden (wobei Letzteres nur in entsprechender Demoqualität zu genießen ist).

Jetzt drängt sich gleich die nächste Frage auf: Wie kann die LED über einen einzigen GPIO mit 2 möglichen Zuständen gedimmt werden? Hierbei kommt die sogenannte Puls-Weiten-Modulation oder kurz PWM in’s Spiel, die sehr vereinfacht gesagt durch schnelles frequenzveränderndes Ein- und Ausschalten der LED eben den Effekt erzielt, dass die LED bei schnellerem Ein- und Ausschalten heller, bei langsamerem Hin- und Her entsprechend dunkler zu leuchten scheint. Diese PWM erledigt das RavenSystem, ohne dass wir uns für das Script weitere Gedanken machen müssen. Die Standardfrequenz liegt ohne weitere Code-Eingaben übrigens bei 305 Hz, was für die eigenen Anforderungen frei verändert werden kann (was an dieser Stelle allerdings nicht weiter beleuchtet werden soll).

Wir haben uns über den sehr überschaubaren Code also mal eben eine HomeKit-Lampe gebastelt, die zwar nicht unbedingt atemberaubende Lichtatmosphären erzeugt, immerhin aber bspw. als Status-LED einen gewinnbringenden Einsatz in unserem Smarthome zuließe. Das Beispiel lässt natürlich auch den Einsatz von separaten LEDs oder LED-Streifen zum Zwecke einer Raumbeleuchtung zu, die man an den ESP respektive an ausgewählte GPIOs anlötet und in gleicher Weise in RavenSystem codiert. Bishin zu RGB-CW-WW LEDs kann alles über das RavenSystem direkt in HomeKit gebracht werden.

Haben wir eben mal ein Beispiel für einen GPIO als Output kennengelernt, soll die eben gebastelte Lampe im Folgenden durch einen eigenen physischen Schalter ergänzt werden, der die Lampe unabhängig von HomeKit direkt ein- oder ausschalten soll = Wir nutzen dazu einen weiteren GPIO als Input.

Spätestens an dieser Stelle müssen wir entweder Lötarbeiten in Betracht ziehen oder wir nutzen den beliebten Weg aller ESP-Bastelnden und investieren in ein sogenanntes Breadboard, oder auch altdeutsch Steckbrett genannt, samt verschiedener Jumper Wires oder auch Steckbrücken. Wobei entweder/oder nicht ganz richtig ist, denn auch mit Steckbrett müssen wir zumindest den D1 Mini löttechnisch mit den zumeist mitgelieferten Pin Sätzen versehen, damit derselbe auf das Steckbrett gesteckt werden kann. Danach kann dann aber Vieles durch einfaches Umstecken von Kabeln für die ersten Experimente verwirklicht werden.

Als besagten physischen Lampen-Schalter können wir alles verwenden, was 2 Pole ein- und ausschalten kann, also beliebige Kipp-, Druckschalter samt allem, was mit Taster an- oder aufhört. Und selbst ganz ohne Schalter können wir das Experiment ausprobieren und einfach nur ein Steckkabel ein- und ausstecken.

Der für unser Script nötige Basis-Key definiert die "Digital Inputs" unserer Lampe mit einem "b" als sogenannten alleserklärenden "Binary Input". Dadurch weiß das System also, dass etwas in den ESP und die definierte Lampe "reinkommt". Es ist leicht zu erahnen, dass wir wiederum einen freien GPIO benötigen, diesmal wie gesagt als Input, der in gleicher Weise wie der Output durch den Key "g" samt Nummer des GPIO gewählt werden kann. Im Beispiel verwende ich einfach mal den GPIO 13, der der ESP-Beschriftung "D7" entspricht. Sobald ich diesen GPIO 13 mit Ground (im ESP als "G" bezeichnet) verbinde bzw. davon trenne, erhalte ich die gewünschte Umschaltung zwischen „low“ und „high“.

Nun muss ich dem ESP noch mindestens mitteilen, wie die Zustandsänderung von "low" und "high" schalttechnisch für die Lampe interpretiert werden soll. Habe ich also einen Taster, der nach jedem Loslassen wieder in den low-Zustand verfällt, soll ja die Lampe trotzdem eingeschaltet bleiben und erst bei der nächsten Tasterbetätigung ausgeschaltet und damit getoggled werden. Habe ich dagegen einen Schalter, der An und Aus durchgängig hält, soll die LED entsprechend anders geschaltet werden.

Der dafür notwendige Key nennt sich vielsagend "Press Type" und wird durch "t" definiert. RavenSystem bietet exakt 6 Möglichkeiten, von denen in diesem Beispiel 2 angewendet werden sollen. Den meisten HomeKit Freunden sind die Types "Single", "Double" als auch "Long-Press" sicherlich durch zahllose kommerzielle HomeKit-Schalter geläufig. Wir benötigen für das Tasterbeispiel nur den klassischen "Single Press" mit der Nummer 1, also "t":1. Das ergibt zusammen mit dem GPIO- und Input-Key den fertigen Code:

{"a":[{"t":30,"ty":1,"g":[102],"b":[{"g":13,"t":1}]}]}

Gleich dazu ein grundsätzlicher Hinweis: "t":1 ist in RavenSystem als ein default- also Standardwert gekennzeichnet. ALLE derartigen Werte können im Code entfallen, was wiederum Speicherplatz im ESP zu sparen hilft. Der obige Code kann also nochmal reduziert werden, ohne dass sich funktionell irgend etwas ändert.

{"a":[{"t":30,"ty":1,"g":[102],"b":[{"g":13}]}]}

Fehlt noch die eben erwähnte alternative Schaltmöglichkeit per Schalter statt eines Tasters. Doch wie soll das gehen, schließlich macht der Schalter grundsätzlich nichts anderes als der Taster, außer dass er das Einschalten quasi festhält, wenn man ihn loslässt? Tatsächlich könnten wir denselben Code auch mit einem Schalter nutzen, müssten dann aber immer nach dem Einschalten erst einmal aktionslos ausschalten, um dann wieder einzuschalten, was wir natürlich nicht wollen. RavenSystem bietet exakt für diesen Fall den Press Type "t":0 an, der das "Gegenteil" von "t":1 bewirkt. Da wir beide Types für den GPIO 13 aktivieren wollen, notieren wir einfach beide Keys mit Kommatrennung als Array.

{"a":[{"t":30,"ty":1,"g":[102],"b":[{"g":13,"t":1},{"g":13,"t":0}]}]}

Oder wiederum um den Standardwert gekürzt:

{"a":[{"t":30,"ty":1,"g":[102],"b":[{"g":13},{"g":13,"t":0}]}]}

Jede Schalteränderung wechselt ab sofort den Schaltstatus der Lampe. So war’s gewollt. Es gilt noch zu bedenken, dass Schaltungen über die Home App zwar selbstverständlich noch ausgeführt werden, dass sich dadurch aber natürlich die Schaltpositionen des physischen Schalter vertauschen. Solche Schalter mit eindeutigen Symbolen für den Schaltzustand können also womöglich irritieren, wenn derselbe also auf "Ein" steht, zwischenzeitlich aber per App umgeschaltet wurde, sodass man gegen die langjährige analoge Erfahrung den Schalter auf "Aus" schalten muss, um die Lampe wieder einzuschalten.

Zitat von loonypac

python3 -m esptool --port /dev/cu.usbserial-14230 read_flash 0 0x400000 /Verzeichnispfad-fürBackup/HAA-Backup-Name.bin

Der Befehl erzeugt auf meinem Mac eine Beschwerde über einen fehlenden USB-Port:

A fatal error occurred: Could not open /dev/cu.usbserial-14230, the port doesn't exist

Ich habe es daher mit der Portangabe vom erprobten Fullhaaboot-Flash probiert:

python3 -m esptool -b 115200  read_flash 0 0x400000 D1mini.bin

Das scheint zu funktionieren, eine D1mini.bin wurde erstellt und lässt sich auf einen anderen D1mini übertragen mit:

python3 -m esptool -b 115200 write_flash 0 D1mini.bin

Im Setup-Mode des neuen D1mini wurde noch ein "Reset HomeKit ID" veranlasst, damit sich Neu und Alt nicht in die Quere kommen. Jetzt hab ich also zwei Geräte - einen nackt und einen (für das Steckbrett) mit Stiftsockelleisten verlötet. Die Experimente mit der Peripherie können also beginnen.

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_id

ermittelt 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.

Zitat von loonypac

Edward J. Nately III macht weiter

The show must go on.

Ich war nur ein paar Tage auf Dienstreise und hab die HK-Bereitschaft des D1mini wohlgesonnen aus der Ferne betrachtet.

Zitat von loonypac

Ich hatte dabei ja erwähnt, dass der Port

...

ermittelt werden kann

Ok, jetzt verstehe ich den Befehl. Geht aber (wie gesagt) auch ohne.

Zitat von loonypac

Es ist mir ein Rätsel, dass sich das noch nicht auf breiter HomeKit Front durchgesetzt hat.

Das war hier schon mal Thema. Sebbo187 hatte Raven für den MagicHome Controller vorgestellt. Wahrscheinlich habe ich das Anno 2019 auch probiert (daher war wohl esptool bei mir schon installiert), es aber nicht an's Laufen bekommen und die Tragweite des Systems damals überhaupt nicht begriffen. Das ändert sich gerade

Zitat von loonypac

Die Besonderheit, dass die LED im Zustand "low" also quasi invers einschaltet

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.

Mit wieviel mA darf man die Ausgänge eigentlich belasten? Im Netz findet man unterschiedlichste Angaben.

Noch ne Frage zu diesem kleinen, mit "Reset" beschrifteten Taster auf dem D1: Was für ein Reset macht der? Werkszustand oder nur Warmstart? Und wie lange bzw. wie oft muß man ihn dafür drücken?

Zitat von Edward J. Nately III

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.

Zitat von Edward J. Nately III

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.

Zitat von Edward J. Nately III

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?

Zitat von Edward J. Nately III

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.

Zitat von loonypac

Andersrum gefragt: Was willste denn anschließen?

Später mal Relais. Die werden dann aber entkoppelt. Zum Testen hab ich jetzt LEDs dran. Mit dem empfohlenen Vorwiderstand von 330 Ohm fließt weniger als 1 mA. Das glimmt daher nur. Für etwas mehr Helligkeit wollte ich wissen, was man den Ausgängen zumuten kann.

Hab mal lose recherchiert. 220 Ohm sollten reichen.

Zitat von walta

Will man selber löten dann empfehle ich einen Mosfet.

Ich liebe den Geruch von Kolophonium am Morgen - in dem genannten Fall ist das Selberlöten aber unsinnig. Die fertigen Relaisbausteine sind einfach zu billig. Hab bereits welche gekauft und einen auch schon angeschlossen. Funktioniert!

Zitat von walta

Da gibt es Typen die bei 3,3V einiges an Leistung schalten können.

Ja, vielleicht für den Antrieb von RGBW-Stripes interessant. Da habe ich noch keine fertigen Module für ESP-Anwendung gesehen. Muss man aber wahrscheinlich nur etwas intensiver suchen. Mittlerweile gibt es ja nix mehr, was es nicht gibt.