ESP RGBWW Wifi Led Controller - Firmware vbs

[ext23]

Du müsstest die HTTP-Kommunikation auf beiden Seiten von TCP auf Seriell umbiegen. Könnte mir vorstellen, dass das möglich ist.

Und wie schaut es mit einem LAN Chip aus? Beim ESP8266 könnte man ja mit einem "ENC28J60" ein LAN hinzufügen.

Würde deine Firmware auch auf dem ESP32 laufen? Dieser hat nämlich LAN schon mit drin bis auf den physical layer (http://s.click.aliexpress.com/e/JyrF2zB). Könnte man das über diesen Weg eventuell realisieren?

https://hackaday.com/2017/04/18/enabling-ethernet-on-the-esp32/

/Daniel

[vbs]

@Pythonf
Finde ich eine sehr interessante Sache. Irgendjemand hatte sowas vor einiger Zeit auch schonmal gepostet (warst evtl. auch du).
Ich glaube zu verstehen, wie deine Variante die Farbtemperatur für ein reines Weiß setzt. Aber wie würdest du dir die Integration in die bestehende Firmware vorstellen? Normalerweise arbeitet die FW im HSV-Modus eben um auch Farben dar zu stellen.

@ext23
Soweit ich weiß, läuft Sming momentan nicht auf Esp32:
https://github.com/SmingHub/Sming/issues/1333

Zu der LAN-Integration kann ich ansonsten nciht viel sagen, sorry...

[ext23]

Soweit ich weiß, läuft Sming momentan nicht auf Esp32:
https://github.com/SmingHub/Sming/issues/1333

Mhh hat das Sming auch irgend welche Vorteile
Aber gut, es scheint ja auch schon der Gedanke da zu sein es auf ein Arduino zu portieren. Das ist ja schon mal was.

/Daniel

[Pythonf]

Ich schätze, das war auch ich. Ich finde das Thema Farbtemperatur irgendwie sehr spannend.

Für die Farbübergänge von bsp. Rot nach Weiß würde ich alles belassen wie es ist.
Sollte dann die Farbtemperatur, welche nur bei der ausschließlichen Darstellung von weißem Licht interessant sein dürfte, per "set <name> ct ...." geändert werden, dann könnte man vielleicht intern den Modus von RGBWW auf RGB ändern, die  berechneten Werte für RGB in hsv umrechnen und den Wert für die WW-LED parallel nur an den WW Kanal senden.

Diese Umstellung wäre ja auch nur interessant wenn RGBWW oder RGBCW ausgewählt sind, denn hier hat der "set <name> ct ...." bislang ja keinen Effekt. Bei RGB wäre die Änderung der Farbtemperatur in der Theorie zwar auch möglich, erscheint mir aber wenig sinnvoll und bei RGBWWCW würde ich ebenfalls alles belassen wie es ist.

Man müsste im Reading nicht mal festlegen, ob es sich um WW, NW oder CW handelt.
Ich stell mir das in etwa so vor:

Code Auswählen Erweitern


attr dev cal_r comma seperated list of measured values for the red led in cooperation with measured values for blue, green and white LEDs (attributes cal_b, cal_g, cal_w).
attr <name> cal_r <1st color_temp_in_Kelvin><1st Value for raw_red or value for red>,<1nd color_temp_in_Kelvin><1nd Value for raw_red or value for red>, ... ,<n color_temp_in_Kelvin><n Value for raw_red or value for red>
attr dev cal_r 2000:1023,3000:768,4000:512,5000:256


Lg
Fabian

[vbs]

Für die Farbübergänge von bsp. Rot nach Weiß würde ich alles belassen wie es ist.
Sollte dann die Farbtemperatur, welche nur bei der ausschließlichen Darstellung von weißem Licht interessant sein dürfte, per "set <name> ct ...." geändert werden, dann könnte man vielleicht intern den Modus von RGBWW auf RGB ändern, die  berechneten Werte für RGB in hsv umrechnen und den Wert für die WW-LED parallel nur an den WW Kanal senden.

Die Farbtemperatur spielt mMn nicht nur bei komplett "weißem" Licht eine Rolle, sondern immer dann wenn Sättigung <100% ist. Das sind ja fließende Übergänge. Z.B. ich hab reines Weiß und gebe dann 5 % rot dazu. Was würde dann passieren im Rahmen des aktuellen HSV-Modells?

Wie erstellt man eigentlich diese Kalibrationstabelle? Ich muss ja z.B. meine RGBWW-Werte ermitteln, die dann z.B. 2675 Kelvin ergeben, richtig? Und das mache ich für mehrere Stützstellen und lege eine Kurve da durch. Aber wie ermittle ich 2765 Kelvin?

[Pythonf]

Wie erstellt man eigentlich diese Kalibrationstabelle? Ich muss ja z.B. meine RGBWW-Werte ermitteln, die dann z.B. 2675 Kelvin ergeben, richtig? Und das mache ich für mehrere Stützstellen und lege eine Kurve da durch. Aber wie ermittle ich 2765 Kelvin?

Ich habe in meinem Fall eine Philips HUE als Referenz genommen und dort verschiedene Farbtemperaturen angegeben und die LEDs dem jeweiligen Weißton angepasst. Wenn das nicht geht, dann könnte man aber auch einfach einen Wert bei beispielsweise 2000K für warmes Licht, 4000K für neutral und 7000K für kaltes Licht nach persönlichem Wohlbefinden, annehmen. Die Berechnung von beispielsweise 3000K erfolgt dann durch einsetzten in die die vier generierten Funktionen vom Typ 'a + b * x + c * x^2' mit x = ct für jeden Kanal, welche mir dann die RGB + W Werte liefert.

Das die Farbtemperaturwerte mehr eine Schätzung sind, stört m. M. nach nur wenig. Ich seh weder bei den HUE noch bei den LEDs einen wirklich sichtbaren Unterschied zwischen 3100 K und 2900 K. Und wenn ich ein ramping durch die Farbtemperatur bei den HUE bzw. bei den LEDs mache, lässt sich für mich an keiner Stelle (2000 < ct < 6500) ein Unterschied ausmachen

Die Farbtemperatur spielt mMn nicht nur bei komplett "weißem" Licht eine Rolle, sondern immer dann wenn Sättigung <100% ist. Das sind ja fließende Übergänge. Z.B. ich hab reines Weiß und gebe dann 5 % rot dazu. Was würde dann passieren im Rahmen des aktuellen HSV-Modells?

Im Moment fällt mir dazu keine Lösung ein. Ich hätte angenommen, dass komplett weißes Licht ausschließlich die WW LEDs sind.
Wie sieht denn hier die Berechnung im RGBWWCW Modus aus? Was wird als komplett weißes Licht festgelegt? Weil hier kann ich ja auch Unterscheiden zwischenem "reinem" CW oder WW ?

[vbs]

Im Moment fällt mir dazu keine Lösung ein. Ich hätte angenommen, dass komplett weißes Licht ausschließlich die WW LEDs sind.

Da ist richtig: bei komplett weißem Licht (Sättigung = 0%) leuchten nur die WW-LEDs im (RGBWW-Modus). Aber eben sobald man die Sättigung erhöht, spielen auch die RGBs mit.

Wie sieht denn hier die Berechnung im RGBWWCW Modus aus? Was wird als komplett weißes Licht festgelegt? Weil hier kann ich ja auch Unterscheiden zwischenem "reinem" CW oder WW ?

Ich hab da noch nie reingeschaut, aber ich denke, dass da je nach Farbtemperatur die Intensität zwischen WW und CW aufgeteilt wird. Sprich wenn du 2700k einstellst bist du bei 100% WW und 0% CW und bei 4500k bei 50% CW und 50% WW (oder ähnlich).

[Pythonf]

Ich hab mir das ganze mal bei Philips Hue angeschaut:
Wenn ich dort rgb 00FF00 und dann ct 6500 setzte, dann ändert er logischerweise die Farbe zu kaltem weiß. Wenn ich dann die Sättigung reduziere ändert sich aber die Farbe nicht wieder zurück zum rgb Wert, was ich so nicht wirklich schön finde.
Ich würde also, auch wenn es eventuell nicht viel besser erscheint, zwischen ct ausschließlich für Farbtemperatur und hsv für alles andere unterscheiden.
Es wäre auch merkwürdig, wenn ich die ganze Zeit ein schönes Grün gewöhnt bin, dann ändere ich einmal die Farbtemperatur und wenn ich das nächste mal Grün einstelle sieht es ganz anders aus.
Der harte Übergang, der leider nicht ausbleibt wäre dann, wenn ich per ct 2000 K einstelle und dann sage sat 0. Dann würde der Wert vom berechneten Wert für die Farbtemperatur auf RGB = 000000, WW = 255 springen.

[vbs]

Wenn ich dort rgb 00FF00 und dann ct 6500 setzte, dann ändert er logischerweise die Farbe zu kaltem weiß. Wenn ich dann die Sättigung reduziere ändert sich aber die Farbe nicht wieder zurück zum rgb Wert, was ich so nicht wirklich schön finde.

Hm, ist für mich erstmal nicht unbedingt logisch: die Farbtemperatur ist mMn unabhängig vom Rest bzw. von der Sättigung. Darum finde ich es nicht logisch, dass er beim Setzten von ct zu weiss springt. Und ich verstehe nicht warum die Sättigung dann offenbar >0 ist und du sie dann noch reduzieren kannst.

Ich verstehe dich so, dass für dich das Setzen einer Farbtemperatur auch immer implizit das Leuchtmittel auf ein reines Weiß setzt? Ist offenbar bei der Hue so. Wenn das so ist, dann passt das nicht so gut zu der Logik int der FW bzw. so wie zumindest ich das Konzept einer Farbtemperatur verstehe.

[Pythonf]

Ich verstehe dich so, dass für dich das Setzen einer Farbtemperatur auch immer implizit das Leuchtmittel auf ein reines Weiß setzt?

Die Farbtemperatur resultiert ja aus der Schwarzkörperstrahlung. Daher impliziert das setzten der Farbtemperatur die Ausgabe von weißem Licht.
https://commons.wikimedia.org/wiki/File:BlackbodySpectrum_loglog_de.svg Hier wird schön gezeigt, welcher Bereich des sichtbaren Lichtes bei welcher Temperatur emittiert. Die Farbtemperatur der weißen LEDs wiederum sind aber festgelegt auf einen spezifischen Wert. Ein Mischen von einer gesetzten Farbtemperatur für die weißen LEDs mit farbigem Licht würde darin resultieren, dass die Farbtemperatur einer rein weißen Lichtquelle durch beimischen variiert wird und anschließend diese Farbtemperatur/ weißes Licht mit rgb gemischt würde.

Die Logik des Controllers ist mir an dieser Stelle zwar nicht bekannt, aber es scheint mir deutlich zu kompliziert, die Änderung der Farbtemperatur der verbauten weißen LEDs über set ct zum Mischen per hsv zu implementieren 

[vbs]

Schade eigentlich... wäre schon eine super Feature, aber lässt sich mMn nicht sauber integrieren, solange wir nicht raus finden, wie man das mit dem HSV-Model kombinieren kann Der einzige Weg wäre einen dritten Modus einzuführen, der völlig unabhängig läuft und dann eben nur reines Weiß unterstützt... gefällt mir aber nicht so richtig 

Falls jemand Lust hat, dort einzusteigen: die momentane Implementierung ist hier zu finden:
https://github.com/verybadsoldier/RGBWWLed/blob/master/RGBWWLedColor.cpp

[tunguskar]

Ein kurze Frage zu dem Dimmer von Tablet UI

Ich wollte diesen nutzen um das ESP Modul zu dimmen. Schaut dann so aus:
<div data-type="dimmer"     
     data-device="licht.kueche.unterschrank"
     data-dim="hsv 0,0,"></div>

Es wird dann folgendes gesendet wenn ich z.B. auf 10 Prozent Dimme:
set licht.kueche.unterschrank hsv 0,0, 10

Problem ist bei der 10 am Schluss, dass ein Leerzeichen eingefügt wird und ich glaube dann funktioniert das Ganze nicht. Weiss jemand wie ich das umgehen kann?

[vbs]

Ist vermutlich eher eine Tablet-UI-Frage. Kann ich nicht viel zu sagen, aber ich hab gestutzt über

Code Auswählen Erweitern

data-dim="hsv 0,0,"

Die Tablet-UI Doku sagt dazu (https://wiki.fhem.de/wiki/FTUI_Widget_Dimmer):

data-dim   Name des Readings, das für den DIM-Wert zuständig ist

Ich würde es dementsprechend mal versuchen mit:

Code Auswählen Erweitern

data-dim="val"

[tunguskar]

Irgendwie mach ich da was falsch.

Was ich bräuchte:

Aktueller Status:
Mit dem Befehl 192.168.1.xx/color?mode im Browser bekomme ich z.B. das:
{"hsv":{"h":0.00,"s":0.00,"v":49.95,"ct":0}}

Das ist aber nicht in den Userreadings vorhanden. Wie bekomme ich das in das reguläre device in FHEM? Bzw. in den state um stateFormat anwenden zu können. Der STATE in den INTERNALS liefert auch nur 1.

Weiterhin mache ich wohl bei dem DIM Befehl etwas falsch. Wenn ich diesen über die Maske in FHEM auswähle und zw. 100 eingebe passiert nichts. Wenn ich das Ganze. Z.B. mit dem Befehl hsv 0,0,100 teste geht die Lampe auf 100%

Weiss hier jemand weiter?

[vbs]

Du musst mich mal irgendwo abholen, ich kann nicht so recht folgen, fürchte ich.

Aktueller Status:
Mit dem Befehl 192.168.1.xx/color?mode im Browser bekomme ich z.B. das:
{"hsv":{"h":0.00,"s":0.00,"v":49.95,"ct":0}}

Das ist aber nicht in den Userreadings vorhanden. Wie bekomme ich das in das reguläre device in FHEM?

Also es gibt u.a. die Readings "hsv" und "ct". Userreadings musst du immer selbst erzeugen.

Bzw. in den state um stateFormat anwenden zu können. Der STATE in den INTERNALS liefert auch nur 1.

Hm, was meinst du? Hast du evtl. selbst schon stateFormat gesetzt und damit selbst die 1 erzeugt? state sollte normalerweise "opened" sein.

Weiterhin mache ich wohl bei dem DIM Befehl etwas falsch. Wenn ich diesen über die Maske in FHEM auswähle und zw. 100 eingebe passiert nichts. Wenn ich das Ganze. Z.B. mit dem Befehl hsv 0,0,100 teste geht die Lampe auf 100%

Hm, Dim sollte funktionieren. Hast du aktuelles Modul? aktuelle Firmware? Ist was im Log zu sehen? Poste mal list und Log bitte.