Beiträge von loonypac

Du schreibst "alte Firmware", installiert ist also die Firmware vor 12.x?

Der Sensor zeigt in HomeKit die Temperatur korrekt an, nur die DB funzt nicht?

Dann probier folgenden Code:

{
  "c":{"b":[{"g":0,"t":5}],"l":16},
  "a":[{
    "t":22,
    "g":12,
    "n":3,
    "j":5,
    "y0":[{
      "0":{"h":[{"h":"192.168.178.55","p":8086,"m":2,"u":"write?db=macmini","c":"sensor,device=office value=#HAA@0000"}]},
      "v":0,
      "r":1
    }]
  }]
}

Ich bin leider kein Spezialist für influxDB. Im Beispiel von RavenSystem beginnt der Content String "c" mit "sensor,location=…", während bei dir "sensor,device=…" steht. Da sollte auf alle Fälle erstmal die korrekte Syntax bzw. der korrekte Link für die Dateneingabe in deine influxDB recherchiert werden. Ich vermute einmal, dass hier der Fehler liegt.

Das "HAA@0000" ist eine sogenannte "magic Expression", also eine Variable in RavenSystem, die in den ersten beiden Ziffern 00 festlegt, dass der HTTP Request von demjenigen Service ausgelöst wird, der ihn in seinem Array beinhaltet – in deinem Fall der Sensor "t":22. Die folgenden Ziffern 00 legen die zu speichernde "charasteristic" des Sensors fest, also konkret den Temperaturwert des Sensors. "HAA@0001" würde bspw. die Luftfeuchtigkeit in die Datenbank speichern. Ich nehme mal an, dass bei dir der feste Wert 30 für Testzwecke eingegeben wurde?!

Was meinst du mit "Namen für den Sensor"?

Ein Blick in dein Script könnte womöglich hilfreich sein.

Zitat von walta

Kann es sein, dass eine ständige Weiterleitung der Werte gar nicht geht?

Im Influxx-Beispiel wird genau das erreicht. Für die Wildcard-Action ist der Zielwert dazu über den Key "v" auf den Wert 0 gesetzt, was bedeutet, dass alle Werte, die über 0° C gemessen werden, in regelmäßigen Zeitintervallen in der Datenbank erfasst werden. Wichtig ist der Key "r":1, der bewirkt, dass bei jeder Temperaturänderung ein Wert in die DB geschrieben wird – und zwar so lange er über 0° Grad ist. "r":0 hingegen würde nur einmal einen Wert abspeichern, wenn er größer als 0 gemessen wird und erst beim nächsten Überschreiten einmal einen neuen Wert erfassen, nachdem der Zielwert 0 vorher unterschritten war. Mit dem "j"-Key kannst du wiederum bestimmen, in welchen Zeitabständen das geschehen soll. Im Beispiel werden mit "j":30 alle 30 Sekunden die Temperaturwerte gemessen und in die Datenbank geschrieben.

Für Innentemperaturenmessungen sollte also der Zielwert 0 für eine lückenlose Datenerfassung reichen, da vermutlich die Bude immer oberhalb von 0° Grad warm sein wird. Für Minustemperaturenerfassungen im Außenbereich können entsprechend negative Zahlen eingegeben werden, da der "v"-Key Zahlenwerte vom Typ Float zulässt, also negative, positive Zahlen inkl. Nachkommagenauigkeit.

Das könnte womöglich über einen ESP gelingen. „Könnte“, weil ich sowas noch nicht umgesetzt habe.

Theoretisch würde ein HTTP-Request mit dem Link für die PHP-Abfrage vom ESP versendet werden, um dann den entsprechenden Response zu empfangen und per Filter den numerischen Wert auszulesen. Dieser Wert kann dann innerhalb des ESP per Bedingungsdefinition einen oder mehrere virtuelle Schalter (mit verschiedenen Schaltstufen) auslösen, der/die wiederum in HomeKit nativ eingebunden wird/werden. Die eigentliche Automation erledigt also der ESP und HomeKit automatisiert per automatischem Schalter nur noch die gewünschten Gerätschaften.

Das wäre ein schönes Bastelprojekt für den einzigen RavenSystem Beitrag in diesem Forum, setzt allerdings einen gewissen Pioniergeist und die Investitions-Bereitschaft von knapp 4,- € für den ESP voraus.

Zitat von sschuste

