Beiträge von loonypac

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.

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.

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

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.

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 HolgerKR

War bei mir nur so semi, vermutlich weil die Zeit, bis der Dummyswitch in HomeBridge -> Home aktiv wurde, variierte. Aber du hast mich inspiriert, dem ganzen demnächst noch mal eine Chance zu geben.

Das hatte ich auch erst über Homebridge-PlugIn gelöst und bin letztes Jahr dann endlich umgeschwenkt auf das RavenSystem. Damit laufen derartige Dummy-Schalter nativ mit HomeKit und sind entsprechend deutlich geschmeidiger. Bei Interesse kannst du dich hier mal einlesen. Leider musst du große Teile erstmal durchschollen, bevor es nach einer hitzigen Off-Topic Grundsatzkontroverse in’s Produktive geht. Ich habe damit derzeit 75 virtuelle Schalter und Lampen in 4 ESPs umgesetzt und seit einigen Monaten ohne einen Ausfall in Betrieb.

Zitat von HolgerKR

Ein weiteres -von mir viel genutztes- Feature des "Hue Universums" ist, dass man die Bewegungsmelder bei Bedarf deaktivieren kann. Nützlich, wenn man per Schalter das Licht auf was anderes einstellt und der BWM einem dann nicht "dazwischen funkt". Etwas, was in HomeKit schlicht nicht vorkommt. Für Apple sind Bewegungsmelder "always on".

Genau diese Funktion nutze ich in HomeKit bis zum Abwinken mithilfe eines ganz simplen Fakes- bzw. virtuellen Schalters, der seinerseits über andere sinnreiche Automationen (bspw. sobald TV eingeschaltet wird), manuell über zahlreiche Aqara- und HUE-Schalter und nicht zuletzt über Siri entsprechend der kurzfristigen Anforderungen schnell umgeschaltet werden kann. Dieser virtuelle Schalter muss nur in allen Bewegungsmelder-Automationen als Bedingung integriert werden und schon ist alles im besten Sinne vielfältigst unter Kontrolle zu bringen.

Dabei werden die eigentlichen Bewegungsmelder also nicht deaktiviert und erkennen weiterhin Bewegungen, die dann für überlappende Automationen, die anderes außer Licht durch Bewegungen schalten, weiter aktiv bleiben. Ich schalte derzeit bspw. damit diverse Heizungsanhebungen, wenn ich mich in diversen Räumen befinde.

Hm, wenn ich den ersten Befehl ausführe, erhalte ich tatsächlich dieselbe Fehlermeldung, obwohl Python bei mir installiert ist. Das ist was für Terminalbefehl-Profis.

So wie ich’s verstanden hab, ist Python ohnehin in jedem neueren MacOs bereits standardmäßig installiert. Du kannst das auch über einen Installer von der Python Website (für Mac) in der aktuellen Version installieren.

Anschließend sollten die beiden in der RavenSystem Installationsanweisung aufgeführten Befehle zum Erfolg führen und das für das eigentliche Vorhaben essentielle ESPTool installieren.

python3 -m pip install --upgrade pip
python3 -m pip install esptool

Wenn danach der Befehl…

python3 -m esptool

... eine vielsagende Funktionsübersicht zeigt, solltest du loslegen können.

Zitat von HolgerKR

Wenn man deine Argumente so liest loonypac könnte man den Eindruck bekommen, die Hue Bewegungsmelder würden nur innerhalb des Hue Universums funktionieren.

Asche auf mein Haupt Das war natürlich so ganz und gar nicht gemeint, sondern das komplette Gegenteil: Ich empfehle ausdrücklich, die HUE-Bewegungsmelder in HomeKit und nicht im HUE System oder Drittanbiert HUE-Apps zu nutzen, wenn man ausgeklügeltere Automationen anlegen möchte. Schließlich habe ich meine sämtlichen Räume bereits seit Jahren ausschließlich mit den HUEs ausgestattet.

Tut mir leid, wenn das falsch verstanden werden konnte

Zitat von Dave69

nur an wenn im anderen Raum Licht nicht an

Allein das wird dir höchstwahrscheinlich mit dem HUE-System nicht möglich sein. Nach kurzer Recherche auf der iConnectHue Website sind Bedingungen (noch) nicht möglich, in der HUE-App sowieso nicht. Ich kann mich irren bzw. es gibt vielleicht Hilfskonstruktionen. Für meine Vorhaben ist mir die Sache allerdings viel zu eingeengt, grade weil der Einsatz von sinnvollen Bewegungsmelder-Automationen jenseits des berühmt-berüchtigten Treppenhauslichts ja doch recht tricky sein kann, was zumindest zahl-/endlose Beiträge zum Thema eindrucksvoll belegen.

Zum Glück kündigen sich endlich die ersten bezahlbaren, vielversprechenden Anwesenheitssensoren für HomeKit an. Mal schau’n, was damit so geht…

Zitat von Dave69

sonst ist Stress mit der Regierung vorprogrammiert.

In dem Fall würde ich dringend auf Bewegungsmelder-Automationen verzichten

Zu dem Thema passt das hier ganz gut, glaube ich.

Ich würde mir als erstes die eine Frage stellen:

Will ich mit den Bewegnunsgmeldern nur Gerätschaften schalten, die an der HUE-Bridge angemeldet sind oder will ich mir offen halten, alles, was in Apple Home so kreucht und fleucht und nicht HUE ist, in meine Automationen einzubeziehen? Wodurch sich je nach Antwort das "oder" im Beitragstitel durch ein "und" ersetzen ließe.

Dicht gefolgt von der zweiten Frage:

Reichen mir die verfügbaren Automationsbedingungen in den HUE-basierten Apps, oder möchte ich bspw. Kontaktsensoren von Aqara und/oder selbst gestrickte Fake-Schalter dafür verwenden, um bspw. per Ikea Switch oder per Siri mal eben die Bewegungsautomationen zu deaktivieren, um dieselben genauso schnell wieder zu reaktivieren, dies womöglich gleich für mehrere Räume gleichzeitig?

Nicht zuletzt ist eine zumindest meiner Prämissen, ALLES an Automationen MÖGLICHST innerhalb einer einzigen Infrastruktur zu konzentrieren und nicht in der einen Bridge jene Automationen und in der anderen App andere Automationen samt dem weiten Feld der Apple Kurzbefehle zu fragmentieren.

Letzteres ist natürlich REINE Geschmacksache.

Ach herrje, dann hat Apple das Problem offensichtlich immer noch nicht gelöst.

