Problem mit aktueller Version von fhem.pl

[betateilchen]

Hallo Rudi,

bis zu dieser Version:

# $Id: fhem.pl 9141 2015-08-27 19:04:33Z rudolfkoenig $

ist alles ok. Wenn ich allerdings die aktuelle fhem.pl verwende, bricht in webviewcontrol nach einigen Sekunden die Verbindung zwischen Browser und fhem ab.

Ich nutze webviewcontrol, um auf einem Android Tablet ein InfoPanel anzuzeigen. Für eine genauere Fehleranalyse habe ich vor Donnerstag keine Zeit. Das Problem konnte ich lösen, indem ich die o.g. Version von fhem.pl wieder eingespielt habe. Alle anderen fhem-Dateien sind auf dem aktuellen Stand von heute.

Da die Änderung in fhem.pl noch nicht so lange her ist, wollte ich Dir einfach schonmal Bescheid geben, dass es irgendwo klemmt. VIelleicht fällt Dir ja schon spontan etwas zu der Fehlerbeschreibung ein.

[rudolfkoenig]

Code Auswählen Erweitern

% svn diff -r9141 fhem.pl
Index: fhem.pl
===================================================================
--- fhem.pl    (revision 9141)
+++ fhem.pl    (working copy)
@@ -1680,7 +1680,7 @@

   my $ret = CallFn($name, "DefFn", \%hash, $def);
   if($ret) {
-    Log 1, "define $name $def: $ret";
+    Log 1, "define $def: $ret";
     delete $defs{$name};                            # Veto
     delete $attr{$name};

@@ -2670,7 +2670,7 @@
   # Check the internal list.
   foreach my $i (sort { $intAt{$a}{TRIGGERTIME} <=>
                         $intAt{$b}{TRIGGERTIME} } keys %intAt) {
-    next if(!$intAt{$i}); # deleted in the loop
+    next if(!defined($i) || !$intAt{$i}); # deleted in the loop
     my $tim = $intAt{$i}{TRIGGERTIME};
     my $fn = $intAt{$i}{FN};
     if(!defined($tim) || !defined($fn)) {


Webviewcontrol erzeugt/benoetigt ein intAt mit undefined index.
Soweit ich das sehe, kann man sowas mit den fhem.pl Funktionen, die intAt modifizieren (InternalTimer / RemoveInternalTimer) nicht bewerkstelligen. Folgende Module greifen auf intAt zu:

Code Auswählen Erweitern

00_SONOS.pm
00_THZ.pm
30_MilightBridge.pm
31_MilightDevice.pm
95_Alarm.pm
98_Modbus.pm
98_apptime.pm
evtl. ist einer von Ihnen an dem undefined Schuld.

[betateilchen]

Ok. Und was soll ich nun tun?

Von den sieben von Dir genannten Modulen habe ich keines im Einsatz.

[rudolfkoenig]

Wenn du das reproduzieren kannst, dann bitte die alte Version der Zeile einspielen, und davor ein

Code Auswählen Erweitern

stacktrace() if(!defined($i));
einbauen. Und mir berichten

[rudolfkoenig]

Mein Vorschlag ist nicht wirklich optimal, jedenfalls ist der Stacktrace() sinnlos, da ich die Ursache erwischen will. Habe noch keine Idee wie, ausser bei jeder Modifikation von intAt eine Pruef-Funktion aufzurufen.

[betateilchen]

Zu Deinem besseren Verständnis:

- Ich nutze webviewcontrol (wvc) ausschließlich auf dem Tablet ausschließlich in seiner Funktion als Browser
- Innerhalb von fhem gibt es kein wvc-Device, da ich das Tablet nicht von fhem aus steuern möchte
- Das InfoPanel arbeitet prinzipiell nur mit Readings, die gelesen und deren Werte dargestellt werden

- Zur Laufzeit gibt es zwischen wvc auf dem Tablet und der fhem-Installation eigentlich nur eine Verbindung: longpoll
- Die Zeitspanne bis zum Verbindungsabbruch könnte in etwa mit der Zeitspanne der ersten Änderung eines longpoll Elementes auf dem Infopanel zusammenpassen, ich schreibe alle 15 Sekunden die Uhrzeit in ein Reading, das auf dem InfoPanel per longpoll dargestellt wird.

Am Wochenende werde ich testen, ob das Problem auch auftritt, wenn ich ein InfoPanel ohne longpoll Elemente verwende.
Für mich ist das aktuell der einzige Ansatzpunkt von meiner Seite

Den Test mit dem stacktrace kann ich gerne einbauen, aber da Du ihn selbst schon für sinnlos erklärt hast, weiss ich nicht genau, ob das noch gewollt ist?

[rudolfkoenig]

stacktrace bleibt sinnlos. Neuer Vorschlag: die "next" Zeile ersetzen mit

Code Auswählen Erweitern


$i = "" if(!defined($i)); # Forum #40598
next if(!$intAt{$i}); # deleted in the loop


[betateilchen]

Hallo Rudi,

mit der vorgeschlagenen Änderung erfolgt aktuell kein Verbindungsabbruch mehr.

Danke!

[rudolfkoenig]

Habs eingecheckt.
Bleibt noch zu klaeren, wer undefined ins %intAt reinsteckt.

[betateilchen]

Hurra, nach einem Update sind heute die Verbindungsabbrüche wieder da. Diesmal aber noch heftiger als vorher, das gesamte Webfrontend steht still und ist überhaupt nicht mehr erreichbar. Und das natürlich wieder mal einen Tag vor der Abreise in den Urlaub. Im Log nix auffälliges.

Die fhem.pl habe ich diesmal nicht in Verdacht, ich tippe auf irgendeine Änderung in der 01_FHEMWEB.

[rudolfkoenig]

Gestern sind da zwei Mini-Patches reingeflossen, davor war in FHEMWEB ein Monat lang Ruhe.
Warum macht man eigentlich ein update vor dem Urlaub?

[betateilchen]

Weil man dort, wohin man in Urlaub fährt, eine auf fhem basierende Wetterstation betreibt und nun zuhause das Update simulieren wollte 

[betateilchen]

Ok, mit der vorherigen 01_FHEMWEB scheint alles wieder gut zu sein. Seit gut drei Stunden keine Abbrüche mehr.

[rudolfkoenig]

Das ist doof, ich weiss nicht was ich fixen soll, wenn ich die eigentliche Ursache nicht kenne.
Steht im JS-Console beim Abbruch was drin?

[betateilchen]

Ich werde nach meinem Urlaub erforschen, welche der beiden gestern in FHEMWEB geänderten Zeilen für das Problem verantwortlich ist.