ESP RGBWW Wifi Led Controller - Support Thread

[pula]

weil da andere komponenten auch noch dranhängen, die einen fhem-neustart leider nicht so gut vertragen (oder genauer gesagt einen neustart des ganzen servers, wo auch noch andere sachen wie zb dhcp/dns laufen).

aber die eigentliche frage, was meinst du mit:

vor allem merkt man das bei niedriger Helligkeit, da werden die Übergänge zwischen den Helligkeitsstufen deutlich sichtbar.

betrifft das "nur" fades oder auch die beleuchtung, wenn sie "fix" ist (also leds ein und fertig)?

[pjakobs]

weil da andere komponenten auch noch dranhängen, die einen fhem-neustart leider nicht so gut vertragen (oder genauer gesagt einen neustart des ganzen servers, wo auch noch andere sachen wie zb dhcp/dns laufen).

ich will nicht Dein Netz debuggen, aber: vernünftige Komponenten kommen damit klar, dass Services hie und da mal nicht verfügbar sind und konfigurieren sich danach wieder korrekt. Ein "alles stromlos machen und wieder anschalten" sollte nie nötig sein und ist auch wirklich keine schöne Lösung, wie in Deinem Fall, weil halt Komponenten in unterschiedlicher Zeit wieder verfügbar sind und je nach Reihenfolge manche gleich wieder in das Problem fallen.

aber die eigentliche frage, was meinst du mit:

vor allem merkt man das bei niedriger Helligkeit, da werden die Übergänge zwischen den Helligkeitsstufen deutlich sichtbar.

betrifft das "nur" fades oder auch die beleuchtung, wenn sie "fix" ist (also leds ein und fertig)?

Der wesentliche Punkt ist, dass wir die Helligkeit nicht linear wahrnehmen. Der Unterschied zwischen pwm=1/256 und pwm=2/256 ist ein deutlich wahrnehmbarer Schritt. Ich sage nicht, dass es unbrauchbar ist, aber es ist halt um den Faktor 4 weniger gut als die 10 Bit pwm hier. Aber: natürlich ist das Licht immer gleich hell, egal ob es jetzt auf 1/256 oder 4/1024 eingestellt ist. Du kannst mit 10 Bit halt in 0,1% Schritten regeln (0%=pwm 0, 100%=pwm 1025) mit 8 Bit nur in 0,4% (0%=pwm 0, 100%=pwm 255). Aber das fällt tatsächlich primär bei Fades auf.

Wenn ich endlich die Version 5.0 der Firmware fertig habe wird das für Controller mit ESP32 (die dann auch kommen) nochmal besser, denn da kann ich PWM Frequenzen von 4kHz machen.

Aber: wenn schon eine andere Firmware, dann würde ich vermutlich Tasmota statt ESPeasy nehmen. Das ist aber vermutlich Geschmackssache.

pj

[pula]

jaja. ich weiß. da sind ein paar selbstgestrickte sachen dabei, die noch auf arduinos laufen, die sind nicht ganz sauber...
wieso espeasy? ich denke an esphome?

esp32 klingt allerdings sehr verlockend. gibts dann auch wieder platinen?
ich will fhem ja nicht schlechtreden oder ganz verlassen, aber home assistant hat ein paar vorteile....
allerdings auch nachteile...
cheers,
Pula

[pjakobs]

jaja. ich weiß. da sind ein paar selbstgestrickte sachen dabei, die noch auf arduinos laufen, die sind nicht ganz sauber...
wieso espeasy? ich denke an esphome?

ah, sorry, das hab ich dann durcheinaner gebracht

esp32 klingt allerdings sehr verlockend. gibts dann auch wieder platinen?

reizvoll wäre das schon, die, an denen ich momentan arbeite sind etwa so groß wie ein Kaugummistreifen.
Allerdings ist der Aufwand halt immer schon immens für ein Hobby Projekt.

ich will fhem ja nicht schlechtreden oder ganz verlassen, aber home assistant hat ein paar vorteile....
allerdings auch nachteile...

