ESP RGBWW Wifi Led Controller - fhem - Modul

[vbs]

Meiner Meinung nach eigentlich nicht so sehr, da der develop-Branch eben der tagesaktuelle Entwicklungsstand ist. Da können täglich Änderungen reinkommen die die API verändern (wie wir gerade am eigenen Leib erfahren haben ) oder sogar Bugs, die das ganze Framework instabil/unbrauchbar machen in dem Moment. Daher bin ich sehr dafür, sich an die getaggten, freigegebenen Versionen zu halten.

[vbs]

Hat das dann eigentlich noch geklappt mit dem Sming 3.1.2?

[pjakobs]

Hat das dann eigentlich noch geklappt mit dem Sming 3.1.2?

Ich kämpfe noch daran.

Gesendet von meinem HTC 10 mit Tapatalk

[vbs]

Sag Bescheid, falls man irgendwie helfen kann.

[vbs]

Also zu dem MQTT/Broadcast-Ansatz:
Wie würdet ihr das machen wollen? Der Master schickt seinen Zustand an die Slaves und die Slaves schalten darauf um oder gibts da noch andere Ansätze?

Wenn man das genau so machen würde, dann müssten alle Slaves (während Fades) permanent 20 Nachrichten pro Sekunde empfangen, damit sie genau so sauber faden wie der Master.

[dev0]

Aus dem Sammelbestell-Thread übernommen:

Mehrere Controller direkt synchronisieren zu können wäre ein tolles Feature! MQTT oder eine andere zentrale Vermittlung ist, ans meiner Sicht, dafür aber der falsche Ansatz, da
- kein standanlone Betrieb (ohne 24/7 Server)
- unnötiger single point of failure
- aufwendiger einzurichten
- zusätzliche Latenz

Eine Alternative, ohne den Umweg über einen Server (zB. MQTT) zu gehen, wäre UDP Broadcasts zu nutzen. Im ESPEasy Framework findet man diese Lösung bereits in umgesetzter Form. Wäre das nicht vielleicht der elegantere Weg?

Das Argument "Server nötig" verstehe ich nicht. Bei mir läuft der MQTT Broker auf dem gleichen RaspberryPi wie fhem selbst. Mir wäre MQTT gerade deshalb sympathisch, weil es sich in die vorhandene Landschaft, die wohl viele fhem Nutzer so haben, prima einfügt.

Es geht mir nicht nur um den zusätzlich Broker Dienst, sondern darum, dass es (wie zB. bei Homematic) unabhängig von einem Server/FHEM funktioniert.

[dev0]

Also zu dem MQTT/Broadcast-Ansatz:
Wie würdet ihr das machen wollen? Der Master schickt seinen Zustand an die Slaves und die Slaves schalten darauf

Ich dachte eher daran, dass der Sollzustand bzw. das selbe Kommando das der Master empfangt geschickt wird. Das Faden bspw. sollte der Slave dann selbst dürchführen.

[pjakobs]

Ich dachte eher daran, dass der Sollzustand bzw. das selbe Kommando das der Master empfangt geschickt wird. Das Faden bspw. sollte der Slave dann selbst dürchführen.

dann hast Du, zumindest theoretisch, das Problem, dass die Fades auseinanderlaufen können, wenn die ESPs nicht synchron laufen. Wenn ein Master mehrere Slaves mit *aktuellen* Kanalwerten versorgt, fällt das weg.
Was Du suchst hat @vbs in einem experimentellen FHEM Modul implementiert, allerdings bin ich nicht überzeugt, dass es dahin gehört.

Wie nutzt Du denn die Controller, wenn Du nicht irgendeinen Server einsetzt? Direkt über die Firmware Oberfläche?
Ich bin durchaus interessiert daran, andere Nutzungsmöglichkeiten zu eröffnen (Mobiltelefon App, openHAB, nodeRED etc) und auch dort glaube ich, dass MQTT in vielen Fällen der einfachere Weg ist (ok, nicht für die Mobiltelefone).

pj

[dev0]

dann hast Du, zumindest theoretisch, das Problem, dass die Fades auseinanderlaufen können, wenn die ESPs nicht synchron laufen. Wenn ein Master mehrere Slaves mit *aktuellen* Kanalwerten versorgt, fällt das weg.

