ESP RGBWW Wifi Led Controller - Hinweise zu Sammelbestellung 2.5

[Pf@nne]

Moin,

Patrick hat die Konfiguration des MQTT-Brokers doch schon in das WEB-IF aufgenommen.
Ich meine die Felder schon gesehen zu haben.

Gruß
Pf@nne

[Frank_Huber]

Noch sind ein paar Bestellungen nicht bezahlt, ich werde noch einmal eine Zahlungserinnerung verschicken, wenn dann noch jemand nicht bezahlt, dann werden vielleicht nochmal 10 Controller verfügbar, aber sicher nicht mehr.

Hi,
falls einer übrig bleibt melde ich mal Interesse an. (Komplettmodul)
danke & Grüße

[hologramm]

Noch sind ein paar Bestellungen nicht bezahlt, ich werde noch einmal eine Zahlungserinnerung verschicken, wenn dann noch jemand nicht bezahlt, dann werden vielleicht nochmal 10 Controller verfügbar, aber sicher nicht mehr.

Ich würde den "ganzen Rest" nehmen - sofern da noch was bleibt.
Bausätze stets willkommen 

lg

[vbs]

Darf ich vorschlagen, im Perl-Modul neben dem set von "hsv" auch "HSV" zuzulassen? Damit wäre Aufruf kompatibel mit WifiLight. Ich habs gerade bei mir mal hinzugefügt und es gefällt mir eigentlich ganz gut. Spricht da etwas dagegen?

[pjakobs]

Darf ich vorschlagen, im Perl-Modul neben dem set von "hsv" auch "HSV" zuzulassen? Damit wäre Aufruf kompatibel mit WifiLight. Ich habs gerade bei mir mal hinzugefügt und es gefällt mir eigentlich ganz gut. Spricht da etwas dagegen?

Moin,

aus meiner Sicht nicht, aber wenn, dann sollten alle Kommandos mit kompatiblen Werten ergänzt werden.
Müsste man die Readings nicht auch spiegeln?
Ich hatte das ursprünglich mal mit HerrmannJ diskutiert und der meinte, dass er wifilight ggf. auch auf lowercase umstellen wird.

Wenn Du einen pull request machst, schau ich es mir an.

Grüße

pj

Gesendet von meinem HTC 10 mit Tapatalk

[vbs]

Müsste man die Readings nicht auch spiegeln?
Ich hatte das ursprünglich mal mit HerrmannJ diskutiert und der meinte, dass er wifilight ggf. auch auf lowercase umstellen wird.

Ja Readings wären auch gut, aber die müsste man wohl wirklich umbenennen, was dann wohl nicht rückwärtskompatibel wäre... :/ Oder wir halten einfach noch ein bisschen aus. Gibt ja dank dir bald die anderen Controller Dann werde ich die LD382/Wifilight bei mir erstmal ausmustern können...

[pjakobs]

Ja Readings wären auch gut, aber die müsste man wohl wirklich umbenennen, was dann wohl nicht rückwärtskompatibel wäre... :/ Oder wir halten einfach noch ein bisschen aus. Gibt ja dank dir bald die anderen Controller Dann werde ich die LD382/Wifilight bei mir erstmal ausmustern können...

Die Readings könntest Du ja zur Not mit userReadings machen.
Aber ja, ich hoffe, dass ich ab kommender Woche die Bausätze verschicken kann, heute kamen nochmal 40 ESPs, hoffentlich kommen bald die letzten DCDC Wandler.

pj

Gesendet von meinem HTC 10 mit Tapatalk

[herrmannj]

Müsste man die Readings nicht auch spiegeln?
Ich hatte das ursprünglich mal mit HerrmannJ diskutiert und der meinte, dass er wifilight ggf. auch auf lowercase umstellen wird.

ja, will er

[RaspiLED]

Moin,
was haltet ihr von einer automatischen Upper/Lowercase Function in 99_myUtils? Könnte man nicht auf die "Modul hat nicht" Events reagieren und das umsetzen?
Gruß Arnd

Diverse RasperryPi mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, WifiLight ...

[pjakobs]

Moin,

nochmal ein Update:

gestern sind noch 40 DC/DC Wandler eingetroffen, dabei hat offenbar eine Sendung eine frühere überholt.