na ja, die Grenzen von fhem kennen wir mittlerweile wohl alle.
und Home Assistant ist schon ziemlich attraktiv.

Mir ging es ja nur darum "meine" Firmware zu verteidigen

Ich bin einfach der Meinung, es gibt für RGB(W(W)) LEDs nix besseres, und mqtt sollte auch mit HASS funktionieren (btw, die Abkürzung war immer eines der Dinge, die ich an Home Assistant nicht mochte, aber woher sollen die Englischsprachigen das wissen)

cheers,
Pula

pj

[pula]

Mir ging es ja nur darum "meine" Firmware zu verteidigen

Ich bin einfach der Meinung, es gibt für RGB(W(W)) LEDs nix besseres, und mqtt sollte auch mit HASS funktionieren (btw, die Abkürzung war immer eines der Dinge, die ich an Home Assistant nicht mochte, aber woher sollen die Englischsprachigen das wissen)

die firmware ist der hammer an dieser stelle noch mal danke dafür. hab eh 8 stück oder so im einsatz. halt nur fertig gekaufte, weil ich als grobmotoriker mit der feineren löterei die meisten bauteile vermutlich geschrottet hätte.
und HA kann auch mqtt (habe ich auch für etliches, auch selbst geschriebene sachen im einsatz), aber im gegensatz zu esphome muss man die mqtt-devices halt manuell konfigurieren, ausser das autodiscovery ist auf dem device implementiert (wobei ich mir nicht sicher bin, ob das HA-spezifisch ist oder allgemein gültig?)

andererseits läuft deine firmware seit jahren EXTREM stabil.

ich denke, ich werde mal testweise auf einem controller mqtt aktivieren und schauen, wie weit ich komme.

falls ich das so halbwegs hinbekomme, werde ich die config hier reinstellen (kann aber dauern, weil ich zur zeit mit projekten gut ausgelastet bin)....

Cheers,
Pula

[pula]

Aber jetzt doch noch eine (hoffentlich nicht ganz) dämliche Frage:
Farbe setzen per MQTT klappt so weit schon mal, zb mit

Code Auswählen Erweitern

{
    "jsonrpc": "2.0",
    "method": "color",
    "params": {
        "t": 700,
        "d": "1",
        "cmd": "fade",
        "hsv": {
            "s": 55,
            "h": 0,
            "v": 100
        },
        "q": "single"
    }
}ins command-topic.
Aber auch nach Studium der API-Beschreibung ist mir nicht klar, wie ein einfaches on/off zu machen ist?
Toggle gibts ja, aber wie ist das mit on und off gedacht?
Grundsätzlich schaltet sich der Controller zwar ab (gibt dann auch stateLight off), wenn man v auf 0 setzt, aber ist das wirklich im Sinne des Erfinders?

Cheers,
Pula

[pjakobs]

Du musst das fade gar nicht mitliefern, es genügt das hsv Objekt, iirc.
Und - ja, "off" ist im fhem treiber genau so implementiert:

Code Auswählen Erweitern

elsif ( $cmd eq 'on' ) {
 
     # Add check to only do something if the controller is REALLY turned off, i.e. val eq 0
     my $state = ReadingsVal( $hash->{NAME}, "stateLight", "off" );
     return undef if ( $state eq "on" );
 
     # OK, state was off
     # val initialized from internal value.
     # if internal was 0, default to 100;
     my $val = $hash->{helper}->{oldVal};
     if ( $val eq 0 ) {
       $val = 100;
     }
 
     EspLedController_SetHSVColor( $hash, undef, undef, $val, undef, $fadeTime, $fadeSpeed,           $transitionType, $doQueue, $direction, $doRequeue, $fadeName );
   }
   elsif ( $cmd eq 'off' ) {
 
     # Store old val in internal for use by on command.
     $hash->{helper}->{oldVal} = ReadingsVal( $hash->{NAME}, "val", 0 );
 
     # Now set val to zero, read other values and "turn out the light"...
     EspLedController_SetHSVColor( $hash, "+0", "+0", 0, $colorTemp, $fadeTime, $fadeSpeed,           $transitionType, $doQueue, $direction, $doRequeue, $fadeName );
   }