Und ich muss auf mein Steinberg UR 22 Audiointerface achten: wird der Treiber dafür auch mit einem alternativen Bootloader arbeiten? Ich würde mal sagen: zu 99% ja, aber das bisschen Unsicherheit hält mich mich augenblicklich davon ab, den Mac umzubauen.

Mein alter MacMini 2009 läuft bspw. allein, um mein ähnlich altes Fireface 400 (seit Jahren discontinued) für die heimische Surround-Satelliten zu beschallen, mit Monterey samt aktuellem Treiber ohne jegliche Mucken. Lediglich die Grafik des Macs zickt hier und da in Ermangelung einer Metal unterstützenden Grafikkarte. Macht nix, da ich den Mac für besagten Zweck überwiegend Headless betreibe.

So wie ich das lese, ist das Steinberg-Interface class compliant und braucht nicht zwingend Treiber. Außerdem ist das noch aktuell im Portfolio. Sollte also so oder so ohne Probleme mit den Bootloadern dieser Welt funzen.

Ohnehin bügel ich mein System niemals mehr einfach mit einem Upgrade über, sondern probiere immer erst eine Installation auf separater Disk. Kann also zwischen verschiedenen Systemen und Konfis wählen. Dabei ist der Carbon Copy Cloner ein treuer Begleiter seit Jahren.

Zitat von sschuste

wenn ich doch bloß nur wüsste, welchen Monitor ich dranhängen soll.

Das kommt doch nur drauf an, was du mit dem Mac schwerpunktmäßig machen willst. Homebridge- oder Serverinstallationen/-Programmierungen? Musikproduktionen mit 200 aktiven Plugins in 64+ Audiospuren, die du allesamt im Blick behalten willst? 8K Raw-Spielfilmproduktionen? Aktuelle hochauflösende 3D Daddelspiele?… etc.

Auch du hast recht. Zwar verzettelt sich das Thema derzeit weiter. Das hat es aber schon seit letztem Sonntag getan und wurde bislang offensichtlich geduldet. Cool23 wäre sein Enttäuschungs-Beitrag erspart geblieben und wir beide würden hier nicht groß weiter vom Thema abweichen

Regeln sind wichtig, keine Frage. Einen eigenen Beitrag für OpenCore würde ich persönlich als HomeKit-förderlich begrüßen. Allerdings ist es recht puppe einfach nach der Anleitung vorzugehen und sich zur Not anderweitig Hilfe zu suchen.

Generell macht das Thema "Nachhaltigkeit" in diesem Zusammenhang großen Sinn, vor allem in SmartHome-Systemen. *Ich-hör-schon-auf*

HolgerKR Hm, das ist aber für sehr viele HomeKit-Anwendungen per älteren Geräten ein essentieller Hinweis. Wenn so etwas bereits den Fokus sprengt, dann bitteschön.

Opencore Legacy Patcher kann manch (ur)alten Mac auf das aktuelle MacOS hieven. Ich selbst habe eine alten MacMini 2009 + iMac 2012 damit "aktualisiert" (derzeit erstmal auf Monterey). Läuft je nach Anwendung fabelhaft mit teils mehr Funktionen als die offiziell noch unterstützten älteren Modelle bieten (Stichwort Airplay, Handoff). Ich kann allerdings nix zur HomeKit-Zuverlässigkeit sagen, weil ich die Funktion deaktiviert habe. Sollte aber funzen.

Zitat von Patrick_

ich hätte erwähnen sollen…

War mir tatsächlich sofort klar, was du meinst. Ich wollte auch nicht besserwisserisch sein, was deine Person betrifft – allein schon, da ich weiß, dass dir Raven geläufig ist

Unbedarfte könnten allerdings mit deiner ersten Aussage leicht den falschen Eindruck gewinnen, dass es keine "alternative" Möglichkeiten gibt außer Homebridge oder Mongoose. An eben diese war mein Schlaubergerhinweis gerichtet.

Zitat von Edward J. Nately III

Wenn loonypack einen Wandler Midi2Homekit hinbekommt, könntest Du damit per Midi im Home lustig steuern. Die Quelle (also das Instrument) wäre letztlich egal.

Wobei ich bei den Steuergeräten weniger an Keyboards, Guitar- oder Breathcontroller dachte, sondern eher im besagten Sinne einer Schaltzentrale deluxe an sowas:

Diejenigen Musizierenden unter uns, die solche Schätzchen ohnehin schon nutzen, müssten dann noch nichtmal neu kaufen oder dran rumbasteln.

