Beiträge von loonypac

Zitat von Edward J. Nately III

Bei Licht denke ich mehr DMX , als an MIDI.

MIDI nach meinem Geschmack deshalb, weil das ein weltweit etablierter, bidirektionaler Steuerungsstandard seit 1982 bis heute ist, mit dem ich mich erstens auskenne und der zweitens alles (und noch mehr) bietet, was für Smarthome allgemein von großem Steuerungs- und Automatisierungsnutzen wäre. Allein die unglaubliche Vielfalt der erhältlichen Controller-Gerätschaften stünde über einen denkbaren „Konverter“ sofort zur Verfügung.

DMX basiert evtl. ähnlich Mackie auf MIDI?

Im Unterschied zu der bereits recht coolen Idee, ein defektes Analogpult umzubauen, brauchte ein schicker Controller „nur“ die CC oder Note-on/off Daten in Steuerdaten für HomeKit über den imaginären Wandler umsetzen – ganz ohne Schrauben und Löten. Erste Anwendungsidee: Anschlagsdynamische Lichtschaltung, je fester ich den MIDI-Lichtschalter drücke, desto heller die Lichtszene

Nachtrag: Weil mir das keine Ruhe gelassen hat, hab ich mal lose recherchiert. Tatsächlich gibt es bereits geeignete „Umsetzer“, zumindest schonmal als MIDI zu 8-fach-Relais. Daneben ESP32-basierte MIDI-Interfaces, die man sich umprogrammieren könnte. Das ist ja schonmal ein vielversprechender Ansatz.

MIDI Switcher - Set your MIDI free!

This module has a MIDI input socket and 8 outputs that can switch a 1 Amp load. Use it to trigger solenoids, relays, lamps, motors etc from a MIDI controller...

www.youtube.com

Zitat von walta

Die Idee des fix Zuordnens heißt, dass homekit umgangen wird. Ob und wie das bei einem d1mini geht weiß ich noch nicht.

Das wäre auch für viele meiner Schaltungen eine Wunschanforderung. Direktschaltungen zwischen den Geräten ohne irgendeine Bridge.

In RavenSystem scheint das möglich. Probiert hab ich’s noch nicht, aber es gibt sendeseitig schonmal die Network Request Actions , um Schaltbefehle direkt an geeignete Empfangsgeräte zu senden. Für den Response gibt es die Network Request unter der Rubrik Free Monitor. Hab damit allerdings noch nix gemacht. Interessant zu wissen wäre, ob/wie man bspw. eine ge-Rave-te Steckdose für den Direktempfang konfigurieren kann, sodass sie sowohl über HomeKit als auch unabhängig davon über einen beliebigen Direktschalter gesteuert werden kann.

Nun denn, nochmal neugierig nachgefragt, ohne über Geschmäcker zu fabulieren: Was für Schalter und welches Gehäuse verwendest du?

„Fix zugeordnet“ heißt was? Hast du eine wie auch immer geartete Direktverbindung zwischen Taster 48 und Licht 17?

Zitat von Edward J. Nately III

Defektes Mischpult

Dafür müsste man erstmal ein Defektes haben (oder auftreiben). Mein altes 03D hätte genug Schalter und Potis. Jetzt noch eine Schnittstelle von MIDI zu ESP, dann wär die Schaltzentrale perfekt.

Das für mich bislang größte Fragezeichen steht für ein gleichermaßen geeignetes wie "hübsches" Gehäuse für eine solche Schaltzentrale, dicht gefolgt von der Auswahl nicht minder "hübscher" Taster – womöglich gleich mit integrierter Status-LED. Hast du da schon Ideen? Da gibt’s zwar Einiges in elegantem Edelstahl, aber wie du schon sagst: teuer ohne Ende, insbesondere wenn es deutlich mehr als 10 Taster sein sollen.

Und man darf nicht die total unsinnige Automationsbegrenzung in HomeKit vergessen. Bei 250 ist Schluss. Bei theoretischen 100 Tastern samt Status LEDs wären schonmal HomeKit-seitig 200 reine Schalt-Automationen nötig. Ok, das ist eine etwas drastische Vorgabe, aber selbst bei 20 Tastern samt LEDs wären 40 Automationen verbraten. Da darf man also nicht schon an der Grenze schrubben, oder viel besser: Alle HomeKit-Automationen gleich nach Home Assistant auslagern und HomeKit nur noch als grafisches Interface nutzen

Zitat von Maddin84

Müsste ja irgend ein Code sein, den ich auf den ESP schreibe?!