Die Platinen hängen offenbar weiterhin beim Zoll, wobei ich auch schon erlebt habe, dass sie quasi im Zustand "Zollereignis" von DHL weiter zu meinem lokalen Zollamt transportiert wurden und ich dann plötzlich ein Schreiben (!) von dort bekam, ich möge doch bitte meine Zollware auslösen.
Da der Warenwert + Versandkosten für die Platinen bei etwa 220US$ liegt, werde ich Zoll und Einfuhr-Umsatzsteuer zahlen, und ich hoffe, dass der Zoll anerkennt, dass es sich hier um ein nicht kommerzielles Projekt handelt.

I'll keep you posted!

pj

[vbs]

Ich hab mal versucht, einen Slave-Modus für das Modul zu basteln. Es bewirkt, dass das Gerät beliebig viele andere andere Geräte vom Typ LedController/WifiLight mitsteuert. Also alle Befehle, die man am Master ausführt, werden auch bei den Slaves ausgeführt.
Dafür gibt es das Attribut "slaves", in das man die Geräte-Namen der Slaves reinschreibt in der Syntax "<slave1> <slave2> ... <slaveN>", also mit Leerzeichen getrennt.
Man kann die HSV-Werte an den Slaves auch mit Offsets belegen mit der Syntax "<slave>:<hue-offset>,<sat-offset>,<val-offset>". Damit könnte man konfigurieren, dass zB die Helligkeit am Slave immer 20 Prozentpunkte unter der des Master liegt ("wz_lightSlave:0,0,-20") oder man möchte immer 10 Prozentpunkte mehr Sättigung "wz_lightSlave:0,10,0".

Das Ganze ist hier zu finden:
https://github.com/verybadsoldier/esp_rgbww_fhemmodule/commits/develop

Bei Gefallen bzw. falls du das übernehmen möchtest, dann würde ich noch die entsprechende commandref-Doku spendieren

[pc1246]

@vbs
Das ist total genial! Das sollte unbedingt uebernommen werden!
Gruss Christoph

[pjakobs]

Ich hab mal versucht, einen Slave-Modus für das Modul zu basteln. Es bewirkt, dass das Gerät beliebig viele andere andere Geräte vom Typ LedController/WifiLight mitsteuert. Also alle Befehle, die man am Master ausführt, werden auch bei den Slaves ausgeführt.
Dafür gibt es das Attribut "slaves", in das man die Geräte-Namen der Slaves reinschreibt in der Syntax "<slave1> <slave2> ... <slaveN>", also mit Leerzeichen getrennt.
Man kann die HSV-Werte an den Slaves auch mit Offsets belegen mit der Syntax "<slave>:<hue-offset>,<sat-offset>,<val-offset>". Damit könnte man konfigurieren, dass zB die Helligkeit am Slave immer 20 Prozentpunkte unter der des Master liegt ("wz_lightSlave:0,0,-20") oder man möchte immer 10 Prozentpunkte mehr Sättigung "wz_lightSlave:0,10,0".

Das Ganze ist hier zu finden:
https://github.com/verybadsoldier/esp_rgbww_fhemmodule/tree/feature-slave

Bei Gefallen bzw. falls du das übernehmen möchtest, dann würde ich noch die entsprechende commandref-Doku spendieren

coole Idee!

Auch, dass Du es implementiert hast, indem Du set commands absetzt gefällt mir (statt die APIs direkt anzusprechen).
Wenn ich so darüber nachdenke wäre das eigentlich was für ein dummy device, das sonst nichts anderes tut, oder? Ich hab was ähnliches mit DOIFs implementiert. Ideal wäre da imho ein eigenes Modul, an das Du Slaves konfigurieren kannst, dann auch mit der Funktion, unterschiedliche Kommandos übersetzen zu können (groß und KLEIN schreibung).

Die Anfrage nach "gekoppelten" Controllern hatten wir ja auch schon das eine oder andere Mal, mein wirklicher Wunsch wären da MQTT Endpoints in und out, so dass ich einen Controller mit seinem Eingang auf den Ausgang eines anderen Controllers subscriben könnte. Die Lösung mit den Slave devices führt ja zu delays, die in der Event Queue von fhem liegen.

