ESP RGBWW Wifi Led Controller - Hinweise zu Sammelbestellung 2.5

[Hauswart]

Hatte ich noch überlegt, war mir nur nicht ganz sicher, ob "Schwarz" wirklich aus ist.

[pjakobs]

ich nutze den Controller nun schon seit zwei Wochen mit dem fhem Modul hier
Wäre schön, wenn andere das auch testen könnten und entsprechend Bugs / Anregungen reporten

pj

[kaihs]

Wäre schön, wenn andere das auch testen könnten und entsprechend Bugs / Anregungen reporten

Hallo,

ich habe es ausprobiert, funktioniert schon ganz gut.
Folgende Vorschläge habe ich noch:

• Verwendung von Color
• Verwendung von SetExtensions
• Statt RGB,HSV,HUE lieber rgb,hsv,hue als Set-Kommando und  Reading, das würde zumindest besser zu den anderen Modulen wie HUEDevice passen und es leichter machen die Beispiele zu übernehmen
• Du verwendest im Code $ledDevice für den Hash, fast alle anderen Moduie dagegen $hash. Ist nur Kosmetik, macht es aber IMHO leichter den Code zu lesen.

Die ersten beiden Punkte habe ich lokal schon umgesetzt und könnte ich zur Verfügung stellen.

[mrpj]

Entschuldigt die Verzögerung - ich bin im Moment recht selten im Forum (und wenn ich Zeit hab ist es nun öfters offline?).

1. hab ich gerade mal nachgemessen, in Ruhe braucht die Schaltung unter 300mW, das ist viel weniger als die ca. 550mW, die ich bisher mit ESP8266 und aktivem WLAN gesehen habe, nutzt Du irgendwelche low power Zustände?

Interressant - eigentlich mache ich genau das Gegenteil in der Firmware mit

Code Auswählen Erweitern

wifi_set_sleep_type(NONE_SLEEP_T);. Wie hast du denn die anderen ESP Schaltungen verkabelt und gemessen? Kann es sein dass dort ein Linearregler verwendet wird?

ansonsten: mein Wohnzimmer erstrahlt nun im Licht von 10m RGBwW single Chip LEDs (also etwa 600 Stück), angesteuert durch den RGBWW Controller und das fhem Modul wie's im Github liegt - ok, da war noch ein kleiner Bug drin, aber den check ich nachher auch noch ein.

Freut mich zu lesen - welche LED Leisten verwendest du denn? Sind die 10m an einem Controller?

Blöde Frage zum Ausschalten der LED-Kette gibt es bisher keine Möglichkeit?

Wurde ja schon beantwortet - Aus ist bisher nur als schwarz definiert (bzw. wenn einzelne Kanäle gefadet werden mit dem wert 0). Wenn nötig kann ich noch einen API Befehl für aus implementieren - sehe aber keine Notwendigkeit

[pjakobs]

@kaihs:

danke für's testen!

Verwendung von Color

Das Konzept muss ich mir ansehen, hatte ich noch nicht

Verwendung von SetExtensions

Hab ich mir gerade mal angesehen, klingt vernünftig und einfach umzusetzen.
Schau ich die Woche mal drauf.

Statt RGB,HSV,HUE lieber rgb,hsv,hue als Set-Kommando und  Reading, das würde zumindest besser zu den anderen Modulen wie HUEDevice passen und es leichter machen die Beispiele zu übernehmen

die hatte ich so übernommen, bin da aber komplett emotionslos

Du verwendest im Code $ledDevice für den Hash, fast alle anderen Moduie dagegen $hash. Ist nur Kosmetik, macht es aber IMHO leichter den Code zu lesen.

same here.
Grundsätzlich denke ich, das Ding sollte, wenn mal alle Funktionalität implementiert ist, in WifiLight gemerged werden, von daher ist alles, was die Struktur von vornherein kompatibel macht sinnvoll.
Ich will mir im Moment einfach nicht die Komplexität von WifiLight auch noch antun.