Das von mir für HomeKit empfohlene ESP-basierte System wird hier in einem eigenen Unterforum beschrieben (siehe meine Signatur). Vielleicht liest du dich da einmal grundlegend ein, ob das überhaupt etwas für dich ist und beschreibst ggf. kurz, was genau dein ESP machen/können soll, dann wird dir sicherlich geholfen. Von meiner Seite muss das allerdings noch etwas warten, da ich derzeit durch andere Projekten vereinnahmt bin.

Eine funktionierende Variante für die genannten Temperatursensoren wurde hier vorgestellt.

Das Prinzip von Zeitplänen habe ich in meinem Weckerbeispiel beschrieben.

Beide Themen wurden noch unter inzwischen veralteter Firmware 11.9.1 umgesetzt. Die aktuelle Firmware macht noch einige Zusatzkonfis nötig. Die ältere Version "reicht" aber für den Einstieg, falls es bei dir schnell gehen muss.

Zitat von Edward J. Nately III

Bin eher ein SMM (Social Media Muffel) und dachte bislang, DISCORD sei ein Spielplatz für Gamer und verunglückte Whistleblower. Findet man sich dort zurecht oder führt einen die Suche nach "Raven" zu den Techno-Freaks?

Tatsächlich bin ich sogar eine SMS (Social Media Skeptiker) und mit deiner DISCORD-Einschätzung könntest du recht haben. Jedoch kannst du dir deine gewünschten Kanäle selbst wählen. In meinem Fall habe ich genau 1 gewählt. Nun darfst du raten, um welchen es sich handelt.

Meinem Geschmack entspricht das Forum überhaupt nicht. Es ist eher alles Kraut und Rüben wie in einem schlechten WhatsApp Chat, in dem alle durcheinanderschreiben und es keinen Moderator gibt.

Also lang nicht so schön übersichtlich und thematisch detailliert gepflegt, wie im Smartapfel-Forum Allerdings scheint der Entwickler auch wirklich ganz allein zu schaffen, weswegen ich nicht auch noch ein eigenes komplexes Fachforum mit allem Trallala erwarten kann.

Zitat von walta

Tja - das UFO und der Lehrling. An so einem Ding arbeite ich auch noch. Leider ist Mechanik (die Schalter) das teuerste in der Elektrik.

Sehr reizvoll, solch ein Schaltpult. Allerdings bin ich persönlich bei mehr als 20 Schaltern raus, wenn noch dazu womöglich 5 verschiedene Schalt-Modi (Einfach, Doppel, Lang, Sehr lang, 8 Sekunden lang) pro Schalter belegt werden.

Zitat von Maddin84

Eine Frage aber noch:

Beim D1 Mini kann ich den Intervall ja zum Beispiel auf „60 Sekunden“ stellen. Kann ich denn auch einstellen, dass dieser Intervall nachts (wo ich nicht in der Sauna bin) nur alle 30 Minuten die Temperatur ausliest? Oder nach Zeitplan schlafen legen und morgens automatisch aufwecken. Da wäre dann der Gedanke Energie Sparen im Vordergrund

Das Mindest-Abfrageintervall beträgt übrigens sage und schreibe 0,1 Sekunden. Damit würde vermutlich aber HomeKit in Information-Overflow-Bedrängnis geraten. Die anvisierten 60 Sekunden oder auch weniger sind überhaupt kein Problem. Ich selbst habe eine Schaltung mit einem DHT22-Temperatur-/Feuchtigkeitssensor realisiert, die alle 10 Sekunden aktualisiert und alle 10 Minuten die Daten in den ESP schreibt, von wo ich sie bei Bedarf als csv-Datein zwecks Auswertung exportieren kann. Alternativ kann der ESP die Daten auch gleich in eine externe Datenbank schreiben.

Was oft nicht bedacht wird, ist die einzigartige Möglichkeit, Automationen direkt im ESP auszuführen zu lassen, dies ohne Umweg und entsprechender Datenverzögerung über bspw. Homebridge oder HomeKit-Steuerzentralen. Schneller und zuverlässiger geht’s nicht (und selbst ein D1 Mini langweilt sich, wenn er nur die Daten eines Sensors auslesen darf).

Der Energiespargedanke für den ESP ist zwar richtig, allerdings macht HomeKit offenbar eine permanente WLAN-Kommunikation nötig, sodass ein Deep-Sleep im ESP regelmäßig zu Kommunikationsproblemen und Fehlverhalten in HomeKit führen würde. Was wohl neuerdings möglich ist, ist ein integrierter WiFi Sleep Mode, der allerdings nur von ESP32 unterstützt wird. Der wiederum würde sich noch viel mehr langweilen, wenn er nur Temperaturdaten messen dürfte.