Hast Du mal getestet, was passiert, wenn Du zyklische Slaves anlegst? Sollte einen netten Disco Mode ergeben

Grundsätzlich: wenn das Feature genutzt wird, nehme ich es auf, solange es nichts anderes stört. Und da habe ich eine Bitte:
Wir haben letztens sehr viel Zeit investiert, um die Performance des Moduls zu erhöhen (wichtig vor allem bei langen Befehlsketten). So, wie die Slave Funktion aktuell eingebunden ist, wird sie bei jedem Aufruf angesprungen, egal, ob Slaves existieren oder nicht.

Also: Am liebsten wäre mir ein abstraktes Master Modul, das sich nur um solche Dinge kümmert. Der Aufwand scheint mir überschaubar.
Aber, wenn Du es hier implementieren willst schlage ich folgendes vor:
wenn Slaves konfiguriert sind: nachdem der Master Controller sein Kommando ausgeführt hat eine Schleife über alle Slaves mit "set $slave $cmd @args"
wenn "Spezialbehandlung" gewünscht ist, und nur dann, nochmal nach $cmd auffächern. Versuche die Anzahl der if() Statements im Codepfad möglichst klein zu halten und möglichst wenig Code hinzuzufügen.

was ich mir vorstelle wäre inetwa so:

Code Auswählen Erweitern


[...]
} elsif ($cmd eq 'stop') {
Log3 ($hash, 4, "$hash->{NAME}: Setting should stop");
$hash->{helper}->{shouldStop} = 1;
LedController_GetHSVColor($hash);

} elsif ($cmd eq 'update') {
LedController_GetHSVColor($hash);
}
#
# ende bestehender $cmd handler
#
if(AttrVal($hash->{NAME},"Slaves","") ne ""){
if(wie-auch-immer-spezialbehandlung-nötig){
if($cmd eq "hsv"){
LedController_SetHSVColor_Slaves();
}
if($cmd eq "rgb"){
LedController_SetRGBColor_Slaves();
}
}else}
fhem("set $SLAVES$".$cmd.@attrs)
}
}


wie gesagt: zwei Punkte sind mir wichtig:
1. darf sich das Interface ansonsten nicht verändern (das passt)
2. sollte der Performance-Impact minimal sein. Das sollte mit meinem Vorschlag hier passen (der ist natürlich als Pseudocode zu verstehen!)

aber: denk nochmal drüber nach, das vielleicht doch in ein eigenes Modul auszulagern.

Je länger ich an diesem Post schreibe, desto mehr könnt Ihr meinen Gedanken live folgen :-D

Was ich in dem Pseudocode oben vorschlage ist eigentlich genau das: ein Master.pm, allerdings in ein anderes Modul verpackt.

Wenn Du den gleichen Code, mit ein bisschen Modul Scaffolding in ein eigenes Ding baust hast Du die gleiche Funktionalität und kannst sie ggf. für alle möglichen anderen Devices verwenden.

Man könnte dann sogar zusätzliche Syntax in die Attribute einbauen, stell Dir vor

Code Auswählen Erweitern


define myMaster Master
   attr myMaster slave="LED1;hsv:HSV;rgb:RGB;on:HSV=0,0,255;off:HSV=0,0,0"

intern könntest Du dann die in ";" gepackten Übersetzungen für jedes Gerät abbarbeiten und so völlig parallel WifiLight, LedController und alles andere steuern. Vermutlich sogar Dinge, die gar nichts mit Licht zu tun haben.
Ich würde es so machen.


Grüße

pj

[vbs]

Die Anfrage nach "gekoppelten" Controllern hatten wir ja auch schon das eine oder andere Mal, mein wirklicher Wunsch wären da MQTT Endpoints in und out, so dass ich einen Controller mit seinem Eingang auf den Ausgang eines anderen Controllers subscriben könnte. Die Lösung mit den Slave devices führt ja zu delays, die in der Event Queue von fhem liegen.

hm, bin ich unsicher: Verzögerungen hättest du bei ja MQTT mMn auch, da du einen Zwischenschritt über den Broker machen musst, der auch eine gewisse Verzögerung haben wird. Wie würde für dich die Schnittstelle bei den in/out-Endpoints aussehen? Ich vermute mal, dass dann jeder Controller wissen muss (=Konfiguration), für wen er Slave und für wen er Master sein soll?

