ESP RGBWW Wifi Led Controller - fhem - Modul

pjakobs · 17 Oktober 2016, 20:44:16

Hmm... ich kann die Logik verstehen, homekit geht also offenbar davon aus, dass das Gerät die grundsätzlichen Zustände "on" und "off" kennt und schaltet es erst einmal ein, damit es dann dimmen kann.

Solltest Du das nicht abschalten können, dann kannst Du ja die defaultColor auf 0,0,0 stellen. Wobei, das ist natürlich auch irgendwie blöd, denn dann würde ein "set on" das Licht ausschalten.

hmm...

pj

kadettilac89 · 31 Oktober 2016, 15:44:19

Hi,

ich habe mehrfach RAW modus gelesen. Ist es im Modul möglich per RAW Befehl sowohl CW als auch WW 100% zu aktivieren? Ohne Fading oder Farbübergang. Einfach nur volle Helligkeit beider Weiß-Kanäle?

Wenn es nicht per Modul möglich ist, gibt es einen HTTP-Befehl oder irgend etwas anderes was ich über Fhem absetzen kann um das zu aktivieren?

Danke!

pjakobs · 31 Oktober 2016, 21:15:16

Zitat von: kadettilac89 am 31 Oktober 2016, 15:44:19
Hi,

ich habe mehrfach RAW modus gelesen. Ist es im Modul möglich per RAW Befehl sowohl CW als auch WW 100% zu aktivieren? Ohne Fading oder Farbübergang. Einfach nur volle Helligkeit beider Weiß-Kanäle?

Wenn es nicht per Modul möglich ist, gibt es einen HTTP-Befehl oder irgend etwas anderes was ich über Fhem absetzen kann um das zu aktivieren?

Danke!

zieh dir die Version aus dem dev-pj Branch, da kannst Du mit

Code Auswählen

set <device> raw r10,g10,b10,ww10,cw10
den 10 Bit (0-1023) Wert für jeden Kanal setzen.

Nicht staunen, die Version erzeugt abstrus viel Debug Output

Grüße

pj

kadettilac89 · 01 November 2016, 15:17:46

Zitat von: pjakobs am 31 Oktober 2016, 21:15:16
zieh dir die Version aus dem dev-pj Branch, da kannst Du mit
Code Auswählen Erweitern
set <device> raw r10,g10,b10,ww10,cw10
den 10 Bit (0-1023) Wert für jeden Kanal setzen.

Nicht staunen, die Version erzeugt abstrus viel Debug Output

Grüße

pj

Danke dir

pjakobs · 07 November 2016, 10:52:19

Ich hab mal meine aktuelle Version auf github gepusht, branch dev-pj

neue Funktionen: dimup / dimdown - tun, was der Name beschreibt. Ich brauchte die für up/down Taster als Dimmer-Trigger (über ein Notify)
experimentelle Funktion: raw - nachdem mehrfach danach gefragt wurde: set <device> raw r10,b10,g10,cw10,ww10 (x10 ist dabei ein 10Bit Wert, also 0-1023) gibt volle Kontrolle über die einzelnen Kanäle.
Dokumentation wieder eingefügt - irgendwann ist mir die html Dokumentation im devel Tree verloren gegangen, ich hab sie hier wieder eingebaut, allerdings stimmt imho irgendwas noch nicht, weil immer de und en angezeigt werden?

Diese Version erzeugt noch jede Menge Debug. Bisher habe ich keine Rückmeldung über Bugs bekommen, ich denke, wenn das so bleibt, werde ich den Debug Kram rausnehmen und sie zum Master promoten (orr... dazu fehlt mir imho ein rebase, mal sehen. git-Schmerzen

)

Was noch fehlt:

Ordentliches Seuqencing der Requests - wenn viele Sets in einer Befehlszeile abgesetzt werden (also z.B., mit fhem("set LED on, set LED off, set LED on"), dann schickt das Modul diese nicht auf einmal an den Controller, sondern wartet jeweils darauf, dass der vorhergegangene Befehl abgearbeitet ist. Wer im Moment Sequenzen programmieren will, der tut gut daran, die getrennt ( fhem("set LED on");fhem("set LED off") zu senden.
Ich suche noch nach einem vernünftigen Weg die verschiedenen Modi des Controllers abzubilden. Es gibt ja
- den "normalen" hsv Modus, den das Modul zumeist verwendet. Hier wird die Berechnung der LED Helligkeit für die einzelnen Kanäle der Firmware überlassen
- den raw Modus, hier übernimmt fhem komplett die Steuerung des Controllers, es wird kein hsv Wert bestimmt (und das ist, zumindest ohne größeren Aufwand, auch nicht möglich)
- zumindest die Möglichkeit, die Kanäle nicht as RGBWWCW sondern als fünf unabhängige Kanäle zu betrachten. Diese würde ich gerne als fünf Devices in FHEM abbilden. Dazu habe ich mir bisher nur ein paar Gedanken gemacht

Wer sich berufen fühlt, hier etwas beizutragen: nur zu!

Grüße

pj

Shuzz · 25 November 2016, 00:06:23

Ich möchte mich an dieser Stelle mal bedanken - und meckern.

Bedanken für den super gemachten und recht gut durchdachten RGBWW Controller incl. des FHEM-Moduls.

Und meckern, weil... naja, weil ich mir ein ESP8266 Board gekauft habe und direkt die Idee hatte "Mensch, damit bauste nen RGB-WiFi-Dimmer". Also flugs mal einen kleinen REST-Service draufgeworfen und per Colorpicker angesteuert. War ein Abend Arbeit und funktionierte schonmal prima. Dann suchte ich nach ner besseren Möglichkeit zur Ansteuerung als über den normalen Colorpicker und stolperte über... das hier.
Was soll ich sagen? Meine Eigenentwicklung ist eingemottet, denn um an den Funktionsumfang und die Qualität dieser Implementierung ranzukommen bräuchte ich Monate - und da siegte die Faulheit.
Und da ich von Perl eher gar keinen Plan habe (Java schon eher, aber...

) finde ich das passende Modul auch super!
Ich muss sagen: Chapeau! Ich ziehe meinen Hut!

Da ich FHEM-Neuling bin kämpfe ich allerdings derzeit mit dem FHEM-Modul. Ich krieg's einfach nicht hin, was anderes als nen on/off switch in der WebGUI angezeigt zu bekommen.
Könnte bitte mal jemand seine komplette Definition für das LedController Modul hier posten damit ich ein wenig spicken kann?
Das hat sich erledigt...

Was nicht zu funktionieren scheint ist das Fading von einer Farbe zur anderen. Geht das nicht automatisch per colorpicker irgendwie? o0

Danke und macht weiter so, der Controller ist ziemlich geil!

pjakobs · 05 Dezember 2016, 10:52:31

Ich habe heute früh mal das git aufgeräumt, der devel und der master branch sind jetzt auf dem gleichen, getesteten und voll funktionalen Stand (zumindest nach meinem Empfinden).

@Shuzz hat sich die Mühe gemacht, den Code aufzuräumen und lesbarer zu gestalten. Zudem gibt es jetzt für alle Parameter range checks, so dass das Modul insgesamt robuster geworden sein dürfte.
Zudem haben wir die "on" Funktion ein bisschen verändert:

wenn die Helligkeit ungleich null ist (val!=0), dann tut on nichts.
wenn ein default Farbwert vorgegeben ist, dann setzt on diesen
defaultColor ist deprecated zugunsten von defaultHue, defaultSat und defaultVal
beim Abschalten wird der letzte val Wert in einem internal gespeichert, wenn kein Default vorgegeben ist, wird dieser beim Einschalten verwendet
wenn weder ein Default noch ein letzter Wert vorhanden ist, wird die Helligkeit auf 100% gesetzt

Damit hoffen wir ein paar Fliegen mit einer Klappe geschlagen zu haben:

Kompatibilität mit homekit/homebridge: es ist schonmal beobachtet worden, dass sich homekit ein wenig seltsam verhält, indem es erst den Farbwert setzt und dann ein on Kommando hinterher sendet. Im bisherigen Zustand hätte der Farbwert zwar das Modul korrekt auf die gewünschte Farbe geschaltet, das nachfolgende on aber sofort auf die defautt-Farbe oder, wenn diese nicht konfiguriert ist, auf 0,0,100. Da das Modul ein on jetzt ignoriert, wenn val != 0 sollte das jetzt nicht mehr vorkommen.
Viele China Controller interpretieren "on" als "aktiviere das letzte Setting" sprich: sie schalten auf die Lichtfarbe, die vor dem Ausschalten aktiv war. Das Controller-Modul hat bisher stattdessen auf eine Default Farbe geschaltet. Die neue Version erlaubt nun beides: ist ein Default gesetzt, wird es verwendet, ist kein Default gesetzt, wird der letzte Zustand wieder hergestellt. Da nun die Default Werte in einzelne Attrs aufgeteilt sind, kann auch eine default Farbe konfiguriert werden, die Helligkeit und die Sättigung werden dann aber z.B. vom letzten mal übernommen bzw. jeder andere Kombination hieraus.

Zudem ist jetzt endlich der master Zweig wirklich up to date, wer noch mit einer der alten dev-pj oder gar der ganz alten master Versionen sollte jetzt updaten

Grüße

pj

hermanski.k · 05 Dezember 2016, 22:40:09

Abend,
ich versuche mit dem LED Controller ein Wakeup light zu erstellen mit Codeauszügen aus dem Forum:

Code Auswählen

# Sonnenaufgangssimulation für bis zu 4 Devices
# Author : Sandra Ohmayer (http://www.animeschatten.net)
# Aufruf: wakeUpSun(<Zeit in Minuten>,"<Devicename>"),wakeUpSun(<Zeit in Minuten>,"<Devicename1>","<Devicename2>") ...

sub
wakeUpSun {
	# Dauer in Minuten (minimum 4 min)
	local $dauer = $_[0];
	# Initialisiern des Lichterarrays
	local @lichter = ($_[1],$_[2],$_[3],$_[4]);

	local @farben = (
        ["240,100,2",1],
        ["240,100,1",1],
	["240,100,2",20],
	["240,100,5",20],
	["240,100,8",20],
	["210,100,6",30],
	["190,100,8",1],
	["90,100,14",1],
	["70,100,16",1],
	["10,100,34",2],
	["30,100,40",30],
	["40,100,60",30],
	["45,100,80",30],
	["50,100,100",30],
	["50,19,75",3],
	["50,0,100",30]
	);
	
	local $gesamtdauersek = $dauer*60;
	
	local $dauerfarben = 0;	
	foreach my $farbe ( @farben ) {
		$dauerfarben+=$farbe->[1];
	}
	
	local $anteiligedauer = $gesamtdauersek/$dauerfarben;

	Log3 (undef, 3, "wakeUpSun: start, angegebene Gesamtdauer in Sekunden $gesamtdauersek, Dauer Farben $dauerfarben, Anteil $anteiligedauer");
	
	# Ausschalten der Lampen (Schalter - off)
	foreach my $licht ( @lichter ) {
		if(defined $licht) {
			fhem("set $licht off");
		}
	}

	# Durchlauf der Farbsimulation
	my $i = 0;
	foreach my $farbe ( @farben ) {
		foreach my $licht ( @lichter ) {
			if(defined $licht) {
				if($i == 0) {
					fhem("set $licht hsv ".($farben[$i][0])." ".ceil($anteiligedauer*($farben[$i][1])));
				} else {
					fhem("set $licht hsv ".($farben[$i][0])." ".ceil($anteiligedauer*($farben[$i][1]))." q");
				}
			}
		}
		$i++;
	}
}

Leider muss ich feststellen das folgende Fehler bei mir vorliegen:
1) Farbablauf bei jedem Aufruf unterschiedlich
2) egal welche dauer ich in Min. angebe, der Farbverlauf läuft zu schnell
3) Bleibt manchmal in einer Farbe stehen