was Änderungen angeht: ich hab mit Patrick ausgemacht, dass er das Modul in seinen Github Account übernimmt, damit ist alles, was zum RGBWW Controller gehört an einer Stelle. Sobald das passiert ist kannst Du Deine Änderungen gerne pushen bzw. einen pull request aufmachen. (je nachdem wie's von den Rechten her funktioniert).

@mrpj

Wie hast du denn die anderen ESP Schaltungen verkabelt und gemessen? Kann es sein dass dort ein Linearregler verwendet wird?

nee, das waren eigentlich immer so 170mA an 3,3V - seltsam. Hätte ja sein können, dass Du irgendeinen tollen Trick anwendest

Freut mich zu lesen - welche LED Leisten verwendest du denn? Sind die 10m an einem Controller?

ich habe auf einer bekannten fernöstlichen Handelsplattform 4in1RGBWW 5050 Strips gefunden. Alle drei LED Chips sind die Strips teilbar oder, alternativ, lassen sich dort zwei Strips nahtlos aneinander löten. Das habe ich getan und habe damit einmal 9m am Stück und noch einmal 1m auf der anderen Seite des Controllers. Insgesamt hängen also 10m an einem und alles zusammen an einem 12V5A Schaltnetzteil. Die höchste Gesamtstromaufnahme habe ich bisher mit 1,8A gemessen, weil ja zumindest beim Ansteuerugngsmodell HSV, wie es das aktuelle fhem Modul verwendet, nie alle LEDs zur gleichen Zeit voll angesteuert sind. Mit RAW ließe sich das wohl auf 5A, möglicherweise sogar höher aufdrehen, aber in meinem Anwendungsfall tritt das nicht auf, und mal ehrlich 60W LED in einem Raum von 4x5m wäre ein bisschen zu hell

Wie vorher schon geschrieben: wenn die LEDs ausgeschaltet sind (also h,s,v=x,y,0), dann sinkt die Stromaufnahme auf knapp und 25mA an 12V also unter 300mW - damit kann ich prima leben, selbst wenn das Netzteil dabei vielleicht nur noch einen Wirkungsgrad von 30% hat und deshalb 1W aus der Steckdose nimmt.

pj

[herrmannj]

Ola,

Verwendung von Color

Ich habe da eine Weile nicht rein gesehen. Im Prinzip ist es aber redundant, in Kern ist das im Modul besser aufgehoben. Denke aber wir haben wesentlichere To-Do

Verwendung von SetExtensions

Veto!
Die Funktionen kollidieren mit dem Konzept der Transitions und der Queue.

Statt RGB,HSV,HUE lieber rgb,hsv,hue als Set-Kommando und  Reading, das würde zumindest besser zu den anderen Modulen wie HUEDevice passen und es leichter machen die Beispiele zu übernehmen

Ebenfalls emotionslos. Wenn sich da was über die verschiedenen module harmonisieren lässt finde ich das super. Können uns gern auf Kleinschreibung einigen.

Grundsätzlich denke ich, das Ding sollte, wenn mal alle Funktionalität implementiert ist, in WifiLight gemerged werden, von daher ist alles, was die Struktur von vornherein kompatibel macht sinnvoll.

Könnte man machen. Weil die Ansteuerung des Controllers ja doch etwas unterschiedlich ist, könnte man das aber auch getrennt weiterlaufen lassen. Ich halte das insofern für Vorteilhaft das mprj dann je nach Lust und Laune die fw des controllers (weiter) entwickeln kann ohne dabei künstlichen Beschränkungen unterworfen zu sein.

WifiLight ist ja von der Philosophie so das es ganz unterschiedlichen Controllern eine einheitliche GUI und ein gleiches look-and-feel gibt. Um spezielle fw Funktionen umzusetzen macht ein spezialisiertes Modul imho Sinn. Von der Bedienung kann es ja kompatibel bleiben - die fw des controllers ist ja auch so ausgelegt.

vg
joerg

[pjakobs]

Ola,
Ich habe da eine Weile nicht rein gesehen. Im Prinzip ist es aber redundant, in Kern ist das im Modul besser aufgehoben. Denke aber wir haben wesentlichere To-Do

ToDo: ToDo sammeln!

Veto!
Die Funktionen kollidieren mit dem Konzept der Transitions und der Queue.

Queue - ja, Transitions? - nö, seh ich nicht.
Die Frage der Queue sollten wir uns eh mal ansehen, denn ich meine, das Thema ist im Controller bereits hinreichend abgedeckt. Vielleicht kann @mrpj ja nochmal was zum Verhalten der REST API sagen, wenn sie asynchron angesprochen wird (also zwei requests gleichzeitig "in flight" sind), aber ich glaube, dass das schon funktioniert.
Transitions, wenn sie auf dem Controller laufen, sind ja jetzt schon kein Thema. Wenn Du die sich ergebenden Werte wirklich im Modul mitplotten willst, dann würde ich das über MQTT machen und dann sehe ich nicht, dass setExtensions dem im Wege stünden.

Ebenfalls emotionslos. Wenn sich da was über die verschiedenen module harmonisieren lässt finde ich das super. Können uns gern auf Kleinschreibung einigen.
Könnte man machen. Weil die Ansteuerung des Controllers ja doch etwas unterschiedlich ist, könnte man das aber auch getrennt weiterlaufen lassen. Ich halte das insofern für Vorteilhaft das mprj dann je nach Lust und Laune die fw des controllers (weiter) entwickeln kann ohne dabei künstlichen Beschränkungen unterworfen zu sein.

WifiLight ist ja von der Philosophie so das es ganz unterschiedlichen Controllern eine einheitliche GUI und ein gleiches look-and-feel gibt. Um spezielle fw Funktionen umzusetzen macht ein spezialisiertes Modul imho Sinn. Von der Bedienung kann es ja kompatibel bleiben - die fw des controllers ist ja auch so ausgelegt.

Am Ende ist es mir wichtig, dass der Controller sich möglichst einfach in bestehende Umgebungen einbinden lässt, u.A. deshalb habe ich mich entschlossen, im Modul weiterhin 8Bit rgb zu verwenden, statt der nativen 10Bit. Klar können wir zusätzlich einen erweiterten API Satz pflegen (und das geht vermutlich sogar innerhalb von WifiLight, wenn auch mit mehr Aufwand) aber der Nutzen und die Nutzbarkeit sollten im Vordergrund stehen.

grüße

pj

[mrpj]

Ich hab das bisherige Module repository mal umgezogen auf:

https://github.com/patrickjahns/esp_rgbww_fhemmodule

Man kann davon forken etc. - alte commits sind in der history enthalten

Bei dem FHEM Modul überlasse ich euch die Konzeption - bei der Umsetzung kann ich gerne helfen - auch auf seiten der API.

Vielleicht kann @mrpj ja nochmal was zum Verhalten der REST API sagen, wenn sie asynchron angesprochen wird (also zwei requests gleichzeitig "in flight" sind), aber ich glaube, dass das schon funktioniert.

Das war irgendwie untergegangen die letzten Tage.

Generell verarbeitet der Controller (bzw. lwip aus SMING) die Verbindungen der "Reihe nach" ab.
Für den Endpunkt /color gibt es den zusätzlichen parameter "q" (queue).
Normalerweise wird bei color immer der letzte API Befehl ausgeführt (und alle befindlichen Befehle in der Queue entfernt). Wenn wir dem controller einen /color Befehl mit dem Parameter q=1 schicken, werden die Befehle in eine interne Queue gesteckt und nacheinander abgearbeitet. Die Queue size ist im Moment auf 50 Einträge gesetzt - sollte das zu wenig sein kann ich in einer späteren Firmware das auch erhöhen.

Ich hoffe damit konnte ich eine Antwort bieten - Anregungen/Änderungswünsche immer gerne hier schreiben 

[Per]

Ebenfalls emotionslos. Wenn sich da was über die verschiedenen module harmonisieren lässt finde ich das super. Können uns gern auf Kleinschreibung einigen.

Ich weiss, dass es nicht konsequent durchgezogen ist, aber INTERNALS groß und readings klein schreiben ist zumindest sehr weit verbreitet (und m.E. sinnvoll).

[pjakobs]

Ich hab das bisherige Module repository mal umgezogen auf:

https://github.com/patrickjahns/esp_rgbww_fhemmodule

Man kann davon forken etc. - alte commits sind in der history enthalten

danke Patrick, ich denke, da die aktuelle Version zu funktionieren scheint wäre es vielleicht eine gute Idee, noch einen devel branch aufzumachen?

Bei dem FHEM Modul überlasse ich euch die Konzeption - bei der Umsetzung kann ich gerne helfen - auch auf seiten der API.

Ich denke, wir haben zwei etwas divergente Ziele:

1. nahtlose Integration in die vorhandenen fhem Umgebungen, dazu ist es sinnvoll, die Fähigkeiten des Controllers so zu mappen, dass er sich mit den gegebenen Widgets / Frontends problemlos bedienen lässt. Im vorliegenden Fall z.B. indem ich HSV als primären Farbstandard anwende und den Controller alles weitere im Hintergrund machen lasse. Ein set rgb 0354a3 mappt erst RGB->HSV, schickt den Wert dann an den Controller, der wiederum das Mapping auf RGBWW(CW) 10 bit macht, ggf. gleich mit den entsprechenden Transitionen.

2. maximale Unterstützung der Fähigkeiten des Controllers - dazu würde z.B. ein set RGBWW10 (bzw. set RAW) gehören, dem man 10-Bit Werte für die fünf Komponenten mitgeben kann. Das können am Einfachsten als erweiterte Funktionalität integrieren und gleichzeitig die Basis aus 1. beibehalten.

Das war irgendwie untergegangen die letzten Tage.

Generell verarbeitet der Controller (bzw. lwip aus SMING) die Verbindungen der "Reihe nach" ab.
Für den Endpunkt /color gibt es den zusätzlichen parameter "q" (queue).
Normalerweise wird bei color immer der letzte API Befehl ausgeführt (und alle befindlichen Befehle in der Queue entfernt). Wenn wir dem controller einen /color Befehl mit dem Parameter q=1 schicken, werden die Befehle in eine interne Queue gesteckt und nacheinander abgearbeitet. Die Queue size ist im Moment auf 50 Einträge gesetzt - sollte das zu wenig sein kann ich in einer späteren Firmware das auch erhöhen.

Ich hoffe damit konnte ich eine Antwort bieten - Anregungen/Änderungswünsche immer gerne hier schreiben 

Ich denke, die Kernfrage ist: was passiert bei folgendem Ablauf:

{request1 set hsv 60,100,100}
{request2 set hsv 120,50,50}
{response1 success}
{response2 ?}

Sprich: der zweite Request kommt, bevor die Rückmeldung vom ersten kam - die Requests können ja entweder sehr schnell von einer Node kommen (z.B. als Abfolge von zu queuenden Settings) oder von zwei unterschiedlichen.
Wenn das Framework dafür sorgt, dass sie in der "richtigen" Reihenfolge einsortiert werden - perfekt.

Was ich verstehe ist: ein Request, der nicht explizit ein 'q' mitliefert löscht eine schon existierende Queue und wird sofort umgesetzt. Find ich ok.

pj

[mrpj]

danke Patrick, ich denke, da die aktuelle Version zu funktionieren scheint wäre es vielleicht eine gute Idee, noch einen devel branch aufzumachen?

Done und ich hab dir collaborator Rechte gegeben - Joerg wenn du mir deinen Github Account sagst, dann leg ich die auch gleich für dich mit an

Ich denke, die Kernfrage ist: was passiert bei folgendem Ablauf:

{request1 set hsv 60,100,100}
{request2 set hsv 120,50,50}
{response1 success}
{response2 ?}

Sprich: der zweite Request kommt, bevor die Rückmeldung vom ersten kam - die Requests können ja entweder sehr schnell von einer Node kommen (z.B. als Abfolge von zu queuenden Settings) oder von zwei unterschiedlichen.
Wenn das Framework dafür sorgt, dass sie in der "richtigen" Reihenfolge einsortiert werden - perfekt.

Was ich verstehe ist: ein Request, der nicht explizit ein 'q' mitliefert löscht eine schon existierende Queue und wird sofort umgesetzt. Find ich ok.

request1 wird mit "success" beantwortet, sobald das request am controller angekommen ist und die Abarbeitung an den Framework weitergegeben wurde. (Die Abarbeitung/Transition findet asynchron from request in einem eigenen loop statt). Request 2 antwortet auch mit success sobald es an den Framework weitergegeben wurde.

Ohne den Parameter q wird das request das als letztes angekommen ist, abgearbeitet. Das Verhalten kommt hier auf den Befehl an - z.b. bei einem Fade auf Farbe X, wird von dem aktuellen Farbwert auf X gefadet. Wenn wir nun in dem Farbwechsel von r1 sind, wird dieser abgebrochen und von dem aktuellen Farbwert auf den neuen Farbwert X gefadet. Kommt nun aber der Befehl Fade von Farbe A auf Farbe B mit r2 an, wird der Farbwechsel von r1 abgebrochen und von Farbe A auf Farbe B gefadet.

Wenn der Parameter q=1 gesetzt ist, wird zuerst der Farbwechsel von r1 und danach der Farbwechsel von r2 abgearbeitet. Die Antwort der API ist bei beiden Fällen direkt success (= Der Befehl ist angekommen und valide).

[pjakobs]

Done und ich hab dir collaborator Rechte gegeben - Joerg wenn du mir deinen Github Account sagst, dann leg ich die auch gleich für dich mit an

perfekt!

request1 wird mit "success" beantwortet, sobald das request am controller angekommen ist und die Abarbeitung an den Framework weitergegeben wurde. (Die Abarbeitung/Transition findet asynchron from request in einem eigenen loop statt). Request 2 antwortet auch mit success sobald es an den Framework weitergegeben wurde.

Ohne den Parameter q wird das request das als letztes angekommen ist, abgearbeitet. Das Verhalten kommt hier auf den Befehl an - z.b. bei einem Fade auf Farbe X, wird von dem aktuellen Farbwert auf X gefadet. Wenn wir nun in dem Farbwechsel von r1 sind, wird dieser abgebrochen und von dem aktuellen Farbwert auf den neuen Farbwert X gefadet. Kommt nun aber der Befehl Fade von Farbe A auf Farbe B mit r2 an, wird der Farbwechsel von r1 abgebrochen und von Farbe A auf Farbe B gefadet.

Wenn der Parameter q=1 gesetzt ist, wird zuerst der Farbwechsel von r1 und danach der Farbwechsel von r2 abgearbeitet. Die Antwort der API ist bei beiden Fällen direkt success (= Der Befehl ist angekommen und valide).

damit denke ich, wir müssen uns nicht um externes queueing kümmern und lassen das den Controller tun.

pj

[herrmannj]

Hallo,

github: herrmannj

Queues im modul mitscheiben:

Der Gedanke bezieht sich auf die Notwendigkeit das Frontend während einer Transition zu aktualisieren.
Dazu wäre es entweder möglich ständig zu pollen oder die Lichtfarbe eben (grob) mitzurechnen.

@pj Wie würdest Du Dir das denn vorstellen ?

vg
joerg

[pjakobs]

@pj Wie würdest Du Dir das denn vorstellen ?

vg
joerg

ich denke, am einfachsten wäre es, wenn @mrpj auf dem Controller die aktuellen Settings (rgbww und/oder hsv) über MQTT published. Mitrechnen wird so gut wie unmöglich sein, denn Du könntest ja theoretisch eine 50 Befehle tiefe Queue haben, die Du abarbeiten musst. Halte ich für wenig förderlich.

Ich hab für meine Heizung ein paar Dallas 18B20 Temperatursensoren an einem ESP8266 hängen, für die habe ich
a) einen MQTT Broker angelegt

