1) Wochentage
Mit folgender Version kann man jetzt eigene Wochentag-Benennungen vornehmen.
Es gibt jetzt das Attribut weekdays, mit diesem können statt Zahlenangaben beliebige Wochentag-Benennungen definiert werden.
Die Angaben werden mit Komma getrennt definiert und müssen mit Sonntag ( 0 ) beginnen und mit Arbeitstagen ( 8 ) enden.
Beispiel:
di_test attr weekdays So,Mo,Di,Mi,Do,Fr,Sa,WE,AT
Angabe in der Definition:
DOIF ([10:00|SoMo])...
oder z. B.
di_mydoif attr weekdays Sonntag,Montag,Dienstag,Mittwoch,Donnerstag,Freitag,Samstag,Wochenende,Arbeitstage
DOIF ([10:00|Arbeitstage])
Es wird wie bisher nach dem Vorkommen der Wochentagnamen gesucht, egal was sonst drin steht. Mit der obigen Definition funktioniert also auch:
DOIF ([10:00|Montag,Dienstag,blabla, Donnerstag sonstwas §$%Arbeitstageasdlfkj])...
Selbstverständlich funktioniert die Ersetzung auch bei indirekten Wochentagangaben aus Readings oder Dummys.
set wochentag Montag,Wochenende
DOIF ([10:00|[wochentag]])...
2) Timer-Management für indirekte Timer wurde überarbeitet. Eine fehlerhafte Definition führte bisher zum Fehler bei der Definition eines DOIF-Moduls - das Modul wurde beim Hochfahren nicht angelegt. Nun wird das DOIF-Modul angelegt, im jeweiligen Timer wird eine entsprechende Meldung abgelegt. Sobald der fehlerhafte Timer zur Laufzeit korrigiert wird, wird der entsprechende Timer gesetzt.
Das Modul ist wie immer voll abwärtskompatibel.
Edit: Version wurde eingecheckt.
Hallo,
das ist eine super Erweiterung mit den Wochentagen, da z.B. die FritzBox beim Wecker im reading alarm1_wday die Wochentage als Text liefert. Allerdings mit einem Leerzeichen getrennt z.B.: "Mo Tu We Th Fr". Wenn ich Deine Beschreibung richtig verstehe, müsste ich also die Leerzeichen eliminieren?
Beste Grüße
Torsten
Zitat von: ToKa am 20 März 2017, 23:19:28
Hallo,
das ist eine super Erweiterung mit den Wochentagen, da z.B. die FritzBox beim Wecker im reading alarm1_wday die Wochentage als Text liefert. Allerdings mit einem Leerzeichen getrennt z.B.: "Mo Tu We Th Fr". Wenn ich Deine Beschreibung richtig verstehe, müsste ich also die Leerzeichen eliminieren?
Beste Grüße
Torsten
nein. Wie schon beschrieben: es ist egal was sonst noch drinsteht, Leerzeichen oder sonstwas. Es reicht die Definition
attr weekdays Su,Mo,Tu,We,Th,Fr,Saund dann die Angabe in der Definition des DOIF:
DOIF ([<zeit>|[alarm1_wday]])...
ZitatDas liefert im Timer timer_01_c01 21.03.2017 06:15:00|[StarGateAP1:alarm2_wdays]
Müssten dort nicht jetzt die Wochentage auftauchen?
nein, es entspricht der bisherigen Vorgehensweise: die indirekte Wochentagangabe erscheint beim Timer, sie wird erst zum Triggerzeitpunkt ausgewertet.
hehe,
ich finds echt genial!
auf diesem wege nochmal vielen, vielen dank, dass du dich der idee angenommen hast und dann auch noch so derartig rasant reagiert hast!
gelöst hast is ja - wie immer - genial.
kanns kaum erwarten, dass du das offiziell machst. wann denkst den, wirds soweit sein und als offizielles update kommen?
Hallo Damian,
habe dein Modul aus dem ersten Beitrag heruntergeladen und Fhem neu gestartet. Bekomme aber folgende Fehlemeldungen:
2017.03.21 10:56:41 1: reload: Error:Modul 98_DOIF deactivated:
Global symbol "$lastWarningMsg" requires explicit package name at ./FHEM/98_DOIF.pm line 1088.
Global symbol "$lastWarningMsg" requires explicit package name at ./FHEM/98_DOIF.pm line 1095.
Global symbol "$lastWarningMsg" requires explicit package name at ./FHEM/98_DOIF.pm line 1096.
Global symbol "$lastWarningMsg" requires explicit package name at ./FHEM/98_DOIF.pm line 1097.
Global symbol "$lastWarningMsg" requires explicit package name at ./FHEM/98_DOIF.pm line 1101.
Fehlt da noch etwas, mache ich was falsch. Würde das neue Feature gerne nutzen.
Viele Grüße
devo
Zitat von: devo am 21 März 2017, 11:09:07
Hallo Damian,
habe dein Modul aus dem ersten Beitrag heruntergeladen und Fhem neu gestartet. Bekomme aber folgende Fehlemeldungen:
2017.03.21 10:56:41 1: reload: Error:Modul 98_DOIF deactivated:
Global symbol "$lastWarningMsg" requires explicit package name at ./FHEM/98_DOIF.pm line 1088.
Global symbol "$lastWarningMsg" requires explicit package name at ./FHEM/98_DOIF.pm line 1095.
Global symbol "$lastWarningMsg" requires explicit package name at ./FHEM/98_DOIF.pm line 1096.
Global symbol "$lastWarningMsg" requires explicit package name at ./FHEM/98_DOIF.pm line 1097.
Global symbol "$lastWarningMsg" requires explicit package name at ./FHEM/98_DOIF.pm line 1101.
Fehlt da noch etwas, mache ich was falsch. Würde das neue Feature gerne nutzen.
Viele Grüße
devo
Du brauchst die aktuelle Version von fhem.pl
Zitat von: the ratman am 21 März 2017, 11:02:11
hehe,
ich finds echt genial!
auf diesem wege nochmal vielen, vielen dank, dass du dich der idee angenommen hast und dann auch noch so derartig rasant reagiert hast!
gelöst hast is ja - wie immer - genial.
kanns kaum erwarten, dass du das offiziell machst. wann denkst den, wirds soweit sein und als offizielles update kommen?
Ich kann es im Grunde genommen jederzeit einchecken - meine Tests sind abgeschlossen. Allerdings können ein paar Tester im Vorfeld nicht schaden, zu mal sich größere Änderungen in dieser Version zusätzlich wegen indirekter Timer ergeben haben.
Hallo,
vielen Dank, nachdem fhem.pm durch ein update aktualisiert wurde, läuft es. Erste Test verliefen erfolgreich.
Vielen Dank für diese praktische Erweiterung!
Gruß
devo
kann auch nicht klagen ... alle doif's rennen bis jetzt normal weiter.
wochentagsdeffinition lässt sich einfügen und es gibt auch keine blöden meldungen im log.
das "neue" doif reagiert brav auf wochentagsänderungen.
war nun sicher kein ausgiebiger test, aber so siehts aus bei mir *g* <-- der onkel ist glücklich und zufrieden
ne frage: wenn ich sowieso nur 0 bis 6 brauch, muß ich dann 7 und 8 auch immer im weekdays mit deffinieren, oder is das dem guten doif egel, wenn ich faul bin?
Zitat von: the ratman am 21 März 2017, 12:31:40
kann auch nicht klagen ... alle doif's rennen bis jetzt normal weiter.
wochentagsdeffinition lässt sich einfügen und es gibt auch keine blöden meldungen im log.
das "neue" doif reagiert brav auf wochentagsänderungen.
war nun sicher kein ausgiebiger test, aber so siehts aus bei mir *g* <-- der onkel ist glücklich und zufrieden
ne frage: wenn ich sowieso nur 0 bis 6 brauch, muß ich dann 7 und 8 auch immer im weekdays mit deffinieren, oder is das dem guten doif egel, wenn ich faul bin?
Es ist ganz einfach. Die Definitionen fangen bei 0 also Sonntag an, was du nicht angibst wird auch nicht in Zahlen übersetzt. Wenn du also 7 und 8 nicht benötigst, dann kannst du die letzten Definitionen weglassen.
Und noch eins: Zahlenangaben funktionieren weiterhin, auch wenn man Umbenennung vorgenommen hat.
Ich habe die Sache noch etwas user-freundlicher gestaltet. Man kann jetzt neben den Ziffern auch Kürzel angeben, dh. das Attribut weekdays braucht nur noch definiert werden, wenn man andere Kürzel nehmen möchte. Die interne Default-Definition sieht so aus.
attr weekdays So,Mo,Di,Mi,Do,Fr,Sa,WE,AT
Die Doku wurde auch entsprechend angepasst.
@Ellert: Das Einsteigerbeispiel in der commandref habe ich auf die neue Syntax angepasst, weil es aussagekräftiger ist; müsste man dann noch im Wiki anpassen:
define di_clock_radio DOIF ([06:30|Mo Di Mi] or [08:30|Do Fr Sa So]) (set radio on) DOELSEIF ([08:00|Mo Di Mi] or [09:30|Do Fr Sa So]) (set radio off)
Neue Version im ersten Post. Wenn keine Einwände kommen, werde ich die neue Version morgen Abend einchecken.
Zitat von: Damian am 21 März 2017, 20:46:11
Ich habe die Sache noch etwas user-freundlicher gestaltet. Man kann jetzt neben den Ziffern auch Kürzel angeben, dh. das Attribut weekdays braucht nur noch definiert werden, wenn man andere Kürzel nehmen möchte. Die interne Default-Definition sieht so aus.
attr weekdays So,Mo,Di,Mi,Do,Fr,Sa,WE,AT
Die Doku wurde auch entsprechend angepasst.
@Ellert: Das Einsteigerbeispiel in der commandref habe ich auf die neue Syntax angepasst, weil es aussagekräftiger ist; müsste man dann noch im Wiki anpassen:
define di_clock_radio DOIF ([06:30|Mo Di Mi] or [08:30|Do Fr Sa So]) (set radio on) DOELSEIF ([08:00|Mo Di Mi] or [09:30|Do Fr Sa So]) (set radio off)
Neue Version im ersten Post. Wenn keine Einwände kommen, werde ich die neue Version morgen Abend einchecken.
Habe ich angepasst.
Neue Version wurde eingecheckt.
Hallo Damian,
habe gerade noch mal mit der neusten Version getestet. Entweder ich steh auf dem Schlauch und meine doif-Definition ist falsch oder es geht nicht ein reading für die Wochentage zu verwenden :(
List vom DOIF
Internals:
DEF ( [[StarGateAP1:alarm2_time]|[StarGateAP1:alarm2_wdays]] and
[StarGateAP1:alarm2_state] eq "on" )
## Nachtlicht für 10 Minuten zur Weckzeit einschalten, wenn Wecker aktiv und Wochentag stimmt
( {Log 3, 'Test Weekdays'} )
NAME di.02.ST.fl.SD.wakeUpLight.Torsten
NR 224
NTFY_ORDER 50-di.02.ST.fl.SD.wakeUpLight.Torsten
STATE 23.03.2017 18:10:00|[StarGateAP1:alarm2_wdays] (on)
TYPE DOIF
Readings:
2017-03-22 18:16:54 Device StarGateAP1
2017-03-22 07:00:17 cmd 2
2017-03-22 07:00:17 cmd_event StarGateAP1
2017-03-22 07:00:17 cmd_nr 2
2017-03-22 18:16:54 e_StarGateAP1_alarm2_state on
2017-03-22 07:00:17 state cmd_2
2017-03-22 18:10:00 timer_01_c01 23.03.2017 18:10:00|[StarGateAP1:alarm2_wdays]
Condition:
0 DOIF_time_once($hash,0,$wday,"[StarGateAP1:alarm2_wdays]") and ReadingValDoIf($hash,'StarGateAP1','alarm2_state') eq "on"
Days:
0 [StarGateAP1:alarm2_wdays]
Devices:
0 StarGateAP1
all StarGateAP1
Do:
0:
0 {Log 3, 'Test Weekdays'}
1:
Helper:
event box_wlanCount: 3,mac_34_D2_70_AB_1A_5D: linux (WLAN, 148 / 98 Mbit/s, -41),mac_20_64_32_D4_47_1D: Android (WLAN, 53 / 65 Mbit/s, -74),mac_4C_66_41_10_66_12: UPnP-Monkey-on-SM-N910F-10a698085f2eb7e9 (WLAN, 129 / 51 Mbit/s, -52),lastReadout: 304 values captured in 2.00 s
globalinit 1
last_timer 1
sleeptimer -1
timerdev StarGateAP1
timerevent box_wlanCount: 3,mac_34_D2_70_AB_1A_5D: linux (WLAN, 148 / 98 Mbit/s, -41),mac_20_64_32_D4_47_1D: Android (WLAN, 53 / 65 Mbit/s, -74),mac_4C_66_41_10_66_12: UPnP-Monkey-on-SM-N910F-10a698085f2eb7e9 (WLAN, 129 / 51 Mbit/s, -52),lastReadout: 304 values captured in 2.00 s
triggerDev StarGateAP1
timerevents:
box_wlanCount: 3
mac_34_D2_70_AB_1A_5D: linux (WLAN, 148 / 98 Mbit/s, -41)
mac_20_64_32_D4_47_1D: Android (WLAN, 53 / 65 Mbit/s, -74)
mac_4C_66_41_10_66_12: UPnP-Monkey-on-SM-N910F-10a698085f2eb7e9 (WLAN, 129 / 51 Mbit/s, -52)
lastReadout: 304 values captured in 2.00 s
timereventsState:
box_wlanCount: 3
mac_34_D2_70_AB_1A_5D: linux (WLAN, 148 / 98 Mbit/s, -41)
mac_20_64_32_D4_47_1D: Android (WLAN, 53 / 65 Mbit/s, -74)
mac_4C_66_41_10_66_12: UPnP-Monkey-on-SM-N910F-10a698085f2eb7e9 (WLAN, 129 / 51 Mbit/s, -52)
lastReadout: 304 values captured in 2.00 s
triggerEvents:
box_wlanCount: 3
mac_34_D2_70_AB_1A_5D: linux (WLAN, 148 / 98 Mbit/s, -41)
mac_20_64_32_D4_47_1D: Android (WLAN, 53 / 65 Mbit/s, -74)
mac_4C_66_41_10_66_12: UPnP-Monkey-on-SM-N910F-10a698085f2eb7e9 (WLAN, 129 / 51 Mbit/s, -52)
lastReadout: 304 values captured in 2.00 s
triggerEventsState:
box_wlanCount: 3
mac_34_D2_70_AB_1A_5D: linux (WLAN, 148 / 98 Mbit/s, -41)
mac_20_64_32_D4_47_1D: Android (WLAN, 53 / 65 Mbit/s, -74)
mac_4C_66_41_10_66_12: UPnP-Monkey-on-SM-N910F-10a698085f2eb7e9 (WLAN, 129 / 51 Mbit/s, -52)
lastReadout: 304 values captured in 2.00 s
Internals:
Interval:
Itimer:
all StarGateAP1
Localtime:
0 1490289000
Readings:
0 StarGateAP1:alarm2_state
all StarGateAP1:alarm2_state
Realtime:
0 18:10:00
Regexp:
0:
All:
State:
Time:
0 [StarGateAP1:alarm2_time]
Timecond:
0 0
Timer:
0 0
Timers:
0 0
Trigger:
Triggertime:
1490289000:
localtime 1490289000
Hash:
Attributes:
alias wakeUpLight Torsten2
group Zeitsteuerung Beleuchtung
icon socket_timer
room Zentrale Steuerung
sortby 2
stateFormat timer_01_c01 (e_StarGateAP1_alarm2_state)
verbose 5
weekdays So,Mo,Di,Mi,Do,Fr,Sa,WE,AT
Um 18:10 hätte es einen Logeintrag geben müssen, aber das Kommando wird nicht ausgeführt. Im StarGateAP1:alarm2_wdays steht aktuell: Mo Tu We Th Fr
Kannst Du mir weiterhelfen?
Beste Grüße
Torsten
Du willst, dass er am We schaltet und definierst aber Mi - das passt nicht ;)
Man wie blind war ich... wenn die Box englische Wochentage liefert, sollte man diese auch in weekdays definieren.
Vielen Dank für den Schubers in die richtige Richtung - jetzt funktioniert es :)
Hallo zusammen,
ich versuche gerade eine simple Zeitsteuerung für meine Rollos zu bauen. Leider bringt das DOIF einen Fehler (siehe Readings) und die timer passen noch nicht. Beispiel: timer_01_c01, müsste hier nicht stehen 22.04.2017 16:35:00|WE - da dies der nächste WE Tag ist?
defmod timer_Rollo_WZ_L DOIF ([[$SELF:WE_AUF,00:00]|WE] or [[$SELF:WD_AUF,00:00]|AT])(set Rollo_WZ_L up)\
DOELSEIF ([[$SELF:WE_AB,00:01]|WE] or [[$SELF:WD_AB,00:01]|AT])(set Rollo_WZ_L down)
attr timer_Rollo_WZ_L alias Wohnzimmer links
attr timer_Rollo_WZ_L group Rollo_Zeitsteuerung
attr timer_Rollo_WZ_L readingList WE_AUF WE_AB WD_AUF WD_AB
attr timer_Rollo_WZ_L room 99_Labor
attr timer_Rollo_WZ_L setList WE_AUF:time WE_AB:time WD_AUF:time WD_AB:time
attr timer_Rollo_WZ_L webCmd WE_AUF:WE_AB:WD_AUF:WD_AB
attr timer_Rollo_WZ_L weekdays So,Mo,Di,Mi,Do,Fr,Sa,WE,AT
Readings:
2017-04-18 16:24:33 WD_AB 16:30
2017-04-17 14:26:44 WD_AUF 08:00
2017-04-17 14:26:35 WE_AB 22:00
2017-04-18 16:24:40 WE_AUF 16:35
2017-04-18 16:30:00 cmd 2
2017-04-18 16:30:00 cmd_event timer_4
2017-04-18 16:30:00 cmd_nr 2
2017-04-18 16:47:26 error timer_Rollo_WZ_L: error in default: 00:01
2017-04-18 16:30:00 state cmd_2
2017-04-18 16:47:26 timer_01_c01 19.04.2017 16:35:00|WE
2017-04-18 16:47:26 timer_02_c01 19.04.2017 08:00:00|AT
2017-04-18 16:47:26 timer_03_c02 18.04.2017 22:00:00|WE
2017-04-18 16:47:26 timer_04_c02 19.04.2017 16:30:00|AT
Hatte bereits doppelte Klammern und verschiedene andere Kombinationen probiert aber im Moment seh ich den Wald vor lauter Bäumen nicht.
Hat jemand einen Tipp?
Danke & Gruss Sven
müsste hier nicht stehen 22.04.2017 16:35:00|WE - da dies der nächste WE Tag ist?
Es wird immer der aktuelle Tag oder der nächste Tag angezeigt. Ausgelöst wird aber nur, wenn die Wochentagbeschränkung zutrifft.
Den Default-Wert müsstest Du in Anführungszeichen setzen.
Super, klappt. Vielen Dank für die schnelle Antwort. Gruss Sven
Hey,
ich versuche gerade die Wochentagsfunktion mit einem Regex aus einem Reading zu verwenden.
Mit den Zeiten funktioniert das auch super. Vielleicht ist auch eine Verkettung nicht möglich?
Folgendes Beispiel übergibt mein Reading, dass ich auslese:
20:51-20:52|2345|
Daraus mache ich dann im DOIF folgendes:
([
[dummyTest:state:[([0-9]{2}:[0-9]{2})]]
-[dummyTest:state:[((?<=.).[0-9]:[0-9]{2})]] |
[dummyTest:state:[((?<=.{12})[0-9]*)]]
]) (set Kreis1 on) DOELSE (set Kreis1 off)
leider wird das regex für die nummern nicht übernommen.
Ich bekomme die Meldung:
SetKreis1 DOIF: right bracket without left bracket: 9]*)]]
doch meines Erachtens fehlt dort nichts.
Vielleicht kann mich jemand eines besseren belehren.
Grüße
Was es alles gibt :)
Du möchtest Ausgabeformatierung bei Timern verwenden. Das ist zwar nirgends beschrieben und von mir nicht getestet, aber es könnte funktionieren :)
Warum hast du die Regex-Angaben in eckige Klammern gesetzt, sie werden lt. Commandref
Syntax: [<device>:<reading>|<internal>:d<number>|"<regex>":<output>]
in Anführungszeichen angegeben, also z. B.:
[dummyTest:state:"([0-9]{2}:[0-9]{2})"]
Hey Damian,
Um genau zu sein, möchte ich die Wochentage aus dem Reading filtern, die in 1234 angegeben werden.
DOIF kann zum Beispiel folgendes ohne Probleme:
([
[dummyTest:state:"([0-9]{2}:[0-9]{2})"]
-[dummyTest:state:"((?<=.).[0-9]:[0-9]{2})"] |1234
]) (set Kreis1 on) DOELSE (set Kreis1 off)
Das Problem entsteht erst mit dem dritten Regex
Muss ich die Wochentage als MoDi definieren?
Hab mal die Syntax umgestellt ;)
Bei mir wird der Ausdruck soweit erkannt.
Die Wochentagangaben werden erst zum Triggerzeitpunkt ausgewertet, daher steht der Ausdruck für die Wochentage wie angegeben hinter der Zeit bei den Timerreadings.
Internals:
CFGFN
DEF ([
[d_test:state:"([0-9]{2}:[0-9]{2})"]-[d_test:state:"((?<=.).[0-9]:[0-9]{2})"]|[d_test:state:"((?<=.{12})[0-9]*)"]
])
MODEL FHEM
NAME di_test1
NR 7516
NTFY_ORDER 50-di_test1
STATE initialized
TYPE DOIF
READINGS:
2018-07-24 21:53:21 cmd 0
2018-07-24 21:53:21 mode enabled
2018-07-24 21:53:21 state initialized
2018-07-24 21:53:21 timer_01_c01 25.07.2018 05:00:00|[d:test:state:"((?<=.{12})[0-9]*)"]
2018-07-24 21:53:21 timer_02_c01 25.07.2018 06:00:00|[d:test:state:"((?<=.{12})[0-9]*)"]
Regex:
condition:
0 DOIF_time($hash,0,1,$wday,$hms,"[d_test:state:"((?<=.{12})[0-9]*)"]")
days:
0 [d_test:state:"((?<=.{12})[0-9]*)"]
1 [d_test:state:"((?<=.{12})[0-9]*)"]
devices:
do:
0:
0
1:
helper:
globalinit 1
last_timer 2
sleeptimer -1
interval:
0 -1
1 0
intervalfunc:
itimer:
all d_test
localtime:
0 1532487600
1 1532491200
realtime:
0 05:00:00
1 06:00:00
time:
0 [d_test:state:"([0-9]{2}:[0-9]{2})"]
1 [d_test:state:"((?<=.).[0-9]:[0-9]{2})"]
timeCond:
0 0
1 0
timer:
0 0
1 0
timers:
0 0 1
triggertime:
1532487600:
localtime 1532487600
hash:
1532491200:
localtime 1532491200
hash:
uiState:
uiTable:
Attributes:
Edit:
Das Problem wird wohl wegen doppelter Anführungszeichen dieser Perl-Ausdruck sein:
DOIF_time($hash,0,1,$wday,$hms,"[d_test:state:"((?<=.{12})[0-9]*)"]")
Alternativ könnte man die drei Zeitangaben in DOIF_Readings ablegen.
Moment mal.
Also ich habe mal deinen Test:
([
[d_test:state:"([0-9]{2}:[0-9]{2})"]-[d_test:state:"((?<=.).[0-9]:[0-9]{2})"]|[d_test:state:"((?<=.{12})[0-9]*)"]
])
Ich bekomme jedoch weiter die Meldung: SetKreis1 DOIF: right bracket without left bracket: 9]*)"]
Theoretisch könnte ich ja auch nach den "| |" filtern und sie im selben regex nicht berücksichtigen.
Aber wie nur? :o
Wie würde denn so ein DOIF Rediang dafür aussehen?
Da bin ich überfragt.
Edit: Leider geht auch das Folgende Regex nicht:
[dummyTest:state:"(?<=.{12})(.*)(?=\|)
Ich bekomme als timer nicht die werte aufgelistet, sondern das: timer_01_c01
24.07.2018 22:32:00|[dummyTest:state:"(?<=\|)(.*)(?=\|)"]
Grüße
Dann hast du evtl. nicht die aktuelle DOIF-Version.
Mit DOIF-Readings:
Internals:
CFGFN
DEF ([
[$SELF:anfang]-[$SELF:ende]|[$SELF:woche]
])
MODEL FHEM
NAME di_test1
NR 7516
NTFY_ORDER 50-di_test1
STATE initialized
TYPE DOIF
DOIF_Readings:
anfang ReadingValDoIf($hash,'d_test','state','','([0-9]{2}:[0-9]{2})')
ende ReadingValDoIf($hash,'d_test','state','','((?<=.).[0-9]:[0-9]{2})')
woche ReadingValDoIf($hash,'d_test','state','','((?<=.{12})[0-9]*)')
READINGS:
2018-07-24 23:20:08 anfang 05:00
2018-07-24 23:19:53 cmd 0
2018-07-24 23:20:08 ende 06:00
2018-07-24 23:19:53 mode enabled
2018-07-24 23:19:53 state initialized
2018-07-24 23:20:08 timer_01_c01 25.07.2018 05:00:00|[di_test1:woche]
2018-07-24 23:20:08 timer_02_c01 25.07.2018 06:00:00|[di_test1:woche]
2018-07-24 23:20:08 woche 123
Regex:
DOIF_Readings:
d_test:
anfang:
state ^d_test$:^state:
ende:
state ^d_test$:^state:
woche:
state ^d_test$:^state:
condition:
0 DOIF_time($hash,0,1,$wday,$hms,"[di_test1:woche]")
days:
0 [di_test1:woche]
1 [di_test1:woche]
devices:
do:
0:
0
1:
helper:
DOIF_Readings_events
globalinit 1
last_timer 2
sleeptimer -1
interval:
0 -1
1 0
intervalfunc:
intervaltimer:
itimer:
all di_test1
localtime:
0 1532487600
1 1532491200
realtime:
0 05:00:00
1 06:00:00
time:
0 [di_test1:anfang]
1 [di_test1:ende]
timeCond:
0 0
1 0
timer:
0 0
1 0
timers:
0 0 1
triggertime:
1532487600:
localtime 1532487600
hash:
1532491200:
localtime 1532491200
hash:
uiState:
uiTable:
Attributes:
DOIF_Readings anfang:[d_test:state:"([0-9]{2}:[0-9]{2})"],ende:[d_test:state:"((?<=.).[0-9]:[0-9]{2})"],woche:[d_test:state:"((?<=.{12})[0-9]*)"]
Die DOIF_Readings werden erst gesetzt, wenn d_test aktualisiert wird
hier z. B mit
set d_test 05:00-06:00|123
Vielen Dank für den Hinweis.
Habe mal ein Update durchlaufen lassen und scheibar war ich hinter dem DOIF_Readings Stand.
Auf DOIF_Readings schaltet das DOIF nun, jetzt muss ich nur noch rausbekommen, wie ich einen dummy damit trigger.
Edit: Hat sich auch gerade gelöst.
Dankeschön für die tolle und späte Hilfe ;D
Zitat von: Syrex-o am 24 Juli 2018, 23:55:00
Dankeschön für die tolle und späte Hilfe ;D
Warum spät, meine Reaktionszeit nach deiner ersten Anfrage betrug gerade mal 34 Minuten ;)
ich glaube das war auf die Uhrzeit bezogen ;-)
Zitat von: l2r am 25 Juli 2018, 09:19:55
ich glaube das war auf die Uhrzeit bezogen ;-)
Dann hätte es wohl zur späten Zeitstunde heißen müssen ;) immerhin Problem gelöst.
Zitat von: Damian am 25 Juli 2018, 09:38:42
Dann hätte es wohl zur späten Zeitstunde heißen müssen ;) immerhin Problem gelöst.
@Damian Aber natürlich meinte ich zu später Stunde ;D