Was sehrwohl möglich ist, sind ESP-interne Zeitpläne, wann die Sensoren messen sollen. Dafür kann man diese einfach automatisiert und/oder manuell de-/aktivieren. Das jedoch wird wenig am Energieverbrauch des ESP ändern.

Zitat von walta

Bringt die neue Version für die esp8266-er einen Vorteil?

Die Vorteile scheinen derzeit für ESP8266 eher marginal, insbesondere laufende Projekte profitieren da noch nicht spürbar, weswegen ich im Unterschied zu Edward J. Nately III meine ESPs auch noch nicht geupgradet habe Ich nehme aber stark an, dass zukünftig weitere Actions auch für die 8266 ergänzt werden.

Regelrecht neu lernen muss man eigentlich nicht, wie gesagt ist das GPIO-Setup überarbeitet und im Config-Array nun recht übersichtlich zentral angeordnet worden. Es ist also mehr ein Dazulernen. Ich werde dazu, wenn wieder Zeit ist, mal eine Kurzerkäuterung hier für euch beide posten.

Die Vorteile von Merlin gelten im Moment ganz klar vor allem für ESP32 basierte Geräte. Ich könnte nun 3 meiner D1 Mini mit 1 ESP32 ersetzen und noch jede Menge dazustricken. In einer kleinen Demo hat der Entwickler spaßeshalber 100 Schalter über 1 Microkontroller angelegt. Der DRAM vom ESP32 ist fast um Faktor 10 gegenüber dem 8266 größer. Dadurch lassen sich komplexe Multi-Devices mit vielen Sensoren und Hardware-IOs nur mit 1 Kontroller basteln.

Das Treiben im Raven-Discord-Forum ist derzeit sehr rege und bietet bereits viele fertige Scripte. Und wie gesagt mischt der Mastermind da nach Kräften sehr engagiert mit und reagiert teilweise in Echtzeit. Das habe ich noch nirgendwo anders so engagiert erlebt.

Zitat von RavenSystem Release

Changelog v12.0.1:

• Fixes ESP8266 GPIO 16 initial state bug.
• Remove unnecessary variable in Advanced Logger NTP library.

Changelog v12.0.0:

• BREAKING CHANGES !!! Check Migration Guide
  • GPIOs must be declared in a new general array to be used, GPIOs Configuration.
  • Continuous Mode for Binary Inputs must be enabled explicitly when needed. Binary Input Continuous Mode.
  • UART Configuration has a new way to setup UART receivers.
  • I2C can have pull-up resistors optionally, for SCL and SDA pins. I2C Configuration.
  • Log outputs are different to allow use of UART2 for ESP32 models.
  • Logs: UART must be configure to use as log output.
• Add support for Espressif ESP32, ESP32 Single-Core, ESP32-C2, ESP32-C3, ESP32-S2 and ESP32-S3 chip models.
• New Action: PWM Actions.
• UART for ESP32 support modes, including RS485 and IrDA.
• New WiFi Sleep Mode: Added "d" key to configure it.
• Added network hostnames for HAA Installers and HAA Main in Setup Mode.
• Huge DRAM improvements in JSON library.
• CPU and DRAM improvements.
• Initial GPIOs state at boot is DISABLE for ESP8266.

Dann ergänz doch bitte laut obigem V12 kompatiblem Sonoff Basic Script den „io“-Key im Config-Array

"io":[[[13],3],[[0],6],[[12],2]],

Hm, da hat sich nix geändert. Vor allem auf die alte Version müsste ja unverändert zugegriffen werden können. Hier vermute ich, im Trüben fischend, ein Netzwerkproblem.

Löst du den Setup-Mode über den HAA-Manger aus. Wird beim Schalter dabei das ok angezeigt?

Nachtrag: Hast du in der Adressleiste mal überprüft, ob Firefox vor die IP ein www. Setzt? Safari macht das mitunter, was dann auch entsprechend fehlschlägt.

Bitte IMMER vor Updates Hinweise auf der GitHub Site beachten. Das erspart derartigen Verdruss

Zitat von Edward J. Nately III

Oder kann man die Skripte auch remote ändern?

Selbstverständlich. Wir erinnern uns an den Setup-Mode!

Ich habe mal im Discord-Forum einen Rollgriff für folgende Standard-Geräte gemacht. Schau mal, ob du klar kommst, die „io“ Eintragungen in der Config „c“ sind entscheidend. Außerdem musst du alles, was mit Push Up/Down Widerständen im alten Accessory-Bereich definiert war, dort löschen.

