ESP RGBWW Wifi Led Controller - fhem - Modul

Begonnen von pjakobs, 28 Juni 2016, 10:31:13

Vorheriges Thema - Nächstes Thema

pjakobs

Zitat von: Shuzz am 11 April 2017, 19:28:07
Guten Tag zusammen,

ich möchte mich gern wieder zurück melden... ;)
Hatte die letzten Wochen/Monate privat einiges um die Ohren und hatte keine Zeit mehr für den Controller (FHEM und FW).

Nach allem was ich so lese hat sich der Status seit Januar aber nicht gravierend geändert oder?
Gut finde ich die FW auf dem 3.1.2er Sming Framework. Ich werde die Tage mal versuchen, das nachzuvollziehen und zu bauen.

Kurzer Hinweis zu den "vordefinierten" Animationen: Die wird es so nicht geben laut Patrick Jahns.
Seine Idee ist, einen kompletten Fade in einen einzigen HTTP POST zu packen - mehr aber auch nicht.
Auf den Controllern soll nichts gespeichert werden weil er der Meinung ist, das gehöre dort nicht hin sondern soll im FHEM Modul (oder sonstwo, jedenfalls nicht im Controller) verbleiben.
Sonst müsste man ja schließlich die Animationen immer auf allen Controllern synchron halten usw. usf.
Das war jedenfalls der Stand als ich das letzte Mal Kontakt zu ihm hatte, iwann Ende Januar.
Zumindest sollen diese Animationen dann aber loopen können, was ja schonmal etwas wäre.

Den MQTT Ansatz zur Synchronisierung finde ich eigentlich sehr schnuckelig, und viel effizienter als per Publish/Subscribe kriegt man viele Geräte eh nicht synchronisiert.
Selbst wenn da 50 Nachrichten pro Sekunde und Controller über's WLAN gehen - wäre das schlimm?
Ist ja nicht wie bei den 433/868MHz Standards, dass man nur eine gewisse Anzahl an Telegrammen senden darf...
Ich denke, selbst bei relativ großen Installationen sollte ein handelsübliches Home-Wifi da locker mithalten können.


Beste Grüße,

Shuzz

hey Shuzz, welcome back!

wir nehmen gerade wieder Fahrt auf! Mit pf@nne und @vbs hatte ich ein paar Firmware Enhancements besprochen.
Mal sehen, wie wir das koordiniert bekommen!
Dein Karton war heute schon fast fertig, dann fehlte aber noch ein Controller, sollte vielleicht noch vor Ostern klappen!

pj

funclass

Hey Leute,
ich muss nun hier nochmal die Frage stellen, da grad wieder Schwung in die FW/Modul-Entwicklung kommt.

Welchen Aufwand würde die Implementierung eines neuen Befehls "stop" in die Firmware bedeuten? Ziel sollte sein, eine aktuell laufende Animation zu stoppen, den Zustand zu halten und die Werte der Kanäle zu publishen um z.B. in FHEM die Farbwerte aktuell zu halten.

VG funclass

vbs

Mal eine Frage:
In dem Modul kommt an mehreren Stellen vor "( $fadeTime == 0 ) ? 'solid' : 'fade'". Also ob Modus 'solid' oder 'fade' gewählt wird, wird nur implizit über die fadeTime geregelt. Das verstehe ich nicht so richtig, da man ja dadurch gar keine solid-Time nutzen kann, oder? Also ich kann nicht sagen "HSV xyz für 20 Sekunden halten" (als solid), da durch die Angabe "20 Sekunden" immer ein _Fade_ auf xyz (anstelle von solid) ausgeführt würde, oder?

pjakobs

Zitat von: vbs am 12 April 2017, 08:06:59
Mal eine Frage:
In dem Modul kommt an mehreren Stellen vor "( $fadeTime == 0 ) ? 'solid' : 'fade'". Also ob Modus 'solid' oder 'fade' gewählt wird, wird nur implizit über die fadeTime geregelt. Das verstehe ich nicht so richtig, da man ja dadurch gar keine solid-Time nutzen kann, oder? Also ich kann nicht sagen "HSV xyz für 20 Sekunden halten" (als solid), da durch die Angabe "20 Sekunden" immer ein _Fade_ auf xyz (anstelle von solid) ausgeführt würde, oder?
Wenn ich mich recht entsinne, dann habe ich aber auch ein 'pause' kommando eingebaut das eigentlich 'solid' verwenden sollte, damals gab es aber noch einen Bug in der Firmware weshalb ich das erst mit minimalem fade gelöst hatte...
Ich muss mal wieder reinschauen.