Ich beschäftige mich mit der Programmierung und Fhem erst seit kurzem, daher würde ich mich freuen wenn mir jemand helfen könnte.
Vielen Dank im voraus.
Sg,
Kamilo

pjakobs · 06 Dezember 2016, 09:17:00

Hi Kamillo,

ich hab das gerade mal getestet (nicht sehr ausgiebig, gebe ich zu) und bei mir schaut das auf den ersten Blick sehr ok aus.
Ich habe den Code ganz leicht abgewandelt (die "local" Definition der Variablen oben mit "my" ersetzt, zusätzliche Logausgabe):

Code Auswählen

# Sonnenaufgangssimulation für bis zu 4 Devices
# Author : Sandra Ohmayer (http://www.animeschatten.net)
# Aufruf: wakeUpSun(<Zeit in Minuten>,"<Devicename>"),wakeUpSun(<Zeit in Minuten>,"<Devicename1>","<Devicename2>") ...

sub
wakeUpSun {
	# Dauer in Minuten (minimum 4 min)
	my $dauer = $_[0];
	# Initialisiern des Lichterarrays
	my @lichter = ($_[1],$_[2],$_[3],$_[4]);

	my @farben = (
        ["240,100,2",1],
        ["240,100,1",1],
	["240,100,2",20],
	["240,100,5",20],
	["240,100,8",20],
	["210,100,6",30],
	["190,100,8",1],
	["90,100,14",1],
	["70,100,16",1],
	["10,100,34",2],
	["30,100,40",30],
	["40,100,60",30],
	["45,100,80",30],
	["50,100,100",30],
	["50,19,75",3],
	["50,0,100",30]
	);
	
	my $gesamtdauersek = $dauer*60;
	
	my $dauerfarben = 0;	
	foreach my $farbe ( @farben ) {
		$dauerfarben+=$farbe->[1];
	}
	
	my $anteiligedauer = $gesamtdauersek/$dauerfarben;

	Log3 (undef, 3, "wakeUpSun: start, angegebene Gesamtdauer in Sekunden $gesamtdauersek, Dauer Farben $dauerfarben, Anteil $anteiligedauer");
	
	# Ausschalten der Lampen (Schalter - off)
	foreach my $licht ( @lichter ) {
		if(defined $licht) {
			fhem("set $licht off");
		}
	}

	# Durchlauf der Farbsimulation
	my $i = 0;
	foreach my $farbe ( @farben ) {
		foreach my $licht ( @lichter ) {
			if(defined $licht) {
				if($i == 0) {
                    Log3(undef,3,"wakeUpSun: set $licht hsv ".($farben[$i][0])." ".ceil($anteiligedauer*($farben[$i][1])));
					fhem("set $licht hsv ".($farben[$i][0])." ".ceil($anteiligedauer*($farben[$i][1])));
				} else {
                    Log3(undef,3,"wakeUpSun: set $licht hsv ".($farben[$i][0])." ".ceil($anteiligedauer*($farben[$i][1]))." q");
					fhem("set $licht hsv ".($farben[$i][0])." ".ceil($anteiligedauer*($farben[$i][1]))." q");
				}
			}
		}
		$i++;
	}
}

