ERROR evaluating FW_svgCollect

[mumpitzstuff]

Seit ich mit Fhem auf einen neuen Server umgezogen bin, habe ich immer mal wieder diverse des unten stehenden Fehlers im Logfile. Hat irgendwer einen Tipp was ich dagegen machen könnte?

Code Auswählen Erweitern

2018.10.10 23:22:35 1: ERROR evaluating {FW_svgCollect('WEB_192.168.1.107_62927,SVG_FileLog_PFLANZE_BODEN_1,<svg Daten??>Can't use an undefined value as an ARRAY reference at ./FHEM/01_FHEMWEB.pm line 1959.

[rudolfkoenig]

Ich fuerchte das ist ein FHEMWEB Bug, und ich habe nach langen gruebeln keine Ursache gefunden, habe ihn aber mit einer Prufung in der Zeile davor "unter dem Teppich" gekehrt. Wenn jemand die Ursache beschreiben kann, oder mir was zum Nachstellen gibt, werde ich es richtig fixen.

Workaround: "attr WEB plotEmbed 1"

[mumpitzstuff]

Ich glaube die Zeilenangabe von mir war falsch. Bin im Log zu weit nach hinten gegangen und hatte erst danach das letzte Update eingespielt. Die Zeile in der der Fehler aufzutreten scheint ist diese:

Code Auswählen Erweitern

return if(int(keys %{$res}) != int(@{$atEnds}));

Damit dürfte $h nicht das Problem sein. Ich vermute eher, das $atEnds hier undefiniert ist. Wenn ich was fürs debuggen einbauen soll, dann kann ich das machen. Den Fehler erhalte ich ziemlich oft.

[rudolfkoenig]

Ich glaube die Zeilenangabe von mir war falsch.

Ok, damit kann ich eher was anfangen. Dein System ist schneller mit Plot-Rendern im geforkten Prozess fertig, als mit dem Aufruf der naechsten Zeile im Elternprozess. Was ist das fuer HW und  OS?

Ich habe einen anderen Fix eingebaut, bitte testen.

[mumpitzstuff]

Ein schnelles Notebook mit Debian Stretch. Die Erklärung passt aber, den der Umzug erfolge von einem Raspberry 2B auf dieses Notebook, was nun um Welten schneller ist.

[mumpitzstuff]

Habe den Fehler leider immer noch. Dieses Mal direkt nach dem shutdown restart.

Code Auswählen Erweitern

Can't use an undefined value as an ARRAY reference at ./FHEM/01_FHEMWEB.pm line 1959

Code Auswählen Erweitern

return if(int(keys %{$res}) != int(@{$atEnds}));

Eine dieser Variablen steht auf undef irgendwie.

[rudolfkoenig]

Das muss wohl $atEnds sein, und ich habe keine Ahnung warum, auch nach 10 Minuten Code-Anstarren nicht, es sei denn du verwendest nicht die aktuelle Version.
Wenn du mir was zum Nachstellen gibts, dann suche ich gerne weiter.

[mumpitzstuff]

Ich habe eigentlich alles aktuell. Die Zeile in der der Fehler auftritt enthält ja auch deine letzte Änderung. Ich versuche mal was in den Code einzubauen, was mir mehr Hinweise liefert.

[mumpitzstuff]

Ich habe mal folgendes in den Code eingefügt:

Code Auswählen Erweitern

sub
FW_svgCollect($)
{
  my ($cname,$d,$enc) = split(",",$_[0],3);
  my $h = $FW_svgData{$cname};
  my ($res, $atEnds) = ($h->{RES}, $h->{ATENDS});
  $res->{$d} = decode_base64($enc);
  print "test1: ".Dumper($cname);
  print "test2: ".Dumper($d);
  #print "test3: ".Dumper($enc);
  print "test4: ".Dumper($atEnds);
  return if(int(keys %{$res}) != int(@{$atEnds}));
  $FW_RET = $h->{FW_RET};
  delete($FW_svgData{$cname});
  FW_svgDone($res, $atEnds, 1);
  FW_finishRead($defs{$cname}, 0, "");
}


Mir ist nicht ganz klar weshalb, aber man sieht hier deutlich, das die SVGs diese Funktion im Fehlerfall mehrmals durchlaufen. Das ist aber ein Problem, da delete($FW_svgData{$cname}); die Daten für die SVGs bereits im ersten Durchlauf gelöscht hat. Wenn also die Funktion noch einmal aufgerufen wird, dann ist $h einfach undef und das Ding crasht (manche werden auch ein zweites Mal erfolgreich aufgerufen, weil wahrscheinlich manchmal die Funktion $FW_svgData schon wieder neue Daten enthält). Ich konnte einmal den Fall reproduzieren das kein Fehler aufgetreten ist. In diesem Fall wurde jedes SVG genau einmal durchlaufen und dann war gut.
Das laden der Seite selbst dauert auch 2-3 Minuten. Erst dann verschwindet der Ladebalken. Bei den Plots Petersilie und Schnittlauch ist das Daten generierende Device Disabled. Mit anderen Worten, die beiden Logfiles enthalten nur sehr alte Daten.
Macht FHEM eine Art Auto Refresh der SVG Anzeige und kann es vielleicht sein, das dies mit dem manuell ausgelösten Refresh kollidiert?
Ich hab jetzt mal die Zeile eingefügt:

Code Auswählen Erweitern

return if(!defined($h));

Das sind zwar die Fehler weg, das Laden der SVGs dauert aber immer noch ewig, weil die einzelnen SVGs immer noch mehrmals geladen werden.

Code Auswählen Erweitern

Internals:
   CONNECTS   68
   CSRFTOKEN  csrf_549900232985295
   DEF        8083 global
   FD         6
   NAME       WEB
   NR         6
   NTFY_ORDER 50-WEB
   PORT       8083
   STATE      Initialized
   TYPE       FHEMWEB
   READINGS:
     2018-10-25 00:57:36   state           Initialized
Attributes:
   JavaScripts pgm2/clock.js
   allowedHttpMethods GET|POST|HEAD
   confirmJSError 0
   hiddenroom AlarmRoom
   longpoll   1
   plotfork   1
   plotsize   1024,320
   styleData  {
"f18": {
  "Pinned.menu": true,
  "cols.bg": "F8F8F8",
  "cols.fg": "465666",
  "cols.link": "4C9ED9",
  "cols.evenrow": "E8E8E8",
  "cols.oddrow": "F0F0F0",
  "cols.header": "DDDDDD",
  "cols.menu": "EEEEEE",
  "cols.sel": "CAC8CF",
  "cols.inpBack": "FFFFFF",
  "savePinChanges": true,
  "Pinned.Room.FLOWERS.grp.DOIF": true,
  "showDragger": true,
  "Pos.style_list_Styles": {
   "left": 0,
   "top": 0,
   "width": 255,
   "height": 377,
   "oTop": 20,
   "oLeft": 0
  },
  "Pos.style_list_f18_special": {
   "left": 0,
   "top": 399,
   "width": 255,
   "height": 151,
   "oTop": 40,
   "oLeft": 0
  },
  "Pos.style_list_f18__Room_specific": {
   "left": 0,
   "top": 592,
   "width": 255,
   "height": 569,
   "oTop": 40,
   "oLeft": 0
  },
  "rightMenu": false,
  "snapToGrid": false,
  "Pos.Room_BAD_grp_smokeDetector": {
   "left": 0,
   "top": 0,
   "width": 308,
   "height": 40,
   "oTop": 20,
   "oLeft": 0
  },
  "Pos.Room_Alarm_grp_alarmNotifier": {
   "left": 0,
   "top": 0,
   "width": 310,
   "height": 232,
   "oTop": 20,
   "oLeft": 0
  }
}
}
   stylesheetPrefix dark
   verbose    3

[rudolfkoenig]

Das laden der Seite selbst dauert auch 2-3 Minuten.

Ich glaube, das erklaert es: manche Browser (Chrome?) senden nach etwa 90 Sekunden die Anfrage nochmal, wenn bis dahin keine Daten gekommen sind. Keine Ahnung wieso, ueber TCP/IP duerfen die Daten nicht verlorengehen.

Leider habe ich bei der Implementierung der neuen parallelen Berechnung der SVGs mit plotEmbed=0 und plotFork>0 einen Denkfehler gemacht: Waehrend der Berechnung mit BlockingCall ist FHEMWEB nicht blockiert, und reagiert auf weitere Anfragen. Die SVG Daten werden aber nicht Anfragenspezifisch, sondern Verbindungspezifisch zwischengespeichert, dazu kommt, dass die Daten vor den SVGs gar nicht gerettet werden. Wenn man den Browserrefresh nach 90 Sekunden beruecksichtigt, dann faellt mir auch keine sinvolle Loesung ein => plotEmbed=0 mit plotFork>0 ist kaputt, und ich muss es ganz anders loesen, z.Bsp. SVG per JavaScript bestellen, also embed per JS nachbauen.

Solange bitte entweder plotFork auf 0 setzen, oder plotEmbed auf 1.

[mumpitzstuff]

Passiert mit Chrome auf dem iPad genauso wie mit Firefox auf dem PC. Ich setze jetzt die von dir vorgeschlagenen Einstellungen. Falls ich irgendwas testen soll, dann melde dich einfach. Ansonsten kann ich dir auch die die SVG Einstellungen und die zugehörigen Logfiles zukommen lassen falls benötigt.

[rudolfkoenig]

Hat etwas laenger gedauert, aber ich meine ich habe jetzt eine Loesung gebaut: https://forum.fhem.de/index.php?topic=106646.new#new