Sowas sehr Ähnliches ist bei mir schon mehrmals aufgetreten. Wenn du Lust hast, einen quasi historischen Roman zu diesem Thema durchzuarbeiten, könntest du dich hier mal durcharbeiten.

"Kurz" zusammengefasst samt neuer Erkenntnisgewinnungen:

Mit an Sicherheit grenzender Wahrscheinlichkeit nach wurde/wird deine Apple HomeKit-Umgebung nicht mehr korrekt synchronisiert und das wird sich von selbst über die Zeit meiner Erfahrung nach eher verschlechtern als von selbst regeln. Das ist die schlechte Nachricht und eigentlich könnte man hier schon aufhören und dir viel Glück dabei wünschen, alles nochmal von Grund – und zwar wirklich von Grund auf – neu aufzusetzen.

Da du das sogar selbst scheinbar ohne jegliche innere wie äußere Aufregung in Erwägung ziehst, ist das tatsächlich der sauberste und aussichtsreichste Weg, ein für eine unbestimmte Zukunft unbeschwertes Leben mit Apple Home zu führen.

In meinem Fall mit fast 100 Szenen und fast 250 Automationen winken nicht nur permanent die gnadenlosen HomeKit-Limits mit Totenkopffahnen, sondern schwant mir in wiederkehrenden Albträumen Fürchterliches bei der Vorstellung, dieses in Jahren wildgewachsene Puzzle nochmal bei Null zu beginnen. In der Tat würde ich das nicht mehr tun, sondern ohne Umschweife zum rettenden Eiland Home Assistant mit integriertem Red-Node überlaufen, um mich bei Apple Home durch dessen schmähliche Degradierung als GUI für all die vergeudeten Stunden Lebenszeit zu rächen. HomeKit und mich verbindet seit Jahren nur noch die gegenseitige Hassliebe gepaart mit der Unfähigkeit, sich voneinander zu trennen.

Szenen verschwinden von selbst – zumindest meiner Erfahrung nach – spätestens dann, wenn sämtliche darin enthaltenen Devices aus ihnen gelöscht werden. Und das macht sogar noch Sinn und wäre für mich ok. Tatsächlich passiert sowas allerdings auch darüberhinaus in gradezu willkürlicher und unvorhersehbarer Art und Weise, genau wie ebenfalls der von Mia beschriebene umgekehrte Fall, in dem bereits (mehrfach) gelöschte Szenen wie von Geisterhand als Zombies wieder auftauchen. Selbst die Unmöglichkeit des Löschens von Szenen/Automationen ist mir inzwischen nur allzu vertraut.

In meiner HomeKit-Biografie mit mehrfachen ähnlich gelagerten GAUs konnte ich Manches, wenn auch nicht alles retten, indem ich für sämtliche in HomeKit beteiligten Gerätschaften, iPhones, ATVs, iPad und Co die Home-Synchronisation innerhalb iClouds deaktiviert habe, auf denselben Geräten die Home-Apps gelöscht, sowie alle Apps von Drittanbietern beendet habe, die auf Home zugreifen, um nach einem rituellen Trauertanz ein Gnadengebet an Steve Jobs abzusenden. Nach 3 Fastentagen in einem verdunkeltem Raum ohne den virtuellen und physischen Kontakt zu menschlichen Wesen wagte ich dann heldengleich und zeitlupenhaft mit 1 Steuerzentrale in Gestalt eines Apple TVs die Wiederanmeldung in Apple Home. Danach wurde gleichermaßen ehrfürchtig jedes Gerät im selben Sinne einzeln dazugeschaltet, bis irgendwann alles mehr oder weniger rampuniert wieder so war, wie es dies vor Stunde Null war. Erst nach 2 bis 3 weiteren Tagen mit Nacharbeitungen konnte ich dann ein neues Leben als ein für immer Gezeichneter weiterführten und erste Nahrung aufnehmen.

Meine persönlichen Tipps wären…

• GRUNDSÄTZLICH alles das, was mit Alpha, Beta oder sonstigem griechischen Buchstaben beginnt – egal in welchem Zusammenhang – im Prinzip des Teufels und des Weihwassers aus deiner alltäglichen Smarthome-Umgebung von vornherein rauszulassen.
• So gut es geht, ALLE an Home beteiligten Geräte auf deren letzte Versionen zu bringen, um einen Mischbetrieb bspw. zwischen iOS 13, Catalina und AppleTVOS 16.2 zu vermeiden – Abwärtskompatibilität ist ein Relikt aus den 90ern. Also auch nicht veraltete Macs mit Home synchronisieren, die nicht mehr für das aktuellste MacOS kompatibel sind.
• Nicht sofort immer gleich die neuesten Major-Updates direkt nach (und schon gar nicht vor) ihrem Erscheinen installieren, sondern Geduld sowie demütige Genügsamkeit an den Tag legen und händereibend und sich in Sicherheit wiegend die zahllosen Frontkämpfer vorprobieren lassen. Unmittelbar und ganz von selbst tauchen allein in diesem Forum dann neue heißbegehrte und im Sekundentakt sich füllende Beiträge auf mit so Aufhängern wie "Habt ihr nach dem Update auch folgendes Problem…" oder "Anfänglich dachte ich noch, wow, alles geht schneller. Jetzt stelle ich leider fest, dass…"
• Nur soviel wie wirklich nötig mit Home zu synchronieren und nicht noch die verfügbaren 20 iPhones von Oma, Kumpel, Kind und Kegel, die Home gar nicht nutzen, auf Gedeih und Verderb mit Home anmelden. Das gilt umso mehr für diverse MacBooks, iMacs und Co, aber auch für abschaltbare Steuerzentralen, wenn man dieselben NICHT als Bluetooth-Repeater benötigt. 1 Steuerzentrale reicht, mehr bringen keine zusätzliche Performance – auch nicht im Jahre Anno 2023 – sondern in der Summe eher Ärger.

Diese Tipps sind unbelegbare Ahnungen aus meinem Leben zur Vermeidung zukünftiger GAUs und basieren auf der einfachen wie logischen Annahme, dass in einem komplexen System mehr Geräte auch gleichzeitig mehr potentielle Fehlerquellen sind. Apple lässt bis heute leider nicht mehr an Fehleranalyse zu.

Im Folgenden hab ich noch einen Artikel gefunden (leider nur als Screenshot), der beschreibt, wie man durch ein halboffizielles Profil Apple-Home sauber zurücksetzen kann – was lustigerweise allein durch seine Existenz belegt, dass da bei Apple Home was unsauber läuft bzw. laufen kann. Ich hab dazu keinerlei Erfahrung und gebe entsprechend keinerlei Gewähr.

