asyncOutput und "Connection lost, trying reconnect every 5 seconds"

DS_Starter · 30 September 2017, 20:32:42

Hallo zusammen,

ich habe in meiner Synology Surveillance Steuerung einen get-Abruf zur Ausgabe des SVS-Logs eingebaut. Die Ausgabe erfolgt mit asyncOutput und arbeitet im Prinzip auch einwandfrei mit der nachfolgenden Beschränkung.

Das SVS-Logfile wird von der Syno abgerufen und aufbereitet (Auszug):

Code Auswählen


my $log  = '<html>';
...
while ($data->{'data'}->{'log'}->[$i]) {
    .....
    $log .= "$time - $level - $desc<br>";
    $i++;
}	
$log .= '</html>';
# Ausgabe Popup der Log-Daten	    
asyncOutput($hash->{HELPER}{CL},"$log");

Aufgefallen ist mir nun folgendes. Die abgerufen Logdaten haben rund 1400 Zeilen.
Wenn ich versuche alle Daten über diesen Weg auszugeben funktioniert die Ausgabe nicht, statt dessen erscheint "Connection lost, tring reconnect every 5 seconds".
Begrenze ich die Anzahl der auszugebenden Zeilen auf max. 928 Zeilen ($log .= "$time - $level - $desc<br>"; ), funktioniert die Ausgabe problemlos wie gewünscht.

Ändere ich den Ergebniszeilenaufbau und verringere die Daten pro Zeile z.B. durch weglassen von $time:

Code Auswählen


....
$log .= "$level - $desc<br>";
...

kann ich mehr Zeilen des logs ausgeben, in meinen Tests waren es 1164 statt 928 Zeilen.

Nun habe ich versucht in fhem.pl, 01_FHEMWEB.pm und fhemweb.js versucht die Ursache dafür zu finden, habe aber nichts brauchbares für dieses Fehlerbild ergründen können. Mir fehlt da schlicht der nötige Überblick der Zusammenhänge.
Eine Beschränkung der Datenmenge an sich scheint es aber nicht zu geben, eher vllt. ein time/timeout-Problem.

Ich hoffe ihr, bzw. Rudi, könnt mir da ein paar Hinweise geben.
Im Prinzip könnte ich zwar die Abrufzeilen begrenzen, das wäre jetzt auch nicht der Showstopper, aber schöner wäre es schon wenn man weiß wie dieser Fehler zustande kommt und evtl. vermeiden könnte.

Danke und ein schönes WE,
Heiko

rudolfkoenig · 01 Oktober 2017, 12:38:44

Wie gross sind bei die Datenmengen?
Worauf ist "attr global longpoll" gestellt?

asyncOutput ist nicht dafuer gedacht, gosse Datenmengen zu uebertragen, sondern eher fuer kurze Mitteilungen, bzw. Rueckgabewerte von einem "get", die man in einem Dialog sinnvoll darstellen kann. Es kann normalerweise etwa 100k uebertragen (siehe fhem.pl/addToWritebuffer() fuer Details).

DS_Starter · 01 Oktober 2017, 13:07:27

Hallo Rudi,

es sind ca. 159334 Zeichen, also etwa 159k.
Jetzt habe ich dank deines Hinweises die Beschränkung in addToWritebuffer gesehen:

Code Auswählen