pj

Gesendet von meinem HTC 10 mit Tapatalk


vbs

Ok danke, verstehe. Wobei sich die solid/fade-Frage eigentlich durch alle Befehle zieht: hsv,rgb,raw,on,off,rotate,dimup,dimdown,hue,... Das lässt sich mMn wohl nicht immer durch pause ersetzen. Ich bin jetzt mit der FW erstmal für den Moment durch und mache mich nun über das FHEM-Modul her... hab jetzt für 'solid' erstmal ein neues Flag 's' eingeführt, ansonsten ist 'fade' default.

pjakobs

Wie würdest Du 'solid' bei rotate, dimup, dimdown etc interpretiertieren?

Gesendet von meinem HTC 10 mit Tapatalk


RaspiLED

Hi,
Wäre solid 20 sec nicht eigentlich ein on-for-timer 20 sec?
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Raspberry Pi mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, WifiLight2, Bravia, ...

vbs

Genauso wie bei hsv/raw. Das sollte der gleichen Logik folgen.

ZB. dimup:
dimup 20 10 s
-> erhöhe Helligkeit um 20 und bleibe dort für 10 s

dimup 20 10
-> erhöhe Helligkeit um 20 mit einer Ramp von 10 s


rotate 30 10 s
-> rotiere Hue um 30 und bleibe dort für 10 s

rotate 30 10
-> rotiere Hue um 30 mit einer Ramp von 10 s

(nur weils komisch aussieht: das "s" im Befehl steht für "solid", das "s" in meiner Beschriebung für Sekunden)

Also solid schaltet immer sofort auf den neuen Wert und bleibt (mindestens) die Zeit dort.
Fade interpretiert die Zeit als ramp mit Wert als Ziel.

So hatte ich zumindest immer solid/fade verstanden. Bitte korrigieren falls ich mich irre. Dann hab ich vermutlich an ziemlich vielen Stellen ziemlich Mist gebaut  :o

pjakobs

Gute Frage, ich hätte solid immer nur im Kontext einer Queue gesehen, eben im Sinne von 'pause'. On-for-timer würde ich immer mit fhem Bordmitteln machen. Zudem ich mir nicht sicher bin, ob die maximale fade Zeit des Controllers dafür genügt, denn intern zählt der Millisekunden und ich weiß nicht, ob das 32Bit sind. Wenn ja, dann wäre das maximum allerdings ausreichend mit ca. 4 Millionen Sekunden...

Gesendet von meinem HTC 10 mit Tapatalk


pjakobs

#189
Zitat von: vbs am 12 April 2017, 09:16:48
Genauso wie bei hsv/raw. Das sollte der gleichen Logik folgen.

ZB. dimup:
dimup 20 10 s
-> erhöhe Helligkeit um 20 und bleibe dort für 10 s

dimup 20 10
-> erhöhe Helligkeit um 20 mit einer Ramp von 10 s


rotate 30 10 s
-> rotiere Hue um 30 und bleibe dort für 10 s

rotate 30 10
-> rotiere Hue um 30 mit einer Ramp von 10 s

(nur weils komisch aussieht: das "s" im Befehl steht für "solid", das "s" in meiner Beschriebung für Sekunden)

Also solid schaltet immer sofort auf den neuen Wert und bleibt (mindestens) die Zeit dort.
Fade interpretiert die Zeit als ramp mit Wert als Ziel.

So hatte ich zumindest immer solid/fade verstanden. Bitte korrigieren falls ich mich irre. Dann hab ich vermutlich an ziemlich vielen Stellen ziemlich Mist gebaut  :o

im fhemmodule hatten wir das so gelöst:


