Hallo,
nach dem ich ein bisschen Systempflege machen wollte, hat sich ein (alter?) Fehler wieder gezeigt.
Mein letztes Update war vom 14.12.2017 (Versionsnummer hab ich nicht gefunden). Mit dem heutigen Update habe ich die Meldung:
Modification of non-creatable array value attempted, subscript -1 at ./FHEM/98_DOIF.pm line 1908.
im Log und Fhem hängt sich auf :-[
Hatte diesen(?) Fehler schon mal und konnte ihn durch ändern von selftrigger all in selftrigger wait beheben.
https://forum.fhem.de/index.php/topic,78473.15.html (https://forum.fhem.de/index.php/topic,78473.15.html)
Wie kann ich dem neuen(alten) Problem auf die Schliche kommen.
Viele Grüße,
Rob
Zitat von: Robert1963 am 22 Dezember 2017, 06:21:22
Hallo,
nach dem ich ein bisschen Systempflege machen wollte, hat sich ein (alter?) Fehler wieder gezeigt.
Mein letztes Update war vom 14.12.2017 (Versionsnummer hab ich nicht gefunden). Mit dem heutigen Update habe ich die Meldung:
Modification of non-creatable array value attempted, subscript -1 at ./FHEM/98_DOIF.pm line 1908.
im Log und Fhem hängt sich auf :-[
Hatte diesen(?) Fehler schon mal und konnte ihn durch ändern von selftrigger all in selftrigger wait beheben.
https://forum.fhem.de/index.php/topic,78473.15.html (https://forum.fhem.de/index.php/topic,78473.15.html)
Wie kann ich dem neuen(alten) Problem auf die Schliche kommen.
Viele Grüße,
Rob
In der Zeile 1908 der aktuellen DOIF Version steht:
my ($seconds, $microseconds) = gettimeofday();das kann nicht zu diesem Problem führen;
shutdown restart vergessen? https://wiki.fhem.de/wiki/DOIF/Tools_und_Fehlersuche#Neustart_nach_Update_automatisieren
@ Damian
Hatte ich mir auch schon angekuckt, aber kein Urteil gewagt.
Fhem mit "altem" DOIF läuft jetzt den ganzen Tag normal.
Frage: Worin genau bestehen die Unterschiede der beiden Versionen
@ Ellert
;) Natürlich
Zitat von: Robert1963 am 22 Dezember 2017, 17:21:16
@ Damian
Hatte ich mir auch schon angekuckt, aber kein Urteil gewagt.
Fhem mit "altem" DOIF läuft jetzt den ganzen Tag normal.
Frage: Worin genau bestehen die Unterschiede der beiden Versionen
@ Ellert
;) Natürlich
Seit dem 14.12.2017 hat sich nichts geändert, die letzte Version ist vom 05.12.2017.
OK,
wird wohl das Datum meines NAS Tests sein. ::)
Letzte funktionierende Version: 98_DOIF.pm 14790 2017-07-26
Hab grad ein wenig Stress, beim aufrufen eines beliebigen DOIF in der Version 14790 und dem restl. akt. Dateien (Update) schmiert Fhem mit
Undefined subroutine &main::DOIF_detailFn called at ./FHEM/98_DOIFtools.pm line 347.
ab.
Passt wohl alles nicht zusammen. Das zurückspielen der gestrigen fhem.cfg, fhem.pl und FHEM (Modulordner) allein bracht nichts.
Schiebe grad ein Backup von Gestern rauf um erst mal den WAF wieder zu erhöhen.
Ach ja:
my ($seconds, $microseconds) = gettimeofday(); taucht bei mir ganz woanders auf, Notepad++.
Wo liegt mein Fehler?
Hab nochmal gecheckt, falsche DOIF bekuckt ::)
Fhem pegelt sich grade wieder ein, 98_DOIF.pm 14790 2017-07-26 .
Werde erst mal die die DOIF/Tools Fehlersuche weiter verinnerlichen und in einem ruhigeren Moment nochmal ein Update angehen.
Vielen Dank für eure Zeit,
schöne Festtage,
Rob
Zitat von: Robert1963 am 22 Dezember 2017, 19:10:22
OK,
wird wohl das Datum meines NAS Tests sein. ::)
Letzte funktionierende Version: 98_DOIF.pm 14790 2017-07-26
Hab grad ein wenig Stress, beim aufrufen eines beliebigen DOIF in der Version 14790 und dem restl. akt. Dateien (Update) schmiert Fhem mit
Undefined subroutine &main::DOIF_detailFn called at ./FHEM/98_DOIFtools.pm line 347.
ab.
Passt wohl alles nicht zusammen. Das zurückspielen der gestrigen fhem.cfg, fhem.pl und FHEM (Modulordner) allein bracht nichts.
Schiebe grad ein Backup von Gestern rauf um erst mal den WAF wieder zu erhöhen.
Ach ja:
my ($seconds, $microseconds) = gettimeofday(); taucht bei mir ganz woanders auf, Notepad++.
Wo liegt mein Fehler?
Hab nochmal gecheckt, falsche DOIF bekuckt ::)
Fhem pegelt sich grade wieder ein, 98_DOIF.pm 14790 2017-07-26 .
Werde erst mal die die DOIF/Tools Fehlersuche weiter verinnerlichen und in einem ruhigeren Moment nochmal ein Update angehen.
Vielen Dank für eure Zeit,
schöne Festtage,
Rob
hier: Undefined subroutine &main::DOIF_detailFn called at ./FHEM/98_DOIFtools.pm line 347.
DOIFtools merkt sich nach FHEM Initialisierung die DOIF_detailFn. Wenn nach einem Downgrade von DOIF keine DOIF_detailFn aufgerufen werden kann, weil das alte DOIF keine bereitstellt, dann führt das zu dem Fehler.
Bei einem Downgrade gilt um so mehr, dass ein "shutdown restart duchzuführen ist". Es sollte auch immer das komplette FHEM aktualisiert werden, dann ist sicher gestellt, dass alle Module und Versionen, die von einander abhängen auch zu einander passen.
Hallo,
ich habe dieses Problem auch häufiger, aber keine Ahnung von welchem der hundert DOIFs der kommt.
Modification of non-creatable array value attempted, subscript -1 at ./FHEM/98_DOIF.pm line 1905.
Kann man im Perlcode nicht grundsätzlich einen negativen Index abfangen?
Grüße
Hanske
Zitat von: hanske am 21 Februar 2018, 18:44:22
Hallo,
ich habe dieses Problem auch häufiger, aber keine Ahnung von welchem der hundert DOIFs der kommt.
Modification of non-creatable array value attempted, subscript -1 at ./FHEM/98_DOIF.pm line 1905.
Kann man im Perlcode nicht grundsätzlich einen negativen Index abfangen?
Grüße
Hanske
zunächst musst du auf das aktuelle Modul aktualisieren: # $Id: 98_DOIF.pm 16182 2018-02-14 21:36:04Z Damian $
Ok, danke.
Probiere ich gleich mal aus.
Ist aber schon seit einigen Updates so.
Hallo Damian,
ich habe am 21.02. ein Update gemacht.
Leider tritt der Fehler immer noch auf:
Modification of non-creatable array value attempted, subscript -1 at ./FHEM/98_DOIF.pm line 1906
Wie kann ich eigentlich die gerade genutzte DOIF Versionsnummer abfragen?
Grüße
Hast Du nach dem Update shutdown restart durchgeführt? Siehe dazu https://wiki.fhem.de/wiki/DOIF/Tools_und_Fehlersuche#FHEM_aktuell_halten
Zitat
Wie kann ich eigentlich die gerade genutzte DOIF Versionsnummer abfragen?
DOIFtools zeigt sie und auch die FHEM Revision in der Detailansicht an.
Hi,
ja klar, mache dann immer ein Restart.
Ich benutze folgende Version:
98_DOIF.pm 16182 2018-02-14 21:36:04Z Damian
Ich habe inzwischen mehrmals täglich den Absturz durch ein DOIF.
Modification of non-creatable array value attempted, subscript -1 at ./FHEM/98_DOIF.pm line 1906.
Ein cron job startet mir jetzt glücklicherweise FHEM dann wieder neu.
Kann ich irgendwie weiter analysieren, wenn man den Fehler nicht direkt im Sourcecode abfangen kann?
Danke und Grüße
hanske
Zitat von: hanske am 26 Februar 2018, 09:37:28
Hi,
ja klar, mache dann immer ein Restart.
Ich benutze folgende Version:
98_DOIF.pm 16182 2018-02-14 21:36:04Z Damian
Ich habe inzwischen mehrmals täglich den Absturz durch ein DOIF.
Modification of non-creatable array value attempted, subscript -1 at ./FHEM/98_DOIF.pm line 1906.
Ein cron job startet mir jetzt glücklicherweise FHEM dann wieder neu.
Kann ich irgendwie weiter analysieren, wenn man den Fehler nicht direkt im Sourcecode abfangen kann?
Danke und Grüße
hanske
Man müsste jetzt wissen, wie die Definition des DOIF-Devices aussieht.
Ich kann den Fehler zunächst abfangen. Die Ursache wäre interessanter.
Hallo und Guten Morgen zusammen
auch bei mir ist nach dem heutigen Update fhem nicht wieder per browser erreichbar gewesen, da ich täglich ein update laufen lasse - habe ich festgestellt das es nicht doif sein kann, denn diese pm war heute nicht dabei - meiner logdatei nach, hängt sich fhem nach etwas anderem auf
2018.02.26 10:46:07 1: ERROR evaluating my $NAME='global';my $TYPE='Global';my $EVENT='INITIALIZED';my $SELF='fhem_not';my $EVTPART0='INITIALIZED';{fhem_not();}: Undefined subroutine &main::fhem_not called at (eval 856) line 1.
Gruss tagedieb
Guten Morgen,
bei mir auch. In meiner Installation wurden folgende Module erneuert:
List of new / modified files since last update:
UPD ./CHANGED
UPD FHEM/00_FBAHA.pm
UPD FHEM/00_MQTT.pm
UPD FHEM/10_CUL_HM.pm
UPD FHEM/10_EQ3BT.pm
UPD FHEM/10_FBDECT.pm
UPD FHEM/10_MQTT_DEVICE.pm
UPD FHEM/10_ZWave.pm
UPD FHEM/14_CUL_TCM97001.pm
UPD FHEM/23_LUXTRONIK2.pm
UPD FHEM/30_DUOFERN.pm
UPD FHEM/49_SSCam.pm
UPD FHEM/72_FRITZBOX.pm
UPD FHEM/73_ElectricityCalculator.pm
UPD FHEM/73_GasCalculator.pm
UPD FHEM/73_WaterCalculator.pm
UPD FHEM/93_DbLog.pm
UPD FHEM/93_DbRep.pm
UPD FHEM/95_Babble.pm
UPD FHEM/98_DOIFtools.pm
UPD FHEM/98_GOOGLECAST.pm
UPD FHEM/98_SVG.pm
UPD FHEM/98_freezemon.pm
UPD FHEM/99_SUNRISE_EL.pm
UPD FHEM/HMConfig.pm
UPD contrib/commandref_join.pl
UPD www/pgm2/babble.js
UPD www/pgm2/f18.js
Leider gibt es bei mir im Log überhaupt keine Fehlermeldung, welche Komponente ein Problem verursacht. Fhem bleibt einfach hängen. Hier mal zur Gegenüberstellung:
Erfolgreicher Start:
2018.02.26 11:20:17.844 1: Including fhem.cfg
2018.02.26 11:20:17.920 3: telnetPort: port 7072 opened
2018.02.26 11:20:18.817 3: WEB: port 8083 opened
2018.02.26 11:20:18.818 3: WEBphone: port 8084 opened
2018.02.26 11:20:18.818 3: WEBtablet: port 8085 opened
2018.02.26 11:20:18.987 2: eventTypes: loaded 3031 events from log/eventTypes.txt
2018.02.26 11:20:21.935 1: HMCCU: Device CCU2. Initialized version 4.2.002
2018.02.26 11:20:25.221 1: HMCCU: Read 110 devices with 482 channels from CCU 10.0.0.20
2018.02.26 11:20:25.221 1: HMCCU: Read 4 interfaces from CCU 10.0.0.20
2018.02.26 11:20:25.421 1: HMCCURPC: Device CCU2_rpc. Initialized version 1.0
2018.02.26 11:20:26.834 1: SONOS0: Modify Device: Sonos
2018.02.26 11:20:26.881 1: SONOS0: Modify SonosPlayer-Device: Sonos_Schlafzimmer
2018.02.26 11:20:26.976 1: SONOS0: Modify SonosPlayer-Device: Sonos_Kind1
2018.02.26 11:20:26.978 1: SONOS0: Modify SonosPlayer-Device: Sonos_Esszimmer
2018.02.26 11:20:26.981 1: SONOS0: Modify SonosPlayer-Device: Sonos_Bad
2018.02.26 11:20:26.983 1: SONOS0: Modify SonosPlayer-Device: Sonos_Kueche
2018.02.26 11:20:26.986 1: SONOS0: Modify SonosPlayer-Device: Sonos_HWR
2018.02.26 11:20:26.988 1: SONOS0: Modify SonosPlayer-Device: Sonos_Kind2
2018.02.26 11:20:27.333 3: WZ_Lampe_Sub: I/O device is LIGHTIFY_GW
2018.02.26 11:20:27.334 3: LNA_Tischlampe: I/O device is LIGHTIFY_GW
2018.02.26 11:20:28.071 3: [STV] defined with host: 10.0.0.33 port: 55000 MAC: 00:0c:29:79:b1:12
2018.02.26 11:20:28.292 3: TelegramBot_Define Telegram: called
2018.02.26 11:20:29.071 3: LIGHTIFYGroup0: I/O device is LIGHTIFY_GW
2018.02.26 11:20:29.072 3: LIGHTIFYGroup1: I/O device is LIGHTIFY_GW
2018.02.26 11:20:29.074 3: LIGHTIFYGroup2: I/O device is LIGHTIFY_GW
2018.02.26 11:20:29.107 1: HMCCURPCPROC: [d_rpcBidCos_RF] Initialized version 1.0.002 for interface BidCos-RF
2018.02.26 11:20:29.108 1: HMCCURPCPROC: [d_rpcBidCos_Wired] Initialized version 1.0.002 for interface BidCos-Wired
2018.02.26 11:20:29.108 1: HMCCURPCPROC: [d_rpcHmIP_RF] Initialized version 1.0.002 for interface HmIP-RF
2018.02.26 11:20:29.109 1: Including ./log/fhem.save
2018.02.26 11:20:29.181 0: HMCCU: Start of RPC server after FHEM initialization in 12 seconds
2018.02.26 11:20:29.681 3: LIGHTIFY_GW: connected to 10.0.0.73
2018.02.26 11:20:29.685 0: Featurelevel: 5.8
2018.02.26 11:20:29.685 0: Server started with 284 defined entities (fhem.pl:16228/2018-02-20 perl:5.022001 os:linux user:fhem pid:1287)
Fehlerhafter Start:
2018.02.26 11:16:14.871 1: Including fhem.cfg
2018.02.26 11:16:14.946 3: telnetPort: port 7072 opened
2018.02.26 11:16:16.239 3: WEB: port 8083 opened
2018.02.26 11:16:16.239 3: WEBphone: port 8084 opened
2018.02.26 11:16:16.240 3: WEBtablet: port 8085 opened
2018.02.26 11:16:16.461 2: eventTypes: loaded 3031 events from log/eventTypes.txt
2018.02.26 11:16:20.510 1: HMCCU: Device CCU2. Initialized version 4.2.002
2018.02.26 11:16:23.604 1: HMCCU: Read 110 devices with 482 channels from CCU 10.0.0.20
2018.02.26 11:16:23.604 1: HMCCU: Read 4 interfaces from CCU 10.0.0.20
2018.02.26 11:16:23.844 1: HMCCURPC: Device CCU2_rpc. Initialized version 1.0
2018.02.26 11:16:24.663 1: SONOS0: Modify Device: Sonos
2018.02.26 11:16:24.686 1: SONOS0: Modify SonosPlayer-Device: Sonos_Schlafzimmer
2018.02.26 11:16:24.750 1: SONOS0: Modify SonosPlayer-Device: Sonos_Kind1
2018.02.26 11:16:24.752 1: SONOS0: Modify SonosPlayer-Device: Sonos_Esszimmer
2018.02.26 11:16:24.755 1: SONOS0: Modify SonosPlayer-Device: Sonos_Bad
2018.02.26 11:16:24.757 1: SONOS0: Modify SonosPlayer-Device: Sonos_Kueche
2018.02.26 11:16:24.759 1: SONOS0: Modify SonosPlayer-Device: Sonos_HWR
2018.02.26 11:16:24.761 1: SONOS0: Modify SonosPlayer-Device: Sonos_Kind2
2018.02.26 11:16:25.009 3: WZ_Lampe_Sub: I/O device is LIGHTIFY_GW
2018.02.26 11:16:25.010 3: LNA_Tischlampe: I/O device is LIGHTIFY_GW
2018.02.26 11:16:25.410 3: [STV] defined with host: 10.0.0.33 port: 55000 MAC: 00:0c:29:79:b1:12
2018.02.26 11:16:25.690 3: TelegramBot_Define Telegram: called
Ok,
dann mache ich lieber erst mal kein Update.
Bisher stürzt FHEM ja "nur" ab und zu ab.
Welches DOIF das verursacht kann ich leider nicht sagen.
Vor einem halbe Jahr hatte ich eine reproduzierbare Zeile im DOIF, die das verursacht hat.
Die Zeile war aber komplett unauffällig.
Das DOIF war sehr lang mit ca. zehn DOELSEIFs und an die 30 Bedingungen.
Ich habe sie dann rausgeschmissen und baue jetzt lieber kleinere DOIFs.
Leider tritt der Fehler jetzt wieder auf, aber ich weiß nicht von wo.
Grüße
hanske
Aktuell ist es wohl das fritzbox Modul dass den Start verhindert.
Mit dem Handy online, daher kurz gefasst...
Zitat von: hanske am 26 Februar 2018, 09:37:28
Hi,
ja klar, mache dann immer ein Restart.
Ich benutze folgende Version:
98_DOIF.pm 16182 2018-02-14 21:36:04Z Damian
Ich habe inzwischen mehrmals täglich den Absturz durch ein DOIF.
Modification of non-creatable array value attempted, subscript -1 at ./FHEM/98_DOIF.pm line 1906.
Ein cron job startet mir jetzt glücklicherweise FHEM dann wieder neu.
Kann ich irgendwie weiter analysieren, wenn man den Fehler nicht direkt im Sourcecode abfangen kann?
Danke und Grüße
hanske
Es müsste ein DOIF-Device sein, welches cmdpause benutzt.
Du kannst die angehängte Version testen.
cmdpause ist ein guter Hinweis, das benutze ich nur selten.
Ich kann mal gucken, ob ich es temporär abschalten kann.
Zitat von: hanske am 27 Februar 2018, 12:51:08
cmdpause ist ein guter Hinweis, das benutze ich nur selten.
Ich kann mal gucken, ob ich es temporär abschalten kann.
Ich würde erst mal nur die gepatchte DOIF-Version drauf spielen und nichts an der Konfiguration ändern, damit ich weiß, ob das Problem damit behoben ist.
Hallo,
seit nunmehr 4 Tagen komme ich nur noch zu spät ins Bett, weil sich Fhem immer zwischen 22 und 24 Uhr so aufhängt, das nicht mal ein reboot hilft. Der Fhem Prozess endet immer bei 100% CPU.
Um es kurz zumachen, habe ich gestern den Übeltäter finden können, und erstmal aus der cfg geschmissen.
Sobald folgendes DOIF im cfg steht, hängt sich Fhem genau um 23:15 auf.
DEF ([RollosOst] eq "closed")
(set WandTableau ttsSay Rolladen vorne sind nun zu)
DOELSEIF ([([Wecker] - [06:15])|01234] and [?Bubu] == 0 and [?Status] eq "Alltag")
(set WandTableau audioPlay /Audio/soft-bells.mp3, set Gigablue msg message 5 Nun aber ins Bett !)
DOELSE
Augenmerk also auf den DOELSEIF Teil. Das Ganze DOIF lief allerdings schon seit Monaten einwandfrei. Das Problem kann also erst nach dem letzten Update (Samstag) akut sein. Die Zeitberechnung [([Wecker] - [06:15])|01234] ist laut Commadref in Ordnung. Das Wecker Dummy hat den Wert 05:30. Außerdem kommt der Befehl derzeit nicht zur Ausführung weil [?Status] eq "Alltag" unwahr ist.
Bin Ratlos was ich machen soll. Ist es wirklich ein Bug im DOIF, und ich kann das nach einem Update wieder so einbauen ? Oder hat sich irgendwas geändert das solche Definitionen nicht mehr funktionieren. Liegt es am Zusammenspiel irgendwelcher Attribute ?
Hier nochmal die gesamte def:
Internals:
DEF ([RollosOst] eq "closed")
(set WandTableau ttsSay Rolladen vorne sind nun zu)
DOELSEIF ([([Wecker] - [06:15])|01234] and [?Bubu] == 0 and [?Status] eq "Alltag")
(set WandTableau audioPlay /Audio/soft-bells.mp3, set Gigablue msg message 5 Nun aber ins Bett !)
DOELSE
NAME Sprachmeldung_Tableau
NR 174
NTFY_ORDER 50-Sprachmeldung_Tableau
STATE initialized
TYPE DOIF
READINGS:
2018-03-07 10:31:50 cmd 0
2018-03-07 10:31:50 mode enabled
2018-03-07 10:31:50 state initialized
2018-03-07 10:31:50 timer_01_c02 07.03.2018 23:15:00|01234
Regex:
condition:
0 InternalDoIf($hash,'RollosOst','STATE') eq "closed"
1 DOIF_time_once($hash,0,$wday,"01234") and InternalDoIf($hash,'Bubu','STATE') == 0 and InternalDoIf($hash,'Status','STATE') eq "Alltag"
days:
0 01234
devices:
0 RollosOst
all RollosOst
do:
0:
0 set WandTableau ttsSay Rolladen vorne sind nun zu
1:
0 set WandTableau audioPlay /Audio/soft-bells.mp3, set Gigablue msg message 5 Nun aber ins Bett !
2:
0
helper:
DOIF_Readings_events
DOIF_eventas
globalinit 1
last_timer 1
sleeptimer -1
internals:
0 RollosOst:STATE
1 Bubu:STATE Status:STATE
all RollosOst:STATE Bubu:STATE Status:STATE
itimer:
all Wecker
localtime:
0 1520460900
realtime:
0 23:15:00
time:
0 ([Wecker]-[06:15])
timeCond:
0 1
timer:
0 0
timers:
1 0
triggertime:
1520460900:
localtime 1520460900
hash:
uiState:
uiTable:
Attributes:
cmdpause 0:300
group Meldungen
repeatsame 0:3
room 9.0_System
verbose 0
Wäre für eine Tip dankbar...
Zitat von: Skusi am 07 März 2018, 11:07:07
Die Zeitberechnung [([Wecker] - [06:15])|01234] ist laut Commadref in Ordnung. Das Wecker Dummy hat den Wert 05:30.
Wenn man von 06:15 Uhr bis 05:30 Uhr des nächsten Tages rechnet, kommen genau 23 Stunden und 15 Minuten raus.
Ist das Zufall?
Zitat von: Skusi am 07 März 2018, 11:07:07
Sobald folgendes DOIF im cfg steht, hängt sich Fhem genau um 23:15 auf.
Wohl eher nicht. Offenbar wird im vorliegenden Fall eine relative Zeitdauer in einen absoluten Zeitpunkt verwandelt.
Bei deiner Zeitberechnung kommt -00:45 heraus, das wird vom DOIF als 45 Minuten vor Mitternacht angesehen, daher 23:15. Du kannst versuchen das Problem weiter einzukreisen, in dem du die Definition abspeckst. Z. B.
Zitat(set WandTableau audioPlay /Audio/soft-bells.mp3, set Gigablue msg message 5 Nun aber ins Bett !)
auskommentierst. Oder die gesetzten Attribute löschst.
Im DOIF hat sich nichts geändert, was auf das Problem hindeuten würde.
Zitat von: Skusi am 07 März 2018, 11:07:07
Hallo,
seit nunmehr 4 Tagen komme ich nur noch zu spät ins Bett, weil sich Fhem immer zwischen 22 und 24 Uhr so aufhängt, das nicht mal ein reboot hilft. Der Fhem Prozess endet immer bei 100% CPU.
Um es kurz zumachen, habe ich gestern den Übeltäter finden können, und erstmal aus der cfg geschmissen.
Sobald folgendes DOIF im cfg steht, hängt sich Fhem genau um 23:15 auf.
DEF ([RollosOst] eq "closed")
(set WandTableau ttsSay Rolladen vorne sind nun zu)
DOELSEIF ([([Wecker] - [06:15])|01234] and [?Bubu] == 0 and [?Status] eq "Alltag")
(set WandTableau audioPlay /Audio/soft-bells.mp3, set Gigablue msg message 5 Nun aber ins Bett !)
DOELSE
Augenmerk also auf den DOELSEIF Teil. Das Ganze DOIF lief allerdings schon seit Monaten einwandfrei. Das Problem kann also erst nach dem letzten Update (Samstag) akut sein. Die Zeitberechnung [([Wecker] - [06:15])|01234] ist laut Commadref in Ordnung. Das Wecker Dummy hat den Wert 05:30. Außerdem kommt der Befehl derzeit nicht zur Ausführung weil [?Status] eq "Alltag" unwahr ist.
Bin Ratlos was ich machen soll. Ist es wirklich ein Bug im DOIF, und ich kann das nach einem Update wieder so einbauen ? Oder hat sich irgendwas geändert das solche Definitionen nicht mehr funktionieren. Liegt es am Zusammenspiel irgendwelcher Attribute ?
Hier nochmal die gesamte def:
Internals:
DEF ([RollosOst] eq "closed")
(set WandTableau ttsSay Rolladen vorne sind nun zu)
DOELSEIF ([([Wecker] - [06:15])|01234] and [?Bubu] == 0 and [?Status] eq "Alltag")
(set WandTableau audioPlay /Audio/soft-bells.mp3, set Gigablue msg message 5 Nun aber ins Bett !)
DOELSE
NAME Sprachmeldung_Tableau
NR 174
NTFY_ORDER 50-Sprachmeldung_Tableau
STATE initialized
TYPE DOIF
READINGS:
2018-03-07 10:31:50 cmd 0
2018-03-07 10:31:50 mode enabled
2018-03-07 10:31:50 state initialized
2018-03-07 10:31:50 timer_01_c02 07.03.2018 23:15:00|01234
Regex:
condition:
0 InternalDoIf($hash,'RollosOst','STATE') eq "closed"
1 DOIF_time_once($hash,0,$wday,"01234") and InternalDoIf($hash,'Bubu','STATE') == 0 and InternalDoIf($hash,'Status','STATE') eq "Alltag"
days:
0 01234
devices:
0 RollosOst
all RollosOst
do:
0:
0 set WandTableau ttsSay Rolladen vorne sind nun zu
1:
0 set WandTableau audioPlay /Audio/soft-bells.mp3, set Gigablue msg message 5 Nun aber ins Bett !
2:
0
helper:
DOIF_Readings_events
DOIF_eventas
globalinit 1
last_timer 1
sleeptimer -1
internals:
0 RollosOst:STATE
1 Bubu:STATE Status:STATE
all RollosOst:STATE Bubu:STATE Status:STATE
itimer:
all Wecker
localtime:
0 1520460900
realtime:
0 23:15:00
time:
0 ([Wecker]-[06:15])
timeCond:
0 1
timer:
0 0
timers:
1 0
triggertime:
1520460900:
localtime 1520460900
hash:
uiState:
uiTable:
Attributes:
cmdpause 0:300
group Meldungen
repeatsame 0:3
room 9.0_System
verbose 0
Wäre für eine Tip dankbar...
Dann ersetze die Befehle
(set WandTableau audioPlay /Audio/soft-bells.mp3, set Gigablue msg message 5 Nun aber ins Bett !)durch einen Log-Befehl
{Log 1, "DOIF Test"}Wenn es dann keine Probleme gibt, könnte es mit einem Befehl zusammenhängen.
Das bei meiner Berechnung 23:15 als Zeitpunkt herauskommt ist mir klar, und auch so gewollt.
(set WandTableau audioPlay /Audio/soft-bells.mp3, set Gigablue msg message 5 Nun aber ins Bett !)
Wenn ich diese Befehle manuel absetze werden sie einwnadfrei ausgeführt. Also kann ich mir nicht denken das das auskommentieren den Absturz verhindert.
...
Das Attribut repeatsame macht nur Sinn wenn ein zyklischer Trigger da wäre, du hast aber nur einen um 23:15.
Hier wäre die Kombination mit repeatcmd statt cmdpause sinnvoll.
Allerdings würde ich zunächst alle Attribute löschen, um ein Fehlverhalten auszuschließen.
Juhu ! Gestern konnte ich einfach mal ohne lange Sitzung am Notebook zu Bett gehen.
Nachdem ich also nun den DOELSEIF Teil raus genommen und alle Attribute gelöscht habe, gab es keinen Absturz mehr.
OK, aber nun interessiert mich immer noch die eigentliche Ursache des Ganzen. Hab ich jetzt den Fehler verursacht, oder hat sich in Fhem irgendwas geändert das dieses Verhalten ausgelöst hat ?
Nun habe ich eben den bösen Teil testweise wieder eingefügt und die Berechnung so modifiziert das der Trigger Zeitpunk zeitnah liegt.
DOELSEIF ([([Wecker] - [17:15])|01234] and [?Bubu] == 0 and [?Status] ne "Alltag") \
(set WandTableau audioPlay /Audio/soft-bells.mp3, set Gigablue msg message 5 Nun aber ins Bett !)\
Keine Attr gesetzt !
Trigger Zeitpunkt liegt nun bei "Wecker" = 03:00 um 9:45. Was soll ich sagen: Fhem hängt bei 100% CPU und nix geht mehr. >:(
Das kann doch nur an der Zeitberechnung liegen die über die Mitternachtsgrenze geht. Ich habe noch in anderen DOIFs solche Rechnungen die einwandfrei funktionieren. Aber keine von denen geht rückwärts in den negativen Bereich.
Ist da im DOIF Modul irgendwas schief das das nicht funktioniert ? Ich kann mir das nicht anders erklären. Vor allem vor dem Hintergrund das ich dieses DOIF ewig nicht angefasst hatte und nun seit Samstag bringt es das gesamte System zum stehen.
Zitat von: Skusi am 08 März 2018, 10:07:44
Juhu ! Gestern konnte ich einfach mal ohne lange Sitzung am Notebook zu Bett gehen.
Nachdem ich also nun den DOELSEIF Teil raus genommen und alle Attribute gelöscht habe, gab es keinen Absturz mehr.
OK, aber nun interessiert mich immer noch die eigentliche Ursache des Ganzen. Hab ich jetzt den Fehler verursacht, oder hat sich in Fhem irgendwas geändert das dieses Verhalten ausgelöst hat ?
Nun habe ich eben den bösen Teil testweise wieder eingefügt und die Berechnung so modifiziert das der Trigger Zeitpunk zeitnah liegt.
DOELSEIF ([([Wecker] - [17:15])|01234] and [?Bubu] == 0 and [?Status] ne "Alltag") \
(set WandTableau audioPlay /Audio/soft-bells.mp3, set Gigablue msg message 5 Nun aber ins Bett !)\
Keine Attr gesetzt !
Trigger Zeitpunkt liegt nun bei "Wecker" = 03:00 um 9:45. Was soll ich sagen: Fhem hängt bei 100% CPU und nix geht mehr. >:(
Das kann doch nur an der Zeitberechnung liegen die über die Mitternachtsgrenze geht. Ich habe noch in anderen DOIFs solche Rechnungen die einwandfrei funktionieren. Aber keine von denen geht rückwärts in den negativen Bereich.
Ist da im DOIF Modul irgendwas schief das das nicht funktioniert ? Ich kann mir das nicht anders erklären. Vor allem vor dem Hintergrund das ich dieses DOIF ewig nicht angefasst hatte und nun seit Samstag bringt es das gesamte System zum stehen.
Also die Zeitberechnung ergibt zumindest eine sinnvolle Triggerzeit, siehe Timer-Readings. Wenn du irgendwo Wecker veränderst, dann wird jedes mal DOIF getriggert und führt eine Neuberechnung der Zeit durch. Vielleicht hast du dir da irgendwo ein Loop eingebaut.
Versteh ich nicht ::)
Das hier funkt doch auch:
([([Wecker]+[00:15])|8])
(set Kaffeemaschine on-for-timer 900)
Außerdem stürzt Fhem ja nicht ab wenn ich Wecker verändere und das DOIF die triggertime neu setzt, sondern erst wenn der trigger aktiv wird.
Ich sehe da den loop nicht heraus.
Zitat von: Skusi am 08 März 2018, 11:57:11
Versteh ich nicht ::)
Das hier funkt doch auch:
([([Wecker]+[00:15])|8])
(set Kaffeemaschine on-for-timer 900)
Außerdem stürzt Fhem ja nicht ab wenn ich Wecker verändere und das DOIF die triggertime neu setzt, sondern erst wenn der trigger aktiv wird.
Ich sehe da den loop nicht heraus.
Ein Loop, wenn überhaupt, kann schon mal indirekt entstehen, z. B.:
DOIF ([irgendwas]) (set blabla)
notify blabla: set irgendwas
OK, hab ich verstanden. Ich bin mir aber sehr sicher das das Dummy "Wecker" nur übers FTUI Tablet oder der Fhem Web Oberfläche geändert wird.
Ein Loop könnte doch nur bedeuten das:
(set WandTableau audioPlay /Audio/soft-bells.mp3, set Gigablue msg message 5 Nun aber ins Bett !)
irgendwie eine weiteres DOIF oder Notify anstößt, das wiederum den Wecker Dummy ändert.
Das habe ich schon untersucht, und dabei keinen "Kreis" schließen können.
Dagegen spricht doch aber auch das die Bedingung:
DOELSEIF ([([Wecker] - [06:15])|01234] and [?Bubu] == 0 and [?Status] eq "Alltag")
zu Zeitpunkt der ersten Absturz Abende nicht erfüllt wurde, da das [Status] Dummy nicht auf "Alltag" stand. Also wurde doch gar keine Befehl ausgeführt, der einen Loop anstoßen könnte.
Zitat von: Skusi am 08 März 2018, 20:30:40
OK, hab ich verstanden. Ich bin mir aber sehr sicher das das Dummy "Wecker" nur übers FTUI Tablet oder der Fhem Web Oberfläche geändert wird.
Ein Loop könnte doch nur bedeuten das:
(set WandTableau audioPlay /Audio/soft-bells.mp3, set Gigablue msg message 5 Nun aber ins Bett !)
irgendwie eine weiteres DOIF oder Notify anstößt, das wiederum den Wecker Dummy ändert.
Das habe ich schon untersucht, und dabei keinen "Kreis" schließen können.
Dagegen spricht doch aber auch das die Bedingung:
DOELSEIF ([([Wecker] - [06:15])|01234] and [?Bubu] == 0 and [?Status] eq "Alltag")
zu Zeitpunkt der ersten Absturz Abende nicht erfüllt wurde, da das [Status] Dummy nicht auf "Alltag" stand. Also wurde doch gar keine Befehl ausgeführt, der einen Loop anstoßen könnte.
Dann scheint es mit der negativen Zeitberechnung zusammenzuhängen.
Du kannst die Triggerzeit zum Testen wie folgt angeben z. B.:
([[Wecker2]|01234]
mit Wecker2 = 23:15
Ich konnte das Problem nachstellen. Es liegt an der Zeitberechnung mit Minus in die Vergangenheit - was keinen Sinn macht. Das wird offenbar im Modul nicht sauber abgefangen. Zukünftig werde ich in diesem Fall eine Fehlermeldung liefern. Du musst dir auf jeden Fall eine Zeitberechnung überlegen, die keine negative Zeit liefert.
Na super das Du mir nun wenigstens glauben kannst. Ich hatte schon an meiner Intelligenz gezweifelt.
Ich hab Mittlerweile einen zweiten PI genommen, und den mit dem Image Backup meiner SD Karte gefüttert. Getrennt vom Netztwerk an einem Notebook zum testen.
Nun verbringe ich schon Stunden damit verschiedene Abänderungen der DOIF def auszuprobieren.
Mittlerweile bin ich schon auf folgendes runter:
([([Wecker] - [06:15])\
(set Test BlaBla)\
Test ist eine extra angelegter Dummy ohne weiter verbindung, ohne Atribute.
Selbst das bringt den Absturz.
Dann hab ich eine Backup von 26.02. zurückgeschrieben. Auch da passiert der Absturz. Langsam krieg ich da keine Logic mehr rein. Ich bin schon ganz gaga und kurz vorm aufgeben. Ich bin mir sicher das es vor dem 03.03. keine Abstürze gab. Das DOIF ist schon Monate lang unverändert in der cfg.
Egal, Du hast es glücklicherweise reproduzieren können. Also liegt es nicht an meinem System. Warum das nun erst auftritt kan ich mir nicht erklären.
Fazit also:
([([Wecker] - [06:15])|01234]
geht plötzlich nicht mehr !!!
Aber nun brauche ich noch einen Tipp wie ich diese Funktion anders realisieren kann. Wie kann ich also einen Trigger setzen der 6 Stunden bevor ich aufstehe eine Aktion auslöst ???
Es ist eigentlich ganz einfach.
Du musst immer in die Zukunft "schauen" und nicht in die Vergangenheit, daher:
([weckzeit]+[17:45])...
17:45 ergibt sich aus 24:00-06:15
Na Klar !!!
Manchmal hat man echt ein Brett vorm Kopf und die Lösung ist so nah...
Ich hab das mal so eingebaut, und bin guter Hoffnung das es nun wieder so läuft wie gewohnt.
-Danke erstmal für dei Unterstützung.
Ich hab nochmal nachgedacht und mit einem Fhem Kumpel darüber diskutiert warum dieses Problem denn nun plötzlich auftritt obwohl das DOIF Modul nicht zu dem Zeitpinkt geupdated wurde.
Da viel mir ein das ich am letzten Wochenende auch den Monquitto MQTT Broker installiert habe. Während dessen habe ich garantiert auch ein apt-get update / upgrade ausgeführt.
Kann es also sein das die Probleme erst mit einer neueren Version irgendwelcher Packete auftreten ?
Auf jeden Fall wäre es sinnvoll solche Berechnungen dann in einer neuen DOIF Version abzufangen und nicht anzunehmen. Damit nicht noch jemand diesen langen Weg zur Lösung gehen muß.
Wenn alles die Tage ohne Absturz läuft, bin ich erstmal dankbar raus....
Gruß Skusi
Zitat von: Skusi am 10 März 2018, 10:17:45
Na Klar !!!
Manchmal hat man echt ein Brett vorm Kopf und die Lösung ist so nah...
Ich hab das mal so eingebaut, und bin guter Hoffnung das es nun wieder so läuft wie gewohnt.
-Danke erstmal für dei Unterstützung.
Ich hab nochmal nachgedacht und mit einem Fhem Kumpel darüber diskutiert warum dieses Problem denn nun plötzlich auftritt obwohl das DOIF Modul nicht zu dem Zeitpinkt geupdated wurde.
Da viel mir ein das ich am letzten Wochenende auch den Monquitto MQTT Broker installiert habe. Während dessen habe ich garantiert auch ein apt-get update / upgrade ausgeführt.
Kann es also sein das die Probleme erst mit einer neueren Version irgendwelcher Packete auftreten ?
Auf jeden Fall wäre es sinnvoll solche Berechnungen dann in einer neuen DOIF Version abzufangen und nicht anzunehmen. Damit nicht noch jemand diesen langen Weg zur Lösung gehen muß.
Wenn alles die Tage ohne Absturz läuft, bin ich erstmal dankbar raus....
Gruß Skusi
Das wird schon funktionieren ;)
Ich werde im kommenden Update negative Zeitberechnungen mit Fehler quittieren.
Zitat von: Damian am 10 März 2018, 14:09:37
Ich werde im kommenden Update negative Zeitberechnungen mit Fehler quittieren.
Ab morgen per Update verfügbar.