...
  } elsif($nolimit || length($hash->{$wbName}) < 102400) {
    $hash->{$wbName} .= $txt;
...

Man kann offensichtlich bewußt ein "nolimit" mitgeben. Vielleicht könnte ich das irgendwie nutzen bei der Parameterübergabe an asyncOutput.

Longpoll steht bei mir auf "1", getestet habe ich es auch mit "websocket". Hatte aber keine Besserung gebracht.

Grüße
Heiko

rudolfkoenig · 01 Oktober 2017, 13:52:32

Die in der Zeile 1818 heisst asyncOutput.

ZitatMan kann offensichtlich bewußt ein "nolimit" mitgeben. Vielleicht könnte ich das irgendwie nutzen bei der Parameterübergabe an asyncOutput.

asyncOutput ruft addToWriteBuffer ohne $nolimit auf. Falls der Puffer leer ist, dann wird die Groesse nicht geprueft.
Man koennte die Pruefung komplett entfernen, ich bin aber noch nicht ueberzeugt, dass es sinnvoll ist in einem Browser-Dialog oder im telnet (evtl. unaufgefordert) 160k angezeigt zu bekommen. Die aktuelle Pruefung sorgt dafuer, dass bei verklemmten Browserverbindungen die FHEM-Puffer nicht beliebig anwachsen.

DS_Starter · 01 Oktober 2017, 14:09:44

Danke für die Erläuterungen, Rudi.

Zitat
Man koennte die Pruefung komplett entfernen, ich bin aber noch nicht ueberzeugt, dass es sinnvoll ist in einem Browser-Dialog oder im telnet (evtl. unaufgefordert) 160k angezeigt zu bekommen. Die aktuelle Pruefung sorgt dafuer, dass bei verklemmten Browserverbindungen die FHEM-Puffer nicht beliebig anwachsen.

So eine Prüfung ist sicher sinnvoll und die würde ich auch nicht komplett entfernen wollen.
Was ich mir aber vorstellen könnte, wäre die Möglichkeit die feste 100k-Grenze zu flexibilisieren.
Zum Beispiel bei dem Aufruf einen Parameter nolimit mitzugeben:

Code Auswählen


asyncOutput($hash->{HELPER}{CL}, $log, $nolimit);

Das würde bedeuten mit z.B.

Code Auswählen


asyncOutput($hash->{HELPER}{CL}, $log, 1);

könnte der Entwickler selbst festlegen, ob beispielsweise max. 120k angezeigt werden könnten/sollten.
Ich denke dass eine sinnvolle Größe an dieser Stelle von vielen Faktoren wie der eingetzten Technik, dem subjektiven Nutzerempfinden etc. abhängig ist.
Wie denkst du darüber ?

(Für meinen konkreten Fall könnte ich sicherlich auch damit leben max 900 Zeilen anzeigen zu lassen und diese Beschränkung in der Commandref dem User mitzuteilen)

rudolfkoenig · 01 Oktober 2017, 14:23:21

Zitatkönnte der Entwickler selbst festlegen, ob beispielsweise max. 120k angezeigt werden könnten/sollten.

Sicher, ich wuesste aber gerne einen konkreten Fall, wo es notwendig ist, 100k+ in einem Dialog anzuzeigen.
Es wundert mich auch, dass in deinem Fall der Puffer nicht leer ist (sonst wird ja auch nicht geprueft).

Vielleicht waere es sinnvoller, diese Daten anders anzuzeigen, wobei mW in FHEMWEB dafuer noch keine Empfehlung gibt. Die Daten in eine von FHEMWEB zugaenglichen Datei abzulegen, und diese per <iframe> im Dialog zu verlinken geht trotzdem.

DS_Starter · 01 Oktober 2017, 14:47:27

ZitatSicher, ich wuesste aber gerne einen konkreten Fall, wo es notwendig ist, 100k+ in einem Dialog anzuzeigen.

So ein Fall ist ja mein Beispiel wobei der Terminus "notwendig" sicherlich nicht zutrifft. Ich kann ja die Menge entsprechend begrenzen um die Rahmenbedingung zu erfüllen. Meine Überlegung/Vorschlag war eher prinzipieller Natur diese Möglichkeit einem Modulautor einzuräumen.
Wenn dieser Vorschlag nicht auf Gegenliebe trifft, wäre es auch nicht so dramatisch.

ZitatEs wundert mich auch, dass in deinem Fall der Puffer nicht leer ist (sonst wird ja auch nicht geprueft).

Das kann ich allerdings auch nicht beantworten, aber da kann ich nochmal schauen ob mir etwas aufällt.

ZitatVielleicht waere es sinnvoller, diese Daten anders anzuzeigen, wobei mW in FHEMWEB dafuer noch keine Empfehlung gibt.

Auch das wäre sicher möglich.
Die get-Ausgabe war zunächst eine sehr schöne und einfache Möglichkeit die Daten mit einem Klick anzuzeigen.

Danke Rudi !

viele Grüße
Heiko

DS_Starter · 02 Oktober 2017, 12:04:16

Hallo Rudi,

du/wir hatte uns doch gewundert dass die Prüfung überhaupt durchlaufen wurde, bzw. der WRITEBUFFER nicht leer ist.
Ich habe etwas weiter geforscht und herausgefunden dass es offensichtlich einen Zusammenhang mit der Eventgenerierung gibt bzw. der Positionierung des asyncOutput-Aufrufs innerhalb des Codes zu tun hat.
Zum Einen war die Prüfung negativ (d.h. die Ausgabe funktionierte mit 160k), sobald ich im Device nur einen Eintrag für "event-on- ... -reading" erstellt hatte. Dabei war es nebensächlich welches Reading es war.

Zu diesem Zeitpunkt hatte ich im Coding die asyncOutput-Ausgabe noch vor dem readingsBulkUpdate-Block stehen:

Code Auswählen


# Ausgabe Popup der Log-Daten	    
asyncOutput($hash->{HELPER}{CL}{1},"$log");

readingsBeginUpdate($hash);
# readingsBulkUpdate($hash,"LogEntryCount",$lec);
readingsBulkUpdate($hash,"LastLogEntry",$log0) if(!$hash->{HELPER}{CL}{1});  # Datenabruf im Hintergrund;
readingsBulkUpdate($hash,"Errorcode","none");
readingsBulkUpdate($hash,"Error","none");
readingsEndUpdate($hash, 1);

delete($hash->{HELPER}{CL});

Nachdem ich nun die Reihenfolge geändert habe und asyncOutput nach der readingsBulkUpdate-Auswertung steht, klappt nun auch die Ausgabe von 160k problemlos ohne dass ich ein "event-on- ... -reading" setzen muss.

D.h. mit dieser Codefolge erfolgt keine Prüfung weil WRITEBUFFER leer ist:

Code Auswählen


readingsBeginUpdate($hash);
# readingsBulkUpdate($hash,"LogEntryCount",$lec);
readingsBulkUpdate($hash,"LastLogEntry",$log0) if(!$hash->{HELPER}{CL}{1});  # Datenabruf im Hintergrund;
readingsBulkUpdate($hash,"Errorcode","none");
readingsBulkUpdate($hash,"Error","none");
readingsEndUpdate($hash, 1);
				
# Ausgabe Popup der Log-Daten	    
asyncOutput($hash->{HELPER}{CL}{1},"$log");
delete($hash->{HELPER}{CL});

Dadurch werden nun natürlich ebenfalls die "Connection lost, trying reconnect every 5 seconds"-Meldungen vermieden.

Was ich nun momentan nicht einschätzen kann bzw. noch nicht ergründen konnte ist, wodurch dieser Zusammenhang hervorgerufen wird. Im FHEMWEB wird an etlichen Stellen (z.B. FW_Notify) die Funktion FW_addToWritebuffer aufgerufen die ihrerseits wiederum "addToWritebuffer" aufruft.
Möglicherweise hat sich an einer Stelle ein unerwünschte Verknüpfung eingeschlichen oder es soll so sein und man muss es nur wissen ...

Vielleicht hilft diese Erkenntnis auch Anderen.

viele Grüße
Heiko