Ich war länger nicht hier. Schön zu sehen, dass es RavenSystem noch gibt und wie es sich weiter entwickelt hat.
Ich hänge der Vollständigkeit einfach nochmal zwei alte Threads an, die sich vor wenigen Jahren auch mal damit beschäftigt haben. Vielleicht helfen die Ergänzungen ja dem ein oder anderen..
Zwischenstecker mit Sonoff Basic auf Basis von RavenSystem
LED Strip mit MagicHome Controller auf Basis von RavenSystem
Ich hänge der Vollständigkeit einfach nochmal zwei alte Threads an
Die hatte ich mir erst kürzlich noch mal angesehen, als das Thema Raven hier wieder aufkam und dabei gedacht: Man hört nichts mehr von ihm. Was wohl der Sebbo macht? Daher schön, hier wieder von Dir zu lesen!
Vielleicht helfen die Ergänzungen ja dem ein oder anderen.
Ich hab diesbezüglich gleich mal ne Frage: Mit dem erworbenen Halbwissen zum Flashen eines D1mini juckt es mich, noch einmal zu versuchen, einen Sonoff Basic und einen MagicHome mit der Raven-Firmware zu versehen. Die Teile hatte ich in der Grabbelkiste eingemottet, nachdem das Flashen via Raspbi damals irgendwie fehlschlug. Jetzt hab ich den Sonoff nochmal über einen seiellen USB-Adapter mit gedrückter Taste am Mac angeschlossen und mit dem Terminalbefehl von loonypac angepingt:
nately@NatelysMac ~ % python3 -m esptool flash_id
esptool.py v4.4
Found 2 serial ports
Serial port /dev/cu.usbserial-AQ00JOGE
Connecting....
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting...
Detecting chip type... ESP8266
Chip is ESP8285N08
Features: WiFi, Embedded Flash
Crystal is 26MHz
MAC: 84:ad:8e:67:91:fd
Uploading stub...
Running stub...
Stub running...
Manufacturer: 51
Device: 4014
Detected flash size: 1MB
Hard resetting via RTS pin...Ok, der Port bleibt offensichtlich ein Geheimnis, aber der ESP antwortet. Also probiere ich:
nately@NatelysMac ~ % python3 -m esptool erase_flash
esptool.py v4.4
Found 2 serial ports
Serial port /dev/cu.usbserial-AQ00JOGE
Connecting...
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting...
Detecting chip type... ESP8266
Chip is ESP8285N08
Features: WiFi, Embedded Flash
Crystal is 26MHz
MAC: 84:ad:8e:67:91:fd
Stub is already running. No upload is necessary.
Erasing flash (this may take a while)...
Chip erase completed successfully in 3.6s
Hard resetting via RTS pin...Das Löschen scheint also auch funktioniert zu haben. Wie aber bekomme ich jetzt die fullhaaboot.bin hochgeladen? Der write_flash will ja allerlei Angaben bzgl. der verwendeten Schnittstelle transportieren.
Was spricht gegen den Originalbefehl aus der RavenSystem Installation?
python3 -m esptool -b 115200 write_flash -fs 1MB -fm dout -ff 40m 0x0 fullhaaboot.binWas spricht gegen den Originalbefehl
Da spricht ganz offensichtlich nix gegen. Der funktioniert auch hier!
nately@NatelysMac ~ % python3 -m esptool -b 115200 write_flash -fs 1MB -fm dout -ff 40m 0x0 fullhaaboot.bin
esptool.py v4.4
Found 2 serial ports
Serial port /dev/cu.usbserial-AQ00JOGE
Connecting...
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting...
Detecting chip type... ESP8266
Chip is ESP8285N08
Features: WiFi, Embedded Flash
Crystal is 26MHz
MAC: 84:ad:8e:67:91:fd
Stub is already running. No upload is necessary.
Configuring flash size...
Flash will be erased from 0x00000000 to 0x00062fff...
Compressed 403344 bytes to 286837...
Wrote 403344 bytes (286837 compressed) at 0x00000000 in 25.5 seconds (effective 126.8 kbit/s)...
Hash of data verified.
Leaving...
Hard resetting via RTS pin...TNX!
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.
Hey, vielen lieben Dank.
es hat tatsächlich geklappt!
ich habe im RSP den Code:
{"a":[{"t":22,"g":14,"n":3},{"t":22,"g":12,"n":3}]}
drin. Neustart hat langegedauert. Zack war im HK ein neuer Sensor zu sehen!
Zeigt beide Temp. richtig an.
jetzt wollte ich die Abfrage Zeit ändern. ( wo genau im Code gebe ich die J5 eigentlich ein)
Aber nichts da.
auf der IP auf dem er funkt: 192.168.178.150 ( zugegriffen hatte ich mit :4567 ) geht nicht mehr.
Wie komme ich auf die HAA Oberfläche?
Nochmals Danke!
Wenn du mit 5 und 6 die GPIOs meinst (D1 Mini hat übrigens keinen GPIO 6), probiere:
Code{"a":[{"t":22,"g":5,"n":3},{"t":22,"g":6,"n":3}]}Wenn du die D1 Mini Beschriftung D5 und D6 meinst, dann:
Code{"a":[{"t":22,"g":14,"n":3},{"t":22,"g":12,"n":3}]}Wenn du beide Sensoren an einen GPIO anschließen willst (bspw. GPIO 14), dann
Code{"a":[{"t":22,"g":14,"n": 3},{"t":22,"g":14,"n":3,"u":2}]}
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.
Hallo zusammen,
ich versuche mal das ganze für den ein oder anderen aber auch für mich schriftlich festzuhalten.
Ziel war es 2 Temperatur Sensoren im ( lasse ich einfach in den Skimmer eintauchen ) und beim Pool zu verbauen die direkt an Apple HK die Daten senden!
Gesamter Kostenaufwand keine 20 €
Da ich einen Salzwasserpool habe muss ich alle 2 Jahre den Temperatursensor austauschen.
Es gibt bestimmt andere Lösungen aber diese waren mir zu teuer.
Was habe ich gemacht:
Einen RSP8266 ( kostet gerade mal im 3er Pack 12,99 € ) mit Raven HAA geflasht.
Hier zu kann Mann der Anleitung folgen https://github.com/RavenSystem…devices/wiki/Installation
Ich habe es auf dem Mac nicht hin bekommen mit den Befehlen.
Also habe ich folgenden Loader genommen NodeMCU Flasher für den MAC: https://github.com/marcelstoer/nodemcu-pyflasher/releases
Letztendlich muss folgende Datei auf den RSP8266: https://github.com/RavenSystem…/download/fullhaaboot.bin
Als Temperaturfühler habe ich 2 x DS18B20 an den Pins des RSP8266 an D5 und D6 dran.
Dazwischen habe ich jeweils an den Datenleitungen 2 x 4,6 kOhm widerstände dran.
Nach dem Flashen zugriff über:
http://192.168.4.1:4567
habe ich das richtige WLAN zugeordnet und Save.
Nach Neustart bekommt der HAA dann eine neue IP. Bei mir war es dann 192.168.178.150:4567
Danach sieht das ganze so aus:
hier habe im den MEPLHAA Scribt folgenden Befehl reingeschrieben:
{"a":[{"t":22,"g":14,"n":3},{"t":22,"g":12,"n":3}]}
Hier wird wohl alle 30 Sekunden die Temp. Abgefragt.
Danach braucht es eine weile und Schlussendlich tauchen diese im Apple HK als neue Aktoren auf.
Für kleines Geld habe ich nun meine 2 Sensoren die direkt an Apple HK die Daten senden.
Ich bin Happy. 
Sorry ist meine erste Anleitung.
Ich bedanke mich Rechtherzlich bei:
Für Eure Beiträge und tolle Hilfestellung.
Sehr schön.
Wo kaufst du deine Dinger? Der reine ESP8266er koste bei ebay und co. incl. Versand ab 2€ und der D1mini ab 2,50€.
Mit 2 Temperatursensoren langweilt sich der Chip zu Tode. Noch ein AM2320 dran und du hast auch noch Lufttemperatur und Feuchtigkeit und er ist noch lange nicht ausgelastet.
Mit den Möglichkeiten steigen die Ansprüche 
Walta
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?
Alles anzeigenSehr schön.
Wo kaufst du deine Dinger? Der reine ESP8266er koste bei ebay und co. incl. Versand ab 2€ und der D1mini ab 2,50€.
Mit 2 Temperatursensoren langweilt sich der Chip zu Tode. Noch ein AM2320 dran und du hast auch noch Lufttemperatur und Feuchtigkeit und er ist noch lange nicht ausgelastet.
Mit den Möglichkeiten steigen die Ansprüche
Walta
Moin,
ja, ich habe die auch schon günstiger gesehen.
Habe die damals bei Amazon gekauft.
Nächster Step ist einen OH Sensor an das ganze dran zu machen. Allerdings konnte ich noch keine PH Sonde finden wo ich die Daten über das Raven HAA Abrufen kann.
Letztendlich benötige ich von der Sonde den PH Wert.
Es gibt Zahlreiche die mit dem ESP8266 funktionieren sollen.
Hast Du eine Idee welche am geeignetsten sein könnte?
Danke Vorab
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?
Hallo,
ich hatte den gleichen Sensor Jahrelang an einem Sonoff Wifi Schalter dran. Name kann ich Dir nicht sagen.
Leider geht das nicht mehr. Auch die Abfrage war nur über Umwege in meinem Falle über Homebridge möglich gewesen.
Kalibriert habe ich das ganze nicht. Aber Manuelles Nachmessen mit anderen Temp. Fühlern und auch der eingebaute Temp. Sensor der Wärmepumpe liefern exakt die gleichen Daten.
Ich konnte in den letzten Jahren keine Temp. Abweichungen feststellen.
Es ist halt für meine zwecke super Praktisch.
1. Ich kann den Temp. Fühler einzeln sofort für kleines Geld austauschen.
2. Die daten werden direkt an Apple HK gesendet und somit sind mehr Möglichkeiten wie Automationen oder auch die einfache Abfrage von der Terrasse wie Warm ist das Poolwasser für die ganze Familie super praktisch.
Wie 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?
Vielen Dank Vorab.
Wie 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?!
Nachdem sich mein alter Sonoff Basic erfolgreich flashen ließ, stellt sich mir die Frage, ob die neuen Sonoffs vom Typ BasicR2 auch noch den ESP8266 an Bord haben oder schon mit dem noch-nicht-raven-fähigen ESP32 ausgestattet sind. Weiß das jemand?
Ein anderes altes Schätzchen, welches bisher über das MagicHome-Plugin der Homebridge eingebunden war tickt jetzt ebenfalls nativ per Raven:
Das Script dazu:
{"c":{"b":[{"g":0,"t":5}]},"a":[{"t":30,"g":[14,12,13,15],"ld":[0,1,0,1],"b":[{"g":0}]}]}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_idEntsprechend gibt es keinen Service Type in RavenSystem, durch den du den gemessenen Wert korrekt als PH-Wert in HomeKit anzeigen lassen könntest
Solche Werte lasse ich mir als Batterie anzeigen (Batterieladung 75%) oder Temperatur. Die Reichweite meines e-autos wird mit diesem Trick angezeigt - Reichweite 175°C 
Mit PH Sensoren hab ich noch nicht gespielt. Gehöre zu den armen Schluckern die keinen Pool haben 
Walta
aber funke ihn doch einfach mal an
Jaha, dazu müßte ich erst mal einen haben! Die kosten in Kina zwar nur $5, trotzdem hätte ich gern gewußt, ob es sich als Raver lohnt, dort welche zu bestellen.
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.
(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}]}Du gibst Dir wahnsinnig viel Mühe. Klasse!
Aber nach dem ersten Zitat von mir verstehe ich nur noch Bahnhof. Und diese Codezeilen.
Und: was ist ein ESP8266 und wo soll ein Shelly sowas haben? Temperatur kann von diesem auch nicht genommen werden. Es ist ja auch unterputz verbaut, und dort sind die Temperaturen eh etwas anders.
Ich verstehe da leider nur Bahnhof.
Was richtig ist: nur dafür die Homebridge auf der Synology laufen zu lassen, ist schon etwas viel.
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
