komisches Verhalten eines regelmäßigen at

betateilchen · 26 Februar 2017, 17:22:12

Seit kurzem habe ich ein Problem mit at devices, die wiederholt ausgeführt werden sollen.


define at_heartbeat at +*00:01:00 {qx(touch /opt/fhem/log/fhem.heartbeat)} 
attr at_heartbeat alignTime 00:01

Das funktioniert eine Zeitlang hervorragend, irgendwann stellt das at aber einfach seinen Dienst ein.

Klicke ich dann im Frontende das DEF an und speichere es über den zugehörigen Button unter dem Editorfenster wieder ab, wird die Ausführung wieder für eine gewisse Zeit fortgesetzt.

Kann das irgendwie mit den Änderungen an 90_at.pm zusammenhängen, die in den vergangenen Tagen erfolgt sind?

rudolfkoenig · 26 Februar 2017, 17:50:40

Seit 5.8 ist perlSyntaxCheck aktiviert. Bis vorgestern wurde diese Funktion bei jeder at-definition (was nach jeder at Ausfuehrung automatisch wiederholt wird) auch mit ausgefuehrt. Ich wuesste zwar nicht, wieso das nur in manchen Faellen ein Problem sein sollte, aber wenn ja, dann wuerde das dein Problem erklaeren.

betateilchen · 26 Februar 2017, 17:56:06

Ich werde perlSyntaxCheck testweise abschalten.

Apropos perlSyntaxCheck: könntest Du bei Gelegenheit die Werteliste zum Attribut noch in FHEM hinterlegen?

BerndArnold · 27 Februar 2017, 06:15:17

Ich habe ein at, welches alle 15 Sekunden ausgeführt wird. Seit dem Update ist es in einem Loop. Soll heißen, es wird so oft ausgeführt wie nur möglich (hunderte Male pro Sekunde).

Danke für den Hinweis zum perlSyntaxCheck, werde ich auch mal versuchen.

betateilchen · 27 Februar 2017, 09:03:01

Also am perlSyntaxCheck liegt es nicht, den hab ich abgeschaltet. Mein at hängt seit gestern Abend 21:36 schon wieder.
FHEM wurde um 21:35 neugestartet, nach dem Neustart wird das at nicht mehr ausgeführt.

Code Auswählen


2017.02.26 21:35:53 0: Server shutdown
2017.02.26 21:36:04 3: telnetPort: port 7072 opened
2017.02.26 21:36:05 3: web: port 8083 opened
2017.02.26 21:36:08 0: Featurelevel: 5.8
2017.02.26 21:36:08 0: Server started with 8 defined entities (fhem.pl:13532/2017-02-26 perl:5.020002 os:linux user:fhem pid:16406)

Nach einem Klick auf "DEF" und "modify" läuft das at wieder.

Ich werde mir jetzt mal eine alte Modulversion von at besorgen. So kann ich at nicht gebrauchen.

betateilchen · 27 Februar 2017, 09:22:22

Der Fehler ist auf meinem Test-FHEM beliebig reproduzierbar.

Nach einem FHEM restart wird das at nicht mehr neu gestartet.

Code Auswählen


fhem.pl           13532 2017-02-26 17:04:14Z rudolfkoenig 
90_at.pm          13500 2017-02-24 09:12:38Z rudolfkoenig

Edit: mit #12717 scheint alles wieder wie gewünscht zu funktionieren.

betateilchen · 27 Februar 2017, 09:37:42

Zitat von: betateilchen am 27 Februar 2017, 09:22:22
Edit: mit #12717 scheint alles wieder wie gewünscht zu funktionieren.

Zu früh gefreut. Geht auch damit nicht dauerhaft.

Im Logfile nichts auffälliges:

Code Auswählen


2017.02.27 09:38:32 5: Cmd: >define at_heartbeat at +*00:01:00 {qx(touch /opt/fhem/log/fhem.heartbeat)}<
2017.02.27 09:38:32 5: Loading ./FHEM/90_at.pm
2017.02.27 09:38:33 5: Cmd: >attr at_heartbeat alignTime 00:01<
2017.02.27 09:38:33 5: Cmd: >attr at_heartbeat group 50 Maintenance<
2017.02.27 09:38:33 5: Cmd: >attr at_heartbeat icon hourglass<
2017.02.27 09:38:33 5: Cmd: >attr at_heartbeat room 99 System<

betateilchen · 27 Februar 2017, 10:04:02

Vielleicht hilft es bei der Fehlereingrenzung:

Lösche ich das Attribut alignTime, rennt das at nach einem (re)start wie gewünscht los.

JWRu · 27 Februar 2017, 10:25:11

