Neue Features:
Attribut selftrigger erlaubt Selbsttriggerung über Wait
Attribut timerevent erzeugt Events beim Setzen von Timern
Für Attribute: cmdpause, repeatcmd, repeatsame, waitsame, waitdel, wait können nun Berechnungen mit Angabe von Readings , Stati, Perl-Funktionen durchgeführt werden. Das Trennzeichen Doppelpunkt oder Komma innerhalb von Klammern und Anführungszeichen ist geschützt und gilt dort nicht als Trennzeichen.
Beispiel:
attr my_di repeatcmd myfunc():Attr("device","attr",""):[mydevice:myreading]*10
cmdState kann nun auch für Sequenzen cmd1_1, cmd1_2 usw. benutzt werden, es sind ebenfalls Angaben von Readings, Stati und Perlfunktionen möglich.
Beispiel:
attr my_di cmdState erster [mydevice:myreading], zweiter {([mydevice:myreading]*2)}|"Text für cmd2, Komma als Trennzeichen oder Pipe-Zeichen | lässt sich innerhalb von Anführungszeichen schützen"
attr my_di state Der Status lautet [my_di]
Doku muss noch aktualisiert werden.
Gruß
Damian
Zitat von: Damian am 19 März 2016, 22:12:40cmdState kann nun auch für Sequenzen cmd1_1, cmd1_2 usw. benutzt werden
Das geht schonmal :D
Ich bin immer wieder begeistert, wie manche den Überblick behalten, ich habe schon bei der Anwendung von DOIF meine Problem...
Neue Version im ersten Post:
Auszug aus der Doku:
Zitat
Status des Moduls back
Der Status des Moduls wird standardmäßig mit cmd_1, cmd_2, usw., bzw. cmd1_1 cmd1_2 usw. für Befehlssequenzen belegt. Dieser lässt sich über das Attribut "cmdState" mit Komma bzw. | getrennt umdefinieren:
attr <DOIF-modul> cmdState <Status für cmd1_1>,<Status für cmd1_2>,...| <Status für cmd2_1>,<Status für cmd2_2>,...|...
Beispiele:
attr di_lamp cmdState on|off
Pro Status können ebenfalls Stati oder Readings in eckigen Klammern oder Perlfunktionen sowie Berechnungen in Klammern der Form {(...)} angegeben werden.
Die Trennzeichen Komma und | sind in Klammern und Anführungszeichen geschützt und gelten dort nicht als Trennzeichen.
Zustände cmd1_1, cmd1 und cmd2 sollen wie folgt umdefiniert werden:
attr di_mytwilight [mytwilight:ss_astro], {([mytwilight:twilight_weather]*2+10)}|My attribut is: {(Attr("mydevice","myattr",""))}
...
Readingauswertung nur beim Event des jeweiligen Readings back
Standardmäßig werden angegebene Readings ausgewertet, wenn irgend ein Event des angegebenen Devices triggert. Möchte man gezielt nur dann ein angegebenes Reading auswerten, wenn sich nur dieses ändert, so lässt sich das mit dem Attribut checkReadingEvent einschränken.
Beispiel:
define di_lamp ([[mytwilight:ss_weather]])(set lamp on)
attr di_lamp do always
attr di_lamp checkReadingEvent 1
Ohne checkReadingEvent, würde alle fünf Minuten die Einschaltzeit der Lampe neu gesetzt werden, da das twilight-Modul regelmäßig andere Reading wie z. B. das light-Reading ändert und damit Events erzeugt. Durch die Angabe des Attributes checkReadingEvent wird die Zeit nur dann neu gesetzt, wenn sich tatsächlich das Reading ss_weather ändert.
Eindeutige Statuserkennung back
Bei Änderungen des Readings state wird in FHEM standardmäßig, im Gegensatz zu allen anderen Readings, der Readingname hier: "state: " im Event nicht vorangestellt. Möchte man eindeutig eine Statusänderung eines Moduls erkennen, so lässt sich das mit dem Attribut addStateEvent bewerksteligen. Bei Statusänderungen eines Devices wird bei der Angabe des Attributes addStateEvent im Event "state: " vorangestellt, darauf kann man dann gezielt im DOIF-Modul triggern.
Beispiel:
define di_lamp ([FB:"^state: on$"]) (set lamp on)
attr di_lamp do always
attr di_lamp addStateEvent
Triggerung durch selbst ausgelöste Events back
Standardmäßig unterbindet das DOIF-Modul Selbsttriggerung. D. h. das Modul reagiert nicht auf Events, die es selbst direkt oder indirekt auslöst.
Wenn das Attribut selftrigger ungleich Null gesetzt ist, kann das DOIF-Modul auf selbst ausgelöste Events reagieren. Dazu müssen die entsprchenden Kommandos mit wait verzögert werden.
Setzen der Timer mit Event back
Wenn das Attribut timerevent ungleich Null gesetzt ist, wird beim Setzen der Timer im DOIF-Modul ein Event erzeugt. Das kann z. B. bei FHEM2FHEM nützlich sein, um die Timer-Readings zeitnah zu aktualisieren.
Gruß
Damian
ZitatMöchte man gezielt nur dann ein angegebenes Reading auswerten, wenn sich nur dieses ändert, so lässt sich das mit dem Attribut checkReadingEvent einschränken.
Betrifft das tatsächlich nur Änderungen oder auch Aktualisierungen des Readings?
Zitat von: Ellert am 25 März 2016, 10:58:18
Betrifft das tatsächlich nur Änderungen oder auch Aktualisierungen des Readings?
Beides.
Hallo Damian,
ich habe die Kurzreferenz angepasst.
Grundlage ist die Version hier aus dem 1. Beitrag, runtergeladen am 25.3.
Schöne Feiertage
Ellert
Zitat von: Ellert am 26 März 2016, 13:47:06
Hallo Damian,
ich habe die Kurzreferenz angepasst.
Grundlage ist die Version hier aus dem 1. Beitrag, runtergeladen am 25.3.
Schöne Feiertage
Ellert
OK. Ich habe es übernommen.
Gruß
Damian
Was man vielleicht noch erwähnen sollte: In der dieser Version wird Zeilenumbruch \n gegen ein Leerzeichen ersetzt.
Damit braucht man kein Leerzeichen am Zeilenende anzugeben. Das musste man insb. in der Bedingung bei and oder or Operatoren bisher tun.
Gruß
Damian
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.
Edit:
Hatte vergessen zu schreiben, dass Angaben bei allen Attributen mit Sekundenangaben erweitert wurden.
Auszug aus Doku zu wait:
ZitatStatt Sekundenangaben können ebenfalls Stati, Reading in eckigen Klammen Perl-Funktionen sowie Perl-Berechnung angegeben werden. Dabei werden die Trennzeichen Komma und Doppelpunkt in Klammern geschützt und gelten dort nicht als Trennzeichen.<br>
Diese Angaben können ebenfalls bei folgenden Attributen gemacht werden: cmdpause, repeatcmd, repeatsame, waitsame, waitdel<br>
Gruß
Damian
Hinweis am Rande:
PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/98_DOIF.pm line 1158.
...
PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 207.
...
PERL WARNING: Use of uninitialized value $_ in pattern match (m//) at ./FHEM/98_DOIF.pm line 942.
...
PERL WARNING: substr outside of string at ./FHEM/98_DOIF.pm line 127.
PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 210
Bei mir hat sich etwas zum Vorteil geändert, was ich mir aber nicht erklären kann. Ich habe ein DOIF welches alle 60 Sekunden eine Überprüfung vornimmt. Aber zu 99% muss das DOIF keine Umschaltung vom cmd_1 auf cmd_2 oder ähnliches vornehmen. Dennoch wurde das Log vollgemüllt. Mit der neuen Version bleibt das Log plötzlich leer. Schön, aber vielleicht nicht richtig?
Und es spielt keine Rolle ob mit "checkReadingEvent" oder ohne.
2016-03-31_14:00:03 di_zustandsanzeige timer_1_c1: 31.03.2016 14:01:03
2016-03-31_14:00:03 di_zustandsanzeige timer_2_c2: 31.03.2016 14:01:03
2016-03-31_14:01:03 di_zustandsanzeige timer_1_c1: 31.03.2016 14:02:03
2016-03-31_14:01:03 di_zustandsanzeige timer_2_c2: 31.03.2016 14:02:03
2016-03-31_14:02:03 di_zustandsanzeige timer_1_c1: 31.03.2016 14:03:03
2016-03-31_14:02:03 di_zustandsanzeige timer_2_c2: 31.03.2016 14:03:03
2016-03-31_14:03:03 di_zustandsanzeige timer_1_c1: 31.03.2016 14:04:03
2016-03-31_14:03:03 di_zustandsanzeige timer_2_c2: 31.03.2016 14:04:03
2016-03-31_14:04:03 di_zustandsanzeige timer_1_c1: 31.03.2016 14:05:03
2016-03-31_14:04:03 di_zustandsanzeige timer_2_c2: 31.03.2016 14:05:03
2016-03-31_14:05:03 di_zustandsanzeige timer_1_c1: 31.03.2016 14:06:03
2016-03-31_14:05:03 di_zustandsanzeige timer_2_c2: 31.03.2016 14:06:03
2016-03-31_14:06:03 di_zustandsanzeige timer_1_c1: 31.03.2016 14:07:03
2016-03-31_14:06:03 di_zustandsanzeige timer_2_c2: 31.03.2016 14:07:03
2016-03-31_14:07:03 di_zustandsanzeige timer_1_c1: 31.03.2016 14:08:03
2016-03-31_14:07:03 di_zustandsanzeige timer_2_c2: 31.03.2016 14:08:03
2016-03-31_14:08:03 di_zustandsanzeige timer_1_c1: 31.03.2016 14:09:03
2016-03-31_14:08:03 di_zustandsanzeige timer_2_c2: 31.03.2016 14:09:03
2016-03-31_14:09:03 di_zustandsanzeige timer_1_c1: 31.03.2016 14:10:03
2016-03-31_14:09:03 di_zustandsanzeige timer_2_c2: 31.03.2016 14:10:03
2016-03-31_14:10:03 di_zustandsanzeige timer_1_c1: 31.03.2016 14:11:03
2016-03-31_14:10:03 di_zustandsanzeige timer_2_c2: 31.03.2016 14:11:03
2016-03-31_14:11:03 di_zustandsanzeige timer_1_c1: 31.03.2016 14:12:03
2016-03-31_14:11:03 di_zustandsanzeige timer_2_c2: 31.03.2016 14:12:03
2016-03-31_14:12:03 di_zustandsanzeige timer_1_c1: 31.03.2016 14:13:03
2016-03-31_14:12:03 di_zustandsanzeige timer_2_c2: 31.03.2016 14:13:03
Zitat von: FunkOdyssey am 31 März 2016, 14:16:25
Hinweis am Rande:
PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 207.
PERL WARNING: Use of uninitialized value $_ in pattern match (m//) at ./FHEM/98_DOIF.pm line 942.
Wie sieht die dazugehörige Definition aus?
Zitat
Bei mir hat sich etwas zum Vorteil geändert, was ich mir aber nicht erklären kann. Ich habe ein DOIF welches alle 60 Sekunden eine Überprüfung vornimmt. Aber zu 99% muss das DOIF keine Umschaltung vom cmd_1 auf cmd_2 oder ähnliches vornehmen. Dennoch wurde das Log vollgemüllt. Mit der neuen Version bleibt das Log plötzlich leer. Schön, aber vielleicht nicht richtig?
Und es spielt keine Rolle ob mit "checkReadingEvent" oder ohne.
2016-03-31_14:00:03 di_zustandsanzeige timer_1_c1: 31.03.2016 14:01:03
2016-03-31_14:00:03 di_zustandsanzeige timer_2_c2: 31.03.2016 14:01:03
2016-03-31_14:01:03 di_zustandsanzeige timer_1_c1: 31.03.2016 14:02:03
2016-03-31_14:01:03 di_zustandsanzeige timer_2_c2: 31.03.2016 14:02:03
2016-03-31_14:02:03 di_zustandsanzeige timer_1_c1: 31.03.2016 14:03:03
2016-03-31_14:02:03 di_zustandsanzeige timer_2_c2: 31.03.2016 14:03:03
2016-03-31_14:03:03 di_zustandsanzeige timer_1_c1: 31.03.2016 14:04:03
2016-03-31_14:03:03 di_zustandsanzeige timer_2_c2: 31.03.2016 14:04:03
2016-03-31_14:04:03 di_zustandsanzeige timer_1_c1: 31.03.2016 14:05:03
2016-03-31_14:04:03 di_zustandsanzeige timer_2_c2: 31.03.2016 14:05:03
2016-03-31_14:05:03 di_zustandsanzeige timer_1_c1: 31.03.2016 14:06:03
2016-03-31_14:05:03 di_zustandsanzeige timer_2_c2: 31.03.2016 14:06:03
2016-03-31_14:06:03 di_zustandsanzeige timer_1_c1: 31.03.2016 14:07:03
2016-03-31_14:06:03 di_zustandsanzeige timer_2_c2: 31.03.2016 14:07:03
2016-03-31_14:07:03 di_zustandsanzeige timer_1_c1: 31.03.2016 14:08:03
2016-03-31_14:07:03 di_zustandsanzeige timer_2_c2: 31.03.2016 14:08:03
2016-03-31_14:08:03 di_zustandsanzeige timer_1_c1: 31.03.2016 14:09:03
2016-03-31_14:08:03 di_zustandsanzeige timer_2_c2: 31.03.2016 14:09:03
2016-03-31_14:09:03 di_zustandsanzeige timer_1_c1: 31.03.2016 14:10:03
2016-03-31_14:09:03 di_zustandsanzeige timer_2_c2: 31.03.2016 14:10:03
2016-03-31_14:10:03 di_zustandsanzeige timer_1_c1: 31.03.2016 14:11:03
2016-03-31_14:10:03 di_zustandsanzeige timer_2_c2: 31.03.2016 14:11:03
2016-03-31_14:11:03 di_zustandsanzeige timer_1_c1: 31.03.2016 14:12:03
2016-03-31_14:11:03 di_zustandsanzeige timer_2_c2: 31.03.2016 14:12:03
2016-03-31_14:12:03 di_zustandsanzeige timer_1_c1: 31.03.2016 14:13:03
2016-03-31_14:12:03 di_zustandsanzeige timer_2_c2: 31.03.2016 14:13:03
Das Setzen der Timer erzeugt keine Events, wenn man das neue Attribut "timerevent" nicht gesetzt hat.
Das sieht nicht nach der neuen Version aus.
Gruß
Damian
Ich hatte in letzter Zeit hier im Forum über verschiedene DOIF-Probleme berichtigt und diese wohl in diesem Thread ein wenig verwechselt.
checkReadingEvent ist also dafür, wenn ich das DOIF nur auf ein bestimmtes Reading (Condition) reagieren soll und nicht wenn sich anderweitige Readings ändern.
timerevent würde theoretisch wieder dafür sorgen, dass meine DOIF-Logs wieder vollgemüllt werden. Das habe ich nun verstanden.
Gute Features!
Zitat von: Damian am 31 März 2016, 16:27:44
Das sieht nicht nach der neuen Version aus.
Das Log im letzten Post bezog sich auf die vorherige offizielle DOIF-Version.
Zitat von: Damian am 31 März 2016, 16:27:44
Wie sieht die dazugehörige Definition aus?
Ich hatte den Beitrag gestern mehrfach um weitere Fehler erweitert. Ich habe gestern an mehreren DOIF herumgespielt. Ich denke, dass die Warnungen nur bei Änderung der DOIFs reagieren. Im Laufe des Tages sind keine weiteren hinzugekommen. Ich versuche mal, mich an die Fehlerquelle heranzutasten.
Nachtrag:Ich benötige es eigentlich gar nicht. Aber ich habe es gerade ausprobiert. Ich wollte (wie vorher) die regelm. Timer-Aktualisierungen bei einigen DOIFs reproduzieren. Ich habe also
timerevent hinzugefügt. Das hat aber scheinbar nicht gereicht. Ich musste zusätzlich
checkReadingEvent entfernen. Das ist wahrscheinlich gewollt, aber auf dem ersten Blick nicht direkt erkennbar. Vielleicht etwas für die Doku.
Zitat von: FunkOdyssey am 01 April 2016, 11:09:08
I
Ich benötige es eigentlich gar nicht. Aber ich habe es gerade ausprobiert. Ich wollte (wie vorher) die regelm. Timer-Aktualisierungen bei einigen DOIFs reproduzieren. Ich habe also timerevent hinzugefügt. Das hat aber scheinbar nicht gereicht. Ich musste zusätzlich checkReadingEvent entfernen. Das ist wahrscheinlich gewollt, aber auf dem ersten Blick nicht direkt erkennbar. Vielleicht etwas für die Doku.
checkReadingEvent und timerevent haben nichts miteinander gemeinsam.
Das habe ich wohl verstanden, aber dennoch funktionierte timerevent erst dann, wenn ich checkReadingEvent entfernt hatte.
(
[[twilight:ss_indoor]-[twilight:sr]]
)
(set lampe on)
DOELSE
(set lampe off)
Zitat von: FunkOdyssey am 01 April 2016, 15:59:31
Das habe ich wohl verstanden, aber dennoch funktionierte timerevent erst dann, wenn ich checkReadingEvent entfernt hatte.
(
[[twilight:ss_indoor]-[twilight:sr]]
)
(set lampe on)
DOELSE
(set lampe off)
Ich habe es gerade bei mit getestet: Das kann ich nicht bestätigen, bei mir funktioniert alles, wie beschrieben.
Edit:
Natürlich schränkt
checkReadingEvent die Aktualisierung des Timers auf den Trigger des Reading, aber wenn er aktualisiert wird, dann gibt es auch ein Timer-Event.
Die Version # $Id: 98_DOIF.pm Version 0.3 $ erzeugt beim Start und Betrieb von FHEM Perl-Warnungen
Ich habe es auf meinem Testsystem mal nachgestellt für das DOIF
Internals:
DEF ([TSL2561:broadband] > 0) (({Log 1,"[TSL2561:broadband]"}))
NAME di
NR 51
NTFY_ORDER 50-di
STATE cmd_1
TYPE DOIF
Readings:
2016-04-02 10:37:20 Device TSL2561
2016-04-02 10:37:20 cmd_event TSL2561
2016-04-02 10:37:20 cmd_nr 1
2016-04-02 10:37:20 e_TSL2561_broadband 4549
2016-04-02 10:37:20 state cmd_1
Condition:
0 ReadingValDoIf($hash,'TSL2561','broadband','','',AttrVal($hash->{NAME},'notexist',undef)) > 0
Devices:
0 TSL2561
all TSL2561
Do:
0:
0 ({Log 1,"[TSL2561:broadband]"})
Helper:
event gain: 16,integrationTime: 0.101,broadband: 4549,ir: 3441,luminosity: 37.7
globalinit 1
last_timer 0
sleeptimer -1
timerdev TSL2561
timerevent gain: 16,integrationTime: 0.101,broadband: 4549,ir: 3441,luminosity: 37.7
triggerDev TSL2561
timerevents:
gain: 16
integrationTime: 0.101
broadband: 4549
ir: 3441
luminosity: 37.7
timereventsState:
gain: 16
integrationTime: 0.101
broadband: 4549
ir: 3441
luminosity: 37.7
triggerEvents:
gain: 16
integrationTime: 0.101
broadband: 4549
ir: 3441
luminosity: 37.7
triggerEventsState:
gain: 16
integrationTime: 0.101
broadband: 4549
ir: 3441
luminosity: 37.7
Internals:
Itimer:
Readings:
0 TSL2561:broadband
all TSL2561:broadband
Regexp:
0:
All:
State:
Trigger:
Attributes:
do always
room 0_Test
erhalte ich beim Start von FHEM folgende Warnungen:
Zitat2016.04.02 10:28:13 0: Server started with 77 defined entities (fhem.pl:11144/2016-03-29 perl:5.020002 os:linux user:fhem pid:26333)
Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 497.
2016.04.02 10:28:18 1: 3608
Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 207.
2016.04.02 10:28:18 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 497.
2016.04.02 10:28:18 3: stacktrace:
2016.04.02 10:28:18 3: main::__ANON__ called by ./FHEM/98_DOIF.pm (497)
2016.04.02 10:28:18 3: main::ReplaceAllReadingsDoIf called by ./FHEM/98_DOIF.pm (161)
2016.04.02 10:28:18 3: main::EvalValueDoIf called by ./FHEM/98_DOIF.pm (944)
2016.04.02 10:28:18 3: main::DOIF_cmd called by ./FHEM/98_DOIF.pm (1174)
2016.04.02 10:28:18 3: main::DOIF_Trigger called by ./FHEM/98_DOIF.pm (1270)
2016.04.02 10:28:18 3: main::DOIF_Notify called by fhem.pl (3151)
2016.04.02 10:28:18 3: main::CallFn called by fhem.pl (3073)
2016.04.02 10:28:18 3: main::DoTrigger called by fhem.pl (3953)
2016.04.02 10:28:18 3: main::readingsEndUpdate called by ./FHEM/51_I2C_TSL2561.pm (594)
2016.04.02 10:28:18 3: main::I2C_TSL2561_Poll called by fhem.pl (2761)
2016.04.02 10:28:18 3: main::HandleTimeout called by fhem.pl (586)
2016.04.02 10:28:18 1: 4088
2016.04.02 10:28:18 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 207.
2016.04.02 10:28:18 3: stacktrace:
2016.04.02 10:28:18 3: main::__ANON__ called by ./FHEM/98_DOIF.pm (207)
2016.04.02 10:28:18 3: main::SplitDoIf called by ./FHEM/98_DOIF.pm (800)
2016.04.02 10:28:18 3: main::DOIF_SetState called by ./FHEM/98_DOIF.pm (1011)
2016.04.02 10:28:18 3: main::DOIF_cmd called by ./FHEM/98_DOIF.pm (1174)
2016.04.02 10:28:18 3: main::DOIF_Trigger called by ./FHEM/98_DOIF.pm (1270)
2016.04.02 10:28:18 3: main::DOIF_Notify called by fhem.pl (3151)
2016.04.02 10:28:18 3: main::CallFn called by fhem.pl (3073)
2016.04.02 10:28:18 3: main::DoTrigger called by fhem.pl (3953)
2016.04.02 10:28:18 3: main::readingsEndUpdate called by ./FHEM/51_I2C_TSL2561.pm (594)
2016.04.02 10:28:18 3: main::I2C_TSL2561_Poll called by fhem.pl (2761)
2016.04.02 10:28:18 3: main::HandleTimeout called by fhem.pl (586)
2016.04.02 10:29:18 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 497.
2016.04.02 10:29:18 3: stacktrace:
2016.04.02 10:29:18 3: main::__ANON__ called by ./FHEM/98_DOIF.pm (497)
2016.04.02 10:29:18 3: main::ReplaceAllReadingsDoIf called by ./FHEM/98_DOIF.pm (161)
2016.04.02 10:29:18 3: main::EvalValueDoIf called by ./FHEM/98_DOIF.pm (944)
2016.04.02 10:29:18 3: main::DOIF_cmd called by ./FHEM/98_DOIF.pm (1174)
2016.04.02 10:29:18 3: main::DOIF_Trigger called by ./FHEM/98_DOIF.pm (1270)
2016.04.02 10:29:18 3: main::DOIF_Notify called by fhem.pl (3151)
2016.04.02 10:29:18 3: main::CallFn called by fhem.pl (3073)
2016.04.02 10:29:18 3: main::DoTrigger called by fhem.pl (3953)
2016.04.02 10:29:18 3: main::readingsEndUpdate called by ./FHEM/51_I2C_TSL2561.pm (594)
2016.04.02 10:29:18 3: main::I2C_TSL2561_Poll called by fhem.pl (2761)
2016.04.02 10:29:18 3: main::HandleTimeout called by fhem.pl (586)
2016.04.02 10:29:18 1: 4124
2016.04.02 10:29:18 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 207.
2016.04.02 10:29:18 3: stacktrace:
2016.04.02 10:29:18 3: main::__ANON__ called by ./FHEM/98_DOIF.pm (207)
2016.04.02 10:29:18 3: main::SplitDoIf called by ./FHEM/98_DOIF.pm (800)
2016.04.02 10:29:18 3: main::DOIF_SetState called by ./FHEM/98_DOIF.pm (1011)
2016.04.02 10:29:18 3: main::DOIF_cmd called by ./FHEM/98_DOIF.pm (1174)
2016.04.02 10:29:18 3: main::DOIF_Trigger called by ./FHEM/98_DOIF.pm (1270)
2016.04.02 10:29:18 3: main::DOIF_Notify called by fhem.pl (3151)
2016.04.02 10:29:18 3: main::CallFn called by fhem.pl (3073)
2016.04.02 10:29:18 3: main::DoTrigger called by fhem.pl (3953)
2016.04.02 10:29:18 3: main::readingsEndUpdate called by ./FHEM/51_I2C_TSL2561.pm (594)
2016.04.02 10:29:18 3: main::I2C_TSL2561_Poll called by fhem.pl (2761)
2016.04.02 10:29:18 3: main::HandleTimeout called by fhem.pl (586)
Das DOIF funktioniert, wie der Logeintrag (rot) zeigt
Bei der Version 98_DOIF.pm 10985 2016-03-03 17:25:24Z damian-s gibt es keine Warnungen.
Die DOIF Version # $Id: 98_DOIF.pm Version 0.3 $ ignoriert cmdState 0.
Ich habe es auf meinem Testsystem mal nachgestellt für das DOIF:
Zitat
Internals:
DEF ([du:state:d])
(({Log 1, "(du): [du], (di:state): [di:state]"}))
DOELSEIF (![du:state:d])
(({Log 1, "(du): [du], (di:state): [di:state]"}))
NAME di
NR 51
NTFY_ORDER 50-di
STATE cmd_2
TYPE DOIF
Readings:
2016-04-02 11:15:50 Device du
2016-04-02 11:15:50 cmd_event du
2016-04-02 11:15:50 cmd_nr 2
2016-04-02 11:15:50 e_du_state x0
2016-04-02 11:15:50 state cmd_2
Condition:
0 ReadingValDoIf($hash,'du','state','(-?\d+(\.\d+)?)','',AttrVal($hash->{NAME},'notexist',undef))
1 !ReadingValDoIf($hash,'du','state','(-?\d+(\.\d+)?)','',AttrVal($hash->{NAME},'notexist',undef))
Devices:
0 du
1 du
all du
Do:
0:
0 ({Log 1, "(du): [du], (di:state): [di:state]"})
1:
0 ({Log 1, "(du): [du], (di:state): [di:state]"})
Helper:
event x0
globalinit 1
last_timer 0
sleeptimer -1
timerdev du
timerevent x0
triggerDev du
timerevents:
x0
timereventsState:
state: x0
triggerEvents:
x0
triggerEventsState:
state: x0
Internals:
Itimer:
Readings:
0 du:state
1 du:state
all du:state
Regexp:
0:
1:
All:
State:
Trigger:
Attributes:
cmdState 1|0
do always
room 0_Test
Für du=x1 funktioniert es und di:state wird 1.
Zitat von: Ellert am 02 April 2016, 11:33:29
Die DOIF Version # $Id: 98_DOIF.pm Version 0.3 $ ignoriert cmdState 0.
Ich habe es auf meinem Testsystem mal nachgestellt für das DOIF:Für du=x1 funktioniert es und di:state wird 1.
Ich habe es gefixt und an der Doku noch etwas gefeilt.
Version 0.4 im ersten Post.
Gruß
Damian
Zitat von: Damian am 02 April 2016, 13:16:51
Ich habe es gefixt und an der Doku noch etwas gefeilt.
Version 0.4 im ersten Post.
Gruß
Damian
Nachdem cmdState 0 funktioniert, habe ich die Version 0.4 versuchsweise im Wirkbetrieb eingesetzt.
Die Menge der Perlwarnungen gegenüber der Version "10985 2016-03-03 17:25:24Z damian-s" ist etwas irritierend.
Ich kann die Warnungen keinem Gerät eindeutig zuordnen, daher erstmal nachrichtlich die Warnungen:
2016.04.02 17:37:59 0: Featurelevel: 5.7
2016.04.02 17:37:59 0: Server started with 404 defined entities (fhem.pl:11144/2016-03-29 perl:5.014002 os:linux user:fhem pid:15922)
2016.04.02 17:38:00 1: PERL WARNING: Use of uninitialized value $_ in pattern match (m//) at ./FHEM/98_DOIF.pm line 941.
2016.04.02 17:38:00 1: PERL WARNING: Use of uninitialized value $_ in pattern match (m//) at ./FHEM/98_DOIF.pm line 942.
2016.04.02 17:38:00 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 497.
2016.04.02 17:38:00 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 207.
2016.04.02 17:50:43 1: PERL WARNING: Use of uninitialized value in subtraction (-) at ./FHEM/51_RPI_GPIO.pm line 510, <GEN25> line 2.
2016.04.02 17:50:43 1: PERL WARNING: Use of uninitialized value $_ in pattern match (m//) at ./FHEM/98_DOIF.pm line 941, <GEN25> line 2.
2016.04.02 17:50:43 1: PERL WARNING: Use of uninitialized value $_ in pattern match (m//) at ./FHEM/98_DOIF.pm line 942, <GEN25> line 2.
2016.04.02 17:50:43 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 497, <GEN25> line 2.
2016.04.02 17:50:43 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 207, <GEN25> line 2.
2016.04.02 17:50:44 1: PERL WARNING: Use of uninitialized value in subtraction (-) at ./FHEM/51_RPI_GPIO.pm line 510, <GEN29> line 2.
2016.04.02 17:50:44 1: PERL WARNING: Use of uninitialized value $_ in pattern match (m//) at ./FHEM/98_DOIF.pm line 941, <GEN29> line 2.
2016.04.02 17:50:44 1: PERL WARNING: Use of uninitialized value $_ in pattern match (m//) at ./FHEM/98_DOIF.pm line 942, <GEN29> line 2.
2016.04.02 17:50:44 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 497, <GEN29> line 2.
2016.04.02 17:50:44 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 207, <GEN29> line 2.
2016.04.02 17:51:35 1: PERL WARNING: Use of uninitialized value $_ in pattern match (m//) at ./FHEM/98_DOIF.pm line 941, <GEN25> line 3.
2016.04.02 17:51:35 1: PERL WARNING: Use of uninitialized value $_ in pattern match (m//) at ./FHEM/98_DOIF.pm line 942, <GEN25> line 3.
2016.04.02 17:51:35 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 497, <GEN25> line 3.
2016.04.02 17:51:35 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 207, <GEN25> line 3.
2016.04.02 17:51:35 1: PERL WARNING: Use of uninitialized value $_ in pattern match (m//) at ./FHEM/98_DOIF.pm line 941, <GEN29> line 3.
2016.04.02 17:51:35 1: PERL WARNING: Use of uninitialized value $_ in pattern match (m//) at ./FHEM/98_DOIF.pm line 942, <GEN29> line 3.
2016.04.02 17:51:35 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 497, <GEN29> line 3.
2016.04.02 17:51:35 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 207, <GEN29> line 3.
2016.04.02 18:06:52 1: PERL WARNING: Use of uninitialized value $_ in pattern match (m//) at ./FHEM/98_DOIF.pm line 941, <GEN25> line 4.
2016.04.02 18:06:52 1: PERL WARNING: Use of uninitialized value $_ in pattern match (m//) at ./FHEM/98_DOIF.pm line 942, <GEN25> line 4.
2016.04.02 18:06:52 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 497, <GEN25> line 4.
2016.04.02 18:06:52 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 207, <GEN25> line 4.
2016.04.02 18:06:53 1: PERL WARNING: Use of uninitialized value $_ in pattern match (m//) at ./FHEM/98_DOIF.pm line 941, <GEN29> line 4.
2016.04.02 18:06:53 1: PERL WARNING: Use of uninitialized value $_ in pattern match (m//) at ./FHEM/98_DOIF.pm line 942, <GEN29> line 4.
2016.04.02 18:06:53 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 497, <GEN29> line 4.
2016.04.02 18:06:53 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 207, <GEN29> line 4.
2016.04.02 18:23:40 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 497, <GEN25> line 5.
2016.04.02 18:23:40 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 207, <GEN25> line 5.
2016.04.02 18:23:42 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 497, <GEN29> line 5.
2016.04.02 18:23:42 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 207, <GEN29> line 5.
2016.04.02 18:24:20 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 497, <GEN25> line 6.
2016.04.02 18:24:20 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 207, <GEN25> line 6.
2016.04.02 18:24:46 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 497, <GEN29> line 6.
2016.04.02 18:24:46 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 207, <GEN29> line 6.
2016.04.02 18:25:14 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 497, <GEN25> line 7.
2016.04.02 18:25:14 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 207, <GEN25> line 7.
2016.04.02 18:25:14 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 497, <GEN29> line 7.
2016.04.02 18:25:14 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 207, <GEN29> line 7.
2016.04.02 18:27:29 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 497, <GEN29> line 8.
2016.04.02 18:27:29 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 207, <GEN29> line 8.
2016.04.02 18:30:51 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 497, <GEN25> line 8.
2016.04.02 18:30:51 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 207, <GEN25> line 8.
2016.04.02 18:30:54 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 497, <GEN29> line 9.
2016.04.02 18:30:54 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 207, <GEN29> line 9.
2016.04.02 18:31:23 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 497, <GEN29> line 10.
2016.04.02 18:31:23 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 207, <GEN29> line 10.
2016.04.02 18:32:58 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 497, <GEN25> line 9.
2016.04.02 18:32:58 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 207, <GEN25> line 9.
2016.04.02 18:32:58 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 497, <GEN29> line 11.
2016.04.02 18:32:58 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 207, <GEN29> line 11.
2016.04.02 18:51:10 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 497, <GEN25> line 10.
2016.04.02 18:51:10 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 207, <GEN25> line 10.
2016.04.02 18:51:12 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 497, <GEN29> line 12.
2016.04.02 18:51:12 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 207, <GEN29> line 12.
2016.04.02 18:51:50 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 497, <GEN25> line 11.
2016.04.02 18:51:50 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 207, <GEN25> line 11.
2016.04.02 18:51:54 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 497, <GEN29> line 13.
2016.04.02 18:51:54 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 207, <GEN29> line 13.
2016.04.02 19:00:04 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 497, <GEN29> line 14.
2016.04.02 19:00:04 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 207, <GEN29> line 14.
2016.04.02 19:13:33 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 497, <GEN29> line 15.
2016.04.02 19:13:33 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 207, <GEN29> line 15.
2016.04.02 19:14:16 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 497, <GEN29> line 16.
2016.04.02 19:14:16 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 207, <GEN29> line 16.
2016.04.02 19:15:36 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 497, <GEN25> line 12.
2016.04.02 19:15:36 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 207, <GEN25> line 12.
2016.04.02 19:15:41 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 497, <GEN29> line 17.
2016.04.02 19:15:41 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 207, <GEN29> line 17.
2016.04.02 19:16:47 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 497, <GEN25> line 13.
2016.04.02 19:16:47 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 207, <GEN25> line 13.
2016.04.02 19:19:50 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 497, <GEN25> line 14.
2016.04.02 19:19:50 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 207, <GEN25> line 14.
2016.04.02 19:19:53 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 497, <GEN29> line 18.
2016.04.02 19:19:53 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 207, <GEN29> line 18.
2016.04.02 19:26:33 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 497, <GEN29> line 19.
2016.04.02 19:26:33 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 207, <GEN29> line 19.
2016.04.02 19:26:34 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 497, <GEN25> line 15.
2016.04.02 19:26:34 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 207, <GEN25> line 15.
2016.04.02 19:29:14 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 497, <GEN29> line 20.
2016.04.02 19:29:15 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 207, <GEN29> line 20.
2016.04.02 19:31:01 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 497, <GEN25> line 16.
2016.04.02 19:31:01 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 207, <GEN25> line 16.
2016.04.02 19:31:16 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 497, <GEN29> line 21.
2016.04.02 19:31:16 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 207, <GEN29> line 21.
2016.04.02 19:32:44 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 497, <GEN25> line 17.
2016.04.02 19:32:44 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 207, <GEN25> line 17.
2016.04.02 19:32:45 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 497, <GEN29> line 22.
2016.04.02 19:32:45 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 207, <GEN29> line 22.
2016.04.02 19:41:25 1: PERL WARNING: substr outside of string at ./FHEM/98_DOIF.pm line 127, <GEN29> line 22.
2016.04.02 19:41:25 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 210, <GEN29> line 22.
2016.04.02 19:43:27 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 497, <GEN25> line 18.
2016.04.02 19:43:27 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 207, <GEN25> line 18.
2016.04.02 19:43:28 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 497, <GEN29> line 23.
2016.04.02 19:43:28 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 207, <GEN29> line 23.
2016.04.02 19:46:50 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 497, <GEN29> line 24.
2016.04.02 19:46:50 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 207, <GEN29> line 24.
2016.04.02 19:46:51 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 497, <GEN25> line 19.
2016.04.02 19:46:51 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 207, <GEN25> line 19.
2016.04.02 19:48:23 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 497, <GEN29> line 25.
2016.04.02 19:48:23 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 207, <GEN29> line 25.
2016.04.02 19:48:33 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 497, <GEN25> line 20.
2016.04.02 19:48:33 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 207, <GEN25> line 20.
2016.04.02 19:48:57 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 497, <GEN29> line 26.
2016.04.02 19:48:57 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 207, <GEN29> line 26.
2016.04.02 19:49:36 1: PERL WARNING: substr outside of string at ./FHEM/98_DOIF.pm line 127, <GEN29> line 26.
2016.04.02 19:49:36 1: PERL WARNING: Use of uninitialized value $tailBlock in string ne at ./FHEM/98_DOIF.pm line 210, <GEN29> line 26.
Version 0.5 im ersten Post sollte jetzt keine Warnings bringen.
Beim FHEM-Neustart habe ich noch folgende Warnings. Leider kenne ich die exakte Quelle noch nicht.
PERL WARNING: Use of uninitialized value $reading in regexp compilation at ./FHEM/98_DOIF.pm line 1066.
PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/98_DOIF.pm line 1162.
Zitat von: FunkOdyssey am 03 April 2016, 00:26:01
Beim FHEM-Neustart habe ich noch folgende Warnings. Leider kenne ich die exakte Quelle noch nicht.
PERL WARNING: Use of uninitialized value $reading in regexp compilation at ./FHEM/98_DOIF.pm line 1066.
PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/98_DOIF.pm line 1162.
Mit Version 0.6 sollten auch diese Warnings weg sein.
Einer ist noch drinne:
PERL WARNING: Use of uninitialized value $reading in regexp compilation at ./FHEM/98_DOIF.pm line 1069.
Zitat von: FunkOdyssey am 03 April 2016, 14:20:29
Einer ist noch drinne:
PERL WARNING: Use of uninitialized value $reading in regexp compilation at ./FHEM/98_DOIF.pm line 1069.
Version 0.7 - so langsam müssten sie alle ausgemerzt sein.
Zitat von: Damian am 03 April 2016, 15:07:02
Version 0.7 - so langsam müssten sie alle ausgemerzt sein.
Bis jetzt sind keine Warnungen mehr aufgetaucht.
Zitat von: Ellert am 04 April 2016, 11:48:06
Bis jetzt sind keine Warnungen mehr aufgetaucht.
Das ist gut. Wenn sich keine weiteren Auffälligkeiten ergeben, dann werde ich die Version bald einchecken.
Gruß
Damian
Ich kann auch keine Probleme finden.
Die Perl-Warnings sind nun tatsächlich alle weg.
Ich habe gerade addStateEvent probiert, es scheint nicht zu funktionieren.
DOIF Version 0.7
ZitatInternals:
CFGFN
DEF ([Test:"^state: "]) (({Log 1, "$DEVICE $EVENTS"}))
NAME state_di
NR 1696
NTFY_ORDER 50-atHome_di
STATE initialized
TYPE DOIF
Readings:
2016-04-05 20:22:51 Device Test
2016-04-05 20:22:51 e_Test_events 1
2016-04-05 20:20:26 state initialized
Condition:
0 EventDoIf('Test',$hash,'^state: ',1)
Devices:
0 Test
all Test
Do:
0:
0 ({Log 1, "$DEVICE $EVENTS"})
1:
Helper:
event 1
globalinit 1
last_timer 0
sleeptimer -1
triggerDev Test
triggerEvents:
1
triggerEventsState:
state: 1
Internals:
Itimer:
Readings:
Regexp:
0:
All:
State:
Trigger:
all Test
Attributes:
addStateEvent 1
do always
room 0_Test
Zitat von: Ellert am 05 April 2016, 20:28:13
Ich habe gerade addStateEvent probiert, es scheint nicht zu funktionieren.
DOIF Version 0.7
Version 0.8 mit Korrekturen und weiteren Anpassungen.
So sieht die neue Einleitung der Commandref aus:
ZitatDOIF (ausgeprochen: du if, übersetzt: tue wenn) ist ein universelles Modul, welches ereignis- und zeitgesteuert in Abhängigkeit definierter Bedingungen Anweisungen ausführt.
In einer Hausautomatisation geht es immer wieder um die Ausführung von Befehlen abhängig von einem Ereignis. Oft reicht aber eine einfache Abfrage der Art: "wenn Ereignis eintritt, dann Befehl ausführen" nicht aus. Ebenso häufig möchte man eine Aktion nicht nur von einem einzelnen Ereignis abhängig ausführen, sondern abhängig von mehreren Bedingungen, z. B. "schalte Außenlicht ein, wenn es dunkel wird, aber nicht vor 18:00 Uhr" oder "schalte die Warmwasserzirkulation ein, wenn die Rücklauftemperatur unter 38 Grad fällt und jemand zuhause ist". In solchen Fällen muss man mehrere Bedingung logisch miteinander verknüpfen. Das lässt sich mit Hilfe eines Perl-if-Befehls in Kombination mit dem notify-Modul bei Ereignissteuerung oder dem at-Modul bei Zeitsteuerung bewerkstelligen. Das setzt allerdings bereits eine gewisse Mindestkenntnis der Programmiersprache Perl voraus.
An dieser Stelle setzt das Modul DOIF an. Es stellt eine eigene Benutzer-Schnittstelle zur Verfügung ohne Programmierkenntnisse in Perl vorauszusetzen. Mit diesem Modul ist es möglich, sowohl Ereignis- als auch Zeitsteuerung mit Hilfe logischer Abfragen miteinander zu kombinieren. Damit können komplexere Problemstellungen innerhalb eines DOIF-Moduls gelöst werden, ohne Perlcode in Kombination mit anderen Modulen programmieren zu müssen.
Das DOIF-Modul bedient sich selbst des Perlinterpreters, damit sind beliebige logische Abfragen möglich. Logische Abfragen werden in DOIF/DOELSEIF-Bedingungen vornehmlich mit Hilfe von and/or-Operatoren erstellt. Diese werden mit Angaben von Stati, Readings, Internals, Events oder Zeiten kombiniert. Sie werden grundsätzlich in eckigen Klammern angegeben und führen zur Triggerung des Moduls und damit zur Auswertung der dazugehörigen Bedingung. Zusätzlich können in einer Bedingung Perl-Funktionen angegeben werden, die in FHEM definiert sind. Wenn eine Bedingung wahr wird, so werden die dazugehörigen Befehle ausgeführt.
Syntax:
define <name> DOIF (<Bedingung>) (<Befehle>) DOELSEIF (<Bedingung>) (<Befehle>) DOELSEIF ... DOELSE (<Befehle>)
Die Angaben werden immer von links nach rechts abgearbeitet. Zu beachten ist, dass nur die Bedingungen überprüft werden, die zum ausgelösten Event das dazughörige Device bzw. die dazugehörige Triggerzeit beinhalten. Kommt ein Device in mehreren Bedingungen vor, so wird immer nur ein Kommando ausgeführt, und zwar das erste, für das die dazugehörige Bedingung in der abgearbeiteten Reihenfolge wahr ist.
Das DOIF-Modul arbeitet mit Zuständen. Jeder Ausführungszweig DOIF/DOELSEIF..DOELSEIF/DOELSE stellt einen eigenen Zustand dar (cmd_1, cmd_2, usw.). Das Modul merkt sich den zuletzt ausgeführten Ausführungszweig und wiederholt diesen standardmäßig nicht. Ein Ausführungszweig wird erst dann wieder ausgeführt, wenn zwischenzeitlich ein anderer Ausführungszweig ausgeführt wurde, also ein Zustandswechsel stattgefunden hat. Dieses Verhalten ist sinnvoll, um zu verhindern, dass zyklisch sendende Sensoren (Temperatur, Feuchtigkeit, Helligkeit, usw.) zu ständiger Wiederholung des selben Befehls oder Befehlsabfolge führen.
Gruß
Damian
Schöne Einleitung in der Doku.
Mit der v0.8 habe ich wieder eine Warnung:
PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/98_DOIF.pm line 1168.
addStateEvent funktioniert jetzt. In diesem Zusammenhang ist mir aufgefallen, dass für ([Test:"^state: "]) (({Log 1, "$DEVICE $EVENTS"})) "do always" erforderlich ist, da ein Event als Status erhalten bleibt und das DOIF nicht auf cmd_2 wechselt, wenn das Ereignis vorbei ist.
Wäre es nicht konsequenter eine Bedingung mit Event, nur zum Zeitpunkt des Events wahr werden zu lassen? Die Eigenart eines Events impliziert eigentlich ein "do always" Verhalten. Dazu wäre dann ein Attribut "do once" passend.
Das Triggern auf Status/Reading wäre dann komplementär zum Triggern auf Events.
Die Einleitung finde ich sehr verständlich, sie stellt das grundsätzliche Verhalten des DOIF deutlich heraus.
Zitat von: Ellert am 06 April 2016, 14:38:54
addStateEvent funktioniert jetzt. In diesem Zusammenhang ist mir aufgefallen, dass für ([Test:"^state: "]) (({Log 1, "$DEVICE $EVENTS"})) "do always" erforderlich ist, da ein Event als Status erhalten bleibt und das DOIF nicht auf cmd_2 wechselt, wenn das Ereignis vorbei ist.
Das verstehe ich nicht. Warum soll ein Event als Status erhalten bleiben? Das Modul verhält sich, wie sonst auch:
Es handelt sich hier um eine Event-Abfrage mit konkreter Deviceangabe. Die Eventabfrage ist nur zum Zeitpunkt des Events wahr und sonst nicht. Damit wird beim Eintreffen des Ereignisses die Regexp ausgewertet, und wenn sie nicht wahr ist dann wechselt der Status auf cmd_2 (ohne do always).
Das ist doch unabhängig davon, ob ich addStateEvent hinzufüge oder nicht.
Zitat von: FunkOdyssey am 06 April 2016, 13:50:08
Schöne Einleitung in der Doku.
Mit der v0.8 habe ich wieder eine Warnung:
PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/98_DOIF.pm line 1168.
V 0.9
Zitat von: Damian am 06 April 2016, 15:05:09
Das verstehe ich nicht. Warum soll ein Event als Status erhalten bleiben? Das Modul verhält sich, wie sonst auch:
Es handelt sich hier um eine Event-Abfrage mit konkreter Deviceangabe. Die Eventabfrage ist nur zum Zeitpunkt des Events wahr und sonst nicht. Damit wird beim Eintreffen des Ereignisses die Regexp ausgewertet, und wenn sie nicht wahr ist dann wechselt der Status auf cmd_2 (ohne do always).
Das ist doch unabhängig davon, ob ich addStateEvent hinzufüge oder nicht.
Mit "addStateEvent" hat meine Überlegung nichts zu tun.
Zitatda ein Event als Status erhalten bleibt
Da habe ich mich unverständlich ausgerückt.
Mir ist bei dem DOIF mit einer Bedingung nur aufgefallen, dass nicht automatisch in den cmd_2 gewechselt wird, wenn die Bedingung unwahr wird.
Die Bedingung wird unwahr, sobald das Ereignis beendet ist, die Bedingung wird dann jedoch nicht erneut geprüft.
Bei einem Reading gibt es für jeden Zustandswechsel/-aktualisierung eine Prüfung der Bedingung.
Ein Event stelle ich mir als zwei Zustandswechsel vor, "Event erscheint" und "Event verschwindet".
Deshalb hätte ich einen Statuswechsel des DOIF auf cmd_2 erwartet.
Oder anders formuliert: Wenn eine Bedingung mit Eventangabe nur zum Zeitpunkt des zutreffenden Events wahr ist, müsste sie zu jedem anderen Zeitpunk unwahr sein und das DOIF müsste einen Zustandswechsel nach cmd_2 durchführen, bzw. "do always" implizieren.
Mir kommt dieses Verhalten intuitiver vor, deshalb hatte es erwähnt.
Zitat von: Ellert am 06 April 2016, 18:07:35
Mit "addStateEvent" hat meine Überlegung nichts zu tun.
Da habe ich mich unverständlich ausgerückt.
Mir ist bei dem DOIF mit einer Bedingung nur aufgefallen, dass nicht automatisch in den cmd_2 gewechselt wird, wenn die Bedingung unwahr wird.
Die Bedingung wird unwahr, sobald das Ereignis beendet ist, die Bedingung wird dann jedoch nicht erneut geprüft.
Bei einem Reading gibt es für jeden Zustandswechsel/-aktualisierung eine Prüfung der Bedingung.
Ein Event stelle ich mir als zwei Zustandswechsel vor, "Event erscheint" und "Event verschwindet".
Deshalb hätte ich einen Statuswechsel des DOIF auf cmd_2 erwartet.
Oder anders formuliert: Wenn eine Bedingung mit Eventangabe nur zum Zeitpunkt des zutreffenden Events wahr ist, müsste sie zu jedem anderen Zeitpunk unwahr sein und das DOIF müsste einen Zustandswechsel nach cmd_2 durchführen, bzw. "do always" implizieren.
Mir kommt dieses Verhalten intuitiver vor, deshalb hatte es erwähnt.
OK. Allerdings muss man an der Stelle weiter denken. Was soll dann passieren bei logischen Verknüpfungen, die ja den Schwerpunkt des Moduls ausmachen?
Beispiel:
([dev1:"event"] and [dev2:reading]) (...)
oder
([dev1:"event"] or [dev2:reading]) (...)
würdest du dann als User eine doppelte Triggerung (wahr/unwahr) erwarten, wenn event eintrifft? Damit würden sehr viele Definition sich nicht mehr so verhalten, wie die Benutzer es erwarten. Und es würde gegen den bisher eingehaltenen Grundsatz des Moduls verstoßen: "Eine Bedingung wird nur
einmal ausgewertet, wenn ein dazugehöriger Trigger kommt und sonst nicht". Damit würden auch meine Beispiele nicht mehr so funktionieren, wie ich sie in der Commandoref formuliert habe. Z. B. der on-for-timer, der sich gut für einen Bewegungsmelder eignet. Damit dürften auch Befehlssequenzen nicht mehr funktionieren, usw.
Gruß
Damian
V 0.10 Unterstützt jetzt $SELF und cmd-Reading.
Beispiel:
DOIF ([$SELF:cmd] == 1 and ...) (set ...)
im Reading cmd steht die Nummer des letzten Kommandos 1, 2, 3 usw. oder bei Sequenzen 1.1, 1.2, 1.3 usw., auf die man abfragen kann.
Gruß
Damian
Zitat von: Damian am 06 April 2016, 19:33:35
OK. Allerdings muss man an der Stelle weiter denken. Was soll dann passieren bei logischen Verknüpfungen, die ja den Schwerpunkt des Moduls ausmachen?
Beispiel:
([dev1:"event"] and [dev2:reading]) (...)
oder
([dev1:"event"] or [dev2:reading]) (...)
würdest du dann als User eine doppelte Triggerung (wahr/unwahr) erwarten, wenn event eintrifft? Damit würden sehr viele Definition sich nicht mehr so verhalten, wie die Benutzer es erwarten. Und es würde gegen den bisher eingehaltenen Grundsatz des Moduls verstoßen: "Eine Bedingung wird nur einmal ausgewertet, wenn ein dazugehöriger Trigger kommt und sonst nicht". Damit würden auch meine Beispiele nicht mehr so funktionieren, wie ich sie in der Commandoref formuliert habe. Z. B. der on-for-timer, der sich gut für einen Bewegungsmelder eignet. Damit dürften auch Befehlssequenzen nicht mehr funktionieren, usw.
Gruß
Damian
Ja, ich merke, dass meine Sicht recht eigenwillig ist und in das grundsätzliche Verhalten des DOIF nicht passt.
Zitat von: Ellert am 07 April 2016, 09:04:51
Ja, ich merke, dass meine Sicht recht eigenwillig ist und in das grundsätzliche Verhalten des DOIF nicht passt.
ja, das Problem ist einfach, dass der Zeitpunkt Event-Verschwindet nicht gleich Event-Erscheint sein kann -> zwei Trigger direkt hintereinander (würde auch einem wait nicht gut tun). Und jeder spätere Zeitpunkt für Event-Verschwindet ist nicht eindeutig definierbar.
Gruß
Damian
Zitat von: Damian am 06 April 2016, 23:04:10
V 0.10 Unterstützt jetzt $SELF und cmd-Reading.
Beispiel:
DOIF ([$SELF:cmd] == 1 and ...) (set ...)
im Reading cmd steht die Nummer des letzten Kommandos 1, 2, 3 usw. oder bei Sequenzen 1.1, 1.2, 1.3 usw., auf die man abfragen kann.
Gruß
Damian
Gibt es einen besonderen Grund den Punkt zu benutzen und nicht wie bisher den Unterstrich?
In meinen DOIF benutze ich häufiger die Abfrage auf einen Zwischenstatus [di] eq "cmd_x_y", das müsste ich dann ändern in [di] eq "cmd_x.y"
([du:state:d])
(({Log 1, "Sequenz 1_1"}))
(({Log 1, "Sequenz 1_2"}))
DOELSEIF (![du:state:d])
(({Log 1, "Sequenz 2_1"}))
(({Log 1, "Sequenz 2_2"}))
und den Attributen:
wait 0,10:0,10
do always
die vom DOIF erzeugten Events sehen so aus:
Zitat2016.04.07 09:48:09 1: Sequenz 1_1
2016.04.07 09:48:09 1: Lauscher di: cmd_nr: 1
2016.04.07 09:48:09 1: Lauscher di: cmd_seqnr: 1
2016.04.07 09:48:09 1: Lauscher di: cmd: 1_1
2016.04.07 09:48:09 1: Lauscher di: cmd_event: du
2016.04.07 09:48:09 1: Lauscher di: cmd_1.1
2016.04.07 09:48:09 1: Lauscher di: wait_timer: 07.04.2016 09:48:19 cmd_1_2 du
2016.04.07 09:48:19 1: Lauscher di: wait_timer: no timer
2016.04.07 09:48:19 1: Sequenz 1_2
2016.04.07 09:48:19 1: Lauscher di: cmd_nr: 1
2016.04.07 09:48:19 1: Lauscher di: cmd_seqnr: 2
2016.04.07 09:48:19 1: Lauscher di: cmd: 1_2
2016.04.07 09:48:19 1: Lauscher di: cmd_event: du
2016.04.07 09:48:19 1: Lauscher di: cmd_1
Das DOIF nimmt einmal für state einen veränderten Zustand cmd_1
.1, er war sonst cmd_1
_1
Gemäß Deiner Beschreibung hätte ich folgendes erwartet:
Zitat2016.04.07 09:48:09 1: Lauscher di: cmd: 1.1
2016.04.07 09:48:09 1: Lauscher di: cmd_1_1
Zitat von: Damian am 06 April 2016, 23:04:10
im Reading cmd steht die Nummer des letzten Kommandos 1, 2, 3 usw. oder bei Sequenzen 1.1, 1.2, 1.3 usw., auf die man abfragen kann.
Immer, auch wenn cmdState verwendet wird?
Zitat von: Per am 07 April 2016, 11:11:39
Immer, auch wenn cmdState verwendet wird?
Klar, es muss ein Reading sein, auf das man sich immer verlassen kann. Das ist bei cmd_nr, cmd_seqnr, state nicht der Fall. Natürlich kann man mit $SELF auch jeden anderen Reading nutzen. $SELF wird einfach durch den eigenen Devicenamen ersetzt.
Zitat von: Ellert am 07 April 2016, 10:27:14
Gibt es einen besonderen Grund den Punkt zu benutzen und nicht wie bisher den Unterstrich?
In meinen DOIF benutze ich häufiger die Abfrage auf einen Zwischenstatus [di] eq "cmd_x_y", das müsste ich dann ändern in [di] eq "cmd_x.y"
([du:state:d])
(({Log 1, "Sequenz 1_1"}))
(({Log 1, "Sequenz 1_2"}))
DOELSEIF (![du:state:d])
(({Log 1, "Sequenz 2_1"}))
(({Log 1, "Sequenz 2_2"}))
und den Attributen:
wait 0,10:0,10
do always
die vom DOIF erzeugten Events sehen so aus:
Das DOIF nimmt einmal für state einen veränderten Zustand cmd_1.1, er war sonst cmd_1_1
Gemäß Deiner Beschreibung hätte ich folgendes erwartet:
cmd_1.1 wäre dann ein Fehler. Es muss natürlich cmd_1_1 bleiben.
cmd als Dezimalzahl auszulegen hatte den Hintergrund einfach mit == ohne Anführungszeichen den Zustand abzufragen - ist zwei Zeichen kürzer und für den Einen oder Anderen vielleicht etwas verständlicher als eq usw.
Zitat von: Damian am 07 April 2016, 11:28:07
cmd_1.1 wäre dann ein Fehler. Es muss natürlich cmd_1_1 bleiben.
cmd als Dezimalzahl auszulegen hatte den Hintergrund einfach mit == ohne Anführungszeichen den Zustand abzufragen - ist zwei Zeichen kürzer und für den Einen oder Anderen vielleicht etwas verständlicher als eq usw.
Version 0.11
mit cmd 1.1 und state cmd_1_1, wie beschrieben. Doku muss ich noch anpassen.
Ich habe die Kurzreferenz angepasst auf Grundlage der Version 0.11
Zitat von: Ellert am 07 April 2016, 18:50:44
Ich habe die Kurzreferenz angepasst auf Grundlage der Version 0.11
ZitatDE FHEM/98_DOIF.pm: Unbalanced ul (1, last line ok: 1894)
irgendwo fehlt ein <ul>
Habe ich korrigiert, commandref_join.pl meldet keine Fehler.
Zitat von: Ellert am 07 April 2016, 20:35:22
Habe ich korrigiert, commandref_join.pl meldet keine Fehler.
Version 0.12:
cmd-Reading wird jetzt mit 0 vorbelegt bei Initialisierung.
Jetzt gibt es zusätzlich auch eine Perl-Variable $cmd in der Bedingung. Damit spart man bei Abfragen weitere Zeichen. $cmd entspricht dem Reading cmd.
Beispiel
Toggel-Schalter über Zustandsabfrage des Moduls:
([Trigger:""] and $cmd == 2) (set lamp off)
DOELSEIF ( [Trigger:""] and $cmd <= 2) (set lamp on)
Edit:
oder einfach:
([Trigger:""] and $cmd == 2) (set lamp off) DOELSE (set lamp on)
Ich habe die Kurzreferenz angepasst auf Grundlage der Version 0.12, commandref_join.pl meldet keine Fehler für DOIF.
Zitat von: Ellert am 08 April 2016, 10:16:24
Ich habe die Kurzreferenz angepasst auf Grundlage der Version 0.12, commandref_join.pl meldet keine Fehler für DOIF.
OK. Ich werde noch die restliche Doku anpassen und dann langsam einchecken, bevor mir wieder was einfällt ;)
Gruß
Damian
... da wäre noch was auf der Liste: https://forum.fhem.de/index.php/topic,47979.msg416359.html#msg416359
8) Duck und wech ...
Zitat von: Ralli am 08 April 2016, 11:16:03
... da wäre noch was auf der Liste: https://forum.fhem.de/index.php/topic,47979.msg416359.html#msg416359
8) Duck und wech ...
ja, steht auf der todo-Liste, wie auch das Neuaufsetzen eines wait-Timers nach einem Restart oder checkall-Attribut und noch ein paar andere Dinge. Allerdings werde ich irgendwann dann die Überschrift auf "Features Weihnachten 2016" ändern müssen ;)
Ein bestimmt schnell zu behebender Fehler mit aber derben Auswirkungen ist mir noch aufgefallen (V 0.12):
Bei der Verwendung von wait wird der Befehlsspeicher nicht geleert.
Beispiel
([Trigger1]) (Com1.1) (Com1.2)
DOELSEIF ([Trigger2]) (Com2.1)
wait 1,1:1
wird nach Com2.1 noch Com1.2 ausgführt, inkl. waittimer.
Verwende ich gleichviel Commandos
([Trigger1]) (Com1.1) (Com1.2)
DOELSEIF ([Trigger2]) (Com2.1) ()
wait 1,1:1,0
passt es.
Falls es sich mit dem Kurzbeispiel nicht nachvollziehen lässt, kann ich auch noch ein reales nachliefern.
Außerdem habe ich das Problem, dass bei do always der waittimer nicht zurück gesetzt wird, bei do resetwait schon, aber nicht auf cmd x.1, sondern der aktuelle :-\.
Da ich aber das erste Mal den waittimer aktiv beobachtet und resetwait eingesetzt habe, kann das auch ne andere Ursache haben.
Was mir noch aufgefallen ist, weiss aber nicht, ob das an fhem.pl oder 98_DOIF.pm liegt:
TAB vor DOELSE(IF) wird problemlos erkannt und umgesetzt, danach nicht, da muss zwingend ein Leerzeichen stehen. Ich kann damit leben, ich formatiere meine Quelltexte halt nur gern, weil ich sonst schnell den Überblick verliere.
Zitat von: Per am 10 April 2016, 09:53:23
Ein bestimmt schnell zu behebender Fehler mit aber derben Auswirkungen ist mir noch aufgefallen (V 0.12):
Bei der Verwendung von wait wird der Befehlsspeicher nicht geleert.
Beispiel
([Trigger1]) (Com1.1) (Com1.2)
DOELSEIF ([Trigger2]) (Com2.1)
wait 1,1:1
wird nach Com2.1 noch Com1.2 ausgführt, inkl. waittimer.
Verwende ich gleichviel Commandos
([Trigger1]) (Com1.1) (Com1.2)
DOELSEIF ([Trigger2]) (Com2.1) ()
wait 1,1:1,0
passt es.
Falls es sich mit dem Kurzbeispiel nicht nachvollziehen lässt, kann ich auch noch ein reales nachliefern.
Außerdem habe ich das Problem, dass bei do always der waittimer nicht zurück gesetzt wird, bei do resetwait schon, aber nicht auf cmd x.1, sondern der aktuelle :-\.
Da ich aber das erste Mal den waittimer aktiv beobachtet und resetwait eingesetzt habe, kann das auch ne andere Ursache haben.
Was mir noch aufgefallen ist, weiss aber nicht, ob das an fhem.pl oder 98_DOIF.pm liegt:
TAB vor DOELSE(IF) wird problemlos erkannt und umgesetzt, danach nicht, da muss zwingend ein Leerzeichen stehen. Ich kann damit leben, ich formatiere meine Quelltexte halt nur gern, weil ich sonst schnell den Überblick verliere.
Ich vermute, dass es ein Verständnisproblem ist. Ich habe es gerade bei mir getestet und alles funktioniert wie beabsichtigt.
bei cmd:
nach 1.1 (state cmd_1_1) kommt 1.2 (im Status steht cmd_1). Die Belegung von cmd ist anders als von State. Das ist für die Eindeutigkeit wichtig.
im DOELESIF-Fall gibt es nur cmd_2 im Status und das entspricht im cmd-reading 2, da es keine Sequenz gibt.
Bei do always wird kein Timer zurückgesetzt, wenn es sich um das gleiche Kommando handelt, das ist normal und beabsichtigt.
Es werden intern mit "\s" Zeichen zum nächsten Kommando überlesen und damit sollte nicht nur Leerzeichen, sondern auch Tab genauso funktionieren.
In der Weboberfläche kann ich kein Tab eingeben, ich editiere nicht die cfg-Datei
Gruß
Damian
Zitat von: Damian am 10 April 2016, 11:58:09
Ich vermute, dass es ein Verständnisproblem ist. ...
Durchaus möglich.
Vllt. habe ich ja eine spezielle Konstellation, dass es bei mir nicht so klappt wie gewünscht.
Hier mal das vollständige DOIF:
([test2:state] eq "off" and [?$SELF:state] !~ "off" and [?$SELF:state] !~ "trigger") () () ()
DOELSEIF ([test2:state] eq "off" and [?$SELF:state] !~ "off" and [?$SELF:state] !~ "trigger") () () ()
DOELSEIF ([?$SELF:state] =~ "auto" and ([test1] eq "on")) (set test2 on)
DOELSEIF ([$SELF:state] eq "trigger" and ([test1] eq "on")) (set test2 on)
DOELSEIF ([?$SELF:state] =~ "auto" and ([test1] eq "off")) (set test2 off)
DOELSEIF ([$SELF:state] eq "trigger" and ([test1] eq "off")) (set test2 off)
cmdState manu_on,auto_m_on,trigger|manu_off,auto_m_off,trigger|auto_on|auto_on|auto_off|auto_off
wait 0,10,10:0,10,10:1:1:1:1
selftrigger 1
initialize auto_off und
test2 sind einfache Dummys mit
setList on off.
Nach
auto_on folgt
auto_m_on und
trigger, danach wieder
auto_on.
Zitat von: Damian am 10 April 2016, 11:58:09
Bei do always wird kein Timer zurückgesetzt, wenn es sich um das gleiche Kommando handelt, das ist normal und beabsichtigt.
Sowohl
[?$SELF:state] !~ [?test2:state]als als auch
[test2:state] and [?$SELF:state] !~ [?test2:state]ergaben nur einen einzigen Trigger bei Änderung von
test2. Oben stehende Variante mit zwei DO-Zeilen hingegen funktioniert wie gewünscht bei jeder Änderung von
test2.
Zitat von: Damian am 10 April 2016, 11:58:09
In der Weboberfläche kann ich kein Tab eingeben
Aber einkopieren ;).
Zitat von: Per am 10 April 2016, 13:39:50
Durchaus möglich.
Vllt. habe ich ja eine spezielle Konstellation, dass es bei mir nicht so klappt wie gewünscht.
Hier mal das vollständige DOIF:
([test2:state] eq "off" and [?$SELF:state] !~ "off" and [?$SELF:state] !~ "trigger") () () ()
DOELSEIF ([test2:state] eq "off" and [?$SELF:state] !~ "off" and [?$SELF:state] !~ "trigger") () () ()
DOELSEIF ([?$SELF:state] =~ "auto" and ([test1] eq "on")) (set test2 on)
DOELSEIF ([$SELF:state] eq "trigger" and ([test1] eq "on")) (set test2 on)
DOELSEIF ([?$SELF:state] =~ "auto" and ([test1] eq "off")) (set test2 off)
DOELSEIF ([$SELF:state] eq "trigger" and ([test1] eq "off")) (set test2 off)
cmdState manu_on,auto_m_on,trigger|manu_off,auto_m_off,trigger|auto_on|auto_on|auto_off|auto_off
wait 0,10,10:0,10,10:1:1:1:1
selftrigger 1
initialize auto_off
test1 und test2 sind einfache Dummys mit setList on off.
Nach auto_on folgt auto_m_on und trigger, danach wieder auto_on.
Sowohl
[?$SELF:state] !~ [?test2:state]
als als auch
[test2:state] and [?$SELF:state] !~ [?test2:state]
ergaben nur einen einzigen Trigger bei Änderung von test2. Oben stehende Variante mit zwei DO-Zeilen hingegen funktioniert wie gewünscht bei jeder Änderung von test2.
Aber einkopieren ;).
Kann doch alles sein: Ausgangszustand cmd_4 (auto_on), cmd_1_1 ist nicht sichtbar weil wait 0, danach kommt cmd_1_2 (auto_m_on), dann cmd_1_2 (trigger), dann durch selbsttrigger cmd_4 (auto_on).
Am besten, wenn du ein Fehlverhalten vermutest, dann speckst du es soweit ab, dass ich es mit paste und copy übernehmen kann, um es nachzuvollziehen.
Alles andere sind Vermutungen, die sich nicht nachvollziehen lassen, weil zu komplex und zu unvollständig und es ist schade dann um unsere kostbare Zeit, die dafür drauf geht.
Gruß
Damian
Zitat von: Damian am 10 April 2016, 15:09:47
cmd_1_1 ist nicht sichtbar weil wait 0
:-[ hast du natürlich recht.
Ich muss aber dennoch auf zwei Abschnitte aufteilen
() (set test2 on), weil der
state von
$SELF zu dem Zeitpunkt anscheind noch nicht gesetzt ist (obwohl es in den readings so angezeigt wird). Interessanterweise hat aber
(set test2 on) () ()auch funktioniert, deshalb meine Vermutung.
@Damian: Hast du das hier gesehen?
https://forum.fhem.de/index.php?topic=45373.new;topicseen
Nicht, dass nachher doch noch etwas am DOIF geändert werden muss.
Zitat von: FunkOdyssey am 10 April 2016, 23:35:46
@Damian: Hast du das hier gesehen?
https://forum.fhem.de/index.php?topic=45373.new;topicseen
Nicht, dass nachher doch noch etwas am DOIF geändert werden muss.
$SELF ist aus meiner Sicht nichts besonderes. Dann muss da noch eine Inkonsistenz in der Syntaxhervorhebung geben, das ist aber nicht meine Baustelle.
Ich habe in der Version noch ne Perl-Warnung gefunden:
PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/98_DOIF.pm line 1168, <FH> line 7512.
Ich kann dir aber leider noch nicht mehr Infos darüber geben.
Zitat von: FunkOdyssey am 18 April 2016, 14:54:30
Ich habe in der Version noch ne Perl-Warnung gefunden:
PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/98_DOIF.pm line 1168, <FH> line 7512.
Ich kann dir aber leider noch nicht mehr Infos darüber geben.
Benutzt du die Version 0.12?
Oh, sorry. Mein Fehler.
Ich aktualisiere mal. Da sind wohl ein paar Versionen an mir vorübergegangen.
Ich habe mit selftrigger 1 etwas rumgespielt und meines Erachtens einen Fehler gefunden. Einfache Testumgebung:
define dmyIfTest dummy
define ifTest DOIF ([dmyIfTest] eq "on") (set dmyIfTest off)
attr ifTest selftrigger 1
attr ifTest wait 5
mache ich nun set dmyIfTest on wird dieses durch ifTest nach 5 Sekunden ausgeschaltet. Das ifTest sieht dann aber so aus (es hat das off zwar gesehen, ist aber noch in cmd_1):
fhem> list ifTest
Internals:
CFGFN
DEF ([dmyIfTest] eq "on") (set dmyIfTest off)
NAME ifTest
NR 993
NTFY_ORDER 50-ifTest
STATE cmd_1
TYPE DOIF
Helper:
Dblog:
Cmd:
Dblog:
TIME 1461013100.6452
VALUE 1
Cmd_event:
Dblog:
TIME 1461013100.6452
VALUE dmyIfTest
Cmd_nr:
Dblog:
TIME 1461013100.6452
VALUE 1
State:
Dblog:
TIME 1461013100.6452
VALUE cmd_1
Wait_timer:
Dblog:
TIME 1461013100.6211
VALUE no timer
Readings:
2016-04-18 22:58:20 Device dmyIfTest
2016-04-18 22:58:20 cmd 1
2016-04-18 22:58:20 cmd_event dmyIfTest
2016-04-18 22:58:20 cmd_nr 1
2016-04-18 22:58:20 e_dmyIfTest_STATE off
2016-04-18 22:58:20 state cmd_1
2016-04-18 22:58:20 wait_timer no timer
Condition:
0 InternalDoIf($hash,'dmyIfTest','STATE','','',AttrVal($hash->{NAME},'notexist',undef)) eq "on"
Devices:
0 dmyIfTest
all dmyIfTest
Do:
0:
0 set dmyIfTest off
1:
Helper:
event off
globalinit 1
last_timer 0
sleepdevice dmyIfTest
sleepsubtimer -1
sleeptimer -1
timerdev dmyIfTest
timerevent off
triggerDev dmyIfTest
timerevents:
off
timereventsState:
state: off
triggerEvents:
off
triggerEventsState:
state: off
Internals:
0 dmyIfTest:STATE
all dmyIfTest:STATE
Itimer:
Readings:
Regexp:
0:
All:
State:
Trigger:
Attributes:
selftrigger 1
wait 5
Entsprechend wird beim nächsten Versuch dmyIfTest auch nicht mehr abgeschaltet. Mache ich dagegen nochmal explizit selbst ein set dmyIfTest off sieht das ifTest so aus und funktioniert wieder (jetzt ist es in cmd_2 gewechselt):
fhem> list ifTest
Internals:
CFGFN
DEF ([dmyIfTest] eq "on") (set dmyIfTest off)
NAME ifTest
NR 993
NTFY_ORDER 50-ifTest
STATE cmd_2
TYPE DOIF
Helper:
Dblog:
Cmd:
Dblog:
TIME 1461013212.23423
VALUE 2
Cmd_event:
Dblog:
TIME 1461013212.23423
VALUE dmyIfTest
Cmd_nr:
Dblog:
TIME 1461013212.23423
VALUE 2
State:
Dblog:
TIME 1461013212.23423
VALUE cmd_2
Wait_timer:
Dblog:
TIME 1461013100.6211
VALUE no timer
Readings:
2016-04-18 23:00:12 Device dmyIfTest
2016-04-18 23:00:12 cmd 2
2016-04-18 23:00:12 cmd_event dmyIfTest
2016-04-18 23:00:12 cmd_nr 2
2016-04-18 23:00:12 e_dmyIfTest_STATE off
2016-04-18 23:00:12 state cmd_2
2016-04-18 22:58:20 wait_timer no timer
Condition:
0 InternalDoIf($hash,'dmyIfTest','STATE','','',AttrVal($hash->{NAME},'notexist',undef)) eq "on"
Devices:
0 dmyIfTest
all dmyIfTest
Do:
0:
0 set dmyIfTest off
1:
Helper:
event off
globalinit 1
last_timer 0
sleepdevice dmyIfTest
sleepsubtimer -1
sleeptimer -1
timerdev dmyIfTest
timerevent off
triggerDev dmyIfTest
timerevents:
off
timereventsState:
state: off
triggerEvents:
off
triggerEventsState:
state: off
Internals:
0 dmyIfTest:STATE
all dmyIfTest:STATE
Itimer:
Readings:
Regexp:
0:
All:
State:
Trigger:
Attributes:
selftrigger 1
wait 5
Offenbar bekommt das ifTest zwar das off Event (dank selftrigger) mit, aber schaltet dann nicht in den richtigen cmd_2 Modus. Ohne das wait Attribut bekommt es übrigens auch das off nicht mit, aber es steht ja in der Doku, dass wait verwendet werden muss. Ein zusätzliches DOELSE () nützt ferner auch nichts. Der cmd_2 Status existiert ja.
Ich hatte mein ursprüngliches spezielleres Problem in einem eigenen Thread gepostet, bevor ich auf die neuste DOIF-Version mit selftrigger hingewiesen wurde. Jetzt konnte ich aber dieses Verhalten hardwareunabhängig mit dem dummy-Device nachstellen.
Viele Grüße,
-Sheridan
Wann wird denn das geplante Attribut "checkall" kommen? (https://forum.fhem.de/index.php/topic,51673.msg434164.html#msg434164 (https://forum.fhem.de/index.php/topic,51673.msg434164.html#msg434164))
Mir fällt gerade etwas bzgl. cmdState auf.
Ich habe drei CMDs mit jeweils verschiedenen Sequenzen.
- cmd1_1
- cmd1_2
- cmd2_1
- cmd2_2
- cmd3_1
- cmd3_2
Ich habe/hatte bisher folgendes Attribut:
cmdState JalAuf|JalHalb|JalZu
Für
cmd1_1 bis cmd1_2|cmd2_1 bis cmd2_2|cmd3_1 bis cmd3_2
Wenn mein DOIF aber (hier Jalousiensteuerung) mit cmd2_2 durch ist und ich bei den Sequenzen nicht weiter unterschieden habe, wird nun NICHT mehr JalAuf angezeigt.
Bin ich nun verpflichtet, für jede Sequenz ein cmdState zu definieren?
Oder auch in kurz:
Bei cmd1_1 habe ich kurz den STATE "JalAuf". Dieser wird mit cmd1_2 direkt wieder cmd1_2 überschrieben.
Wenn Du nur den Endzustand benötigst, könntest Du versuchen den cmd_x_1 leer mit einem Komma angeben.
cmdState ,JalAuf|,JalHalb|,JalZu
Danke für den Tipp. Ich rette mich wohl irgendwie. Notfalls definiere ich das halt mehrmals identisch.
Ich dachte nur, dass das evtl. ein Bug ist.
Schließlich kann ich beim wait-Attribut & Co. auch eine Zahl definieren, die über alle Teilsequenzen gültig wird.
ZitatSchließlich kann ich beim wait-Attribut & Co. auch eine Zahl definieren, die über alle Teilsequenzen gültig wird.
Du hast die Wirkung falsch gedeutet. Der Wait-Timer wirkt nur auf die 1. Sequenz. Für 2. Sequenz ist der ausgelassene Timer standartmässig 0. So, auch beim cmdState, Deine Angaben gelten für die 1. Sequenz. Für die 2. Sequenz wurde die Angabe ausgelassen, daher wird der Standartwert angezeigt. Mit dem Komma schiebst Du Deine Angaben eine Sequenz weiter. Das wäre beim Wait-Timer auch der Fall, dann würde die 2. Sequenz verzögert werden, und die Erste nicht. Die zu beobachtende Gesamtverzögerung wäre gleich.
Tatsache. Dann habe ich das wirklich falsch gedeutet.
Ich bin ja schon froh, dass du mich überhaupt verstanden hast. :-)
Ich wusste nicht genau, wie ich es beschreiben soll.
Zitat von: Damian am 19 März 2016, 22:12:40Attribut selftrigger erlaubt Selbsttriggerung über Wait
Schau mal bitte hier (https://forum.fhem.de/index.php/topic,52461.msg442558.html#msg442558) nach, ob es da Zusammenhänge gibt.
Zitat von: Damian am 19 März 2016, 22:12:40cmdState kann nun auch für Sequenzen cmd1_1, cmd1_2 usw. benutzt werden
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.
Zitat von: Per am 23 April 2016, 00:07:27
Schau mal bitte hier (https://forum.fhem.de/index.php/topic,52461.msg442558.html#msg442558) nach, ob es da Zusammenhänge gibt.
Selftrigger ist immer mit Vorsicht zu genießen. Die Probleme, die sich ergeben z. B. hier https://forum.fhem.de/index.php/topic,52354.0.html und im obigen Beispiel liegen darin begründet, dass beim Auslösen eines Triggers z. B.
DOIF (Bedingung) (set dummy on), der dazugehörige Status des DOIF-Moduls noch nicht gesetzt wird, sondern noch der vorherige Status existiert. Das geht auch nicht anders, da der Befehl zu diesem Zeitpunkt noch nicht abgeschlossen ist - er könnte auch einen Fehler liefern). Dadurch funktioniert der Mechanismus der internen Zustandsauswertung (ohne do always) nicht. Daher, wenn man mit Selftrigger arbeitet, am besten nur eigenen Status auswerten, der ja immer korrekt gesetzt ist, wenn er den Trigger auslöst.
Zitat
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.
Muss ich mir mal genauer anschauen. Ich denke ich werde Selftrigger so erweitern, dass man
Selftrigger wait und
Selfttrigger all (auch ohne wait) angeben kann, damit würde der Selftrigger immer funktionieren, wie früher mal. Allerdings sollte jeder wissen, dass spätestens in der zweiten Rekursionstiefe FHEM die Kette unterbricht.
Gruß
Damian
Zitat von: Per am 23 April 2016, 00:07:27
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.
Das habe ich nun unfreiwillig ausprobiert und das DOIF hat daraufhin gar nicht mehr funktioniert.
Ich hatte cmdState für 1_1, 1_2, etc. gleich betitelt. Und es wurde merkwürdigerweise kein einziger Ausführungsteil ausgeführt. Egal. Ich arbeite nun einfach ohne cmdState.
Zitat von: Damian am 19 März 2016, 22:12:40
Neue Features:
Attribut selftrigger erlaubt Selbsttriggerung über Wait
Attribut timerevent erzeugt Events beim Setzen von Timern
Gruß
Damian
Hallo.
Mit aktuellem DOIF finde ich diese 2 neuen Attr nicht. Heute update gemacht.
Mit der Version aus dem SVN?
Oder die Version aus dem ersten Posts des Threads?
afaik ist die Version noch nicht veröffentlicht. :-)
achso. dann muss ich mir die einspielen.
thx
Version 0.14 im ersten Post.
-kleine Korrekturen
-Attribut Selftrigger wait|all
-Doku angepasst.
Gruß
Damian
Zitat von: Damian am 30 März 2016, 21:42:22
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
Ich habe die letzte Version eingecheckt, damit ist morgen auch die Doku weltweit verfügbar.
Gruß
Damian
ZitatWä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
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 :(
Zitat von: Ellert am 29 April 2016, 05:15:28
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?
Zitat von: Damian am 28 April 2016, 21:24:28
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)?
Zitat von: Damian am 29 April 2016, 07:24:57
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
attr doif wait 1 zu
attr doif wait 1,1,1,1,1,1 ergänzt wird, je nach Zahl der Sequenzen in der DOIF-Definition
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
Zitat von: Damian am 29 April 2016, 13:54:50
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....
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.
Zitat von: Ellert am 29 April 2016, 17:30:10
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
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
(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.
############## 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.
Zitat von: Ellert am 30 April 2016, 08:40:48
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
(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.
############## 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:
attr di wait [$SELF:wait]+10Mit dem Vorschlag von Ralli ginge dann auch
starte mit einer Sekunde und verdopple jeweils die Zeit:
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
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.
Zitat von: Ellert am 30 April 2016, 14:56:36
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
Wäre es dann nicht flexibler, eine Funktion zu implementieren, mit der sich Attributwerte (wait, repeatcmd, repeatsame, cmdState, ...) einfach lesen und setzen lassen?
attrwert(<DOIFname>,<Attributname>,<Befehlszweig Nr>[, <Sequenz Nr>][, <Wert>]) falls Wert angegeben ist, wird das Attribut an entsprechender Stelle geändert.
Damit könnte man auch Attribute während der Befehlsausführung setzen, z.B.
-repeatcmd, um die Wiederholungszeit temperaturabhängig zu ändern, um die Wiederholung der "Fenster offen" Meldung zu kürzen, wenn es kälter wird
-wait, um "selftrigger wait" abzuschalten, weil der wait-Wert eines Zweiges auf 0 gesetzt wird.
- und auch dieses
ZitatEine 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.
Verhalten könnte damit noch flexibler gestaltet werden.
Eine solche Funktion eröffnet ungeahnte Möglichkeiten, birgt aber sicherlich auch einige Gefahren.
Zitat von: Ellert am 01 Mai 2016, 11:13:31
Eine solche Funktion eröffnet ungeahnte Möglichkeiten, birgt aber sicherlich auch einige Gefahren.
ja, allerdings geht das in die Richtung, gebe den Leuten ein goto und du wirst bald den produzierten Code nicht mehr nachvollziehen können, da möchte ich nicht hin.
Mein Anliegen ging in die andere Richtung: Mit einer Angabe (wie in meinen Bespielen) eine ganze Reihe zu definieren.
Diese Funktion würde das aber nicht leisten können, weil sie mit einer festen Sequenznummer arbeitet.
Zitatallerdings geht das in die Richtung, gebe den Leuten ein goto und du wirst bald den produzierten Code nicht mehr nachvollziehen können, da möchte ich nicht hin.
Das ist nachvollziehbar.
ZitatDiese Funktion würde das aber nicht leisten können, weil sie mit einer festen Sequenznummer arbeitet.
Ich denke schon,
Zitat(<Befehle>,{attrwert($SELF,"wait",0,1,attrwert($SELF,"wait",0,0)+2)}) (<Befehle>,{attrwert($SELF,"wait",0,2,attrwert($SELF,"wait",0,1)+2)}) (<Befehle>,{attrwert($SELF,"wait",0,3,attrwert($SELF,"wait",0,2)+2)})
durch einen verschachtelten Funktionsaufruf. Rot liest den Wert der aktuellen Sequenz aus dem Attribut und Blau schreibt den um 2 erhöhten Wert für die nächste Sequenz ins Attribut.
Allerdings, wenn ich mir die Menge Befehlstext ansehe, sieht es nicht gerade einfach aus :D
Zitat(die ich ja jetzt nicht eingecheckt habe)
Sollten meine Bedenken das verhindert haben, ziehe ich sie zurück.
Es ist wie mit dem "Pudding" ;)
Zitat von: Ellert am 01 Mai 2016, 15:10:58
Das ist nachvollziehbar.
Ich denke schon,durch einen verschachtelten Funktionsaufruf. Rot liest den Wert der aktuellen Sequenz aus dem Attribut und Blau schreibt den um 2 erhöhten Wert für die nächste Sequenz ins Attribut.
Allerdings, wenn ich mir die Menge Befehlstext ansehe, sieht es nicht gerade einfach aus :D
Sollten meine Bedenken das verhindert haben, ziehe ich sie zurück.
Es ist wie mit dem "Pudding" ;)
Die Version werde ich mir zur Seite legen. Wenn ich wieder Zeit finde (habe z. Zt. noch andere Projekte) werde ich es so ausbauen, dass man möglichst mit einem! Ausdruck (wie in meinen Beispielen) Verzögerungsreihen aufbauen kann (linear, exponentiell und was man sonst so in der Mathematik per Induktion (über Zugriff auf den Vorgänger) definieren kann). Die Angabe einer komplexen Funktion für jeden wait-Timer ist recht aufwändig und etwas für Profis. Sie lässt sich über myUtils, wie von dir vorgeschlagen, bereits heute realisieren.
Gruß
Damian