Was mir aufgefallen ist: einige der Farbverläufe sind bis zu 30 mal schneller definiert als andere. Die Zahl nach dem Komma in den einzelnen Elementen des @farben Array gibt die relative Dauer an. Das Array im Code definiert 250 Zeiteinheiten, die dann einfach auf die angegebene Gesamtdauer gestreckt werden. Auf fünf Minuten gestreckt zieht sich der Übergang von 30,100,40 zu 50,100,100 (relativ dunkles Orange zu Sonnengelb) über 3x36s also fast zwei Minuten, von dort geht es dann allerdings innerhalb von vier Sekunden nach Weiß. Die Übergänge bzw. die Zeit dafür kannst Du ändern, indem Du den Zeitparameter in der jeweiligen Zeile des @farben Arrays änderst. Zu beachten ist dabei allerdings, dass die Gesamtzeit in Sekunden offenbar nicht kleiner sein darf als die Summe der angegebenen Zeiteinheiten.

Nimm doch bitte mal die Version der Routine, wie ich sie oben reingepostet habe und poste den LOG Output, der sich daraus ergibt hier. Der sollte inetwa so aussehen:

Code Auswählen


2016.12.06 08:53:03 3: wakeUpSun: start, angegebene Gesamtdauer in Sekunden 300, Dauer Farben 250, Anteil 1.2
2016.12.06 08:53:03 3: wakeUpSun: set LED_Sc hsv 240,100,2 2
2016.12.06 08:53:04 3: wakeUpSun: set LED_Sc hsv 240,100,1 2 q
2016.12.06 08:53:04 3: wakeUpSun: set LED_Sc hsv 240,100,2 24 q
2016.12.06 08:53:05 3: wakeUpSun: set LED_Sc hsv 240,100,5 24 q
2016.12.06 08:53:05 3: wakeUpSun: set LED_Sc hsv 240,100,8 24 q
2016.12.06 08:53:06 3: wakeUpSun: set LED_Sc hsv 210,100,6 36 q
2016.12.06 08:53:06 3: wakeUpSun: set LED_Sc hsv 190,100,8 2 q
2016.12.06 08:53:06 3: wakeUpSun: set LED_Sc hsv 90,100,14 2 q
2016.12.06 08:53:07 3: wakeUpSun: set LED_Sc hsv 70,100,16 2 q
2016.12.06 08:53:07 3: wakeUpSun: set LED_Sc hsv 10,100,34 3 q
2016.12.06 08:53:07 3: wakeUpSun: set LED_Sc hsv 30,100,40 36 q
2016.12.06 08:53:07 3: wakeUpSun: set LED_Sc hsv 40,100,60 36 q
2016.12.06 08:53:08 3: wakeUpSun: set LED_Sc hsv 45,100,80 36 q
2016.12.06 08:53:08 3: wakeUpSun: set LED_Sc hsv 50,100,100 36 q
2016.12.06 08:53:09 3: wakeUpSun: set LED_Sc hsv 50,19,75 4 q
2016.12.06 08:53:09 3: wakeUpSun: set LED_Sc hsv 50,0,100 36 q