Darin wird die Controller-App erwähnt, die alles Mögliche, wenn jedoch lang nicht alles in Home backuppen kann. Die hat mir mittlerweile mehrfach durch diese einzigartige Option den A…h gerettet, ist allerdings ein büschschen teuer geworden (Ich hab die Pro Lifetime Version damals in der Vor-Abo-Ära des vergangenen Jahrzehnts noch für 7,99 € erworben).

Zitat von sschuste

Jetzt muss ich mir mal die Hardware anschauen und begreifen. Danach kommt das schlimmste: wofür werde ich das bloß einsetzen *grübel*

Ach kuck, jetzt habe ich ein Stück weit überzeugen können. Die Mühe hat sich gelohnt. Das freut mich besonders

Für die Einsatzmöglichkeiten kann ich sicherlich einige gewinnbringende Vorschläge machen.

Zitat von sschuste

Wenn ich also recht begriffen habe, kauf ich mir so einen D1 mini, installiere ESP tool, flashe die Raven-Software drauf, häng den in mein WLAN und kann dann virtuelle Geräte abbilden und zusätzlich dort laufen lassen.

Yepp, gib/gebt mir etwas Zeit, dann konkretisiere ich das auch noch. Außerdem gibt’s noch ein paar Tricks und wichtige Hinweise, die einigen hassle ersparen.

Ich kaufe immer hier (gibt’s da auch einzeln). Ist im Vergleich zu deinem Link günstiger.

Hey Edward J. Nately III , freut mich, wenn’s etwas Licht in’s Dunkel gebracht hat. Der Rest = vergeben und vergessen.

Genau die Thematik kann bei einem der nächsten Abhandlungen konkretisiert werden. Soviel sei verraten: Es kann weitaus mehr als nur Relais gesteuert werden. Sieh dir die Service Types an, dann bekommst du eine Ahnung was geht.

RavenSystem – Einstieg in das Scripting
HomeKit lernt dabei das Zählen, bekommt Speicherplätze und Zeitschalter

Der einmalige Installationsaufwand wurde ja bereits von walta weitestgehend beschrieben. Zusatzinfos können im späteren Beitrag unter der Überschrift "RavenSystem – Installationshilfen und Grundsätze der HomeKit Integration" nachgelesen werden.

In diesem Beitrag dreht es sich primär um die Nutzung einzelner ESP8266 und damitverbunden um zwei von mir genannte RavenSystem-Schwerpunkte, nämlich die "Funktionserweiterung" von HomeKit sowie die Entwicklung ganz eigener HomeKit-Devices. Es wurde ja bereits vermerkt, dass auch ESP-basierte fertige Produkte wie die berühmten Shellys, Sonoffs etc. auf die gleiche Weise für die direkte HomeKit-Nutzung umprogrammiert werden können. Letzteres soll an dieser Stelle erstmal unberücksichtigt bleiben.

Grade für den Anfang kann übrigens der HAA JSON Configurator recht hilfreich sein, um schnell mal Skripte vorzuentwerfen. Der bildet allerdings nur Ausschnitte dessen an, was möglich ist.

RavenSystem oder auch ESP-HomeKit-Devices nutzt wie gesagt für die gesamte Device-Programmierung eine JSON-Syntax (und damit keine Programmiersprache), die zumindest alle Homebridge-Freunde aus der dort berühmt-berüchtigteren config.json bereits kennen und lieben gelernt haben. Man muss bestimmte Schreibweisen, Klammern und Satzzeichen richtig setzen und formatieren, damit der Code akzeptiert wird und keine Syntaxfehler erzeugt, was der ESP gnadenlos ablehnt. Im Unterschied zur Homebridge-JSON reduziert bzw. komprimiert RavenSystem den Code weitestgehend, um denselben für den vergleichsweise begrenzten Speicherplatz eines ESP zu optimieren. Alle Zeilenumbrüche, Leerzeichen werden eliminiert, vollständige Begriffe wie accessory, configuration, service type etc., die in der Homebridge json noch mehr oder weniger verständlich nachvollziehbar sind, stehen in RavenSystem nur noch mit maximal 2 Buchstaben im Code. Das erschwert schonmal eine direkte Nachvollziehbarkeit und erklärt die Ratlosigkeit Unbedarfter beim Anblick des Codes, selbst, wenn dieselben die Homebridge config.json im Schlaf editieren können.

Ich nehme für den Anfang mal den kleinstmöglichen Code, durch den man in HomeKit bereits ein Device, nämlich einen einfachen Schalter mit AN/AUS-Funktion erzeugen kann.

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

Das "a" steht dabei für Accessories und leitet grundlegend und zwingend jenen Bereich ein, in dem die für HomeKit geplanten Devices der Reihe nach definiert werden können. Womit wir direkt zum "t" gelangen. Dieser essentielle sogenannte Key bestimmt für HomeKit nicht mehr und nicht weniger als den Service Type – was also soll das für ein Device in HomeKit sein. Im ersten Beispiel wird der Service Type durch die Zahl 1 zu einem Schalter definiert. Will ich statt dessen eine Steckdose haben, wähle ich statt der 1 eine 2 und HomeKit wird wie von Geisterhand den ESP als Steckdose verinnerlichen.

Raven System lässt derzeit 35 verschiedene Services zu, die HomeKit versteht und die sicherlich zukünftig erweitert werden, zumal Lücken in der Zahlenfolge zu bemerken sind. Jedes dieser Service Types hat seine eigenen Zusatzkeys mit entsprechenden Funktionsbeschreibungen, die weitestgehend das ermöglichen, was kommerzielle lizensierte HomeKit-Produkte anbieten, aber darüberhinaus auch noch wesentlich mehr an Funktionserweiterungen können. Eine vollständige Übersicht samt Nummern-Codes ist auf der Service Type Seite zu finden.

Da ich es grad erwähne. Die GitHub Website von RavenSystem ist eigentlich vergleichsweise umfangreich dokumentiert und beinhaltet sogar eine Wiki, was für derartige Gratis-Projekte nach meinen Erfahrungen keineswegs eine Selbstverständlichkeit ist. Diese reicht im Grunde aus, um das gesamte Konzept autodidaktisch zumindest grundlegend zu verstehen, zu erlernen und damit zu produzieren. Es handelt sich um keine Raketentechnologie und kann von jedem/jeder unterhalb des Einstein-IQs verstanden werden, die schonmal irgendwas mit einem Code angestellt haben. Wie immer ist es natürlich eine Frage, wie komplex will ich etwas haben, was zu anspruchsvolleren Codes führt. Aber wo ist das in Smarthome anders? Jeder wächst da doch schließlich regelmäßig mit seinen Aufgaben.

