Neue Features - $SELF, $self, cmd-Reading, timerevent, selftrigger ...

[satprofi]

Ich habe Version 0.3 im ersten Post angehängt.

Ich habe das letzte Problem bei der Zeitumstellung korrigiert.

Desweiteren habe ich den Einleitungstext in der Doku umgeschrieben. In der Hoffnung, dass es jetzt auch für Einsteiger verständlicher ist.


Gruß

Damian

Hallo.
Wo findet man die Doku? Bin leider Neuling bei diesen neuen Möglichkeiten.

gruss

[Damian]

Ich habe die letzte Version eingecheckt, damit ist morgen auch die Doku weltweit verfügbar.

Gruß

Damian

[Damian]

Wäre es möglich, wenn nur ein Eintrag (trotz mehrerer Sequenzen) existiert, diesen für den ganzen Zweig zu nehmen? Damit blieb die Abwärtskompatibilität erhalten. Wer wirklich explizit keinen Namen vergeben will, kann ja mit leeren Einträgen arbeiten. Aber das dürfte im rein akademischen Bereich angesiedelt sein.

Ich habe die Mimik beim wait bei Befehlssequenzen geändert:

alt: wait 1,1,1,1,1:1,1,1,1 entspricht jetzt neu: wait 1:1

alt wait 1:1 entspricht jetzt neu: wait 1,0,0...:1,0,0...

bitte schreien, wenn jemand Bedenken hat, sonst checke ich diese Version ein.

Gruß

Damian

[Ellert]

Auf keinen Fall einschecken, dann muss ich alle ausgelassenen Timer finden für Sequenzen, die keine Verzögerung haben sollen, weil ich nur den Zwischenzustand benötige 

[Damian]

Auf keinen Fall einschecken, dann muss ich alle ausgelassenen Timer finden für Sequenzen, die keine Verzögerung haben sollen, weil ich nur den Zwischenzustand benötige 

Wozu brauchst du Zwischenzustände ohne Verzögerung?

[Per]

alt: wait 1,1,1,1,1:1,1,1,1 entspricht jetzt neu: wait 1:1

alt wait 1:1 entspricht jetzt neu: wait 1,0,0...:1,0,0...

Ist zumindest logisch.
Wäre wait 1,0:1 dann gleich wait 1,0,0,0...:1,1,1...?
Und gilt das (vorerst?) nur bei wait (wg. cmdState)?

[Ellert]

Wozu brauchst du Zwischenzustände ohne Verzögerung?

Mehr ist mir vor Schreck heute morgen, nach dem ich kurz gelesen hatte, weil ich nicht schlafen konnte, nicht eingefallen.

Ich kann erhlich gesagt nicht abschätzen, ob durch die Änderung Timer gesetzt werden, die unerwünscht sind.
Die Frage ist, kann es Gründe geben, Sequenzen zu verwenden ohne Timer?
Wenn ja, wie kann man das nachträglich leicht erkennen und entsprechen des neuen Verhalten nachpflegen?

Ich finde es nicht intuitiv, mit der Angabe von einem Timer, eine weitere Zahl von versteckten Timern zu setzen. Das wirkt irgendwie unübersichtlich.

Welche Timer würden gesetzt, wenn ich 6 Sequenzen habe und wait 1,4 angebe?
1,4,4,4,4,4 oder
1,4,1,4,1,4 oder
1,4,1,1,1,1

Wenn die Timer beim Setzen des Attributes ergänzt würden, dann bliebe die Übersichtlichkeit erhalten, so dass

Code Auswählen Erweitern

attr doif wait 1 zu

Code Auswählen Erweitern

attr doif wait 1,1,1,1,1,1 ergänzt wird, je nach Zahl der Sequenzen in der DOIF-Definition

[Damian]

Keine Panik, wenn es zu Kompatibilitätsproblemen führen sollte, dann lasse ich es

Zur Idee:

Es ist sicherlich nicht ganz einheitlich, denn bei wait ohne Sequenz wird kein Timer gesetzt, wenn man wait-Angaben auslässt.

Allerdings:

Befehlssequenzen werden normalerweise gebildet, weil man eine Verzögerung beabsichtigt, ansonsten sollte man sogar aus Performance-Gründe Befehlskette erst gar nicht aufgespalten - unnötige Zwischenzustände produzieren unnötige Ereignisse.
Umgekehrt heißt das, jede Befehlssequenz sollte einen Waittimer haben - auslassen macht keinen Sinn. Auf der anderen Seite möchte man evtl. überall gleiche Verzögerungen haben und dafür wäre die verkürzte Schreibweise sinnvoll.