Code Auswählen Erweitern


define MyBroker MQTT 127.0.0.1:1883
attr MyBroker room System


und dann b) ein entsprechendes MQTT Device

Code Auswählen Erweitern


define Heizung MQTT_DEVICE DS18B20
attr Heizung IODev MyBroker
attr Heizung autoSubscribeReadings /hooks/devices/1/SensorData/+
attr Heizung room System
attr Heizung stateFormat transmission-state
attr Heizung subscribeReading_ruecklaufExtern /hooks/devices/1/SensorData/ruecklaufExtern
attr Heizung subscribeReading_ruecklaufIntern /hooks/devices/1/SensorData/ruecklaufIntern
attr Heizung subscribeReading_uptime /hooks/devices/1/SensorData/uptime
attr Heizung subscribeReading_vorlaufExtern /hooks/devices/1/SensorData/vorlaufExtern
attr Heizung subscribeReading_vorlaufIntern /hooks/devices/1/SensorData/vorlaufIntern
attr Heizung subscribeReading_wifiRSSI /hooks/devices/1/SensorData/wifiRSSI


das Device "Heizung" hat nun die Readings wie oben definiert.
Nun würden wir ja nicht ein externes MQTT Device für den LedController anlegen wollen, sondern könnten vermutlich den Code aus 10_MQTT_DEVICE verwenden, um die eigenen Readings zu füttern.

Jedes Update auf das betreffende Topic würde dann, vom LedController getriggert, das Reading updaten.

@mrpj wie aufwendig wäre es für Dich, uns die aktuellen Werte von h,s,v,r,g,b,cw,ww per MQTT zur Verfügung zu stellen?

pj

[herrmannj]

ok, mqtt ist wäre eine alternative Implementierung.

Stand heute ist das fhem modul ja auf der json api, und die sendet nix zurück, also zumindest keine device-events auser "ok" oder "falsch"

Angenommen wir gehen hier von einer mqtt unabhängigen Lösung aus bleint die Fragestellung bestehen. Das "mitrechnen" würde die device-events ersetzen sollen.. Du schreibst

"Mitrechnen wird so gut wie unmöglich sein, denn Du könntest ja theoretisch eine 50 Befehle tiefe Queue haben, die Du abarbeiten musst. Halte ich für wenig förderlich."

. Wo siehst Du Herausforderung ? Evtl übersehe ich da was.

vg
joerg