Nun wissen wir also schonmal, wie wir einen Schalter oder eine Steckdose auf völlig unaufwändige Weise produzieren. Allerdings haben wir grad das eine durch das andere mithilfe einer Zahl ersetzt. walta hat bereits den nächsten Schritt vorgezeigt:

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

Durch einfaches Aneinanderreihen von kommagetrennten Service Types können wir weitere beliebige HomeKit Devices erzeugen. Im obigen Fall somit 1 Schalter + 1 Steckdose.

Lampe gefällig? Für den Anfang erstmal in virtueller Form:

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

Und schon gibt’s was Neues. Schnell zu erkennen ist der zusätzliche Key "ty" innerhalb des Lampen Service Types. Eben noch haben wir 1 Schalter + 1 Steckdose ausschließlich mit einem einzigen Key definiert, bei der Lampe wird’s komplizierter, da es naturgemäß in HomeKit schließlich verschiedene Lampenarten gibt, solche, die sich nur ein- und ausschalten lassen bishin zu solchen, die zudem mehrkanalige Steuerungen für Farb- und Weiß-LEDs zulassen. Aus diesem Grund muss der Service Type 30 für Lampen noch weiter konkretisiert werden durch den Key "Type" oder "ty". In diesem Fall die besagte virtuelle Lampe, die durch den Wert 0 für HomeKit nutzbar gemacht wird.

Wir nähern uns meinem Beispiel einer interagierenden Schaltgruppe an. Bisher haben wir voneinander unabhängige und leblose HomeKit Devices auf einfachste Art produziert, die bereits in diesem Stadium die meisten Homebridge PlugIns für virtuelle Schalter in ihrer Daseinsberechtigung bedrohen. Als nächstes basteln wir uns einen Timer in Schalterform:

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

Das war’s schon. Der definierte Timer in Schalterform wird, nachdem er in HomeKit manuell oder per Automation eingeschaltet wurde, immer exakt nach 30 Sekunden selbständig wieder ausgeschaltet. Der Key "i" für "Inching Time" lässt genau solche Rückschaltungen zu, wobei der dafür eingebbare Wert vom Typ Float ist, also im Unterschied zu den bisherigen Keys auch Nachkomma-Werte zulässt, was besonders in Zeitbereichen unterhalb 1 Sekunde sinnvoll wird. Der kleinstmögliche Wert ist dabei 0,02 Sekunden bishin zu Zitat "very large". Jeder, der in der Lage ist Sekunden in Minuten, Stunden, Tage umzurechnen, sollte also sehr schnell alle Timer, die man so zum Leben braucht, in einem kleinen Microprocessor HomeKit-ready umsetzen können.

Wie wär das schön, wenn man jetzt noch den einen Service Type mit dem anderen schalten könnte. Da ich das ja im Vorfeld bereits mit meiner Schaltgruppe als möglich angepriesen habe, nähere ich mich der Endrunde, ohne weitere Spannung samt Trommelwirbel aufzubauen, und stelle die vielsagenden "Actions" von RavenSystem anhand zweier Unter-Actions vor:

Wir haben ja bereits Schalter, Steckdosen und sogar Lampen in RavenSystem kennengelernt. Was allen gemein ist, sind die enorm zielführenden Fähigkeiten, dieselben ein- und auszuschalten zu können. In RavenSystem nennen sich diese Fähigkeiten "Service Action", die also von den Service Types selbst ausgeführt werden. Die Genannten bieten dementsprechend exklusiv für beide Schaltzustände je einen Key in Form "0" und "1". Ich verrate jetzt nicht, welcher welchen Zustand beschreibt und gebe die Enträtselung als Hausaufgabe auf.

Mit beiden Keys lassen sich unabhängige, unterschiedlichste weitere Actions auslösen. Hierauf gehe ich an dieser Stelle nicht ein, sondern schwenke direkt über zu den sehr mächtigen "Service Notifications", die ich im besagten Beispiel verwendet habe und beginne zunächst mit der Grundkonfiguration der Schaltgruppe, die nunmehr von jedem besagten "Blinden" verstanden werden sollte:

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

Oder übersichtlicher und Homebridge like:

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

Das Setup beginnt mit 2 Schaltern, gefolgt von 1 virtuellen Lampe, gefolgt von 1 Schalter. Wer immer noch nur Bahnhof versteht, sollte sich spätestens jetzt ohne Umwege in das Homebridge-Forum begeben, dort sein Glück suchen und RavenSystem ganz schnell wieder vergessen!

Ich fange mit dem ersten Schalter an. Der soll der virtuellen Lampe beim Einschalten eine Message schicken: "Hey Lampe, erhöhe deinen Dimmwert um 1!" Hierfür muss ich zunächst wissen, an welcher Stelle die Lampe bezogen auf auf den Schalter steht. Relativ zum Schalter 1 ist die Lampe der übernächste Service Type. Dann soll die Lampe den derzeitigen Dimmwert um 1 erhöhen.

Der einleitende Key für die Service Notification Action ist "m". Danach brauchen wir für mein Beispiel nur noch 2 Werte, die die Action an die Lampe weiterleiten. Als extrahierter Code sieht das dann so aus:

{"m":[[7002,601]]}

Die gewählte Zahl 7002 im konkreten Beispiel lässt sich in RavenSystem schnell unter der sogenannten "Target Service Number" ermitteln. Dabei gibt es grundsätzlich überschaubare 3 Zielort-Möglichkeiten.

1. Ich will die Service Notification an den Schalter selbst schicken
2. Ich will die Service Notification an ein den Schalter nachfolgendes Device schicken
3. Ich will die Service Notification an ein vor dem Schalter befindliches Device schicken

Fall 1 und und 3 scheiden im Beispiel aus, bleibt der Fall 2 für den ich einen in RavenSystem festgelegten Wert 7000 mit jener Zahl addieren muss, die den Abstand zum Zieldevice beschreibt. Umgangssprachlich würde man spontan sagen:"Na, das übernächste soll’s sein". Da man übernächstes nicht mit 7000 addieren kann, hat sich der Entwickler die mathematisch korrekte Umrechnung Übernächstes = 2 einfallen lassen, sodass es nun nur noch die Herausforderung der Summenbildung zu meistern gilt. Wer hätt’s gedacht 7000 + 2 = 7002. Bingo, die virtuelle Lampe kann somit vom Schalter angestuppst werden, um ihr… ja was eigentlich mitzuteilen?

