zweitens Einarbeitungszeit. Wohingegen der Delay Switch der Homebridge schon direkt von ganz alleine in HomeKit auftaucht
Was eben nicht stimmt. Du kannst den Code direkt einsetzen, ohne ihn verstehen zu müssen. Der Switch taucht dann in HomeKit ganz genauso auf.
Ich möchte dich bitten, keine falschen Behauptungen zu posten über Dinge, die du ganz offensichtlich nicht verstanden hast. Herzlichen Dank!
Ich glaube aber auch, dass diese Nische (Du erkennst ja selbst, dass es hier auf wenig Anklang stößt), weniger das ist, was gewünscht wird.
Dazu ist zu sagen, dass dieses Forum nicht der Nabel der SmartHome Welt ist 
Die von dir bezeichnete Nische wird anderweitig sehr emsig genutzt – dies sowohl von Anfangenden als auch von Entwicklerprofis.
Als Nische wäre übrigens auch HomeKit zu bezeichnen, wenn man dessen Relevanz in’s Verhältnis zu den weltweiten Smarthome-Lösungen setzt. Nische ist deswegen nicht mit vernachlässigbar gleichzusetzen
und verspricht dann auch keine dauerhafte Funktion, wie ich das so interpretiere. Es braucht auch Pflege, wenn sich Dinge in Homekit ändern.
Doch, dauerhafte Funktion und Nein, keine Pflege.
Da die Homebridge + Delay Switches schon fix und fertig vorhanden sind, empfinde ich, nur nach dem gelesenen, dass dieses ESP und Raven einen Faktor 100 mehr im Aufwand hat, als die fertige Homebridge + Delay Switch Plugin zu nehmen.
Dann hast du ganz offensichtlich überhaupt nicht verstanden, dass mein Beispiel ebenfalls ein fix und fertiger Delay Switch ist
Sei’s drum, zuviel Lärm um Nichts: Ich gebe in deinem Fall auf und wünsche weiterhin viel Erfolg (und den Homebridge-Forumsteilnehmenden viel Geduld).
Du gibst Dir wahnsinnig viel Mühe. Klasse!
Ich mache mir die Mühe in erster Linie aus eigenem "sportlichen" Interesse. Deine Anforderung in eine konkrete fertige Raven-Lösung umzusetzen bot mir dabei mal zur Abwechslung die Gelegenheit, mich von meinen eigenen Ideen und Konzepten vorübergehend zu trennen und zu prüfen, ob das System universell auch für alle anderen HomeKit Nutzenden gewinnbringend sein könnte. Ich stelle fest: Das tut es. Nicht selten lese ich im Forum angedeutete Lösungen, die gerne mal aus der halbwissenden Hüfte geschossen werden. Kann man so machen, ist aber nicht so mein Ding.
Die in meiner Signatur wählbaren Links sollen Interessierten das an Hilfe bieten, was ich mir beim Einstieg in RavenSystem sehr gewünscht hätte. Die Beiträge sind zugegebenermaßen recht umfangreich, jedoch wollte ich in erster Linie das Grundverständnis für RavenSystem mit möglichst nachvollziehbaren Beispielen und Erklärungen deutlich machen, was hier im Forum aber bislang eher wenig Interesse erzeugt. Macht nix. Das Ganze ist meinerseits ein Versuch, der mir derzeit Spaß macht. Ich beobachte über die Jahre, dass, wie in anderen Lebenslagen auch, häufig eingefahrene Wege reflexartig beschritten werden, wenn eine Mehrzahl von Usern dieselben beschreitet, wodurch womöglich "bessere" Alternativen, die weniger populär sind, unberücksichtigt bleiben. Die immer wieder aufflackernde, fast schon prinzipienhafte Skepsis grade zu Anfang des Threads und in manchen Zwischenbeiträgen ist für meinen Eindruck ein ganz gutes Indiz. Wie sagte meine Mutti öfters: Man kann niemanden zu seinem Glück zwingen 
Ich verstehe da leider nur Bahnhof.
Der Beitrag baut auf die Vorherigen auf. Wie gesagt bin ich bemüht, das Grundverständnis über meine Einzelbeiträge nach und nach auszubauen. Das bedeutet dann allerdings, dass du von Anfang an lesen musst, um ein Verständnis für den Code zu bekommen. Von RavenSystem einmal abgesehen gilt das mindestens genauso für das weite Thema Homebridge. Um’s Schlauermachen kommst du also nicht drumrum, denn eben mal schnell 3 Sätze zu lesen, um ein komplexes Werkzeug zu verstehen, ist eine Illusion. Ich empfehle dir nochmal: Sei proaktiv und bleib neugierig! Außerdem kannst du Fragen stellen.
Und: was ist ein ESP8266 und wo soll ein Shelly sowas haben?
ESPs sind sehr kurz erklärt standardisierte, weltweit etablierte programmierbare Bauteile oder präziser Mikroprozessoren, die komplexe integrierte Schaltungen erlauben, indem selbsterstellte Programmcodes in diese miniaturisierte Hardware geladen werden. Dein Shelly beinhaltet solch einen ESP auf seiner Platine im Sinne eines "Gehirns", das Schaltbefehle in physische Schaltungen vis und versa umsetzt. Im einfachen Beispiel wird ein Schaltbefehl bspw. in HomeKit abgesetzt, gelangt per WLAN (über das der überwiegende Teil von ESPs verfügt) in den ESP deines Shellys und wird dort interpretiert, um ein Relais ein- oder auszuschalten. Schaltest du das Shelly per physischem Schalter, teilt wiederum der ESP über WLAN HomeKit mit, dass das Relais geschaltet wurde.
Da du bislang offenkundig keine Homebridge benutzt hast, muss der im Shelly integrierte ESP also umprogrammiert worden sein bzw. eine andere sogenannte Firmware erhalten haben, da Shellys ab Werk nicht nativ HomeKit kompatibel sind. Entweder hast du das selbst irgendwann mal nach Anleitung gemacht oder du hast dir eine bereits umgeflashte Version gekauft.
Standardisiert soll heißen, dass ESPs zwar eine einheitliche "Sprache" verstehen, deswegen aber nicht unbedingt allesamt baugleich sein müssen. Die hier in den Beiträgen oft zitierten D1 Mini sind z.B. separate ESPs ganz ohne fest verbaute elektronische Bauteile wie Relais, Schalter und Sensoren, die für ganz eigene Geräteentwicklung geeignet sind, so wie die in den mittlerweile zahlreichen Beispielen in diesem Thread. Einer von mehreren Vorteilen ist, dass du mithilfe eines einzelnen ESPs mehrere HomeKit Devices nicht nur nach den eigenen Vorstellungen eigenständig entwicklen kannst, sondern diese Devices innerhalb des ESPs zudem miteinander interagieren lassen kannst, was in dem jüngsten Beispiel hoffentlich klar geworden ist. Das ist schonmal ein großer Unterschied zur Homebridge, in der eben nicht beliebige PlugIns ohne Weiteres miteinander "verschaltet" werden können.
Im Unterschied zu einer Homebridge-Lösung benötigst du somit kein Betriebssystem samt Systemkomponenten (an denen du ja offenbar bereits in diesem Stadium schon scheiterst), du benötigst keinen PlugIn-Entwickler, der eine Lösung genau nach deiner Vorstellung als Download anbieten und zukünftig pflegen muss, da du selbst der Entwickler deiner Schaltungen bist. Außerdem kannst du wie gesagt beliebige elektronische Bauteile direkt mit dem ESP nutzen, um für HomeKit ganz eigene, eigenständige native Devices auszudenken und umzusetzen.
In RavenSystem (als eines von zahllosen weiteren SmartHome Projekten für ESPs) ist durch die Basis-Firmware vom Entwickler bereits alles in die Hardware integriert worden, um "nur noch" über den für dich bislang noch kryptischen Code, der einer JSON-Syntax entspricht, deine Geräteanforderungen zu definieren. D.h. es sind keine Programmiersprachenkenntnisse notwendig, die noch weitaus komplexer sind als die JSON Syntax und die zumeist erst sehr zeitaufwändig erlernt werden müssen.
Hier gleich die "schlechte" Nachricht für dich: Besagte JSON Syntax muss auch in der Homebridge zusätzlich zum bereits jetzt schon für dich grenzwertigen Installationsaufwand für die Konfiguration (config.json) korrekt durch dich ausgeführt werden. Du musst dich also so oder so mit der Syntax befassen.
Zusammengefasst empfiehlt sich eine ESP-Lösung für dich aus folgenden Gründen
(Alle Schaltungen werden komplett innerhalb eines ESP ausgeführt. Keine HomeKit-Automationen oder Kurzbefehle!)
*** Wer nicht lange lesen möchte und vorab einfach mal einen ESP mit dem Temperaturprüfung testen möchte, kann gegen Ende dieses Beitrags im Spoiler "Temperaturprüfer direkt auf D1 Mini flashen" eine fertige bin-Datei laden und auf seinen ESP flashen. ***
Heute will ich mal beispielhaft die praktische Anforderung eines Forumteilnehmers über das RavenSystem umsetzen, um zu verdeutlichen, dass nicht unbedingt eine Homebridge vonnöten ist, um trotzdem recht einfach ausgeklügelte Sonderfunktionen in HomeKit nativ zu integrieren. Besser noch würde ich inzwischen behaupten, dass die Umsetzung über einen ESP deutliche Vorteile gegenüber der gängigen Homebridge-Praxis bietet.
Dazu soll der Fall und die Anforderung von Sequoia nochmal konkretisiert werden.
Das Ausgangs-Problem: Das kürzliche HomeKit Update hat offensichtlich eine Möglichkeit eliminiert, durch beliebige Temperaturänderungen, die in einem Thermostat gemessen werden, Automationen nach folgendem Prinzip auszulösen:
Neuerdings wird solch ein Auslöser "beliebige Temperaturänderung" also aus unerfindlichen Gründen nicht mehr in HomeKit akzeptiert, statt dessen sogar selbsttätig gelöscht, was die Automation unbrauchbar werden lässt.
Ein alternativer Auslöser für die Automation wird nötig. Es bietet sich ein regelmäßig ein- und ausschaltender Timerschalter als Kompromiss an, der in frei bestimmbaren Schaltintervallen die Automation auslöst, die ihrerseits bei jedem Anstoßen durch den Timer überprüft, ob die Temperaturbedingung erfüllt ist, um letztendlich das Heizungsventil entsprechend zu öffnen oder zu schließen.
Prinzipiell ist dies mit geeigneten HomeBridge-PlugIns umzusetzen. Wenn allerdings allein schon ausschließlich für diesen einen Zweck eine Homebridge samt PlugIn aufgesetzt und gepflegt werden muss, stellt sich schnell die Frage nach der Verhältnismäßigkeit. Noch dazu wird Sequoia Ventilschaltung über ein Shelly ausgeführt, das bereits über einen geeigneten ESP verfügt, sodass dieser per RavenSystem für besagtes Projekt ohne weitere Hardware genutzt werden könnte.
Ich hatte ja kürzlich den HomeKit-Blinkgenerator ausführlich beschrieben. Das Schaltprinzip für die jetzt benötigte automatische Temperaturprüfung ist faktisch identisch mit der Blinkschaltung, die ich deswegen an dieser Stelle auch nicht nochmal aufrollen brauche. Ich fasse wie folgt kurz zusammen, was diese macht:
Ein weiterer Schalter soll wie beim Blinker diese endlose Hin- und Herschalterei schaltbar machen, was für die heutige Anforderung sogar entbehrlich wäre, da sie sinnigerweise gewollt endlos durchlaufen soll.
Im Unterschied zum Blinkgenerator macht es außerdem Sinn, dass das zyklische Schalten sofort beginnt, nachdem der ESP gebootet hat. Das standardmäßige Einschalten kennen wir bereits als "Initial State" Key "s":1.
Da wir nur einen der 2 Timerschalter für die Temperaturprüfung benötigen, soll der Timer 2 zwar in seiner Funktion zur Verfügung stehen, wir wollen ihn aber nicht in HomeKit anzeigen, sondern standardmäßig ausblenden. Letzteres erlaubt uns die "HomeKit Visibility" mit dem Key "h", den wir für unseren Zweck einfach nur auf 0 setzen müssen und per Komma getrennt in den Service Type einfügen. Außerdem reicht für Timerschalter 2 eine sehr kurze Schaltverzögerung, während der eigentliche Timer 1, den ich mal "Temperaturprüfung" nenne, alle 30 Minuten = 1800 Sekunden schaltet.
Wir könnten somit Timer 2 auf eine möglichst kurze Zeit im Millisekundenbereich schalten, wollen aber gerne die Schaltung in der Home-App sehenden Auges verfolgen können, was mit zu kurzen Verzögerungen aufgrund der HomeKit-Trägheit nicht möglich wäre. Bei 0,5 Sekunden spielt HomeKit noch mit, was zu folgendem Skript führt:
{"a":[
{"t":1,"s":1,"0":{"m":[[7001,1]]},"i":1800},
// Sichtbarer Timerschalter "Temperaturprüfung" schaltet alle 1800 s = 30 Minuten aus
{"t":1,"h":0,"0":{"m":[[-1,1]]},"i":0.5},
// Unsichtbarer Timerschalter zur Reaktivierung der Temperaturprüfung innerhalb 0,5 s
{"t":1,"s":1,"0":{"m":[[-2,0],[-2,-10000],[-1,0],[-1,-10000]]},"1":{"m":[[-2,-10001],[-2,1],[-1,-10001]]}},
// Manuelle De-/Aktivierung der zyklischen Temperaturprüfung
{"t":2,"1":{"s":[{"a":1}]}}
// Steckdose bzw. Lampe zur Aktivierung des ESP Setup Modes
]}Oder komprimiert und ladefertig für den ESP
{"a":[{"t":1,"s":1,"0":{"m":[[7001,1]]},"i":1800},{"t":1,"h":0,"0":{"m":[[-1,1]]},"i":0.5},{"t":1,"s":1,"0":{"m":[[-2,0],[-2,-10000],[-1,0],[-1,-10000]]},"1":{"m":[[-2,-10001],[-2,1],[-1,-10001]]}},{"t":2,"1":{"s":[{"a":1}]}}]}(In der Home App wurde die Steckdose als Lampe umdefiniert und setzt sich dadurch vom Temperaturprüfer-Duo noch deutlicher ab.
Den Temperaturprüfer in Aktion sieht man in der Animation zu Beginn des Beitrags)
Für Puristen, die auf den Firlefanz wie Setup Mode und De-/Aktivierungschalter verzichten wollen, reduziert sich das Ganze auf einen (vermeintlich) einsamen automatischen Temperatur-Prüfschalter in HomeKit:
{"a":[{"t":1,"s":1,"0":{"m":[[7001,1]]},"i":1800},{"t":1,"h":0,"0":{"m":[[-1,1]]},"i":0.5}]Soviel zu betriebsbereiten Skripten für einen eigenständigen ESP bspw. einem D1 Mini.
Die eben beschriebene Temperaturprüfung kann mit einem günstigen Temperatursensor + separatem ESP (z.B. D1 Mini) zugunsten einer echten Sensorregelung von Heizthermostaten umgebaut werden. Denn was spricht dagegen, die eben stupide durch regelmäßiges Ein- und Ausschalten in HomeKit durchgeführte Temperaturprüfung, die noch dazu den ESP stark unterfordert, durch eine integrierte Temperaturschaltung mithilfe eines Sensors im 1-stelligen Eurobereich über einen virtuellen HomeKit-Schalter für die Ventilsteuerung zu ersetzen?!
Mighty61 hat ja sein Projekt passend zu dieser Anforderung bereits vorgestellt – der selbstkreierte HomeKit-Doppel-Temperatursensor. Ausgehend von seinem Beispiel lässt sich ESP-intern eine Automation ergänzen, die es bspw. ermöglicht, bei bestimmten Temperaturen ganz bestimmte Aktionen auszuführen. So könnte ganz im Sinne von Sequoia beim Überschreiten einer beliebigen Zieltemperatur ein virtueller Schalter intern ausgeschaltet werden, um denselben beim Unterschreiten der Zieltemperatur wieder einzuschalten (Stichwort "Service Notification"). Wohlgemerkt all das innerhalb eines ESPs ganz ohne HomeKit. Dasselbe wiederum muss dann nur die im ESP ausgelösten Schalterzustände mithilfe einfachster Automationen für die Ventilsteuerung umsetzen
Immerhin kriegt sowas HomeKit dann doch noch einigermaßen zuverlässig hin 
Besagte Bedingungsschaltungen heißen in RavenSystem "Wildcard Actions" und werden durch die Keys "y[n]" im Skript verankert. "Minimale" Zielwerte legen dabei die Schaltgrenzen fest, über die eine Aktion ausgelöst wird.
In der konkreten Anforderung von Sequoia gibt es 2 Werte, bei denen die Heizungsventile geschaltet werden sollen, nämlich bei Unterschreitung von 21 Grad AN, bei Überschreiten von 23 Grad AUS. Für die eigentliche Schaltung bietet sich also wieder ein virtueller Schalter "t":1 an, der je nach Messung des am ESP verankerten Sensors simplerweise ein- und ausschaltet. Das Skript wird erstmal auf 1 Temperatursensor statt 2 Sensoren gekürzt und um einen Schalter ergänzt:
{"a":[
{"t":22,"g":14,"n":3,
// Temperatursensor
"y0":[
// Wildcard-Bedingungen wie folgt
{"v":0,"r":1,"0":{"m":[[7001,-10001],[7001,1]]}},
// Sensor aktiviert Schalter "t":1 zwischen 0 bis 21 Grad
{"v":21.1,"r":1,"0":{"m":[[7001,-10000]]}},
// Sensor deaktiviert Schalterfunktion "t":1 zwischen 21,1 bis 23 Grad
{"v":23,"r":1,"0":{"m":[[7001,-10001],[7001,0]]}},
// Sensor deaktiviert Schalter "t":1 bei mindestens 23 Grad
]
},
{"t":1}
// Schalter, der in HomeKit die Ventile per Automation schaltet
]}Oder komprimiert
{"a":[{"t":22,"g":14,"n":3,"y0":[{"v":0,"r":1,"0":{"m":[[7001,-10001],[7001,1]]}},{"v":21.1,"r":1,"0":{"m":[[7001,-10000]]}},{"v":23,"r":1,"0":{"m":[[7001,-10001],[7001,0]]}},]},{"t":1}]}Spy Danke für die Verwendung meiner Zitate. Ich würde mich trotzdem freuen, wenn ich als Autor zumindest genannt würde. *OT_Ende*
Die Reichweite meines e-autos…
… Gehöre zu den armen Schluckern die keinen Pool haben
…und ich hab nichmal’n E-Auto 
…trotzdem hätte ich gern gewußt, ob es sich als Raver lohnt, dort welche zu bestellen.
Ohne Gewähr: Das Raven sollte sich lohnen. Einer GitHub-Quelle in anderem Zusammenhang nach ist im R2 ein ESP8285 verbaut, den RavenSystem unterstützt.
In der "Device Database" ist er zwar nicht aufgeführt (nur R1), aber funke ihn doch einfach mal an und lass dir mitteilen welcher ESP verbaut ist:
python3 -m esptool read_macbzw.
python3 -m esptool flash_idWie schon oben an walta geschrieben ist der nächste Step eine PH Sonde an das Raven HAA System dran zu docken, Hast Du eine Idee welcher hier am besten geeignet ist?
PH-Sensoren werden bislang von HomeKit nicht unterstützt – zumindest nicht dass ich wüsste.
Entsprechend gibt es keinen Service Type in RavenSystem, durch den du den gemessenen Wert korrekt als PH-Wert in HomeKit anzeigen lassen könntest.
Es hat hier im Forum schonmal ein ähnliches Projekt zur PH-Messung gegeben, allerdings über Node Red und Homebridge. Leider ist da nicht mehr veröffentlicht worden, wie das Ganze am Ende umgesetzt wurde.
Als Sensor böte sich bspw. ein analoger pH Sensor an, der für RavenSystem die analogen Messungen in einem Temperatur Service Type und in Grad statt pH wiedergibt – das war offensichtlich auch der Ansatz des besagten Node Red - Homebridge Projekts. Vielleicht wäre das ein Ideenansatz für dich?!
Ich möchte mich bei dir nicht unbeliebt machen
Keine Sorge, ich bin sehr friedliebend und stehe auf Kontroversen 
Sei es weil … die Hersteller immer ein wenig außerhalb des Standards programmieren oder das volle Potenzial des jeweiligen Geräts ausgenutzt werden soll.
Na, genau das ist ja das Problem: Wenn ich als Hersteller immer meine eigene Suppe im eigentlichen Standard koche und vermutlich dazu noch das Rezept der Suppe für mich behalte (damit bspw. Phoscon oder andere Mitbewerber es nicht allzu leicht haben) wird das nix mit der Vereinheitlichung. Nicht, weil es nicht geht, sondern weil es nicht gewollt ist. *Verschwörungstheorie_Ende*
Zigbee Geräte können nicht direkt Teil von Matter sein, Zigbee Bridges hingegen schon.
Das ist schon klar. Ich wollte mit dem Zigbee Beispiel nur verdeutlichen, dass trotz Matterähnlicher Lippenbekenntnisse seitens der Hersteller bis heute jede Zigbee-Welt immer noch ihre eigene Bridge braucht. Conbee beweist andererseits recht plausibel, dass dies nicht nötig wäre, wenn da ein echtes Vereinheitlichungsinteresse bestünde.
Also für das HUE-Beispiel erahne ich, dass irgendwann die HomeKit-Schnittstelle zugunsten einer Matter-Schnittstelle eliminiert wird, was die Produktpflege enorm vereinfachen würde, dass ansonsten aber im internen Zigbee-Sende/Empfangsteil aber alles beim Alten bleibt. Laut @HolgerKR Quelle wird das durch Sätze wie folgt durch die Blume bestätigt:
"Außerdem bedeutet matter, dass wir weniger Integrationen pflegen müssen. Wenn sich der Standard mit der Zeit durchsetzt, wovon wir ausgehen, werden dadurch Kapazitäten frei für andere Dinge."
Das finde ich nicht wirklich fair. Hue ist nunmal auf Beleuchtung spezialisiert. Da sieht man ein das keine anderen Gerätetypen unterstützt werden.
Mein Smiley sollte zum Ausdruck bringen, dass der Satz nicht so ganz ernst gemeint war.
Nichtsdestotrotz: Wenn Zigbee ein Standard ist, sollte auch alles darüber herstellerübergreifend miteinander kommunizieren können. *Theorie_AUS*
Überträgt man die Konjunktive "sollte" ergänzt durch "könnte" auf Matter, erhält man recht klare Vorahnungen.
Ich bekomme es dadurch geregelt, dass alle meine HomePods nachts für 15 Minuten vom Strom getrennt werden. Damit habe ich in 99% der Fälle eine meiner beiden ATVs als Zentrale.
Wenn wie auch immer der Steuerzentralen-Status datentechnisch ermittelbar wäre, könnte man eine sehr schöne Automation basteln, die die HomePods immer dann neustartet, wenn sie sich mal wieder "vorgedrängelt" haben.
Außer besagten Status mit den eigenen Augen abzulesen fällt mir da aber bislang nix ein.
Mighty61 tolle Umsetzung
Vielleicht sollte man noch die von dir verwendeten Sensoren etwas genauer beschreiben. Die sind ja ziemlich spezialisiert und vor allem für deinen Zweck besonders geeignet, da wassertauglich. Mich überzeugt die Genauigkeit von ± 0,5 Grad und die Range -55 bis +125 Grad, zumindest laut Datenblatt, bei einem Stückpreis um die 2,– €. Damit könnte man auch Kochtöpfe smart machen
Gleich meine Frage an dich: Hast du die irgendwie kalibriert und wenn ja, wie?
Und warum sollte ein Hersteller Entwicklungsarbeit in die Integration von Konkurrenzprodukten stecken?
Der für mich springende Punkt zum Thema Matter.
Ich werde in Thema nicht wirklich schlau und alle Beiträge hier erscheinen mir mehr oder weniger Vermutungen zu sein. So’n paar (seriöse) Quellenangaben wären mitunter ganz hilfreich
Bisher wirkt Matter auf mich eher wie eine Marketing-Strategie der führenden SmartHome-Hersteller, die einen Pseudostandard für Smarthome anpreisen, um allerdings in erster Linie die Anpassungen ihrer eigenen Produkte an die verschiedenen Infrastrukturen von HomeKit, Alexa, Google und Co zu vereinheitlichen/vereinfachen, was die Produktentwicklungen kostengünstiger macht. Das Ganze dabei nach dem Motto: Alles kann zwar, muss aber zum Glück nicht.
Ich kann mir anno 2023 leider nicht vorstellen, dass bspw. Philips HUE alle Tore öffnet, um billigste ZigBee-Gerätschaften uneingeschränkt in ihr System einzuladen, ohne mindestens einschneidende Funktionsbegrenzungen davor zu setzen. Ich würd mich gerne irren 
Apropos ZigBee: Da war mal eine sehr ähnliche Motivation von Herstellern für eine "Zusammenarbeit" nachzulesen …
Im Dezember 2016 wurden für die Protokollversion 3.0 20 Zertifizierungen für acht Hersteller ausgestellt, um eine Vereinheitlichung im Bereich IoTvoranzubringen.[7] Durch die Zusammenarbeit mit Herstellern weltweit können Verbraucher zum Beispiel über intelligente Heizkörperthermostate ihre Heizung steuern, smarte Beleuchtungssysteme einbauen und Jalousien nach Bedarf steuern.
5 Jahre später kann ich immer noch keine Aqara Thermostate in die HUE Bridge einbinden 
nobbybln Super Hinweis 
Der ist mir neu. Kann es evtl. sein, dass der erst bei einem der letzten Updates in die App hinzugefügt wurde? 
Dito, weswegen ich seit Jahr und Tag genau 1 ATV 4K als Steuerzentrale definiert habe und damit sehr gut fahre.
Genau das habe ich versucht. Das scheint mir aber eine Falschmeldung seitens Aqara zu sein, zumal es keine Beschreibung bei Aqara gibt, wie das im HK-Modus der App zu bewerkstelligen sein soll. Entsprechend habe ich notgedrungen auch die Registrierung über mich ergehen lassen. Dort wiederum klappt die Kopplung sogar so gut, dass man anscheinend nicht mehr entkoppeln kann, ohne die Gerätschaften komplett abzumelden 
Hey Mighty61 freut mich, dass es geklappt hat Vielleicht magst du dein Projekt, wenn es fertiggestellt wurde, für die Allgemeinheit nochmal genauer vorstellen. Evtl. überzeugt das den ein oder die andere von den Vorzügen des RavenSystems 
Die "Polling Time" lässt sich mit dem Key "j" bequem per Komma getrennt an das jeweilige Device anhängen. Standardmäßig feuern die Sensoren im Moment alle 30 Sekunden einen Temperaturwert an HomeKit. Für deinen Fall sind für beide Sensoren sogar unterschiedliche Angaben möglich. Die Zeitangabe ist dabei vom Typen "float", kann also in beliebigen Bruchteilen von Sekunden eingegeben werden (bitte nicht Komma "," sondern Punkt ".") mit dem atemberaubenden Minimalwert von 0,1 Sekunde. Als Beispiel für alle 2,5678 Sekunden sieht das Skript wie folgt aus:
{"a":[{"t":22,"g":14,"n":3,"j":2.5678},{"t":22,"g":12,"n":3,"j":2.5678}]}Den Setup Mode kannst du über verschiedene Wege auslösen. "Leider" sind in deinem Device keine Schalter verbaut, mit denen du durch schnelles Ein- und Ausschalten (Neudeutsch Toggeln) den Setup Mode direkt auslösen kannst.
Für dich bietet sich der im oberen Link beschriebene "Emergency Setup Mode" an. Übersetzt bedeutet das, dass du den ESP nach dem Versorgen mit Strom denselben innerhalb von 2 Sekunden wieder vom Strom trennen musst, damit er automatisch in den Setup Mode wechselt.
*Grad mal probiert*
Beim D1 Mini mit eingebauter Reset-Taste geht der "Emergency Setup Mode" auch mit derselben. Also 2x innerhalb von 2 Sekunden (während des Bootens) die Resettaste klicken und der Setup Mode ist aktiv.
Alternativ habe ich in meinem HomeKit-Blinkgenerator eine Methode beschrieben, durch die du per zusätzlichem virtuellem Schalter in der Home App den Setup Mode schalten kannst. Für deinen Fall beispielsweise so:
{"a":[{"t":22,"g":14,"n":3,"j":2.5678},{"t":22,"g":12,"n":3,"j":2.5678},{"t":1,"1":{"s":[{"a":1}]}}]}Ich empfehle darüberhinaus die "hauseigene" App namens "HAA Manager". Die ist zwar nicht ganz billig (10,99 €), bietet dafür aber eine Menge an bequemen Funktionen, u.a. kannst du alle RavenESPs darüber managen und u.a. den jeweiligen Setup Mode über die App schalten. Du könntest darüber auch eine Datenaufzeichnung deiner Sensorenmessungen veranlassen über die "Data Historie" Funktion.
CodeSerial port /dev/cu.usbserial-AQ00JOGE
Ok, der Port bleibt offensichtlich ein Geheimnis, aber der ESP antwortet.
Das Geheimnis ist durch die Angabe "AQ00JOGE" ein offenes Geheimnis.
Wie du selbst außerdem neulich festgestellt hattest, funzt der Write Befehl offensichtlich auch ohne Portangabe.
Was spricht gegen den Originalbefehl aus der RavenSystem Installation?
python3 -m esptool -b 115200 write_flash -fs 1MB -fm dout -ff 40m 0x0 fullhaaboot.bin(Alle Schaltungen werden komplett innerhalb eines ESP ausgeführt. Keine HomeKit-Automationen oder Kurzbefehle!)
*** Wer nicht lange lesen möchte und vorab einfach mal einen ESP mit dem Blink-Generator testen möchte, kann zum Ende dieses Beitrags eine fertige bin-Datei laden und auf seinen ESP flashen. ***
Das klassische Blinken "ab Werk" kann HomeKit bekanntlich bis heute nicht, ohne dass man dazu mehr oder minder große Umwege beschreiten muss. Dabei kann es immer mal wieder durchaus hilfreich sein, um per beliebiger blinkender Lampenauswahl – schließlich hängen in allen Räumen irgendwelche smarten Lampen – auf irgendetwas aufmerksam zu machen, wie z.B. das offene Fenster, sobald man die Haustür öffnet.
Ich selbst habe vor Jahren eine Blinkmöglichkeit vorgestellt, die vollständig innerhalb von HomeKit ausgeführt wird. Die funktioniert zwar mehr oder weniger gut, beansprucht jedoch HomeKit ziemlich, da jeweils 2 Automationen jede Sekunde über einen unbekannten Zeitraum ausgewertet und Schaltungen ausgeführt werden werden müssen.
RavenSystem kann HomeKit spürbar entlasten und die Auswertung der Automationen übernehmen, während HomeKit dann nur noch schalten muss. Baut man sich per RavenSystem gar eine eigene Lampe, kann man sogar das Schalten des Lichts aus HomeKit outsourcen und bekommt ein waschechtes integriertes Blinklicht.
Solch ein HomeKit-Blinkkgenerator in 2-Kanalausführung soll in diesem Beitrag grundlegend Step by Step erklärt werden. Er funktioniert sowohl Standalone, um in HomeKit Lampen und/oder Szenen im Sekundentakt ein- und auszuschalten bzw. irgendetwas hin- und herzuschalten. Das Skript selbst kann allerdings als Codeschnispsel auch in ein Lampenskript integriert werden, um dann die Lampe direkt per ESP blinken zu lassen. Übrigens sollten sich auf diesem Wege auch Lampenschaltende Raven-Shellys um eine Blinkfunktion erweitern lassen.
Die folgende Schaltidee ist identisch mit meiner damaligen HomeKit-Lösung, die ich mithilfe der Geschwister Flip und Flop umgesetzt hatte und deren Namen ich in gebührender ehrfürchtiger Verneigung aus der klassischen Flipflop-Schaltung entliehen habe. Dort ist treffenderweise die Rede von "bistabilen Kippgliedern" (welch großartige Begrifflichkeit!), die wir in RavenSystem perfekt und einfach durch 2 sich gegenseitig schaltende Schalter, genauer gesagt zwei sich gegenseitig schaltende Timerschalter umsetzen können.
Ich beginne also mit einem Ausgangsskript, das 2 inzwischen altbekannte Timer in HomeKit erzeugt, die sich jeweils nach einer Sekunde, nachdem sie eingeschaltet wurden, selbständig wieder ausschalten:
{"a":[{"t":1,"i":1},{"t":1,"i":1}]}Die Gebrüder Flip und Flop haben soeben das Licht der virtuellen HomeKit-Welt erblickt, allerdings leben sie im derzeitigen Stadium regelrecht aneinander vorbei. Das wollen wir ganz schnell ändern durch die ebenfalls bereits vorgestellten "Service Notifications", die beiden Geschwisterchen eine einfache Kommunikation ermöglichen nach folgendem Drehbuch:
| Flip (sich einschaltend) | Hallo liebe HomeKit-Welt, ich bin Flip und ich schalte mich grad ein, damit ihr irgendwas automatisieren könnt.
Aber seid gewarnt, ich schalte mich grundsätzlich in 1 Sekunde wieder aus! |
| Flip (sich ausschaltend) | Hallo liebe HomeKit-Welt, ich schalte mich grad aus, damit ihr irgendwas automatisieren könnt. Flop, mein Lieber, übernimm du bitte! |
| Flop (sich einschaltend) | Hey Flip, mein Lieber, das mache ich doch gern! Hallo liebe HomeKit-Welt, ich bin Flop und ich schalte mich grad ein, damit ihr irgendwas automatisieren könnt. Aber seid gewarnt, ich schalte mich grundsätzlich in 1 Sekunde wieder aus! |
| Flop (sich ausschaltend) | Hallo liebe HomeKit-Welt, ich schalte mich grad aus, damit ihr irgendwas automatisieren könnt. Flip, mein Lieber, übernimm du bitte! |
| (Endlose Dialog-Fortsetzung, bis irgendjemand Einhalt gebietet) |
Dramaturgisch gibt die Unterhaltung zwischen Flip und Flop wenig her und taugt bestenfalls für experimentelles Theater. Das muss uns aber nicht stören, da wir den extrem eintönigen Dialog nicht ertragen müssen, sondern ihn gewinnbringend für unser Schaltvorhaben einsetzen werden. Dazu müssen wir nur Flip, wenn er sich ausschaltet, einen Fingerzeig an Flop senden lassen, damit sich dieser einschaltet. Umgekehrt gilt das gleiche für Flop, der Flip zum Einschalten anstößt, sobald er selbst sich ausschaltet. Wir erinnern uns: Flip und Flop müssen dazu jeweils wissen, an welcher Stelle sie im Skript stehen und sie sollen nur beim Ausschalten dem jeweiligen Gegenüber einen verständlichen Einschaltbefehl mitteilen.
Flip ist die Nummer 1, Flop die Nummer 2. Die Anweisung respektive "Service Notification", die beide vom Range eines Schalters verstehen, sind (u.a.) "0" und "1".
Im Skript ergibt das folgenden Dialog-Codeschnipsel für "Hey mein Lieber, schalte dich ein!"
{"m":{[2,1]}} // sagt Flip zum Zweiten
{"m":{[1,1]}} // sagt Flop zum ErstenGleich ein Hinweis für den wahrscheinlichen Fall, dass wir entweder mehrere Geschwisterpärchen haben, weil wir mehrere unabhängige Blinkgeneratoren in einem ESP unterbringen wollen, oder weil die Geschwister nicht unbedingt immer an erster Stelle stehen, da wir noch eine Vielzahl von anderen Service-Types vorgelagert haben:
Die Positionsangaben oder "Target Service Number" für die Service-Notifications kann, wie eben beschrieben, absolut, aber auch relativ erfolgen. Letzteres macht Sinn, wenn wir nicht immer abzählen wollen, an welcher Stelle das jeweilige Device steht, das wir instruieren wollen. Flip und Flop werden sinnigerweise immer nebeneinandergestellt, sodass Flop für Flip der Nächste ist, umgekehrt Flip für Flop der Vorherige. Dadurch wird es auch egal, wo wir das Pärchen hinverfrachten, beim relativen Nummerieren bleiben die Zuordnungen immer erhalten. Genau das kennen wir bereits aus dem Einleitungbeispiel und ersetzen in diesem Sinne den vorherigen Code durch die relative Entsprechung (ohne weitere Erklärung):
{"m":{[7001,1]}} // sagt Flip zum Nächsten
{"m":{[-1,1]}} // sagt Flop zum Vorherigen… und ergänzen damit das Ausgangsskript mit den noch fehlenden Keys für die ausschließliche Mitteilung im Falle des jeweiligen Ausschaltens, also für Action "0":
{"a":[{"t":1,"0":{"m":[[7001,1]]},"i":1},{"t":1,"0":{"m":[[-1,1]]},"i":1}]}Fertig ist der Homekit-Blinkgenerator!
Allerdings hat diese verfrühte Version noch einen entscheidenden Nachteil: Einmal angeworfen hört der nie mehr auf, zumindest nicht solange der ESP mit Energie versorgt wird. Das ist natürlich suboptimal, aber kein Beinbruch, denn RavenSystem erlaubt es, jedes beliebige Device über eine weitere Service Notification per "Target Service Value" durch den Wert "-10000" zu deaktivieren.
Da wir weder Flip noch Flop veranlassen können, ihrem Gegenüber und sich selbst gleichzeitig sowohl das Ausschalten als auch das Einschlafen mitzuteilen, brauchen wir eine weitere Protagonistin in unserem Bühnenstück, die ich Mama Blink nenne. Die freundliche Dame ist in unserem Beispiel ebenfalls vom Stande Schalter "t":1 und damit die Dritte im Bunde. Sie wird dem Erstgeborenen Flip bei ihrem Einschalten mitteilen, dass sich dieser ebenfalls einschalten soll. Das kennen wir bereits:
{"m":{[-2,1]}} // sagt Mama Blink als Dritte in der Reihe zu Flip beim EinschaltenNeu ist die Mitteilung, die Mama Blink beim Ausschalten an ihre beiden Kinder sendet, damit diese sofort einschlafen. Vorher jedoch schaltet Mama Blink beide Schalter ordentlich aus, damit nicht versehentlich einer der Bengels womöglich angeschaltet einschläft.
{"m":[[-2,0],[-2,-10000],[-1,0],[-1,-10000]]}
// sagt Mama Blink zu Flip und Flop beim AusschaltenSobald also Mama Blink ausgeschaltet wird, schlafen beide Geschwisterchen Flip und Flop direkt nach dem Licht löschen bzw. Ausschalten ohne Verzögerung ein und veranlassen sich ab sofort nicht mehr gegenseitig, sich beim Ausschalten jeweils wieder einzuschalten. Es kehrt also planmäßige Ruhe ein. 
Allerdings ist im Moment der Schlaf derart endgültig tief, dass Mama Blink beide Geschwister beim erneuten Einschalten nicht wieder wach bekommt. Sie muss die beiden erst wieder wecken, indem sie sie durch den Wert "-10001 reaktiviert. Erst dann kann sie Flip ausrichten, sich wieder einzuschalten. Insgesamt sieht Mama Blink dann wie folgend aus:
{"t":1,"0":{"m":[[-2,0],[-2,-10000],[-1,0],[-1,-10000]]},"1":{"m":[[-2,-10001],[-2,1],[-1,-10001]]} // Mama Blink SoloansichtWichtig ist die Reihenfolge der Anweisungen für Flip: also erst ausschalten und dann einschläfern bzw. erst aufwecken und dann einschalten. Der ESP erledigt diese beiden direkt aufeinanderfolgenden Anweisungen in Millisekunden, und damit gefühlt zeitgleich. Der Blinkgenerator nimmt somit seine voll funktionstüchtige Form wie folgt an und sieht dann so aus wie die Animation zu Anfang des Beitrags:
{
"a":[
{"t":1,"0":{"m":[[7001,1]]},"i":1}, // Flip
{"t":1,"0":{"m":[[-1,1]]},"i":1}, // Flop
{"t":1,"0":{"m":[[-2,0],[-2,-10000],[-1,0],[-1,-10000]]},"1":{"m":[[-2,-10001],[-2,1],[-1,-10001]]} // Mama Blink
}]
}Nichts ist so gut, dass es nicht noch besser gemacht werden könnte. Wir erinnern uns an die im D1 Mini integrierte LED, die zukünftig die dröge aber rege Unterhaltung zwischen Flip und Flop, sprich das Blinken anzeigen soll. Dafür reicht es, wenn wir z.B. nur Flip mit der LED "verdrahten" und Flop unberücksichtigt lassen. Besagte LED ist über GPIO 2 schaltbar und leuchtet auf, wenn dieser den Status "low" erfüllt. Das hatten wir bereits bei der selbstgebauten HomeKit-LED ausführlicher erklärt, soll also hier nicht weiter vertieft werden. Wir müssen somit Flip neben der bereits vorhandenen Service Notification an Flop die zusätzlichen nötigen Schaltbefehle für die interne LED in folgender Form überreichen:
{"t":1,"0":{"r":[{"g":2,"v":1}],"m":[[7001,1]]},"1":{"r":[{"g":2}]} // FlipWas zur folgenden Skript-Version führt:
{"a":[{"t":1,"0":{"r":[{"g":2,"v":1}],"m":[[7001,1]]},"1":{"r":[{"g":2}]},"i":1},{"t":1,"0":{"m":[[-1,1]]},"i":1},{"t":1,"0":{"m":[[-2,0],[-2,-10000],[-1,0],[-1,-10000]]},"1":{"m":[[-2,-10001],[-2,1],[-1,-10001]]}}]}Noch ein letztes Problem werden wir mit dem inzwischen voll funktionstüchtigen HomeKit-Blinkgenerator samt mitblinkender LED haben. RavenSystem sieht standardmäßig vor, dass 8-maliges Toggeln eines Schalters den Setup Mode des ESP aktiviert und diesen damit in HomeKit unerreichbar werden lässt. Der Blinkgenerator wird diese 8-maligen Schaltvorgänge schnell ausgeführt haben. Er wird sich dadurch ungewollt regelmäßig in HomeKit temporär abmelden, was ja nicht unbedingt in unserem Sinne ist.
Natürlich sieht RavenSystem mehrfache Möglichkeiten vor, diesen Standard zu modifizieren – dies u.a. in der bisher noch nicht erwähnten "Accessory Configuration", die an dieser Stelle noch nicht weitergehend erklärt werden soll. Im Beispielskript ergänze ich für diesen Zweck eine weitere Steckdose, die direkt nach Betätigung den Setup Mode auslöst, während ich vorher noch den Standard des 8-maligen Toggles komplett deaktiviere. Das erreiche ich durch den "Setup Mode Toggle Count" Key "z":0 im besagten Konfigurationsteil des Skripts, der dem Accessory-Teil mit dem Key "a" über den Configuration Key "c": vorangestellt ist, was dann den folgenden Zusatz im Skript bringt:
"c":{"z":0}Da wir durch diese Deaktivierung allerdings den Setup Mode des ESP nicht mehr (ohne Weiteres) aktivieren können, erklärt sich die Steckdose, die natürlich auch ein Schalter sein könnte, sich als Steckdose rein visuell aber besser von dem Blinkschalter-Trio absetzt, und über die wir den Setup Mode für unser Beispiel alternativ wieder hinkriegen. Wohlgemerkt, das ist eine von mehreren Möglichkeiten, die nicht genannt sind, um den Beitrag nicht noch mehr ausufern zu lassen.
Die besagte Steckdose tut also nichts anderes als per "System Action" mit dem Key "s" den Setup Mode über Key "a":1 zu aktivieren. Diese Steckdose ist somit mit Vorsicht zu genießen, da sich der ESP beim Einschalten derselben sofort aus HomeKit abmeldet:
{"t":1,"1":{"s":[{"a":1}]}} // Schalter "An" löst Setup Mode des ESP ausDas nun finale, voll funktionstüchtige und problemfreie Skript sieht so aus:
{"c":{"z":0},"a":[{"t":1,"0":{"r":[{"g":2,"v":1}],"m":[[7001,1]]},"1":{"r":[{"g":2}]},"i":1},{"t":1,"0":{"m":[[-1,1]]},"i":1},{"t":1,"0":{"m":[[-2,0],[-2,-10000],[-1,0],[-1,-10000]]},"1":{"m":[[-2,-10001],[-2,1],[-1,-10001]]}},{"t":2,"1":{"s":[{"a":1}]}}]}(In der Home App wurde die Steckdose als Lampe umdefiniert und setzt sich dadurch vom Blinkschalter-Trio noch deutlicher ab.
Den Blinkgenerator in Aktion sieht man in der Animation zu Beginn des Beitrags)
Verlassen wir die alleinerziehende Mama samt ihrer beiden Söhne und sehen uns die neue Basis-Schaltgruppe für HomeKit bestehend aus 3 Schaltern (+ Setup Mode Steckdose) für den praktischen Einsatz an. In HomeKit integriert können ab sofort beliebige Automationen das Blinken über Mama Blink sowohl einleiten als auch beenden. Flip und Flop ihrerseits bieten im Sinne einer 2-kanaligen Blinkschaltung diverse Möglichkeiten, das gewünschte Blinken zu "gestalten". Vom einfachen Ein und Aus einzelner Lampen über das 2-kanalige Hin und Her neben-/übereinander positionierter Lampen bishin zum oszillierenden Umschalten von Szenen ist nun alles möglich, um auf diverse Dinge im trauten HomeKit-Heim visuell aufmerksam zu machen – das Ganze, ohne zu Löten, ohne zu Schrauben, ohne zu Verkabeln, ausschließlich mit dem ESP.
Sehr leicht lassen sich nach Bedarf weitere Schalter in das Skript ergänzen, die etwa die identische Funktion von Mama Blink haben mit dem Unterschied, dass diese per einfachem zusätzlichen "i" Key ihrerseits zu Timern umfunktioniert werden. Dadurch lässt sich in HomeKit direkt auswählen, wie oft die Blinkfunktion wiederholt werden soll. Mit "i":6 als Zusatz würde Flip exakt 3x einschalten, um dann von selbst in den Schlaf zu verfallen.
Ein Hinweis zum Blinkzeit-Intervall von 1 Sekunde im Beispielskript: Der ESP kann deutlich höhere Schalt-Frequenzen sauber verarbeiten, jedoch ist dann HomeKit u.U. schnell durch die wachsende Schaltbefehl-Bombardierung überfordert und kommt nicht mehr hinterher. Jeder kann bei Interesse gern mal die "i" Key Werte von Flip und Flop verkleinern (bspw. "i":0.5 für 1/2 Sekunde), um zu testen, wann HomeKit aufgibt.