da merkt sich das fhem device halt noch die alte Helligkeit in "oldVal" und nutzt die zum Einschalten wieder.

Du kannst ja einfach "toggle" nehmen... Aber ich schau mal, ob ich in der nächsten Firmware ein echtes "on/off" einbauen kann, wobei auch das natürlich nur ein "Licht aus" sein wird - nur kann ich dann das letzte Lichtsetting im Controller speichern statt im Treiber, das wäre sauberer.
Auch, wenn das Licht aus ist, läuft der Controller natürlich weiter und braucht so ca. 500mW. Wenn Du ein wirkliches "Aus" willst kannst Du das in Hardware erreichen, indem Du die beiden "DISABLE" überbrückst, das schaltet den Spannungswandler ab und der Verbrauch sollte auf ein paar µW zurück gehen.

pj

[pula]

ah ach so. wegen mir brauchst das nicht einbauen, ich weiß es ja jetzt
und die par mW tun glaub ich nicht weh. das passt schon so....
Danke für deine Bemühungen auf jeden Fall!
Cheers,
Pula

[pjakobs]

wie manche vielleicht mitbekommen haben, bin ich ja schon eine Weile dabei, die Firmware für die Controller zu überarbeiten.
Anlass dafür, war sie ESP32 fähig zu machen, aber da ich auf dem Weg dahin eh ein paar Dinge tun musste...

• die neue Firmware wird mDNS fähig sein, dass heißt, Controller werden im Netz auffindbar sein (prima für Autokonfiguration)
• damit sie dann auch erkennbar sind, wird man ihnen auch sprechende Namen zuweisen können (das geht über das API auch heute schon, nur das Frontend kann das nicht)
• wenn ich die Controller jetzt schon auffinden kann, dann kann ich sie auch ... von einem Frontend aus managen, d.h. das Frontend hat jetzt eine dropdown Box, in der Du auswählen kannst, welchen Controller Du gerade bearbeiten willst (dafür gibt es auch einen neuen API endpoint /hosts, der ein json array aller diesem Controller bekannten anderen Controller ausspuckt).
• da ich nun aber schon alle Controller "kenne", kann ich die auch gleich zu Gruppen zusammenfassen, also z.B. alle in der Küche, dem Wohnzimmer, der Modellbahn oder was auch immer - aus der Webapp heraus
• Gruppen sind nur sinnvoll, wenn ich auch was damit tun kann, also wird es Szenen-Presets für Gruppen geben
• Presets wird es auch für einzelne Controller geben - und ich weiß noch nicht, wie ich das im UI machen will - im Moment tendiere ich dazu, dass die Gruppen eine eigene UI Seite bekommen, in der dann für die einzelnen Gruppen die Szenen anzuwenden sind während die Presets für den einzelnen Controller in der "color" Seite bleiben vielleicht mach ich aber auch eine eigene Presets Seite, auf der dann lokale und Gruppenpresets unterschiedlich dargestellt werden.
• apropos "color" Seite - es wird die Möglichkeit geben, fünf Slider für die RAW Kanäle zu nutzen

Ich glaube, ich hatte noch ein paar andere Ideen, aber das waren erstmal die wesentlichen.
Ein paar Wochen brauch ich noch, dann kann ich mal eine beta Version zur Verfügung stellen.

auf ein buntes 2024

pj

[pula]

Hi mal wieder,

bin noch immer am herumspielen mit dem Controller mit MQTT und HA.
Dabei bin ich jetzt auf folgendes gestossen, was ich nicht verstehe (vermutlich übersehe ich einfach was wichtiges).
Ich schicke eine mqtt-Nachricht an das command-topic von einem meiner controller, die so aussieht:

Code Auswählen Erweitern

