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.
% 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:
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.
Ok. Und was soll ich nun tun?
Von den sieben von Dir genannten Modulen habe ich keines im Einsatz.
Wenn du das reproduzieren kannst, dann bitte die alte Version der Zeile einspielen, und davor ein
stacktrace() if(!defined($i));
einbauen. Und mir berichten :)
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.
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?
stacktrace bleibt sinnlos. Neuer Vorschlag: die "next" Zeile ersetzen mit
$i = "" if(!defined($i)); # Forum #40598
next if(!$intAt{$i}); # deleted in the loop
Hallo Rudi,
mit der vorgeschlagenen Änderung erfolgt aktuell kein Verbindungsabbruch mehr.
Danke!
Habs eingecheckt.
Bleibt noch zu klaeren, wer undefined ins %intAt reinsteckt.
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.
Gestern sind da zwei Mini-Patches reingeflossen, davor war in FHEMWEB ein Monat lang Ruhe.
Warum macht man eigentlich ein update vor dem Urlaub?
Weil man dort, wohin man in Urlaub fährt, eine auf fhem basierende Wetterstation betreibt und nun zuhause das Update simulieren wollte 8)
Ok, mit der vorherigen 01_FHEMWEB scheint alles wieder gut zu sein. Seit gut drei Stunden keine Abbrüche mehr.
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?
Ich werde nach meinem Urlaub erforschen, welche der beiden gestern in FHEMWEB geänderten Zeilen für das Problem verantwortlich ist.
Hmm, ich bin eher erstaunt: Ich nutze die WebViewControl-Android-App selber (allerdings tatsächlich auch in Verbindung mit dem FHEM-Modul, und mit fhem-tablet-ui) und kann über keine Probleme berichten, die irgendwie mit FHEM-Updates korrelieren. Im Gegenteil: Das Teil ist auch ohne irgendwas anzufassen extrem finicky und behauptet hin und wieder mal, es könne nicht mit dem Server kommunizieren (besonders gerne: direkt nachdem es die Oberfläche erfolgreich angezeigt hat). Das hat sich bei mir bisher immer durch mehrmaliges Neuladen gelegt: Sobald es einmal entschieden hat mitzuspielen, geht es auch problemlos bis zum nächsten beenden oder neuladen. Das Problem ist verschwunden seitdem ich in den Einstellungen den Timeout extrem hochgestellt habe. Mangels Zugriff auf den Source der App kann ich das auch nicht weiter genau eingrenzen.
Ich wäre *sehr* überrascht wenn die beiden Änderungen in FHEMWEB irgendwie mit WebViewControl interagieren: Die geänderten Codepfade betreffen nur Nicht-GET-Requests, und WebViewControl sendet (soweit ich das sehen kann) ausschliesslich GET-Requests.
Zitat von: henryk am 15 September 2015, 02:51:12
Ich wäre *sehr* überrascht wenn die beiden Änderungen in FHEMWEB irgendwie mit WebViewControl interagieren
Hatte ich gestern irgendwo geschrieben, dass die aktuell aufgetretenen Probleme irgendwas mit WebViewControl zu tun haben?