Ich kann mir im Moment nicht vorstellen warum die beiden Varianten mehr/weniger auseinander laufen sollten. Ob der Steuerbefehl oder die aktuellen Daten verzögert ankommen wirkt sich doch gleich aus. Wenn man nur den Steuerbefehl schickt, ist der Traffic zumindest geringer, der verarbeitet werden muss.

Wie nutzt Du denn die Controller, wenn Du nicht irgendeinen Server einsetzt? Direkt über die Firmware Oberfläche?

Hauptsächich natürlich über FHEM, allerdings wäre der nächste Schritt ein (Touch-)Wandschalter, der direkt mit dem RGBWW Controller spricht um die gleiche Unhabhängigkeit von FHEM zu erreichen wie zB. mit Homematic: alles geht auch ohne FHEM, nur eben nicht automatisiert.

[vbs]

Ich kann mir im Moment nicht vorstellen warum die beiden Varianten mehr/weniger auseinander laufen sollten. Ob der Steuerbefehl oder die aktuellen Daten verzögert ankommen wirkt sich doch gleich aus. Wenn man nur den Steuerbefehl schickt, ist der Traffic zumindest geringer, der verarbeitet werden muss.

Geht dabei weniger um die Netzwerklatenz, sondern um die Clocks der Geräte. Wenn zwei Geräte einen langen Fade synchron ausführen sollen (sagen wir 6h lang), dann müssen die Quarze halt einen sehr guten Gleichlauf haben.

Das Problem hat man tatsächlich gar nicht, wenn die Master regelmäßig ihren Zustand posten und alle Slaves hart darauf umschalten. Dann steckt praktisch keine Logik mehr in den Slaves. Bin da aber auch kein Freund von u.a. wegen dem genannten Konfigurationswissen, was dann in den Controllern verteilt wird. Außerdem finde ich es unschön, dass die Slaves permanent mit 20 NAchrichten pro Sekunde "gefüttert" werden müssten.

Man sollte mMn erstmal rausfinden, wie ungleich die Controller in der Praxis wirklich laufen. Ansonsten zerbricht man sich evtl. den Kopf über ungelegte Eier. ISt auch die Frage welche Länge an Fades man bedienen will. Will man wirklich 3-Tages-Fades supporten oder reichen 3 Stunden? Man könnte dann einfach nach 3 Stunden den Fade neu anstoßen und damit neu synchronsieren.

[RaspiLED]

Hi,
das Problem hat doch eigentlich zwei Komponenten.

a) Kurze Fades (<1 Minute):
Keine Synchronisation notwendig, nur der Set Befehl muss verteilt werden
b) Lange Fades:
Hier könnte man:
1) An einem Master den gesamten Fade rechnen und jede Minute einen Set Befehl an Slaves versenden (Mein Favorit)
2) ein Master rechnet und gibt jedem Zustand weiter -》Viel Funkverkehr
3) alle bekommen Set Befehl und laufen über lange Zeit auseinander. Meine Lösungsidee: Synchronisation zwischen Controllern ermöglichen (Entweder über Master Slaves Ansätze: mqtt oder udp oder einfach über fhem reading?) aber noch besser wäre dass alle Controller gleichberechtigt sind,  selbstständig als Broadcast nach Status fragen können und Antworten von anderen Controllern hören und sich dann anpassen. (Analog zu DHCP Anfragen)

Gruß Arnd

Gesendet von meinem SM-G800F mit Tapatalk

[pjakobs]

Hi,
das Problem hat doch eigentlich zwei Komponenten.

a) Kurze Fades (<1 Minute):
Keine Synchronisation notwendig, nur der Set Befehl muss verteilt werden
b) Lange Fades:
Hier könnte man:
1) An einem Master den gesamten Fade rechnen und jede Minute einen Set Befehl an Slaves versenden (Mein Favorit)
2) ein Master rechnet und gibt jedem Zustand weiter -》Viel Funkverkehr
3) alle bekommen Set Befehl und laufen über lange Zeit auseinander. Meine Lösungsidee: Synchronisation zwischen Controllern ermöglichen (Entweder über Master Slaves Ansätze: mqtt oder udp oder einfach über fhem reading?) aber noch besser wäre dass alle Controller gleichberechtigt sind,  selbstständig als Broadcast nach Status fragen können und Antworten von anderen Controllern hören und sich dann anpassen. (Analog zu DHCP Anfragen)