Da die Lampe leider bestenfalls Zahlen versteht, brauchen wir nun noch einen Wert, der die Lampe im gewünschten Sinn anweist ihre Helligkeit um 1 zu erhöhen. Glücklicherweise hat die Lampe ganz eigene, verschiedene Service Notifications, die sie versteht. Bspw. kann ihr über eine Zahl gesagt werden, dass sie ein- oder ausgeschaltet werden soll, dass sie einen absoluten Wert für die Helligkeit einstellen soll oder dass sie um einen bestimmten Wert die Helligkeit erhöhen oder verringern soll. Und exakt Letzteres ist ja genau unser Begehr!

RavenSystem stellt dafür einen Zahlenbereich zur Verfügung, um genauer zu sein 2 Zahlenbereiche. Alles zwischen 600 bis 700 erhöht die Helligkeit, alles zwischen 300 und 400 verringert dieselbe. Da wir im Beispiel um 1 erhöhen wollen, ergibt sich die Zahl 601, die die Lampe ohne Meckerei akzeptiert und korrekt ausführt. Mit der Zahl 610 würde der Schalter mit jedem Einschalten um 10 erhöhen. Stop, halt…! "mit jedem Einschalten" schreibt der Mann, aber woher weiß die Lampe denn, dass das eben nur beim Einschalten und nicht beim Ausschalten passieren soll?

Und schon stoßen 2 Action-Arten aufeinander und werden miteinander verwoben. Weiter oben erwähnte ich ja bereits die "Service Actions" des Schalters und löse gleichzeitig an dieser Stelle nun das Rätsel, welche Service Action des Schalters für das Einschalten steht: Trärä… es ist die "1" – wer hätt’s gedacht. Dieselbe wird für die Programmierung genau wie andere Keys eingebaut und ergibt gemeinsam mit der bereits hergeleiteten Service Notification Action:

"1":{"m":[[7002,601]]}

Beim Ausschalten mit der Service Action "0" des Schalters passiert nichts, da diese nicht definiert ist. Jetzt will ich nur noch erreichen, dass ich nicht jedesmal, nachdem ich den Schalter 1 gedrückt habe, denselben erst wieder ausschalten, um ihn wieder einzuschalten, also eine Art Tasterfunktion. Ich sage nur "Timer", allerdings diesmal in ziemlich schnell. Mit einer Verzögerung von 0,1 Sekunden schaltet sich im folgenden fertigen Schalter derselbe ratzfatz aus:

{"t":1,"i":0.1,"1":{"m":[[7002,601]]}}

Aufmerksam Lesende sollten bereits an dieser Stelle in der Lage sein den zweiten Schalter zu reproduzieren. Der wiederum soll ja die Lampe beim Einschalten um den Dimmwert 1 verringern. Dazu ist bereits alles erklärt und bis auf die beiden Zahlen in der Service Notification des ersten Schalters kann das gesamte Konstrukt von Schalter 1 kopiert werden, um genau 2 Zahlen anzupassen. Da die Lampe von Schalter 2 aus gesehen das nächste Device ist, machen wir aus der 7002 eine 7001. Da der Dimmwert verringert werden soll, ändern wir entsprechend auf 301 und sind fast fertig.

Schalter 4 ist nicht vergessen. Der soll den Dimmwert der Lampe auf einen festen Wert von 1 stellen. Seine Position folgt der Lampe oder umgekehrt ausgedrückt, die Lampe steht vor dem Schalter. Für diesen Fall müssen wir gar nicht mehr addieren, sondern abzählen, an welcher Stelle die Lampe bezogen auf den Schalter steht und die Zahl mit einem nachvollziehbaren Minuszeichen versehen.

Doch halt, diesmal soll der Dimmwert absolut sein. Auch kein Problem, denn dafür hat RavenSystem exklusiv für Lampen den Zahlenbereich 2 bis 102 reserviert, der alle Werte zwischen 0 und 100 zulässt. Die größte Herausforderung hierbei liegt nun darin, den Zahlenwert zu ermitteln, der den gewünschten Dimmwert der Lampe auslöst. Mein heißer Tipp: Gewünschter Dimmwert + 2 = Zahlenwert für die Service Notification des Reset-Schalters.

Da wäre noch ein kleines Detail, das ich fast vergessen hätte. Die Schaltgruppe, die ich für mich konzipiert hatte, sollte die virtuelle Lampe bei jedem Booten des ESP in HomeKit immer erstmal einschalten, schließlich verbrauchen virtuelle Lampen keine Energie und können 24/7 ohne schlechtes Gewissen durchleuchten. Für diesen Zweck gibt es den alleserklärenden Key "Initial State" oder kurz "s". Warum dieser Wert in meinem Beispiel auf 1 gesetzt wurde, muss nun selbständig bis zum womöglichen nächsten Mal ermittelt werden.

{"a":[                                        
    {"t":1,"i":0.1,"1":{"m":[[7002,601]]}},
    {"t":1,"i":0.1,"1":{"m":[[7001,301]]}},
    {"t":30,"ty":0,"s":1},
    {"t":1,"i":0.1,"1":{"m":[[-1,3]]}}
]}

Wer es nicht erkannt hat: Allein durch diese Schaltgruppe mit ausschließlich den virtuellen HomeKit-Services 3x Schalter und 1x Lampe wird HomeKit durch zwei Fähigkeiten erweitert:

1. HomeKit kann nun ohne Weiteres bis 100 rauf- und runterzählen und ermöglicht dadurch Automationen der Gestalt "nachdem Sensor x-mal meldet, kann Gerät y geschaltet werden", "wenn mehr als x Geräte eingeschaltet werden, kann alles außer y ausgeschaltet werden", "wenn mehr als x Personen im Zuhause sind, soll y geschaltet werden" etc.pp. Ergänzt man noch Timer, lässt sich innerhalb des ESP sogar eine zeitbedingte Zählerschalte für HomeKit konstruieren.
2. HomeKit erhält "Speicherplätze". Licht-, Heizungsszenen u.ä. können bspw. auf feste Speicher- respektive Dimmwerte gelegt werden und mit beliebigen HomeKit-Schaltern (und/oder direkt am ESP angebrachte Taster, Schalter) in der gewünschten Reihenfolge vor- und zurückgeschaltet werden. Oder statt Szenen schaltet ein bestimmter Dimmwert die gewünschten Geräte direkt, was hilft die begrenzten maximalen 100 Szenen in HomeKit sparsam zu nutzen. Durch weitere "Reset"-Schalter können dann auch ganz bestimmte Speicherplätze direkt angewählt werden.

Und das ist jetzt nur 1 Schaltgruppe, die noch ganz an der Oberfläche dessen kratzt, was RavenSystem an umwerfenden Actions noch so zu bitten hat…