Ich beobachte das gleiche Verhalten (siehe hier: https://forum.fhem.de/index.php/topic,67942.0.html), habe aber das Attribut alignTime bei meinen ats gar nicht gesetzt.

rudolfkoenig · 27 Februar 2017, 12:02:02

Ich kann das Problem nicht nachstellen. Ich habe beteteilchens at mit 10s konfiguriert, und der tickt hier seit mehreren Stunden und mehreren "shutdown restarts". Auch ein FHEMWEB modify (DEF bzw. Wizard probiert) bringt ihn nicht aus der Ruhe.

Nach etwas Nachdenken kann ich nur ein anderes Modul vorstellen, der %intAt direkt manipuliert (wieso greifen so viele Module darauf ueberhaupt zu???) oder mit RemoveInternalTimer den at Eintrag loescht.

Mit folgenden Ausdruecken kann man die intAt "Liste" ausgeben:

Code Auswählen


fhem> { map { Log 1, "$intAt{$_}{TRIGGERTIME}=>$intAt{$_}{FN}" } sort { $intAt{$a}{TRIGGERTIME} <=> $intAt{$b}{TRIGGERTIME} } keys %intAt }
fhem> { use Data::Dumper;; map { Log 1, "$intAt{$_}{TRIGGERTIME}=>$intAt{$_}{FN}" } sort { $intAt{$a}{TRIGGERTIME} <=> $intAt{$b}{TRIGGERTIME} } keys %intAt }

evtl. hilt das beim lokalisieren des Problems.

JWRu · 27 Februar 2017, 12:21:31

Habe ich mal gemacht und erhalte für beide Zeilen "6" zurück. Was fange ich jetzt damit an?

CoolTux · 27 Februar 2017, 12:25:19

Zitat von: rudolfkoenig am 27 Februar 2017, 12:02:02
Ich kann das Problem nicht nachstellen. Ich habe beteteilchens at mit 10s konfiguriert, und der tickt hier seit mehreren Stunden und mehreren "shutdown restarts". Auch ein FHEMWEB modify (DEF bzw. Wizard probiert) bringt ihn nicht aus der Ruhe.

Nach etwas Nachdenken kann ich nur ein anderes Modul vorstellen, der %intAt direkt manipuliert (wieso greifen so viele Module darauf ueberhaupt zu???) oder mit RemoveInternalTimer den at Eintrag loescht.

Mit folgenden Ausdruecken kann man die intAt "Liste" ausgeben:
Code Auswählen Erweitern
fhem> { map { Log 1, "$intAt{$_}{TRIGGERTIME}=>$intAt{$_}{FN}" } sort { $intAt{$a}{TRIGGERTIME} <=> $intAt{$b}{TRIGGERTIME} } keys %intAt } fhem> { use Data::Dumper;; map { Log 1, "$intAt{$_}{TRIGGERTIME}=>$intAt{$_}{FN}" } sort { $intAt{$a}{TRIGGERTIME} <=> $intAt{$b}{TRIGGERTIME} } keys %intAt }
evtl. hilt das beim lokalisieren des Problems.

Hallo Rudi,

Ich entschuldige mich schon mal im Voraus weil mein Zwischenfragen bisschen unverschämt ist. Aber es passt gerade so gut.
Ist es eigentlich Notwendig ein RemoveInternalTimer in der Zeitverzögerten aufgerufenen Funktion zu machen wenn der Timer eh schon abgelaufen ist?

Danke Dir
Und noch mal Sorry

rudolfkoenig · 27 Februar 2017, 13:45:57

@JWRu: bitte ins FHEM-Logfile schauen.
@CoolTux: RemoveInternalTimer ist nicht notwendig, der Eintrag wird nach dem Aufruf entfernt. Wenn es nicht entfernt waere, wuerde die spezifizierte Funktion in einer (sehr aufwendigen) Endlosschleife aufgerufen.

betateilchen · 27 Februar 2017, 13:52:40

Zitat von: rudolfkoenig am 27 Februar 2017, 12:02:02
Ich kann das Problem nicht nachstellen. Ich habe beteteilchens at mit 10s konfiguriert, und der tickt hier seit mehreren Stunden und mehreren "shutdown restarts". Auch ein FHEMWEB modify (DEF bzw. Wizard probiert) bringt ihn nicht aus der Ruhe.

Das Problem tritt bei mir auch nicht in allen FHEM Installationen auf. Interessanterweise ausgerechnet aber in der mit den wenigsten devices.

Code Auswählen


Fhem info: 
  Release  : 5.8 FeatureLevel: 5.8 
  OS       : linux 
  Arch     : arm-linux-gnueabihf-thread-multi-64int 
  Perl     : v5.20.2 
  uniqueID : cab637ee0a494784835e71491e440e3b 
  upTime   : 03:48:17 

Defined modules: 
  FHEMWEB  : 1 
  FileLog  : 1 
  at       : 1 
  cmdalias : 1 
  configDB : 1 
  notify   : 2 
  telnet   : 1

Zitat von: rudolfkoenig am 27 Februar 2017, 12:02:02
Mit folgenden Ausdruecken kann man die intAt "Liste" ausgeben:

liefert bei mir:

Code Auswählen

2017.02.27 13:47:47 1: 1488199702=>FW_closeInactiveClients
2017.02.27 13:47:47 1: 1488199702.01774=>at_Exec
2017.02.27 13:47:47 1: 1488236401=>FileLog_dailySwitch

CoolTux · 27 Februar 2017, 13:52:53

Zitat von: rudolfkoenig am 27 Februar 2017, 13:45:57
@CoolTux: RemoveInternalTimer ist nicht notwendig, der Eintrag wird nach dem Aufruf entfernt. Wenn es nicht entfernt waere, wuerde die spezifizierte Funktion in einer (sehr aufwendigen) Endlosschleife aufgerufen.

Ich bedanke mich ganz herzlich. Dann werde ich die nächsten Tage mal bisschen was gerade ziehen bei meinen Modulen. Muss ja nicht sein das sie als schlechtes Vorbild dienen.