Aber bevor ich da in Sachen MIDI tätig werde, ist erstmal meine 8-fach-Kaskadensteckdose im 19-Zoll-Format für mein bescheidenes Studiöchen dran, mit der ich Schaltreihenfolgen der beteiligten Strombezieher per Preset-Schalter in HomeKit integrieren werde.

Gut Ding… etc.

Zitat von Patrick_

Auch gibt es noch keine alternative Homekit-Firmware zum flashen.

Was nicht ganz richtig ist. Wie ich weiter oben beschrieb, wird der Shelly Plus Plug S samt fertigem Script von RavenSystem nativ HomeKit-fähig (siehe unter Devices Database weiter unten "Shelly Plus Plug S").

Ok, dann habe ich dich im Unterschied zu walta gründlich missverstanden. Vergiss also mein Geschreibsel!

Deine Wünsche sind schlichtweg mit der Home App nicht zu realisieren und haben nichts mit den Shellys zu tun. Die momentanen Leistungswerte sind bestenfalls mit Drittanbieter-Apps wie Eve oder Controller darstellbar. Eine Datenauswertung oder Analyse benötigt dann nochmal zusätzliche Lösungen außerhalb von HomeKit.

Wobei Spannung, Strom, Leistung auch über die HAA Manager App innerhalb des Shellys speicherbar ist. Alle Parameter innerhalb des Shellys die verschiedensten Automationen (bspw. Überspannungsschutz-AUS-Schaltung) direkt ausführen können und sämtliche Daten zudem in beliebige Datenbanken (MySQL, Influxx) gespeichert und ausgewertet werden können, die per http ansprechbar sind.

Zitat von Bene2103

Naja, ich denke bei 100 GPIO's und dazu auch 100 oder mehr Accessories ist das Script sowieso unübersichtlich.

Keine Frage, wobei ich bei komplexeren Skripts gerne einen sauber formatierenden Texteditor mit JSON-Syntax nutze und so die zahllosen Accessoires relativ übersichtlich anordnen kann.

Zitat von Mero

Wie gebe ich die Scripte ein? Ich hatte bis jetzt nur eine URL von hier z.B. http://A.B.C.D/ota?url=http://rojer.me/files/shelly/shelly-homekit-Shelly1.zip genutz um umzuflashen

Du müsstest die Shellys zunächst auf Tasmota umflashen.

Das Prozedere ist für ESP8266-basierte Shelly hier, für ESP32-basierte Shelly hier beschrieben.

Von diesem Stadium dann nochmal OTA umflashen, wie hier unter dem Punkt "Tasmota to HAA" beschrieben.

Die bislang verfügbaren MEPLHAA-Skripte für die verschiedenen Shellys findest du hier. Diese kannst du im Nachhinein jederzeit noch anpassen und erweitern. Ggf. nach rechts scrollen, um die Scripte sichtbar zu machen. Am besten erstmal dort nachsehen, welche deiner Shellys dort aufgelistet sind.

Wenn möglich, probiere das erstmal mit einem nicht fest verbauten Shelly, da du nicht OTA wieder zurückflashen kannst, sondern für diesen Fall einen entsprechenden FTDI-USB-Adapter mit dem Shelly verkabeln musst und im Prinzip wie hier vorgehen musst.

Zitat von Bene2103

Allerdings muss ich dazu sagen, dass die "io" Parameter aktuell anders erstellt werden, wie im Wiki von HAA angegeben. Laut Wiki muss das Ganze so aussehen "io":[[[5,4,6]1,0]] aber da ich noch keine Idee hatte, wie ich die GPIO's je nach Konfiguration gruppieren kann, sieht es aktuell so aus "io":[[[5]1,0],[[4]1,0],[[6]1,0]] Ich gehe davon aus, dass das genauso funktioniert.

Das ist schonmal eine großartige Neuigkeit! Tatsächlich funktioniert deine abweichende Konfiguration. Der einzige Nachteil ist eine "unnötige" Ausweitung des Skripts durch die Wiederholung der gleichen Optionen. Die offizielle IO-Konfi fasst sowas (sichtlich) speichersparend zusammen.

Bei kleinen Projekten ist das kein Problem, bei ESP32 mit größerem DRAM schon gar nicht. Bei der Schaltpultidee von walta mit knapp 100 gedachten GPIOs könnte es etwas unübersichtlich werden?!

Zitat von Bene2103