Grundsätzlich: wenn das Feature genutzt wird, nehme ich es auf, solange es nichts anderes stört. Und da habe ich eine Bitte:
Wir haben letztens sehr viel Zeit investiert, um die Performance des Moduls zu erhöhen (wichtig vor allem bei langen Befehlsketten). So, wie die Slave Funktion aktuell eingebunden ist, wird sie bei jedem Aufruf angesprungen, egal, ob Slaves existieren oder nicht.

Stört dich da generell, dass da eine Unterfunktion aufgerufen wird? Viel passiert ja in der Funktion nicht, wenn man keine Slaves konfiguriert hat. Aber ich stimme dir zu, dass man das noch auf Performance optimieren könnte.
Wann hat man bei langen Befehlsketten eigentlich ein Problem mit der Performance? Ich dachte, die werden sowieso in der Cmd-Queue des Controller abgelegt und passieren dann innerhalb des Controllers?

Also: Am liebsten wäre mir ein abstraktes Master Modul, das sich nur um solche Dinge kümmert. Der Aufwand scheint mir überschaubar.
...
Wenn Du den gleichen Code, mit ein bisschen Modul Scaffolding in ein eigenes Ding baust hast Du die gleiche Funktionalität und kannst sie ggf. für alle möglichen anderen Devices verwenden.

Hab da noch keine gute Vorstellung, was das Modul machen könnte. Könntest du das noch etwas erläutern? Ich klebe gedanklich offenbar noch an dem einfachen "ein LED-Controller steuert andere LED-Controller" während du da schon größere Pläne hast.

Aber, wenn Du es hier implementieren willst schlage ich folgendes vor:
wenn Slaves konfiguriert sind: nachdem der Master Controller sein Kommando ausgeführt hat eine Schleife über alle Slaves mit "set $slave $cmd @args"
wenn "Spezialbehandlung" gewünscht ist, und nur dann, nochmal nach $cmd auffächern. Versuche die Anzahl der if() Statements im Codepfad möglichst klein zu halten und möglichst wenig Code hinzuzufügen.

Könntes du nochmal etwas zu dem ""Spezialbehandlung" gewünscht ist, und nur dann, nochmal nach $cmd auffächern" bitte? Hab ich noch nicht ganz geblickt fürchte ich, danke!

[pjakobs]

hm, bin ich unsicher: Verzögerungen hättest du bei ja MQTT mMn auch, da du einen Zwischenschritt über den Broker machen musst, der auch eine gewisse Verzögerung haben wird. Wie würde für dich die Schnittstelle bei den in/out-Endpoints aussehen? Ich vermute mal, dass dann jeder Controller wissen muss (=Konfiguration), für wen er Slave und für wen er Master sein soll?

Meine Idee wäre, dass jeder Controller seine hsv und / oder raw werte published also etwa:
/hooks/devices/LedController/$instance/Actuals/RAW und
/hooks/devices/LedController/$instance/Actuals/HSV

und dass Du, auch für jeden Controller, eine Möglichkeit hast, Dich auf einen solchen Endpoint zu subscriben.
Du hast natürlich Recht, auch da tritt eine Latenz auf - 2x die Netzwerklaufzeit. Ich denke aber, das ist sicher weniger als das, was auftritt, wenn Du die fhem Event Queue nutzt.

Stört dich da generell, dass da eine Unterfunktion aufgerufen wird? Viel passiert ja in der Funktion nicht, wenn man keine Slaves konfiguriert hat. Aber ich stimme dir zu, dass man das noch auf Performance optimieren könnte.
Wann hat man bei langen Befehlsketten eigentlich ein Problem mit der Performance? Ich dachte, die werden sowieso in der Cmd-Queue des Controller abgelegt und passieren dann innerhalb des Controllers?

