Nach Update Perl Fehlermeldung und Fhem down

Begonnen von Robert1963, 22 Dezember 2017, 06:21:22

Vorheriges Thema - Nächstes Thema

Damian

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
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Skusi

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.
HP ThinClient 630, SIGNALduino, NanoCul868 (a-culfw), JeeLink Clone (LaCrosse), Firmata  für FB Heizung,Wasser+Gas+Klingel+Lux, Somfy Rolladen, Pollin Steckd.,TX29DTH,Tasmota+IR Lesekopf an Stromz., MAX Fensterkontakte, IButton, Fingerprint, SonOff Tasmota, ESP LED Controler, WLed,zigbee2mqtt...

Damian

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
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Damian

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.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Skusi

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 ???
HP ThinClient 630, SIGNALduino, NanoCul868 (a-culfw), JeeLink Clone (LaCrosse), Firmata  für FB Heizung,Wasser+Gas+Klingel+Lux, Somfy Rolladen, Pollin Steckd.,TX29DTH,Tasmota+IR Lesekopf an Stromz., MAX Fensterkontakte, IButton, Fingerprint, SonOff Tasmota, ESP LED Controler, WLed,zigbee2mqtt...

Damian

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
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Skusi

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
HP ThinClient 630, SIGNALduino, NanoCul868 (a-culfw), JeeLink Clone (LaCrosse), Firmata  für FB Heizung,Wasser+Gas+Klingel+Lux, Somfy Rolladen, Pollin Steckd.,TX29DTH,Tasmota+IR Lesekopf an Stromz., MAX Fensterkontakte, IButton, Fingerprint, SonOff Tasmota, ESP LED Controler, WLed,zigbee2mqtt...

Damian

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.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Damian

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.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF