HAA Raven System Firmware für ESP Geräte

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…

Moin walta Nach kurzem Einlesen muss ich mal fragen, was hat das mit Homebridge zu tun?

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

Danke. Die Erklärung und Vergleich mit Shelly, nehme ich für den Moment mal so an. 😅

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.

Somit erst einmal, Gruß.

Zitat von DJay

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.

Danke. Ich hab mich dort nämlich auch schon ein bisschen umgetan, aber noch nix gerafft. Daher begrüße ich es, dass ich hier noch ein bisschen mitlesen darf. Vielleicht springt ja irgendwann eine Step-to-Step-Anleitung dabei raus

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.

Erstmal danke für deinen Beitrag.

Zitat von loonypac

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 )

Naja, ich wollte damit sagen: ich schreibe so eine Anleitung. Wenn ich erstmal selbst kapiert habe, wie irgendetwas Komplexes funktioniert, dann schreibe ich es eh für mich auf - so war es vor ein paar Jahren auch bei der Homebridge. Aber bevor hier alles mit offenen Nüstern drauf wartet: ich kann nicht einmal garantieren, dass ich mich überhaupt damit beschäftige.

Zitat von loonypac

Beispiel: 3 virtuelle Schalter + 1 virtuelle Lampe (innerhalb 1 Microcontrollers) sind bereits mit einem sehr überschaubaren Script in wenigen Minuten in HomeKit integriert.

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. Ok, es ist "nur" JSON, aber ist das die Richtung dieses Forums? Natürlich kann man argumentieren, dass das bei der Homebridge ja auch nicht anders ist, und ich selbst habe hier vor Jahren irgendwelche Bash-Skripte veröffentlicht, die hier mit einer gewissen Befriedigung aufgenommen wurden. Dabei haben viele nicht kapiert, wie und warum man jetzt jetzt was macht, und dann kamen die Stolperfallen, und dann wurde es technischer, als es eigentlich gut war.

Damit hängst du dann die Leute endgültig ab. Das erzeugt Frust ("wieso kapier ich den Mist nicht?"). Das ist bestimmt nicht im Sinne des Forengründers und seinen Mitstreitern. 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?

Trotzdem unterstütze ich jetzt erstmal, dass wir hier im Forum solche Entwicklungen betrachten und irgendwie gangbar machen. Am Ende ist dieses Forum hier aber keine demokratische Veranstaltung. Ich jedenfalls zahle hier keinen Cent dafür, dass ich fremden Speicherplatz mit meinem Sermon verschwende.

Ich danke den Admins daher, dass sie uns erstmal mal machen lassen, vor allem vor dem Hintergrund, dass es nirgendwo anders eine Alternative gibt. Aber eine Garantie verlange ich hier nicht.

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.

Zitat von loonypac

Beim identischen Schriftverkehrsaufwand hätten wir statt Überzeugungsgeplänkel schon zig produktive Ideen besprechen können.

Genau das ging mir beim Lesen Deiner Enzyklika durch den Kopf: Statt einer epischen Rechtfertigung (denn die Absolution wurde ja von höchster Stelle bereits erteilt), wäre eine Erläuterung der einzelnen Parameter im Script tatsächlich interessant gewesen. Ich hab nämlich mit der Interpretation von {"a":[{"t":1,"i":0.1,"1":{"m":[[7002,601]]}},{"t"... auch so meine Probleme.

Zitat von sschuste

Das erzeugt Frust ("wieso kapier ich den Mist nicht?").

Wenn selbst ein sschuste es nicht auf Anhieb rallt, bin ich mir schon etwas weniger böse. Trotzdem könnte dies ja ein Hinweis sein, daß die Erklärung so rein didaktisch vielleicht noch ausbaufähig ist.

Am Interesse soll es aber keinesfalls mangeln.

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…

Aha! Genau das hat mir zum Verständnis gefehlt. Super! Muß ich aber erst mal durcharbeiten und sacken lassen. Noch unklar ist mir die Ankopplung der Hardware. Nehme an, man steuert Relais. Woher weiß der ESP welcher Ausgangs-Port mit

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

getriggert werden soll?

Ich danke und bitte gleichzeitig, mein mitunter etwas saloppes Auftreten nicht persönlich zu nehmen. So war und ist es nämlich nicht gemeint.

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.

Zitat von loonypac

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.

Ich auch.

Gut geschrieben! Vielen Dank, das hat mich jetzt doch sehr neugierig gemacht. Jetzt muss ich mir mal die Hardware anschauen und begreifen. Danach kommt das schlimmste: wofür werde ich das bloß einsetzen *grübel*

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.

Zitat von loonypac

So ganz ohne Stichelei geht das hier offensichtlich im Moment wohl noch nicht.

So ist das hier eben in diesem Laden. Da musst du durch .

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.

Zitat von walta

ESP Tool hab ich anders installiert

Nach der Anleitung auf github funktioniert es bei mir jedenfalls nicht. Schon auf das erste Kommando

python3 quit

meldet das Terminal:

/Library/Frameworks/Python.framework/Versions/3.11/Resources/Python.app/Contents/MacOS/Python: can't open file '/Users/nately/quit': [Errno 2] No such file or directory

Muß da ein sudo davor oder bin ich im flaschen Verzeichnis?

Will Python auf dem Mac erst noch aktualisiert werden?

Fragen über Fragen...

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 Edward J. Nately III

python3 quit

Vergiss das.