1,4  bedeutet 1,4,1,1,1,...

1,2,3,4 bedeutet 1,2,3,4,1,1,1,1...

1,,,,,2,,,3 bedeutet 1,1,1,1,2,1,1,3

Allgemein kann man sagen, wenn man etwas weglässt, dann wird der erste Wert genommen.

Gruß

Damian

[Ralli]

1,4  bedeutet 1,4,1,1,1,...

1,2,3,4 bedeutet 1,2,3,4,1,1,1,1...

1,,,,,2,,,3 bedeutet 1,1,1,1,2,1,1,3

Allgemein kann man sagen, wenn man etwas weglässt, dann wird der erste Wert genommen.

Mmh, das finde ich aber jetzt auch nicht so eingängig. Wenn schön Änderung, dann wäre m.E. eher sinnvoll, dass der letzte Wert vor einer Weglassung weiter verwendet wird. Also:

1,4  bedeutet 1,4,4,4,4,...

1,2,3,4 bedeutet 1,2,3,4,4,4,4,4...

1,,,,,2,,,3 bedeutet 1,1,1,1,2,2,2,3,3,3,3,3....

[Ellert]

Beim Durchsehen meiner Wait-Timer habe ich festgestellt, dass viele Timer mit "0" bzw, "," beginnen, weil die erste Sequenz nicht verzögert werden muss.
In solchen Fällen wäre es sinnvoller die jeweils letzte angegebene Zahl fortzuschreiben, wie Ralli vorschlägt.

Grundsätzlich sehe ich bei meinen DOIF keine Unverträglichkeit mit der neuen Eigenschaft des Wait-Attributes.

[Damian]

Beim Durchsehen meiner Wait-Timer habe ich festgestellt, dass viele Timer mit "0" bzw, "," beginnen, weil die erste Sequenz nicht verzögert werden muss.
In solchen Fällen wäre es sinnvoller die jeweils letzte angegebene Zahl fortzuschreiben, wie Ralli vorschlägt.

Grundsätzlich sehe ich bei meinen DOIF keine Unverträglichkeit mit der neuen Eigenschaft des Wait-Attributes.

Ich sehe schon, solche Besonderheiten verwirren mehr als sie womöglich nützen. Im Hinblick auf die Kompatibilität, wird wohl das Beste sein alles beim Alten zu belassen.

Gruß

Damian

[Ellert]

Eine sinnvolle Erweiterung des DOIF wäre vielleicht ein leichteres Auslesen der wait-Angaben im DOIF.

Wenn man z.B. Farbwechsel für ein HUE-Device programmieren möchte, dann enthält der set-Befehl eine Transitionszeit in 100 Millisekunden.
Bei mehrstufigen Farbwechsel muss die Transitionszeit abgelaufen sein und dann der nächste Befehl gestartet werden.
Wenn DOIF eine Funktion zur Verfügung stellen würde, dann könnte man die wait-Angaben leichter als Transitionszeit nutzen.

Beispiel

Code Auswählen Erweitern

(set meinHUE hue 1000 : sat 254 : bri 25 : transitiontime {(wait($SELF,0,1)*10)}) ##Wartezeit 0 Transitionszeit 10
(set meinHUE hue 7300 : sat 254 : bri 15 : transitiontime {(wait($SELF,0,2)*10)}) ##Wartezeit 10 Transitionszeit 20
(set meinHUE hue 47104 : sat 230 : bri 15 : transitiontime {(wait($SELF,0,3)*10)}) ##Wartezeit 20 Transitionszeit 30
(set meinHUE hue 47104 : sat 230 : bri 1 : transitiontime {(wait($SELF,0,4)*10)}) ##Wartezeit 30 Transitionszeit 40
(set meinHUE off) ##Wartezeit 40

wait 0,10,20,30,40

Man könnte die Funktion natürlich auch in die 99_myUtils.pm schreiben.

Code Auswählen Erweitern