Gruß Arnd

Gesendet von meinem SM-G800F mit Tapatalk

Fades werden in der Firmware ja mit 50Hz berechnet uns ausgeführt, und da die ESP 10Bit PWM verwenden ist ein Fade maximal 1023 Schritte lang, d.h. der "schlimmste" Zustand ist ein 20 Sekunden Fade über den gesamten Helligkeitsbereich eines Kanals, der dann etwa 20s lang 50 Messages pro Sekunde erzeugt. Bei schnelleren Fades kommen zwar immer noch 50MQTT Updates pro Sekunde, aber die Schrittweite ist größer, das heißt insgesamt sind es weniger Nachrichten, bei längeren Fades wäre es natürlich sinnvoll, nur für Änderungen eine Message rauszusenden. Bei 20 Minuten wäre das nur noch etwas weniger als eine Nachricht pro Sekunde.

Und zur Konfiguration: die würde man natürlich sinnvollerweise im FHEM Modul unterbringen und dort ein- und ausschaltbar machen, so dass die Konfiguration zwar auf den Controllern umgesetzt, aber zentral verwaltet werden würde.

pj

[vbs]

Fades werden in der Firmware ja mit 50Hz berechnet uns ausgeführt, und da die ESP 10Bit PWM verwenden ist ein Fade maximal 1023 Schritte lang, d.h. der "schlimmste" Zustand ist ein 20 Sekunden Fade über den gesamten Helligkeitsbereich eines Kanals, der dann etwa 20s lang 50 Messages pro Sekunde erzeugt.

Das stimmt zwar, aber nur für einen einzelnen Fade. Wenn der Controller aber z.B. einfach den Hue immer durchrotiert (z.B. Discomodus), dann hast du einfach permanent die 50 Nachrichten pro Sekunde (richtigerweise 50 und nicht wie ich schrieb 20 ).

[pjakobs]

Das stimmt zwar, aber nur für einen einzelnen Fade. Wenn der Controller aber z.B. einfach den Hue immer durchrotiert (z.B. Discomodus), dann hast du einfach permanent die 50 Nachrichten pro Sekunde (richtigerweise 50 und nicht wie ich schrieb 20 ).

Das ist aber auch schwierig, wenn der gleiche Befehl zentral abgesetzt wird, denn dann musst Du ja auf ein Synchronisationssignal der Controller warten (bzw. der loop / predefined animatio Mode muss implementiert sein).

pj

[Shuzz]

Guten Tag zusammen,

ich möchte mich gern wieder zurück melden...
Hatte die letzten Wochen/Monate privat einiges um die Ohren und hatte keine Zeit mehr für den Controller (FHEM und FW).

Nach allem was ich so lese hat sich der Status seit Januar aber nicht gravierend geändert oder?
Gut finde ich die FW auf dem 3.1.2er Sming Framework. Ich werde die Tage mal versuchen, das nachzuvollziehen und zu bauen.

Kurzer Hinweis zu den "vordefinierten" Animationen: Die wird es so nicht geben laut Patrick Jahns.
Seine Idee ist, einen kompletten Fade in einen einzigen HTTP POST zu packen - mehr aber auch nicht.
Auf den Controllern soll nichts gespeichert werden weil er der Meinung ist, das gehöre dort nicht hin sondern soll im FHEM Modul (oder sonstwo, jedenfalls nicht im Controller) verbleiben.
Sonst müsste man ja schließlich die Animationen immer auf allen Controllern synchron halten usw. usf.
Das war jedenfalls der Stand als ich das letzte Mal Kontakt zu ihm hatte, iwann Ende Januar.
Zumindest sollen diese Animationen dann aber loopen können, was ja schonmal etwas wäre.

Den MQTT Ansatz zur Synchronisierung finde ich eigentlich sehr schnuckelig, und viel effizienter als per Publish/Subscribe kriegt man viele Geräte eh nicht synchronisiert.
Selbst wenn da 50 Nachrichten pro Sekunde und Controller über's WLAN gehen - wäre das schlimm?
Ist ja nicht wie bei den 433/868MHz Standards, dass man nur eine gewisse Anzahl an Telegrammen senden darf...
Ich denke, selbst bei relativ großen Installationen sollte ein handelsübliches Home-Wifi da locker mithalten können.


Beste Grüße,

Shuzz