WIFI LED Controller

[betateilchen]

ui ui ui... da ist aber eine Menge durcheinander im Coding...

    # Preset our readings if undefined
    my $tn = TimeNow();

    if( !defined( $hash->{READINGS}{state}{VAL} ) ) {
   $hash->{READINGS}{state}{VAL} = "?";
   $hash->{READINGS}{state}{TIME} = $tn;
    }

    if( !defined( $hash->{READINGS}{rgb}{VAL} ) ) {
   $hash->{READINGS}{rgb}{VAL} = "FFFFFF";
   $hash->{READINGS}{rgb}{TIME} = $tn;
    }
   
    if( !defined( $hash->{READINGS}{hsv}{VAL} ) ) {
   $hash->{READINGS}{rgb}{VAL} = "0 0 100";
   $hash->{READINGS}{rgb}{TIME} = $tn;
    }

    if( !defined( $hash->{READINGS}{dim}{VAL} ) ) {
   $hash->{READINGS}{dim}{VAL} = 100;
   $hash->{READINGS}{dim}{TIME} = $tn;
    }
   
    if( !defined( $hash->{READINGS}{mode}{VAL} ) ) {
   $hash->{READINGS}{mode}{VAL} = 1;
   $hash->{READINGS}{speed}{TIME} = $tn;
    }

    if( !defined( $hash->{READINGS}{speed}{VAL} ) ) {
   $hash->{READINGS}{speed}{VAL} = 250;
   $hash->{READINGS}{speed}{TIME} = $tn;

Lass mich mal ein bisschen basteln, ich bau Dir das mal "state-of-the-art" um.

[Kuzl]

oh ja stimmt da hab ich was übersehen das mit dem mode hab ich grad korrigiert

das wär cool von dir nimm dir bitte die aktuelle version von oben.

wegen dem speed... habs grade nochmal verglichen es gibt definitiv mehr als die 32 geschwindigkeiten von daher würd ich sagen das passt so.
aktualisiert sich bei mir schon beim ersten updateStatus 

[betateilchen]

Dass es mehr als 31 Geschwindigkeiten gibt, mag schon sein, aber dass die App negative Werte anzeigt, ist Kacke. Das kann nämlich der Slider in der App nicht darstellen.

Im _Define kannst Du alle Prüfungen weglassen, ob es attr oder readings schon gibt. Im Define KANN es die noch nicht geben. Und die Readings brauchst Du dort überhaupt nicht setzen, die werden von _Update gesetzt.

Probier mal mit folgendem _Define:

Code Auswählen Erweitern


sub WIFILED_Define( $$ ) {
    my ( $hash, $def ) = @_;
   
    my $name = $hash->{NAME};
   
    my @a = split("[ \t][ \t]*", $def);
   
    # do we have the right number of arguments?
    if( @a != 3 ) {
Log3 $name, 3, "WIFILED_Define: falsche Anzahl an Argumenten";
return( "wrong syntax: define <name> WIFILED <serverip> " );
    }
   
    # preset the internals
    $hash->{IP} = $a[ 2 ];

    $hash->{helper}{RED}   = 255;
    $hash->{helper}{GREEN} = 255;
    $hash->{helper}{BLUE}  = 255;

$attr{$name}{timeout} = 2;
$attr{$name}{updateIntervall} = 60;
$attr{$name}{verbose} = 3;

WIFILED_Update($hash);

return undef;
}


Bei updateIntervall solltest Du das zweite l am Ende streichen (Achtung: Auch im Initialize anpassen!)

Ausserdem brauchst Du eine Forward-Deklaration der _Update:

Code Auswählen Erweitern


#global Variable
my $offset = 36;

sub WIFILED_Update($);


[Kuzl]

hab ich geändert und funktioniert wunderbar dankeschön
also meine App zeigt dann einfach geschwindigkeit 1 an. Abgesehen davon finde ich es nicht gut, wenn wir den funktionsumfang des Moduls aufgrund der App einschränken. Ich finde auch Geschwindigkeit 1 der App immer noch zu schnell für angenehm fließende Übergänge

PS: Version oben ist aktualisiert

EDIT: Meine App-Version ist 2.1.0; was hast du für eine?

[betateilchen]

Du hast die Funktion der readings*Update Funktionen noch nicht verstanden, deshalb gibt es eine Menge Warnungen im Log.

Code Auswählen Erweitern


Use of uninitialized value in string ne at ./FHEM/98_WIFILED.pm line 461.
Use of uninitialized value in string ne at ./FHEM/98_WIFILED.pm line 466.
Use of uninitialized value in string ne at ./FHEM/98_WIFILED.pm line 467.
Use of uninitialized value in string ne at ./FHEM/98_WIFILED.pm line 468.
Use of uninitialized value in string ne at ./FHEM/98_WIFILED.pm line 469.
Use of uninitialized value in string ne at ./FHEM/98_WIFILED.pm line 433.



Beispiel:

Code Auswählen Erweitern


sub WIFILED_UpdateRGB( $ ) {
    my ( $hash, @rest )  = @_;
    my $name = $hash->{NAME};

    my $buf = sprintf( "%02X%02X%02X",
       $hash->{helper}{RED},
       $hash->{helper}{GREEN},
       $hash->{helper}{BLUE} );
   
    if ( $hash->{READINGS}{rgb}{VAL} ne uc($buf)){
readingsSingleUpdate( $hash, "rgb", uc($buf), 1 );
CommandTrigger( "", "$hash->{NAME} RGB: $buf" );
}

    return;
}


macht keinen Sinn.

• Du brauchst nicht prüfen, ob der Wert sich geändert hat, das macht readingsSingleUpdate() automatisch
• Du brauchst kein CommandTrigger absetzen, das macht der Parameter 1 als vierter Parameter beim Funktionsaufruf readingsSingleUpdate

Also einfach so:

Code Auswählen Erweitern


sub WIFILED_UpdateRGB( $ ) {
    my ( $hash, @rest )  = @_;
    my $name = $hash->{NAME};

    my $buf = sprintf( "%02X%02X%02X",
       $hash->{helper}{RED},
       $hash->{helper}{GREEN},
       $hash->{helper}{BLUE} );

    readingsSingleUpdate( $hash, "rgb", $buf, 1 );

    return;
}


Die Konvertierung in Großbuchstaben

Code Auswählen Erweitern

uc($buf)

kannst Du auch weglassen, das erledigt sprintf() bereits, da Du dort mit dem großen X bereits festgelegt hast, dass Du Großbuchstaben in HEX-Werten haben willst.

Ähnliche Punkte gibt es in diesen Zeilen zu ändern:

Code Auswählen Erweitern


      readingsSingleUpdate( $hash, "hsv", $hsv_reading, 1 )                   if ( $hash->{READINGS}{hsv}{VAL} ne $hsv_reading);
      readingsSingleUpdate( $hash, "mode", hex( $colors[ 3 ] ) - $offset, 1 ) if ( $hash->{READINGS}{mode}{VAL} ne hex( $colors[ 3 ] ) - $offset );
      readingsSingleUpdate( $hash, "dim", $dim->{bri}, 1 )                    if ( $hash->{READINGS}{dim}{VAL} ne $dim->{bri} );
      readingsSingleUpdate( $hash, "speed", 255 - hex(  $colors[ 5 ] ), 1 )          if ( $hash->{READINGS}{speed}{VAL} ne 255 - hex( $colors[ 5 ] ) );


Aber den korrekten Umbau kriegst Du nach meinen obigen Hinweisen sicher selbst hin

[Kuzl]

Habs ausprobiert, wenn ich die if-Abfrage weglasse, wird bei jedem update das Reading aktualisiert, auch wenn es bereits das gleiche beinhaltet. Das erzeugt dann unnötig events jede Minute (wenn es auf 60 sec gestellt ist). Ich denke die Warnungen kommen, wenn das reading noch nie gesetzt war und ich mit dem Reading vergleichen will weil dann mit dem undefinierten Reading verglichen wird.

Also doch wieder im define die Readings mit Standartwerten beschreiben?

CommandTrigger benötigt der colorpicker, da er im moment noch explizit ein "RGB" event benötigt (RGB muss großgeschrieben sein).

das uc wird rausgeschmissen - hab ich nicht gewusst danke.

[betateilchen]

Sorry, Du hast recht mit den events, da war ich in Gedanken an einer anderen Stelle.

Trotzdem:

Also doch wieder im define die Readings mit Standartwerten beschreiben?

Auf keinen Fall. Und auch bitte die Vergleiche nicht wieder einbauen!

Falls sich ein Anwender an den events stört, kann er die jederzeit individuell mit "event-on-change" begrenzen. Genau DAS ist ja der Sinn der readingsFnAttr und readings*Update Funktionen. Bei mir steht das Updateintervall ohnehin auf 900 Sekunden, mich stört das nicht, zumal ich ja nach einer Änderung per Befehl ohnehin ein update bekomme. Und ohne Steuerbefehel sollte sich an den readings ohnehin nichts ändern.

CommandTrigger benötigt der colorpicker, da er im moment noch explizit ein "RGB" event benötigt (RGB muss großgeschrieben sein).

Dafür muss es auch eine bessere Lösung geben. Ich schau mal nach.

[betateilchen]

CommandTrigger benötigt der colorpicker, da er im moment noch explizit ein "RGB" event benötigt (RGB muss großgeschrieben sein).

Ich hab die Frage mal weitergeleitet: http://forum.fhem.de/index.php/topic,29656.msg224037.html

[justme1968]

um den colorpicker auf einer bereits sichtbaren seite aktualisieren zu können muss fhem ein event erzeugen das dann per longpoll an den browser geht. dieses event zu erzeugen ist zur zeit auf zwei arten möglich: entweder ein reading aktualisieren oder ein per trigger eines erzeugen.

im colorpicker ist zur zeit der name des events noch hart kodiert. ich werde das noch ändern bin aber nicht dazu gekommen.

gruss
  andre

[Kuzl]

Falls sich ein Anwender an den events stört, kann er die jederzeit individuell mit "event-on-change" begrenzen.

Stimmt, das hatte ich total vergessen.

Die Lösung für den colorpicker, die mir einfallen würde, ist das set und das reading auch "RGB" zu nennen aber das passt dann halt nicht mehr so richtig zum rest

@andre: Dankeschön dann kann man den trigger bald mal rausschmeissen

[Kuzl]

Ich denke, ich/wir könnten anfangen die userdefinierten animationen einzubauen.
die überlegung ist nur WIE kann man das halbwegs angenehm für den anwender machen.
Ich hab an sowas gedacht wie "set anim FF0000 00FF00 0000FF 2 20" wobei die farben zwischen 2 und 16 sein können, "2" der Modus ist also strobe hart oder faden und 20 die geschwindigkeit wieder optional.

Was denkst du?

[betateilchen]

Kann man schon so machen. Aber in diesem Fall würde ich die Geschwindigkeit nicht optional machen, sie beschreibt die Animation grundsätzlich und gehört deshalb immer dazu.

Ich überlege grade, ob es nicht irgendwo auch noch einen Parameter für die "Pause" zwischen der Animationswiederholung gab, kann aber sein, dass ich das grade komplett mit etwas anderem verwechsle.

Mit dem Thema "speed" bin ich übrigens immer noch nicht ganz glücklich. Irgendwie arbeitet der Controller nach einem "off" und anschließendem "on" zwar den eingestellten Modus weiter ab, aber mit einer unterschiedlichen Geschwindigkeit als vor dem Ausschalten.

[justme1968]

ich hab eben eine geänderte version des colorpicker eingecheckt. damit kann das trigger auf RGB entfallen wenn es ein reading gibt das genau so heisst wie das set kommando.

für die animationen ein vorschlag. ich weiss aber nicht ob das auf euer device passt:

für das swap rgb board habe ich 16 'register' im device definiert. jedes register enthält eine rgb farbe und die zeit die bis zum erreichen der farbe verstreichen soll. diese register kann man jetzt von fhem aus als einfache presets verwenden oder man kann sagen starte eine loop über alle register von r1-r2.

gruss
  andre

[betateilchen]

Hallo Andre,

man kann vieles machen, aber lassen wir doch Kuzl erstmal noch ein bisschen mehr Verständnis für Programmierung in fhem aneignen, man ist da glaub ich grade auf einem guten Weg, wenn eigene Ideen umgesetzt werden und Erfolgserlebnisse eintreten. Verbessern kann man so ein Modul immer. Im Moment finde ich den Ansatz mit dem "set anim ..." schonmal sehr gut.

Danke für die Änderungen am colorpicker.

[Kuzl]

Danke für die schnelle Änderung

die Idee mit den Registern ist echt ganz gut, nur für mich glaub ich nicht so schnell ohne sehr viel Hilfe umsetzbar
Ich werde jetzt erst versuchen das mit dem einfachen set hinzubekommen und dann anschließend kann man es ja noch auf die Register umbauen

Bezüglich speed- also bei mir bleibt die vorher eingestellte geschwindikeit erhalten. nur wenn ich in der app den mode ändere wird auch die geschwindigkeit mit der aus der app überschrieben.

einen Pause-Parameter konnte ich nicht finden. Mich würde allerdings interessieren wie man einen anderen Speicherplatz des controllers für die animation belegt. standardmäßig wenn man es nicht "abspeichert" ist es ja anscheinend 21; also einfach die nächste nach den voreingestellten.