Zitat von sschuste

Erstmal danke für deinen Beitrag.

Gern geschehen. Ich danke dir für dein Interesse und deine ausführliche Antwort! Und fühle mich dadurch gleichzeitig »ermächtigt«, weiterhin Off-Topic zu antworten.

Um nochmal grundsätzlich meine Rolle in diesem Beitrag klarzustellen:

Ich bin NICHT Autor desselben (hätte den ganz anders aufgezogen), sondern lediglich überzeugter Unterstützer des RavenSystems, das zwar nicht die einzige ESP-basierte HomeKit-Device-Schmiede ist (da wäre bspw. auch das sehr interessante und mächtige ESP-HomeKit-ADK neben anderen zu nennen), jedoch die einzige, die eine vergleichsweise einfache HomeKit-Device-Produktion ausschließlich über die besagten JSON-Skripte zulässt, was aus meiner bisherigen Erfahrung sehr schnell auch für Anfangende (wie mich selbst) hervorragend geeignet ist, als darüberhinaus aber auch Fortgeschrittenen Raum für komplexe Lösungen lässt.

Ich wollte deshalb walta unterstützen, der diesen Beitrag aus einem anderen konkreteren Thema an diese Stelle quasi extrahiert hat und habe versucht, grob zu umreißen, was man damit machen kann und was es einzigartig und effizient macht. Ich vermutete eine passende Gelegenheit, womöglich Interessierte und Gleichgesinnte zu finden, die unbedarft, neugierig und mit Interesse in die Materie einsteigen möchten und mit denen gemeinsam Projekte erdacht, erörtert und umgesetzt und Probleme gelöst werden – worin nach meinem Verständnis der grundlegende Sinn eines technischen Forums begründet liegt. Allein schon aus fachlicher Perspektive dürfte dagegen eigentlich auch niemand etwas einzuwenden haben, der ein spezialisiertes HomeKit-Technikforum publiziert.

In meinem Aufsatz wollte ich neben überzeugenden Basis-Vorteilen des Systems zudem anhand meines Beispiels eine ungefähre Vorstellung über die vergleichsweise überschaubare Komplexität einer bescheidenen Schaltgruppe geben, die meines Wissens weder mit HomeKit noch mit derzeitigen Homebridge-PlugIns umsetzbar ist. Dies, ohne die Schaltgruppe in jedem einzelnen Detail präzise zu erläutern und ohne darauf einzugehen, welchen Sinn eine solche Schaltgruppe in HomeKit machen könnte.

All das ist mir in deinem Fall sschuste offensichtlich schonmal nicht gelungen. Auch in deiner jetzigen Antwort überwiegen wiederum Skepsis und Missfallen – zu Unrecht, wie ich einmal mehr finde.

Zitat von sschuste

ich schreibe so eine Anleitung. Wenn ich erstmal selbst kapiert habe, wie irgendetwas Komplexes funktioniert

Und ich wiederum schreibe »so eine Anleitung« erst, wenn überhaupt jemand im Universum existiert, der das Werk lesen möchte, denn für mich muss ich’s nicht schreiben. Bislang scheint es in diesem Forum da offenbar keinerlei Bedarf zu geben. Damit kann ich leben.

Diese deine Aussage würde beim fairen Vergleich mit dem RavenSystem allerdings auch bedeuten, dass du im Falle Homebridge nicht nur erst die gesamte Infrastruktur samt Hardware und Software verinnerlicht haben musst (was sicherlich in deinem Fall der Fall ist), sondern sämtliche verfügbaren PlugIns samt ihrer Funktionen und Einrichtungen im Kern verstanden haben musst, um überhaupt beurteilen zu können, was mit Homebridge alles in welcher Weise möglich ist. Spätestens Letzteres bezweifle ich mal ganz voreingenommen. Das ist auch gar nicht möglich und vor allem nicht nötig, solange wir mit HomeKit, Homebridge und RavenSystem keine Sonden zum Mars schicken möchten.

Man kann sich natürlich darüber streiten, ob walta eine gute, genügend ausführliche und ansprechende Darstellungsform mit seiner Step by Step Darstellung gefunden hat, die nach seinem eigenen Bekunden gar keine sein sollte. Fakt ist, dass er nichts anderes gemacht hat, als mit eigenen Worten und individuellen Erfahrungen zu beschreiben, wie man einen ESP für RavenSystem initialisiert. Im übertragenen Sinne hat er quasi beschrieben, wie man Homebridge respektive RavenSystem ohne PlugIn respektive ohne Script aufsetzt. Das ist nach meinem Geschmack legitim und für gänzlich Unwissende hilfreich und stört als Letztes den Betrieb eines Forums. Nichts anderes wird hier in allen möglichen und unmöglichen anderen Zusammenhängen in holder Regelmäßigkeit von allen möglichen Teilnehmenden des Forums getan, ohne dass jeder Ansatz erstmal im Vorfeld kritisch beäugt wird.

Zitat von sschuste