############## Liefert die Zeitangabe aus dem wait des DOIF
#Parameter: <Name des DOIF>, <Nr. des Bedingungszweiges>, <Nr. der Sequenz des Bedingungszweiges> Die Zählung beginnt bei 0
sub wait {
my ($me,$row,$col) = @_;
my @rows = split(":",AttrVal($me,"wait",0));
my @cols = split(",",$rows[$row]);
return $cols[$col];


Das könnte natürlich auch zu speziell sein.

[Damian]

Eine sinnvolle Erweiterung des DOIF wäre vielleicht ein leichteres Auslesen der wait-Angaben im DOIF.

Wenn man z.B. Farbwechsel für ein HUE-Device programmieren möchte, dann enthält der set-Befehl eine Transitionszeit in 100 Millisekunden.
Bei mehrstufigen Farbwechsel muss die Transitionszeit abgelaufen sein und dann der nächste Befehl gestartet werden.
Wenn DOIF eine Funktion zur Verfügung stellen würde, dann könnte man die wait-Angaben leichter als Transitionszeit nutzen.

Beispiel

Code Auswählen Erweitern

(set meinHUE hue 1000 : sat 254 : bri 25 : transitiontime {(wait($SELF,0,1)*10)}) ##Wartezeit 0 Transitionszeit 10
(set meinHUE hue 7300 : sat 254 : bri 15 : transitiontime {(wait($SELF,0,2)*10)}) ##Wartezeit 10 Transitionszeit 20
(set meinHUE hue 47104 : sat 230 : bri 15 : transitiontime {(wait($SELF,0,3)*10)}) ##Wartezeit 20 Transitionszeit 30
(set meinHUE hue 47104 : sat 230 : bri 1 : transitiontime {(wait($SELF,0,4)*10)}) ##Wartezeit 30 Transitionszeit 40
(set meinHUE off) ##Wartezeit 40

wait 0,10,20,30,40

Man könnte die Funktion natürlich auch in die 99_myUtils.pm schreiben.

Code Auswählen Erweitern

############## Liefert die Zeitangabe aus dem wait des DOIF
#Parameter: <Name des DOIF>, <Nr. des Bedingungszweiges>, <Nr. der Sequenz des Bedingungszweiges> Die Zählung beginnt bei 0
sub wait {
my ($me,$row,$col) = @_;
my @rows = split(":",AttrVal($me,"wait",0));
my @cols = split(",",$rows[$row]);
return $cols[$col];


Das könnte natürlich auch zu speziell sein.

ja, genauso gut könnten Berechnungen bezogen auf den Vorgänger interessant sein. Wenn es z. B. ein Reading mit dem aktuellen Wait-Wert gäbe (Standard 0), dann könnte man mit der neuen Version (die ich ja jetzt nicht eingecheckt habe) definieren:

erhöhe Timer einer Sequenz immer um 10:

Code Auswählen Erweitern

attr di wait [$SELF:wait]+10


Mit dem Vorschlag von Ralli ginge dann auch

starte mit einer Sekunde und verdopple jeweils die Zeit:

Code Auswählen Erweitern

attr di wait 1,2*[$SELF:wait]

Übrigens für myUtils bietet sich statt split die Funktion SplitDoIf an. Im Gegensatz zu perl-split ist bei SplitDoIf das angegebene Trennzeichen innerhalb irgendwelcher Klammern geschützt, denn Komma oder Doppelpunkt können bei wait nicht nur als Trennzeichen vorkommen.

Gruß

Damian

[Ellert]

Die Idee ein Reading zu nutzen, statt einer Funktion ist auch praktisch.
Um die Transitionszeit zu unterstützen, müsste es  ein Reading nextwait geben, da die Transitionszeit die Verzögerungszeit des nächsten Befehls ist.
Bisher hat DOIF ja auch keine Funktionssammlung bereitgestellt.

Mir fehlt im Moment die Vorstellung, wann ich wait-Werte einsetzen könnte, die sich als Reihe oä. entwickeln.

Danke für den Tipp mit SpliDoIf.

[Damian]

Mir fehlt im Moment die Vorstellung, wann ich wait-Werte einsetzen könnte, die sich als Reihe oä. entwickeln.

Eine Dynamik könnte ich mir bei Benachrichtigungen vorstellen: je länger ein  Ereignis zurückliegt, desto größer der Benachrichtigungsabstand, z. B. bei Fenster-offen-Meldung. Anfangs öfters, da neu, später seltener, da bereits bekannt, um nicht den Log zuzumüllen.

Gruß

Damian