Zitat von RavenSystem Discord Forum

Sonoff Basic:

{"c":{"io":[[[13],3],[[0],6],[[12],2]],"n":"Sonoff Basic","l":13,"b":[{"g":0,"t":5}]},"a":[{"0":{"r":[{"g":12}]},"1":{"r":[{"g":12,"v":1}]},"b":[{"g":0}]}]}

Sonoff S26:

{"c":{"io":[[[13],3],[[0],6],[[12],2]],"n":"Sonoff S26","l":13,"b":[{"g":0,"t":5}]},"a":[{"t":2,"0":{"r":[{"g":12}]},"1":{"r":[{"g":12,"v":1}]},"b":[{"g":0}]}]}

Shutters remote:

{"c":{"io":[[[0],6],[[14,5,13,3],2]],"n":"Shutters remote"},"a":[{"t":45,"o":32.8,"c":31.3,"f":70,"0":{"r":[{"g":14},{"g":5,"v":1,"i":0.3}]},"1":{"r":[{"g":14,"v":1,"i":0.3},{"g":5}]},"2":{"r":[{"g":5},{"g":14},{"g":4,"v":1,"i":0.3}]},"3":{"r":[{"g":14},{"g":5,"v":1,"i":0.3}]},"4":{"r":[{"g":14,"v":1,"i":0.3},{"g":5}]}},{"t":45,"o":28.7,"c":26.5,"f":70,"0":{"r":[{"g":13},{"g":3,"v":1,"i":0.8},{"g":3,"i":0.5}]},"1":{"r":[{"g":13,"v":1,"i":0.8},{"g":13,"i":0.5},{"g":3}]},"2":{"r":[{"g":3},{"g":13},{"g":12,"v":1,"i":0.3}]},"3":{"r":[{"g":13},{"g":3,"v":1,"i":0.3}]},"4":{"r":[{"g":13,"v":1,"i":0.3},{"g":3}]}}]}

MagicHome RGB:

{"c":{"io":[[[5,12],7,0,0,2],[[13],7]],"n":"MagicHome TV RGB"},"a":[{"t":30,"g":[5,12,13],"fa":[2,5,5]}]}

TV cabinet W:

{"c":{"io":[[[14],7]],"n":"Own TV cabinet W"},"a": [{"t": 30,"g":[14]}]}

Under table lights W:

{"c":{"io":[[[12],7]],"n":"Own table W"},"a":[{"t":30,"g":[12]}]}

Kitchen lights W:

{"c":{"io":[[[15],7]],"n":"Own kitchen W"},"a": [{"t": 30,"g":[15]}]}

Bedroom lights:

{"c":{"io":[[[13,12],7,0,0,2],[[14,4],7]],"n":"Own bedroom RGBW"},"a":[{"t":30,"g":[13,12,14],"fa":[12,7,42]},{"t":30,"g":[4]}]}

Alles anzeigen

Oops, das liest sich so, als hättest du die Migrationsanleitung nicht befolgt. Das Major-Upgrade 12 hat ein neues GPIO-Setup mit dem neuen Key „io“ eingeführt, was den komplexeren ESP32 geschuldet ist. Entweder arbeitest du dich da ein (sollte relativ leicht nachvollziehbar sein) und ergänzt die Konfiguration oder flashst zurück auf 11 bzw. flashst deinen letzten Backup-Clone, den du ja sicherlich gemacht hast

Ich bin wegen einer zeitfressenden Auftragsarbeit grade leider in anderen Gewässern ausgelastet und habe mich noch nicht mit den Details auseinandergesetzt. Kannst aber trotzdem mal ein Script hier posten, vielleicht können wir das schnell migrieren.

Noch ein Tipp: Im Raven-Discord-Forum haben sich zahlreiche User vom RavenSystem-Master himself ihre Scripte checken und migrieren lassen. Der Mann ist offenbar ein Besessener und hat im Minutentakt die Scripte korrigiert, Hammer.

Für die wenigen ESP-Bastler: RavenSystem hat soeben die neue Firmware 12.0.0 Merlin veröffentlicht. Damit werden die Karten nochmal neu gemischt, denn dadurch werden zukünftig ESP32 nativ für HomeKit unterstützt. Das schafft neben deutlich vergrößertem DRAM-Speicher für umfangreiche Scripte auch sehr vorteilhafte Möglichkeiten für beliebte Devices bspw. für aktuelle Shelly Plus Gerätschaften.