Wir haben am Anfang gesehen, dass lange Befehlsketten quasi "in einem Rutsch" bearbeitet werden. Fhem macht kein Multitasking und fhem ist eigentlich noch nicht einmal eventgesteuert (einige werden mir da widersprechen).
Im Wesentlichen gibt es eine Eventqueue auf der alles, was so passiert landed und die vom Main Loop abgearbeitet wird. Der übergibt den Event dann dem zuständigen Modul und das behält den Fokus so lange, bis der komplett verarbeitet ist.
Wenn Du eine lange Befehlskette hast (und wenn Du mit Effektlicht arbeiten willst können das ja mal 50 set's auf einen Rutsch sein), dann bleibt der Fokus so lange beim Modul, bis all diese Befehle abgearbeitet sind, danach geht er zurück an den Main Loop - so jedenfalls sah es für mich aus, als ich das letztes Jahr untersucht hatte.
Aus dem Grund wollen wir hier die Zeit, die zur Abarbeitung eines Befehls gebraucht wird möglichst kurz halten, und Christian hat da extrem viel getan.

Hab da noch keine gute Vorstellung, was das Modul machen könnte. Könntest du das noch etwas erläutern? Ich klebe gedanklich offenbar noch an dem einfachen "ein LED-Controller steuert andere LED-Controller" während du da schon größere Pläne hast.
Könntes du nochmal etwas zu dem ""Spezialbehandlung" gewünscht ist, und nur dann, nochmal nach $cmd auffächern" bitte? Hab ich noch nicht ganz geblickt fürchte ich, danke!

Im Grunde ist doch das, was Du hier vorstellst nicht LedController spezifisch.
Du hast, wenn ich das richtig sehe, ein paar Betriebsmodi:

• alle Slave Devices sollen das gleiche tun und verstehen die gleiche "Sprache" (=Befehlssysntax). In dem Fall musst Du nur durch die Slave Devices iterieren und sie mit $cmd @args aufrufen, das werden sie verstehen
• alle Slave Devices verstehen die gleiche Sprache, aber sie sollen was anderes tun. Wie Du geschrieben hast: vielleicht 10% dunkler oder 20% mehr Sättigung oder um 30% auf dem Farbkreis gedreht, kurz: irgendeine Transformation aber der eigentliche Befehl bleibt gleich Hier müsstest Du imho das Kommando "verstehen" weil die Transformation ja für rgb anders wäre als für hsv und Du müsstest die args aufsplitten und neu zusammensetzen.
• wie 2. allerdings muss auch noch die Befehlssyntax transformiert werden, z.B. von Kleinbuchstaben auf Großbuchstaben (für WifiLight etc.) Das wäre meistens eine einfacher Ersetzung

Ich glaube einfach, dass das cleaner in einem gesonderten Modul unterzubringen wäre und das LedController Modul mit einer Menge Code aufblähen würde, die mit dem Controller selbst nix zu tun hat.
Außerdem wäre es dann m.E. auch für völlig andere Devices nutzbar (z.B. Schaltergruppen oder so).

Das Modul müsste wohl folgendes tun:

Code Auswählen Erweitern


Master_set(@){
  my ($hash,$name,$cmd,@args)=@_;

  getListOfSlaves();
  for slave in @Slaves{
    if(getTransformationsForSlave(slave)){
      doTransformations($cmd,@args);
    }
    fhem("set $slave $cmd @args");
  }
}

das ist natürlich extrem vereinfacht, aber andererseits glaube ich nicht, dass es so fürchterlich schwierig sein würde, das kniffligste ist wohl eine vernünftige Transformatinssyntax, die sich gut parsen lässt und sich halbwegs lesbar in Attrs schreiben lässt.
In meinem Spritpreis Modul verwende ich nummerierte Readings, das wäre hier auch ne Möglichkeit, etwa so:

Code Auswählen Erweitern


define myLedMaster Master
  attr Slave1 <name>:orig_cmd=slave_cmd:orig_cmd=slave_cmd...
  attr Slave2 <name>:orig_cmd=slave_cmd:orig_cmd=slave_cmd...

ich weiß grad nicht, ob ich die Offsets in die gleiche Syntax pressen würde, oder dafür eigene attrs definieren möchte.

Kurzum: ich find die Idee toll und würde mich freuen, wenn Du das angehst, aber ich fürchte, im LedController würde es zum einen ne Menge Code reinbringen, die da nicht wirklich hingehört, und zum anderen die Einsatzmöglichkeiten deutlich verminder.

als eigenes Modul würdest Du dann mit einem

Code Auswählen Erweitern


set myLedMaster hsv 30,40,80

den gleichen Effekt erreichen. Ich denke, das gefällt mir besser.

Grüße

pj