ESP RGBWW Wifi Led Controller - Hinweise zu Sammelbestellung 2.5

[KaiK]

Hab mal mein zweites RGBWW Device an der Stelle installiert.
Das weist das Verhalten offenbar nicht auf.

Hardwareabhänigkeit? Brown-out/Kalte Löstellen?

VG
Kai

[Shuzz]

@Torben: Hast Du die Hardware selbst gebaut oder ist die aus der ersten Sammelbestellung?
Im Zweifel mal den Pullup an GPIO16 checken (Spannung messen) ob der Pin auch ordentlich hochgezogen wird. An GPIO16 sollten 3.3V zu messen sein. Evtl. registriert der Controller ein "Low" auf dem Pin und wirft seine Config weg --> Config-AP geht auf.

[funclass]

Hey Leute, nachdem ich einen meiner Controller nun lange im Einsatz habe und sehr zufrieden bin, würde ich gern die Usability etwas erweitern. Leider scheitere ich bei meinen Überlegungen.

Ich würde gern per Taster (z.B. EnOcean) hoch- oder runterdimmen. Jedoch nur solange der Taster gedrückt ist.
Also:
longpress -> dimup
release -> stop

Da die Kommandos immer einen definierten Value benötigen, weiß ich nicht wie ich das Stop-Kommando umsetzen soll. D.h. ich könnte bei langem Tastendruck mit einer Rampe von z.B. 10 sek. hochdimmen, aber wie bekomme ich den Vorgang "angehalten"?

[pjakobs]

hi @funclass,