elsif ($cmd eq 'pause'){
     
         # For use in queued fades.
         # Will stay at the current color for $fadetime seconds.
         # NOTE: Does not make sense without $doQueue == "true".
         # TODO: Add a check for queueing = true? Or just execute anyway?
         my $val = InternalVal($hash->{NAME}, "valValue", 0);
         my $hue = InternalVal($hash->{NAME}, "hueValue", 0);
         my $sat = InternalVal($hash->{NAME}, "satValue", 0);
         if ($fadeTime eq 0 || $doQueue eq 'false'){
             Log3 ($hash, 3, "$hash->{NAME} Note: pause only makes sense if fadeTime is > 0 AND if queueing is activated for command!");
         }
         LedController_SetHSVColor($hash, $hue, $sat, $val, $colorTemp, $fadeTime, 'solid', $doQueue, $direction);


auf diese Weise lässt sich das, was Du willst stets mit zwei Befehlen lösen

set <light> hsv 10,70,50 0
set <light> pause 20 q
set <light> rotate 70 10 q


ich selbst finde das verständlicher, aber es stimmt schon, ein weiteres Flag wäre vermutlich näher an der API.

pj

[update]

ich hab gerade nochmal in's Modul reingeschaut, wenn Du das "s" (oder lieber "h" für "hold" wegen der Verwechslung mit Sekunden) in die ArgsHelper Routine integrierst, dann wäre das für das ganze Interface erstmal kompatibel und böte die entsprechende Funktionalität.

pj

vbs

Verstehe, ok, so geht's sicherlich auch! Die Option hab ich jetzt aber nicht mehr, da es den pause-Befehl so nicht mehr gibt bei mir  :-X (warum gibts eigentlich hier keinen Smiley mit ausgeschlagenen Zähnen?)

EDIT:
Hab gerade meinen Flux-Pen aus China bekommen! :) Danke für das Löt-Tutorial!

pjakobs

#191
Zitat von: vbs am 12 April 2017, 09:46:06
Verstehe, ok, so geht's sicherlich auch! Die Option hab ich jetzt aber nicht mehr, da es den pause-Befehl so nicht mehr gibt bei mir  :-X (warum gibts eigentlich hier keinen Smiley mit ausgeschlagenen Zähnen?)

EDIT:
Hab gerade meinen Flux-Pen aus China bekommen! :) Danke für das Löt-Tutorial!

warum gibt's den 'pause' Befehl nicht mehr? Der ist doch nichts anderes als "setze die Werte, die aktuell sowieso schon gesetzt sind und warte (solid)" .
Ich verstehe, dass das ggf. bei fünf unabhängig laufenden Queues/Fades global erstmal mist ist, aber dann muss man pause halt optional um eine channel map erweitern.
Es wäre halt schon schön, wenn wir das Modul API auf der fhem Seite stabil halten könnten und neue Funktionen einführen, ohne alte zu brechen.

pj

ps: wenn ich gerade mal über die gestern diskutierte Version mit allokierten Kanälen und einem "cookie" nachdenke - da könnte man die Komplexität, welche Channel denn nun pausieren müssen sogar im Controller verstecken.

vbs

Hm, also ich hab nicht gesagt das es 'pause' nicht mehr gibt. Das gibt es so (in der Form) nicht mehr. ;)

Ich würde die Diskussion gerne auf einen etwas späteren Zeitpunkt verschieben, ehrlich gesagt. Ich bin da erstens selbst noch nicht an allen Stellen gedanklich mit durch und einige Änderungen machen dann auch erst in Zusammenhang mit anderen Änderungen Sinn (bzw. sehen für sich alleine betrachtet seltsam aus im Kontext des alten FW-Standes).

Ich hab schon versucht, so gut es geht, die alte API beizubehalten. Aber es ist tatsächlich so, dass ich an einigen Stellen mit der alten Logik breche (möglicherweise ist es sogar nur die pause-Sache). Sorry dafür schonmal, aber hielt ich unterm Strich für besser...

pjakobs

Zitat von: vbs am 12 April 2017, 09:46:06
EDIT:
Hab gerade meinen Flux-Pen aus China bekommen! :) Danke für das Löt-Tutorial!

vielleicht sollten wir mal einen Wettbewerb im "wer baut den Controller am schnellsten auf" ausschreiben. Ich denke, ich komme auf etwa 20 Minuten pro Controller, wenn ich dabei nicht sabbeln muss!

pj

pjakobs

Neue, eigene Threads für Firmware, Hardware und (länger schon) das fhem Modul
Nachdem die diversen Threads langsam unübersichtlich werden habe ich mal neue, separate Threads für die einzelnen Themen angelegt.

Firmware:
https://forum.fhem.de/index.php/topic,70456.0.html

Hardware:
https://forum.fhem.de/index.php/topic,70455.0.html

fhem Modul:
https://forum.fhem.de/index.php/topic,55065.0.html

Sammelthread nächste Bestellung:
https://forum.fhem.de/index.php/topic,69740.0.html

ein paar der alten Threads (vor allem der erste Sammelbestellungsthread) sind mittlerweile etwas unübersichtlich geworden, da ist es vermutlich besser, neu anzufangen!

Grüße

pj