(diese Zahlen sind für fünf Minuten).

Zudem: welche Version des LedController Moduls verwendest Du? Es gibt seit gestern eine brandneue, aufgeräumte, wenn Du noch eine der älteren hast - zumal vielleicht die aus dem alten master branch, dann kann dort viel merkwürdiges drin sein. "here be dragons" steht irgendwo im Code

Zieh Dir auf alle Fälle die neueste von github: https://github.com/patrickjahns/esp_rgbww_fhemmodule

Grüße

pj

hermanski.k · 06 Dezember 2016, 12:48:12

Super besten Dank. Probiere es gleich mal. Kannst du mir nochmal deinen Programmaufruf zum test sagen.
Langsam hinterfrag ich schon alles.

32_LED_controller.pm grade drauf geschoben.

melde mich gleich nochmal.

Kleiner Nachtrag von mir zu meinem vorgehen:
1.deine Code habe ich per Notepad abgesspeichert in MywakeUpSun.pm. Diese Datei per ftp an den Rasp pi geschoben nach /home/pi.
Anschließen per sudo mv /home/pi/MywakeUpSun.pm /opt/fhem/Fhem.

2. analog mit der 32_LED_Controller.pm

3. in FHEM -> define LED_WoWakeUp LedController 192.168.178.71

4. in FHEM -> {wakeUpSun(4,"LED_WoWakeUp")}
Falls ich was falsch mache bitte ich um Korrektur.

Mario67 · 06 Dezember 2016, 13:31:42

Ein

Code Auswählen

reload 32_LED_Controller.pm und

Code Auswählen

reload MywakeUpSun.pm fehlt.
Du solltest für eigene Module (Nachtrag: welche Du nicht veröffentlichen möchtest/die nur lokal Sinn machen) möglichst das Namensschema 99_my[ModuleName].pm einhalten, z.B. 99_myWakeUpSun.pm.

Gruß,
Mario

hermanski.k · 06 Dezember 2016, 13:58:16

Tatsächlich. Nun geht es. Ich danke euch für eure Unterstützung.
Freue und Bendanke mich über die Hilfsbereitschaft hier im Forum.

SG,

Kamilo

Shuzz · 06 Dezember 2016, 14:33:33

Danke für das Wakeuplight, das gefällt mir prima.

Ich glaube, das installiere ich im Schlafzimmer!

SalvadoreXXL · 07 Dezember 2016, 12:52:32

Nutze 2 von den Controlern seit geraumer Zeit mit FHEM. Danke nochmal an die Macher (Hard- + Software)!

Vieleicht kann mir ja jemand einen Tip geben? Suche eine Möglichkeit, einen unendlichen Colorloop mit dem Controler zu realisieren.

Shuzz · 07 Dezember 2016, 13:07:53

Das ist derzeit nicht 100% möglich.

Du könntest zwar nen Colorloop per FHEM einmalig im Controller queuen, aber das Ding zu wiederholen wird ein Problem.
Theoretisch kannste zwar den Loop zyklisch an den Controller schicken (z.B. per at), aber das wirst Du nicht 100% synchron hinkriegen.
D.h. mit der Zeit läuft Dir entweder die Queue im Controller voll (weil Du eben einen Ticken zu früh sendest) ODER Dein Loop wird kurz unterbrochen (weil der neue Rutsch Kommandos von FHEM einen Ticken zu spät kommt).

Den letzten Fall könnte man noch geschickt kaschieren indem man die Loop auf einer festen Farbe enden lässt so dass es nicht auffällt wenn diese Farbe für ein paar Sekunden "stehen bleibt".