Und dann kommt: {"a":[{"t":1,"i":0.1,"1":{"m":[[7002,601]]}},{"t"...

Tut mir leid, aber das sieht für mich nicht sehr überschaubar aus.

Im Sport nennt man sowas, glaub ich, ein Foul. Du greifst unfairerweise den komprimierten und unkommentierten Code auf, um damit den Anschein zu erwecken, dass daraus überhaupt nichts Verständliches oder Nachvollziehbares zu lesen ist. Zwei Zeilen tiefer habe ich dagegen präzise per strukturiertem Umbruch und Kommentaren beschrieben, was jedes einzelne Accessory ist und macht. Mit ein wenig Fantasie lässt sich mit dieser Übersicht sogar interpretieren, welcher Key bspw. die 0,1 sekündige Ausschaltverzögerung bewirkt.

Und nochmal: Ich habe diesen Code als Beispiel dafür genommen, um darzustellen wie überschaubar ein Code für 4 interagierende HomeKit Devices sein kann, ohne den Anspruch an den Tag gelegt zu haben, jeden einzelnen Key in Bedeutung und Anordnung zu erklären. Sowas kann man leicht klären, wenn es ein Interesse gibt, das zu klären.

Zitat von sschuste

Selbst ich habe bislang bei dem Raven-System so gut wie nix kapiert mit der Folge, dass ich mich frage: soll ich mir das wirklich antun?

Wow, der Satz hat mich dann etwas zusammenzucken lassen. Was willst du damit genau sagen? Man könnte es in dem Sinne lesen, dass, wenn DU als Homebridge-Kompetenz nix kapierst, es deswegen nix taugt??

Wahrscheinlich/hoffentlich war das nicht so gemeint! Die gute Nachricht: Man »tut sich nichts an«, wenn man sich ab und zu in ganz andere technische Konzepte/Projekte reindenkt. Ich habe davon jedenfalls Zeit meines Lebens profitiert und ich frage mich dabei: Warum nur wird hier wieder so eine negative Stimmung aufgemacht, über etwas, das offenkundig nicht verstanden wurde?

Ich habe vor Jahren mit ein bisschen beherzter Rumprobierei das Prinzip von RavenSystem recht schnell verstanden, schließlich gab’s und gibt’s nachvollziehbare Beschreibungen und Beispiele auf der GitHub-Seite. Mir erscheint RavenSystem aus dieser Erfahrung heraus sehr schlüssig, auf’s Wesentliche konzentriert und für jeden nachvollziehbar, der bereit ist, sich darin ein wenig reinzudenken. Ich weiß natürlich lange nicht alles im Detail, jedoch soviel, dass ich damit bereits zahlreiche sehr lohnende Devices für meine persönlichen Anforderungen realisieren konnte, die ich so nicht anders in HomeKit hätte umsetzen können und die vermutlich auch für andere Enthusiasten mit anderen Ideen fruchtbar sein könnten (spätestens dann, wenn ich die sich regelmäßig wiederholenden gewünschten Automationsoptionen lese, bei denen irgendwas nach Zeit X ein-, aus-, umgeschaltet werden soll ).

Zitat von sschuste

Am Ende ist dieses Forum hier aber keine demokratische Veranstaltung.

Auch das habe ich in meinem Beitrag mit anderen Worten genauso festgestellt. Nichtsdestotrotz sollten nach meinem Verständnis persönlich subjektive Vorlieben und Abneigungen keine Entscheidungen darüber auslösen, ob technische Themen zugelassen werden oder nicht, zumal wenn sie ausdrücklich in die publizierte Thematik passen und dieselbe bereichern. Also etwa im Sinne: Homebridge gefällt mir in all ihrer undurchschaubaren Komplexität, weil ich Shell-Skripte sportlich finde und weil das inzwischen alle machen. RavenSystem kenn ich nicht, versteh ich nicht und JSON mag ich nicht, deswegen kommt mir das hier nicht rein. Kann man natürlich als Betreiber genauso machen, was dann aber nicht unbedingt fachlich elegant ist.

Man könnte sich statt dessen zu einer positiven Sicht der Dinge hinreißen lassen, könnte den Hinweis von walta als Chance aufnehmen und das erste deutschsprachige Forum zu diesem Thema öffnen. Nicht meine Idee, sondern die von Spy, der dies gestern noch kurz hier postete, dann aber myteriöserweise wieder löschte – aus welchen Gründen auch immer. Böse Zungen könnten behaupten, er hat sich im Nachhinein näher mit RavenSystem auseinanderzusetzen versucht.

Wie dem auch sei, ich klinke mich aus dem Off-Topic jetzt endgültig mal aus. Beim identischen Schriftverkehrsaufwand hätten wir statt Überzeugungsgeplänkel schon zig produktive Ideen besprechen können.

Ich erlaube mir mal eine ausführlichere Antwort, die mit dem eigentlichen Thread-Titel zwar nicht viel zu tun hat, dennoch hoffentlich mal eine grundsätzliche Klärung/Entspannung bringt und – viel wichtiger – Interesse beim ein oder anderen weckt.

Zitat von DJay

oder der Thread passt nicht ins Forum, vergleichbar iOBroker, Node-RED etc. ❗️Inhalte von SmartApfel Forum HomeKit.Community

RavenSystem ist KEIN eigenständiges IoT und mit den Genannten schonmal gar nicht vergleichbar, sondern es läuft ausschließlich auf und mit HomeKit. Ich setze noch einen drauf: mehr HomeKit geht nicht, vor allem, wenn man seine Möglichkeiten mit den Voraussetzungen für dessen Betrieb in Relation setzt. Einmalig eingerichtet kann das Setup ausschließlich über eine json-Syntax von kinderleicht bis hochkomplex programmiert werden – vergleichbar mit einer Homebridge, für die man keinen Raspi, kein Betriebssystem, keine Plugins, sondern ausschließlich die config.json benötigt, um alle möglichen offiziellen Apple HomeKit Services damit zu realisieren. So gesehen ist RavenSystem damit »mehr« HomeKit als die hier im Forum geliebten Kurzbefehle, die ihrerseits weit über HomeKit hinausgehen und dasselbe nur u.a. »beinhalten«

RavenSystem will/kann Homebridge nicht ersetzen – allein schon weil es bislang ausschließlich auf die standardisierten Microcontroller ESP8266/8285 ausgelegt ist – sondern hat im Kernkonzept nach meinem Verständnis folgende Anwendungs-Schwerpunkte:

• Umfangreiche und flexible Eigenentwicklung von nativen HomeKit Devices aller Art
• Umprogrammierung marktüblicher Produkte (bspw. Sonoff, Shelly u.ä.) für native Nutzung in HomeKit samt der Möglichkeit Zusatzfunktionen zu integrieren
• "Überwindung" von Einschränkungen und funktionale Erweiterungen in HomeKit

Wie gesagt, all das unter der Voraussetzung der Verwendung besagter Microcontroller. Und mit denen allein geht schon jede Menge!

Zitat von DJay

Wobei das doch etwas umfänglicher und komplexer mit RavenSystem ist, als einfach nur eine Firmware über eine Browser UI auf ein Shelly zu laden.

Der Hinweis auf RavenSystem ist daher okay für mich. Wenn das Thema hier zu umfänglich wird als nur dieser Thread, dann bewerte ich das eventuell noch einmal neu.

Das Einzige, das man walta »vorwerfen« könnte, wäre tatsächlich nur die ursprünglich falsche Platzierung seines Threads in Homebridge-Bereich. Deshalb gleich den warnenden Dudu-Finger zu zücken, empfinde ich persönlich als etwas übertrieben und für den Betreffenden samt meiner Wenigkeit nicht grade motivierend, um hier zeitaufwändige Anleitungen auszuarbeiten, die bereits in den ersten Reaktionen überwiegend auf Skepsis statt auf Neugier und konstruktives Interesse stoßen.

DJay Ich hoffe bei deiner Ansage nicht, dass hier im Forum »umfänglicher« und »komplexer« als Ausschlusskriterien gelten. Ich hoffe außerdem nicht, dass nur dieser 1 Thread als Raum für das System zur Verfügung gestellt wird. Nach dem oben Erwähnten sollte je nach Anwendung RavenSystem in den meisten »Geräte«-Unterforen Platz finden dürfen, und zwar im vollständigen Einklang mit euren bisherigen Forum-Statuten. Wenn nicht, dann würde ich zumindest um eine Konkretisierung jenseits von Maßstäben wie »umfänglicher«/»komplexer« bitten Das ist natürlich euer Forum mit euren Entscheidungen, dennoch wäre es hilfreich zu wissen, wo es Sinn macht, die eigene Zeit für Beiträge zu investieren.

Zitat von sschuste

Vielleicht springt ja irgendwann eine Step-to-Step-Anleitung dabei raus

Neben der von walta am Anfang begonnenen Anleitung gibt’s bereits weitere sehr Konkrete:

kuckst du hier und hier. Zudem traue ich grade dir eine überdurchschnittliche JSON-Kompetenz zu

(Was will uns übrigens dein Smiley sagen )

In der Tat wären weitere detaillierte Beschreibungen von praktischen Anwendungen sehr förderlich für alle HomeKit-Bastelnden – nicht zuletzt auch für den Entwickler, der bedauerlicherweise als offenbarer Elektroingenieur zwar sehr kompetent im Umgang mit Schaltungen und Programmierung ist, nach meinem Geschmack jedoch bedauerlicherweise (wie so oft) marketingtechnisch da weniger glücklich agiert, um sein System einer breiten Masse schmackhaft zu machen.

Ich selbst kratze in der Thematik grade mal am Rand rum und bin bereits in dieser Phase begeistert, wie einfach ich HomeKit mit fehlenden Funktionen wie Timer, Counter ergänzen kann.

Beispiel: 3 virtuelle Schalter + 1 virtuelle Lampe (innerhalb 1 Microcontrollers) sind bereits mit einem sehr überschaubaren Script in wenigen Minuten in HomeKit integriert. Das für mich Besondere ist die recht einfache Möglichkeit, solch eine Accessory-Gruppe controller-intern interagieren zu lassen, um quasi eine vorgefertigte autarke funktionale Schaltgruppe in HomeKit zu integrieren, die dort trotz vergleichsweiser simpler Funktionalität nichtmal in Form einer Ansammlung von mehreren Automationen umsetzbar wäre:

{"a":[{"t":1,"i":0.1,"1":{"m":[[7002,601]]}},{"t":1,"i":0.1,"1":{"m":[[7001,301]]}},{"t":30,"ty":0,"s":1},{"t":1,"i":0.1,"1":{"m":[[-1,3]]}}]}

Dasselbe inklusive Formatierung und Erklärung:

// Einleitung des Accessory-Bereichs
{"a":[                                        
    // Schalter, der beim Einschalten das übernächste Accessory (Dimmbare Lampe) um 1 im Dimmwert erhöht und nach 0,1 s ausschaltet
    {"t":1,"i":0.1,"1":{"m":[[7002,601]]}},
    // Schalter, der beim Einschalten das nächste Accessory (Dimmbare Lampe) um 1 im Dimmwert verringert und nach 0,1 s ausschaltet
    {"t":1,"i":0.1,"1":{"m":[[7001,301]]}},
    // Virtuelle Dimmbare Lampe, standardmäßig eingeschaltet
    {"t":30,"ty":0,"s":1},
    // Schalter, der beim Einschalten vorheriges Accessory auf festen (Dimm)Wert 1 resettet und nach 0,1 s ausschaltet
    {"t":1,"i":0.1,"1":{"m":[[-1,3]]}}
]}

Nun könnte jeder dieses Grundscript direkt weiterverwenden und bspw. per Zusatz sogenannter Keys um die Möglichkeit physischer Schalter und/oder eine dimmbare LED zu ergänzen, womit das virtuelle Device ohne Umwege in eine selbst kreierte HomeKit-Hardware verwandelt würde.

Schalter sind nur ein winziger Ausschnitt; Sensoren, RGBW Lampen inkl. Dimmer-Funktion, IR-Fernbedienungen, Weiterleitung/Speicherung von Sensordaten, Sicherheitssysteme und alles, was das HomeKit-Herz begehrt, sind darüberhinaus damit realisierbar. Der Möglichkeiten und Fantasien sind kaum Grenzen gesetzt.

Wer die folgende, zugegebenerweise etwas ausufernde Kontroverse jenseits der eigentlichen Thematik überspringen möchte, um Wissenswertes zum eigentlichen Thema zu erhalten, kann ab hier weiterlesen oder die folgenden Einzelbeiträge zum Thema direkt auswählen.

• Was ist es, was ist es nicht
• Installationshilfen und Grundsätze der HomeKit Integration
• Einstieg in das Scripting – HomeKit lernt das Zählen, bekommt Speicherplätze und Zeitschalter
• Einstieg in die Welt der GPIOs – Wir basteln uns eine HomeKit LED Lampe
• HomeKit hält sich einen Wachhund und begrüßt und verabschiedet beliebige Netzwerkteilnehmer
• HomeKit lernt abzubiegen – Der flexible HomeKit Blinkgenerator
• HomeKit-Heizungssteuerung mit virtuellem Timer als Auslöser für Temperaturprüfungen – oder lieber gleich optimiert per Temperatursensor regeln?
• Der selbständige HomeKit Multitasking Wecker – Das Ende launenhafter HomeKit-Zeitschaltungen
• Kaskadenschaltungen – Schaltreihenfolgen mit individuellen Laufzeitverzögerungen
  (In der Entwicklung)
• Der frei konfigurierbare HomeKit-Timer – Völlig losgelöst von Raum und (Uhr)Zeit
  (In der Entwicklung)
• HomeKit erhält eine Stoppuhr mit allem PiPaPo (in der Entwicklung)

Fortsetzung folgt…

Zitat von walta

In der Fritz Box erscheint auch ein neues HAA Gerät mit IP Adresse - und das war es auch schon. Eigentlich müsste das Ding in setupMode erscheinen - tut sich aber nix. Safari kann die Seite nicht öffnen.

Da braucht man in der Tat etwas Geduld, muss ich zugeben. Mitunter hilft ein Reset beim D1 Mini oder das Ding einfach ein paar Sekunden stromlos machen und dann einfach mal für längere Zeit > 10 Minuten sich selbst überlassen. Wenn man eins geflashed hat, kann man daraus eine .bin-Datei klonen und weitere D1 direkt erstellen.

Hast du beim Einloggen für die letztendliche Adresse auch den Port 4567 eingeben? Also 192.168.xx.yy:4567.