welche Events liefert denn der EnOcean Taster? Das aktuelle Modul für den led controller kennt "dimup" und "dimdown", die jeweils nur die Schrittweite für die Helligkeit (val) als Parameter bekommen. Ein "set <device>dimup [val] [t]" kannst Du mehrfach hintereinander aufrufen (vielleicht nicht allzu schnell, damit sich der Controller nicht verhaspelt, ggf. auch als "set <device dimup [val] [t] q>" . [t] ist dabei die Zeit in Sekunden. Wenn Dein Taster in der Lage ist, während Du den Finger drauf hast mehrere Notifys auszulösen, dann kannst Du es darüber lösen, alternativ .. hmmmm.. Ein doif mit timer oder so... ist ein bisschen kompliziert fürchte ich.
Aber: das Modul kommt Dir da entgegen, wenn auch ein "stop" bei einer bestimmten Helligkeit nicht möglich ist (wenn mehrere "dimup" in der Queue sind, dann laufen die halt nach).

Grüße

pj

[funclass]

Das habe ich vermutet. Der erwähnte Taster war nur ein Beispiel. Dieser hat nur ein Reading, dies ist solange 1 wie der Taster betätigt ist und ansonsten 0. Damit wird also nur bei Zustandsänderung ein Event erzeugt. Cool wäre die Erweiterung der Firmware um ein Stop-Kommando. Dabei müsste der aktuell ausgeführte Befehl abgebrochen, die Cue gelöscht und die aktuellen Werte an FHEM gesendet werden.
Damit könnte auch ein Rotate unterbrochen werden. Für die Bedienung via Taster wäre das ideal.

[pjakobs]

genau das ist der Punkt: da bräuchte es Unterstützung in der Firmware, denn das fhem Modul weiß nicht, welchen Farbwert der Controller zu einem arbiträren Zeitpunkt hat...

pj

[Per]

Ein doif mit timer oder so...

Eher ein DOIF mit repeatcmd, wird automatisch beendet, wenn ein neuer Zustand ("release") erkannt wird. Ein bisschen experimentieren mit den Abständen und den Dimmparametern und fertig.

[funclass]

Danke für die Hinweise. Werd ich mal versuchen, ist mir aber eigentlich zu viel "Notlösung". Ich habe gehofft, dass es vielleicht eine (noch undokumentierte) Stelle in der API des Controllers dafür gibt. Vielleicht lässt sich @mrpj erweichen und sieht eine entsprechende Funktion in einer kommenden FW-Version vor. Weil Weihnachten ist 

[vbs]

Ich habe sowas ähnliches vor: Ich möchte, dass der Controller bei einem Event (Betätigung eines Buttons) anfängt, den Farbton durchzurotieren. Das soll erst aufhören, wenn man den den Button nochmal betätigt. Gibt es einen schönen Weg, dass der Controller permanent die Farbe ändert?

Mein bester Weg bisher:

Code Auswählen Erweitern


set led 1,92,100 10 l

Wobei der Hue-Wert ("1") der aktuelle Wert + 1 ist. Dann mit "l" die lange Richtung anfordern. Dann läuft der Controller zumindest einmalig (fast) das komplette Farbspektrum einmal ab. Kann man das schön in einer Schleife machen?

[funclass]

@VBS: das würde m.E. am besten klappen wenn innerhalb der 10sek. erneut der "gleiche Befehl in die Que geschrieben wird. Problematisch ist hier auch wieder das "Anhalten" der Rotation. Aktuell kann dies nur durch einen Befehl realisiert werden, welcher die Que überschreibt. Die aktuelle Farbe "festzuhalten" wird Glückssache sein.

[pjakobs]

mein Vorschlag:
ein DOIF mit repeatcmd (idealerweise im Sekundentakt) und jedesmal ein dimup/dimdown/rotate um 1 mit einer Dauer von 1. Dann sollte eigentlich auch ein Stop an der richtigen Stelle passieren. Beim Rotate würde ich wohl eher weiter rotieren, denn 360° dauern sonst sechs Minuten - vielleicht ein Rotate von 12? 30s für einen ganzen Farbkreis?

pj

[vbs]

ein DOIF mit repeatcmd (idealerweise im Sekundentakt) und jedesmal ein dimup/dimdown/rotate um 1 mit einer Dauer von 1. Dann sollte eigentlich auch ein Stop an der richtigen Stelle passieren.

Hm, ich hätte hier etwas Bedenken, ob man da die Übergägnge zwischen den einzelnen 1-Sekunden-Abschnitt nahtlos (bzw. unsichtbar) hinbekommt. Der gesamte Farbkreis sollte in nicht viel länger als 10 Sekunden durchlaufen, denk ich.

Ich überlege im Moment Folgendes (im Prinzip das was auch funclass gesagt hat):
Das "Cyclen" starten mit (läuft dann leider nicht "ewig", sondern dann eben nur vier Durchläufe):

Code Auswählen Erweitern


set wz_lightLedTv hsv 114,70,100 10 lq
set wz_lightLedTv hsv 115,70,100 10 lq
set wz_lightLedTv hsv 116,70,100 10 lq
set wz_lightLedTv hsv 117,70,100 10 lq

Die tatsächlichen Werte basieren natürlich auf den aktuellen Werten. Dann würde erstmal das Cyclen komplett im Controller stattfinden (was ich erstmal elegant finde). Jetzt fehlt halt das Anhalten.

Ich hab das ganze schonmal mit Wifilight gemacht. Da ist es einfacher, da ja der Farbverlauf innerhalb des FHEM-Moduls passiert und daher das Modul immer die aktuellen Werte kennt. Also zum Anhalten habe ich da einfach die momentanen Werte nochmal mit set gesetzt, was dann zu einem Anhalten führt.

Nun könnte man das hier theoretisch nachbilden. Es gibt ja den Befehl "update", der eigentlich ja die aktuellen Werte vom Controller holt. Man könnte also die Werte z.B. sekündliche holen und dann ebenfalls zum Stoppen den aktuellen Wert nochmals (ohne Ramp) setzen. Das Problem ist, dass bei mir das "update" in FHEM nicht funktioniert. Also wenn ich während der Controller cycelt, ein "update" mache, dann ändern sich in FHEM die HSV-Readings nicht. Im Browser jedoch kann ich immer die aktuellen Werte abrufen, wenn ich zB mache "http://192.168.2.39/color?mode=hsv".

Mal weiter gucken...

[vbs]

Hab mal versucht, das update-Kommando zu fixen: https://github.com/patrickjahns/esp_rgbww_fhemmodule/pull/15
Wenn das übernommen werden könnte, wäre es klasse.

Ich hätte noch eine andere Idee:
Über ein Attribut könnte man einschalten, dass das Modul zyklisch selbst ein "update" anstößt und damit den aktuellen Zustand des Controller pollt (zb. sekündlich oder halb-sekündlich). Dieses Attribut könnte man dann setzen, wenn man eine längere Ramp angestoßen hat.

Wenn da Interesse bestünde, würde ich mal versuchen, das einzubauen.

[vbs]

Hm, hab es jetzt doch nochmal anders gemacht. Im Prinzip eine Mischung aus allen Ideen, die wir auch angesprochen haben. Ich poste mal meinen Stand. Nicht weil er so toll ist, aber vielleicht hat ja jemand noch Verbesserungsvorschläge oder es hilft doch jemand anderem auch. Es wird immer ein voller Durchlauf angestoßen und das Ganze dann mit einem sleep nach der ramp-Zeit wiederholt. Läuft also im Prinzip ewig bis man abbricht. Während er cycelt, holt dann ein DOIF alle 200 ms den aktuellen Stand, der dann gehalten wird, wenn man das Cyceln stoppt.

Also zum Cyclen:

Code Auswählen Erweitern


sub getLedControllerHsv($)
{
    my ($device) = @_;
    my $h = ReadingsVal($device, "hue", 0);
    my $s = ReadingsVal($device, "sat", 0);
    my $v = ReadingsVal($device, "val", 0);
    return ($h, $s, $v);
}

sub ledControllerQueueCycle($$$)
{
    my ($device, $cycleHue, $cycleSat) = @_;
    my ($h, $s, $v) = getLedControllerHsv($device);
   
    if ($cycleHue)
    {
        my $maxHue = 359;
        $h = $h + 1;
        $h = 0 if ($h > $maxHue);
    }

    if ($cycleSat)
    {
        $s = $s > 50 ? 0 : 100;
    }

    my $ramp = 10;
    my $cmd = "set $device hsv $h,$s,$v $ramp lq; sleep $ramp cycle_$device;{ ledControllerQueueCycle(\"$device\", $cycleHue, $cycleSat);; }";
    Log 3, "ledControllerQueueCycle - cmd: $cmd";
    fhem($cmd, 1);
}


Beim Starten setze ich dann noch ein Reading "cycling":

Code Auswählen Erweitern


fhem("setreading $devName cycling 1");


Und dann zum Stoppen:

Code Auswählen Erweitern


sub stopCycleLedController($)
{
    my ($device) = @_;
    Log 3, "stopCycleLedController";

    my ($h, $s, $v) = getLedControllerHsv($device);
    fhem("cancel cycle_$device");
    fhem("setreading $device cycling 0");
    fhem("set $device hsv $h,$s,$v");
}


Dann noch ein DOIF, der alle 200 ms den aktuellen Stand holt, wenn "cycling" auf 1 steht:

Code Auswählen Erweitern


define diLedUpdate DOIF ([sz_lightLedWall:cycling] eq 1) (set $DEVICE update)
attr diLedUpdate repeatcmd  0.2


Ist mir eigentlich alles zu komplex und zu viel Code Wäre wirklich super, wenn man den Controller per API zum Halten der aktuellen Farbe bewegen könnte. Ich hab mal in die Quellcode der Firmware geguckt, aber es hat sich mir leider nicht spontan erschlossen.

[pjakobs]

Moin zusammen,

wenn ich das richtig sehe, liest Du aber nur die aktuellen h,s,v Werte des Moduls aus, oder? Die stehen, nachdem die Kette der Controller Befehle abgearbeitet wurde, auf dem Zielwert des letzten Befehls in der Queue.  Weiter oben hast Du geschrieben, dass das update command nicht funktioniert, das wäre dann ein bug, und ich fürchte, den Code hat nie jemand wirklich getestet, das schau ich mir mal an.

Was ich eigentlich schon lange haben will, da bin ich mir mit Patrick aber nicht einig geworden ist, dass der Controller seinen aktuellen hsv Wert per mqtt publiziert und wir den zum hsv Reading machen. Das hätte für viele Szenarien erhebliche Vorteile, so auch hier. Es wäre z.B. auch möglich "slave" Controller zu konfigurieren (einfach über ein notify, zwar nicht ms synchron aber sicher gut genug).

Vielleicht nimmt sich ja mal jemand dessen in der Firmware an, ich fänd das den elegantesten Weg.

pj