Ich bin einmal mehr begeistert vom Entwickler und seinem System – jetzt mit neuem Schub für viele weitere (eigene) HomeKit Devices

Zitat von Gassi

da bald die Pool Saison anfängt und ich eigentlich schon seit 2 Jahren nach einer einfachen Lösung ohne Homebridge... also nur mit Homekit-Anbindung funktioniert.

Vielleicht ist die Lösung von @Mighty61 ja was für dich.

Zitat von crizzydizzy81

Oder würdet ihr das anders angehen?

Ich würde das entweder wie im kürzlichen Beitrag zum Thema Leistungssteuerung angedeutet mit einer modifizierten bzw. dafür programmierten Steckdose machen, oder, wenn nur gemessen und nicht die Stromzufuhr geschaltet werden soll, einen Leistungssensor über ESP auslesen. Letzteres muss man dann allerdings selbst bauen.

In beiden Fällen kann so der Zeitpunkt gemessen werden, ab dem die Waschmaschine den letzten Knitterschutz ausgeführt und in einer durchgängigen Standby-Leistung verbleibt. Diesen Zeitpunkt würde ich mir über einen dafür definierten Kontaktsensor in HomeKit melden lassen.

Du kannst dir für knapp 18,- € eine Tasmota geflashte Steckdose mit Leistungsmessung kaufen, dieselbe over the air umflashen, um sie nativ HomeKit zu machen. Neben zahlreichen Sonderfunktionen lässt sich danach u.a. auch die gewünschte Automation mit Schaltung oberhalb/unterhalb einer gewünschten Spannung/Stromstärke/Wattzahl autark innerhalb der Steckdose ausführen, was zuverlässiger und schneller schaltet als der „Umweg“ über HomeKit.

Details dazu nur bei Interesse.

Mia liest sich interessant. Wie aber würden diese Kameras etwa auf ausgedruckte bzw. gefälschte Kennzeichen reagieren? Ist da ein Schutz vorgesehen?

Zitat von HolgerKR

HomeKit-nativ wüsste ich jetzt nicht, wie man das realisieren sollte.

Na, da gibt’s doch schon eine einfache native Lösung  Damit könnten dann auch gleich die WLAN-Geräte in den Fahrzeugen umgesetzt werden. Das Wichtigste ist dabei die Verbindungsgeschwindigkeit.

Hier mal ein rein theoretischer Ideenansatz:

Die gewünschte Automation wird über einen sich an- und abmeldenden WLAN-Teilnehmer ausgelöst.

Dafür wäre ein Accesspoint in der Garage notwendig, der bis zu den gewünschten Fahrzeugen genügend Empfangs-/Sendeleistung haben müsste. In allen relevanten Fahrzeugen könnten x-beliebige WLAN-Geräte fest deponiert werden, die für das jeweilige Fahrzeug festgelegt werden und darin verbleiben, somit also das jeweilige Fahrzeug "identifizieren". Dadurch ist Fahrzeug und Fahrer flexibel austauschbar.

Wenn dann vorgefahren wird und der Verbindungvorgang schnell genug ist, löst die WLAN-Verbindung die Öffnungsautomation aus.

Vorteil gegenüber der GPS-Ortung ist dabei, dass nicht das iPhone, welches ja in der Regel immer am Mann oder an der Frau ist, die Automation auslöst, wenn man bspw. nach dem Sonntagsspaziergang wieder daheim ankommt. Es muss also immer das Fahrzeug bewegt werden. Außerdem können billigste WLAN-Geräte mit möglichst geringem Verbrauch genutzt werden.

Wie gesagt, alles graue Theorie einer Grundautomation, die damit steht und fällt, wie schnell sich eine Gerät am Accesspoint anmeldet. Schließlich will man ja nicht erst 10 Minuten warten.

Habe interessehalber mal einen variablen Graufilter vor die HUE gehalten. Der „regelt“ von 14.400 auf 2.400 Lux runter. Das hat dann aber nix mehr mit akkurater Lux-Messung zu tun.

Zitat von Titanicberlin

Scheinbar ist er ja so konzipiert aus Selbstschutz.

Ein Bug als Feature Bist du zufällig im Bereich Marketing tätig?

Man könnte bei den Teilen zumindest argumentieren, dass sie in erster Linie Bewegungssensoren sind und die Lichtmessung nur eine Zugabe für eingeschränkte Nutzung im nicht zu hellen Indoor-Bereich.

Wie gesagt, bei den Philipsen ist eine vermutlich ganz ähnliche billige Hardware verbaut und die senden auch bei direkter Sonnenstrahlung weiter.