{
    "jsonrpc": "2.0",
    "method": "color",
    "params": {
        "t": 700,
        "d": "1",
        "cmd": "fade",
        "raw": {
            "r": 0,
            "g": 0,
            "b": 0
        },
        "q": "single"
    }
}
In der fhem-Anzeige vom Controller ändern sich darauf hin die Readings raw_blue, raw_green, raw_red und raw_ww.

Das Reading rgb bleibt aber unberührt und auch in der Web-Oberfläche von dem Controller ändert sich nichts (bin gerade nicht vor Ort).
Ist das ein Bug, ein Feature oder bin ich nur zu dumm?

Da auch HA eigentlich mit RGB arbeitet und ich mir die Umrechnerei gerne sparen würde, würde ich wenn möglich gern per mqtt auch mit rgb arbeiten.

Danke im voraus und cheers,
Pula
   

[pjakobs]

das Verhalten ist, so wie Du es beschreibst, korrekt und "as designed".
Liegt daran, dass der controller mit "RAW" und "HSV" zwei Betriebszustände kennt, die nicht aufeinander abgebildet sind. Man kann zwar, und das tut der Controller ja intern, von HSV auf RAW abbilden (und, klar, von RGB auf HSV), nicht aber von RAW auf HSV, jedenfalls ist eine solche Abbildung nicht implementiert. Wenn Du also ein RAW Kommando schickst, wird der Controller in den RAW Mode versetzt und die HSV Werte sind nicht weiter gültig.

[ich hab Deinen Post nochmal gelesen]
einen reinen RGB Modus hat der Controller nicht, einfach weil RGB ja keinen weiß-Kanal abbildet. Sicher, ich könnte einen RGB+W Modus einbauen, aber der wäre elementar weniger flexibel als der HSV Modus.

vielleicht hilft Dir das hier? https://community.home-assistant.io/t/hsl-or-hsv-color-definition-possible-in-ha/647616/3

pj

[pula]

wow, das war ja schnell, danke
aber verstehen tu ich es nicht.
Um per mqtt rgb-befehle an den controller zu schicken, muss ich doch "raw" verwenden, oder?
Wenn ich die dann schicke, werden aber nur die rgb-raw Readings aktualisiert, aber nicht das Reading RGB und auch nicht der Farb-Picker in der Web-Oberfläche des Controllers selbst, der sich sehr wohl ändert, wenn ich einen "hsv-befehl" schicke?

Wenn also in der api rgb als raw betitelt wird, verstehe ich grad nicht, warum sich dann nicht auch das rgb-Reading ändert?
Cheers und danke nochmal,
Pula

[pjakobs]

das api kennt ausschließlich HSV und RAW, wobei HSV bevorzugt ist.
RAW umgeht das ganze interne Farbmodell und setzt die Kanäle direkt (deshalb ist da der Kanalwert auch als int mit 0-1023 definiert, das entspricht der 10Bit PWM). Das heißt im Umkehrschluss eben auch, dass die Oberfläche nicht reagiert, denn die weiß schlicht nichts davon.
Das Beste wäre imho wirklich, so wie im Link angegeben, HA auf HSL umzustellen, dann lieferst Du Werte
h: 0-369
s: 0-100%
l: 0-100%
und alle sind (hoffentlich) glücklich.
Wenn Du RGB brauchst, dann musst Du das im Grunde vorher in HSL umrechnen.
Der Controller abstrahiert ja die Eigenschaft, welche Strips da nun dran hängen, wenn Du RGB Strips hast, mischt er weiß, wenn Du RGBW Strips hast, nimmt er die weißen LED - Dein HA braucht davon nichts zu wissen. Wenn Du allerdings RGB schickst, dann müsste der Controller wissen, ob Du nun wirklich RGB meinst, oder ob Du den Weißwert extrahiert und in den weißen LED angezeigt haben willst.

pj

[pula]

danke für die erklärung, das hätte ich so nicht erwartet 
werd mich dann doch mit HA und hsv beschäftigen...
ja, ich weiss, ist besser als rgb, aber da bin echt noch alte schule...

Cheers,

Pula

[pjakobs]

neues Jahr, neues Wissen