Aktuell habe ich nicht alle Funktionen integriert, welche HAA bietet, da ich nicht wirklich weiss, ob die jemand benutzt. Dinge wie z.B. "HomeKit Device Category" sind nicht im Tool enthalten, sollte es jedoch der eine oder andere unbedingt brauchen, könnte man das noch hinzufügen.

Da bin ich eher der Überzeugung, dass, wenn etwas vorhanden ist, das früher oder später auch von irgendjemandem genutzt wird – grade dann, wenn durch dein Tool womöglich mehr Leute RavenSystem nutzen. Wie das so ist, wächst der ein oder die andere mit ihren Aufgaben und will schnell mehr Möglichkeiten nutzen. Da ist nicht die Frage "ob" jemand das benutzt, sondern wann jemand das nutzen möchte

Optimal wäre natürlich die Integration der gesamten Möglichkeiten. Ich kann mir auf der anderen Seite gut vorstellen, was das für einen Entwicklungsaufwand bedeutet.

Ich persönlich werde, wie gesagt, das Tool einfach mal testen. Jedoch komme ich kurzfristig nicht dazu. Werde dir aber meinen Eindruck auf jeden Fall mitteilen.

Zitat von walta

http://192.168.178.195/relay/0?turn=off

schaltet als Beispiel ein andere Shelly aus.

Das wiederum müsste in Script recht leicht gehen über:

"0": { "h": [{ "h": "192.168.178.195", "u": "relay/0?turn=off"}]}

Zitat von Mero

konstruktive Vorschläge und Tipps

Einer wäre, die Shellys umzuflashen und die bislang fehlenden HomeKit-Services verfügbar zu machen.

Für einen Großteil deiner Shellys stehen fertige Konfigurationen bzw. Skripte zur Verfügung.

Zitat von walta

kann andere Shelly direkt steuern.

Ist dazu irgendwo dokumentiert, wie die Shellys sich "unterhalten"?

Zitat von walta

Dann bin ich auch d1mini gestossen mit den 10 Eingängen, und jetzt der esp32 mit noch mehr. Wie viele eigentlich.

ESP32 hat 34 GPIOs

Wenn du dir für das Schaltpult-Projekt einen Gefallen tun willst, investier in die von RavenSystem direkt unterstützen MCP23017-Expander. Die werden über den I2C Bus über nur 2 GPIOs mit dem ESP verbunden und können per Kaskade beim D1 Mini entsprechend bis zu 8x16 = 128 GPIOs zusätzlich zu den internen GPIOs des D1 Mini (abzüglich der beiden I2C-GPIOs D4 + D5) bereitstellen. Beim ESP32 verdoppelt sich das nochmal durch seine 2 I2C-Busse, dies zzgl. der internen GPIOs. Kurz gesagt: Das sollte erstmal reichen.

Ich habe mal einen solchen Expander für einen 8-fach Touch Tastatur ausprobiert und bin begeistert von der einfachen Erweiterbarkeit und der unkomplizierten, einheitlichen GPIO-Konfiguration. Hier muss man im Unterschied zu den internen GPIOs nicht deren Besonderheiten beachten, Stichwort Pullup-/Pulldown-Widerstände etc.

Zitat von Bene2103

ich habe begonnen ein Tool zu schreiben, mit dem man die JSON configuration ganz einfach in einer GUI vornehmen kann.

Hallo Bene2103 , ein herzliches Willkommen meinerseits speziell in diesem Beitrag. Dein Projekt ist ein aus meiner Sicht großartiger Ansatz, der das RavenSystem nochmal nach vorne bringen könnte, da ich feststelle, dass viele potentielle Anwendende durch die kryptisch anmutenden JSON-Skripte bereits im Vorfeld abgeschreckt werden. Ich selbst hatte schon über eine ähnliche "Lösung" per Excel nachgedacht, aber man kann sich in dem Thema auch ganz schnell verzetteln.

Gleich eine Frage zu deinem GUI (das ich bei Gelegenheit einmal antesten werde): Unterstützt das bereits die neue Firmware 12.x mit neuer GPIO-Konfiguration?

Besonders hilfreich wäre in diesem Zusammenhang ein automatisiertes Migrationstool, das die vorherigen Skripte per Knopfdruck aktualisiert.

Ansonsten würde ich mich persönlich sehr freuen, wenn du mit deiner offensichtlichen Erfahrung und grundsätzlichen Expertise als professioneller Automatisierungsentwickler bei den hier angedachten Projektideen unterstützen würdest. Ich hätte da so ein paar Ideen.