Seit kurzem habe ich in meinen RSS (dargestellt auf webviewcontrol) ein Performanceproblem.
Ich rufe einen RSS feed alle 20 Sekunden auf. Regelmäßig tritt dabei der Effekt auf (ungefähr bei jedem zweiten Aufruf), dass zwar die html-Datei korrekt übertragen wird, aber das darin enthaltene Bild fehlt. Im Log ist nichts auffälliges zu finden. Es scheint so, als ob vom fhem Webservice die Bilddatei nicht "schnell genug" (oder gar nicht) übertragen wird. (Zum ausführlichen Loggen und Analysieren hatte ich noch keine Zeit)
Kann das irgendwie mit den vielen fhemweb-Änderungen der letzten Tage zusammenhängen?
Ja.
dachte ich mir inzwischen, denn mit der vorherigen Version:
# $Id: 01_FHEMWEB.pm 7540 2015-01-12 21:26:50Z rudolfkoenig $
nebst zugehöriger fhemweb.js tritt das Problem nämlich nicht auf.
Ist Abhilfe in Sicht?
Wenn du mir zeigst, wie ich das Problem reproduzieren kann, ja.
Das RSS aus fhem.cfg.demo funktioniert mAn korrekt.
Zitat von: rudolfkoenig am 15 Januar 2015, 14:17:28
Wenn du mir zeigst, wie ich das Problem reproduzieren kann, ja.
Keine Ahnung, wie Du das reproduzieren kannst. Die fhem.cfg.demo kenne ich nicht, die ist für mich aber auch nicht ausschlaggebend (da sie auf meinem Produktivsystem ohnehin nicht funktionsfähig ist und auf reinen Demosystemen sowieso alles funktioniert - dafür sind sie schließlich da).
Ich habe mal eine Debug Zeile eingebaut:
my ($dir1, $dirN, $ofile) = ($1, $2, $3)
if($arg =~ m,^$FW_ME/([^/]*)(.*/)([^/]*)$,);
Debug "1: $dir1 N: $dirN o: $ofile";
if($arg =~ m,^$FW_ME/icons/(.*)$,) {
Die Beantwortung der Anfragen an fhem sieht alle 20 Sekunden gleich aus:
2015.01.15 14:42:28 1: DEBUG>1: rss N: / o: wztablet.html
2015.01.15 14:42:28 1: DEBUG>1: pgm2 N: / o: cordova-2.3.0.js
2015.01.15 14:42:28 1: DEBUG>1: js N: / o: webviewcontrol.js
2015.01.15 14:42:28 1: DEBUG>1: rss N: / o: wztablet.png
2015.01.15 14:42:51 1: DEBUG>1: rss N: / o: wztablet.html
2015.01.15 14:42:51 1: DEBUG>1: pgm2 N: / o: cordova-2.3.0.js
2015.01.15 14:42:51 1: DEBUG>1: js N: / o: webviewcontrol.js
2015.01.15 14:42:51 1: DEBUG>1: rss N: / o: wztablet.png
2015.01.15 14:43:13 1: DEBUG>1: rss N: / o: wztablet.html
2015.01.15 14:43:13 1: DEBUG>1: pgm2 N: / o: cordova-2.3.0.js
2015.01.15 14:43:13 1: DEBUG>1: js N: / o: webviewcontrol.js
2015.01.15 14:43:14 1: DEBUG>1: rss N: / o: wztablet.png
2015.01.15 14:43:36 1: DEBUG>1: rss N: / o: wztablet.html
2015.01.15 14:43:36 1: DEBUG>1: pgm2 N: / o: cordova-2.3.0.js
2015.01.15 14:43:36 1: DEBUG>1: js N: / o: webviewcontrol.js
2015.01.15 14:43:36 1: DEBUG>1: rss N: / o: wztablet.png
Die ersten drei Aufrufe funktionieren korrekt, der letzte Aufruf liefert keine png Datei.
Meine Vermutung: es hat irgendwas mit den Änderungen zu tun, die Du bezüglich der Verzeichnisauflösung gestern eingebaut hast:
01_FHEMWEB.pm: more precise FWEXT checking to allow subdirectories for FWEXT. Forum #32103.An der fhemweb.js (die ich auch schon in Verdacht hatte, da ich .js hasse) liegt es jedenfalls nicht.
Deine Vermutung kann schon stimmen.
Kannst du noch ausgeben lassen, ob das RSS Modul aufgerufen wird?
Und am besten den ganzen $arg (das geht auch mit verbose 4/5).
Was ich nicht verstehe: Die Parameter sind gleich: wieso soll es in manchen Faellen nicht funktionieren?
das $arg sieht auch immer gleich aus:
2015.01.15 15:07:22 1: DEBUG>arg: /fhem/rss/wztablet.html
2015.01.15 15:07:22 1: DEBUG>1: rss N: / o: wztablet.html
2015.01.15 15:07:23 1: DEBUG>arg: /fhem/pgm2/cordova-2.3.0.js
2015.01.15 15:07:23 1: DEBUG>1: pgm2 N: / o: cordova-2.3.0.js
2015.01.15 15:07:23 1: DEBUG>arg: /fhem/js/webviewcontrol.js
2015.01.15 15:07:23 1: DEBUG>1: js N: / o: webviewcontrol.js
2015.01.15 15:07:23 1: DEBUG>arg: /fhem/rss/wztablet.png
2015.01.15 15:07:23 1: DEBUG>1: rss N: / o: wztablet.png
2015.01.15 15:07:45 1: DEBUG>arg: /fhem/rss/wztablet.html
2015.01.15 15:07:45 1: DEBUG>1: rss N: / o: wztablet.html
2015.01.15 15:07:45 1: DEBUG>arg: /fhem/pgm2/cordova-2.3.0.js
2015.01.15 15:07:45 1: DEBUG>1: pgm2 N: / o: cordova-2.3.0.js
2015.01.15 15:07:45 1: DEBUG>arg: /fhem/js/webviewcontrol.js
2015.01.15 15:07:45 1: DEBUG>1: js N: / o: webviewcontrol.js
2015.01.15 15:07:45 1: DEBUG>arg: /fhem/rss/wztablet.png
2015.01.15 15:07:45 1: DEBUG>1: rss N: / o: wztablet.png
2015.01.15 15:08:08 1: DEBUG>arg: /fhem/rss/wztablet.html
2015.01.15 15:08:08 1: DEBUG>1: rss N: / o: wztablet.html
2015.01.15 15:08:08 1: DEBUG>arg: /fhem/pgm2/cordova-2.3.0.js
2015.01.15 15:08:08 1: DEBUG>1: pgm2 N: / o: cordova-2.3.0.js
2015.01.15 15:08:08 1: DEBUG>arg: /fhem/js/webviewcontrol.js
2015.01.15 15:08:08 1: DEBUG>1: js N: / o: webviewcontrol.js
2015.01.15 15:08:08 1: DEBUG>arg: /fhem/rss/wztablet.png
2015.01.15 15:08:08 1: DEBUG>1: rss N: / o: wztablet.png
2015.01.15 15:08:31 1: DEBUG>arg: /fhem/rss/wztablet.html
2015.01.15 15:08:31 1: DEBUG>1: rss N: / o: wztablet.html
2015.01.15 15:08:31 1: DEBUG>arg: /fhem/pgm2/cordova-2.3.0.js
2015.01.15 15:08:31 1: DEBUG>1: pgm2 N: / o: cordova-2.3.0.js
2015.01.15 15:08:31 1: DEBUG>arg: /fhem/js/webviewcontrol.js
2015.01.15 15:08:31 1: DEBUG>1: js N: / o: webviewcontrol.js
2015.01.15 15:08:31 1: DEBUG>arg: /fhem/rss/wztablet.png
2015.01.15 15:08:31 1: DEBUG>1: rss N: / o: wztablet.png
2015.01.15 15:08:54 1: DEBUG>arg: /fhem/rss/wztablet.html
2015.01.15 15:08:54 1: DEBUG>1: rss N: / o: wztablet.html
2015.01.15 15:08:54 1: DEBUG>arg: /fhem/pgm2/cordova-2.3.0.js
2015.01.15 15:08:54 1: DEBUG>1: pgm2 N: / o: cordova-2.3.0.js
2015.01.15 15:08:54 1: DEBUG>arg: /fhem/js/webviewcontrol.js
2015.01.15 15:08:54 1: DEBUG>1: js N: / o: webviewcontrol.js
2015.01.15 15:08:54 1: DEBUG>arg: /fhem/rss/wztablet.png
2015.01.15 15:08:54 1: DEBUG>1: rss N: / o: wztablet.png
2015.01.15 15:09:14 1: DEBUG>arg: /fhem/rss/wztablet.html
2015.01.15 15:09:14 1: DEBUG>1: rss N: / o: wztablet.html
2015.01.15 15:09:14 1: DEBUG>arg: /fhem/pgm2/cordova-2.3.0.js
2015.01.15 15:09:14 1: DEBUG>1: pgm2 N: / o: cordova-2.3.0.js
2015.01.15 15:09:14 1: DEBUG>arg: /fhem/js/webviewcontrol.js
2015.01.15 15:09:14 1: DEBUG>1: js N: / o: webviewcontrol.js
2015.01.15 15:09:14 1: DEBUG>arg: /fhem/rss/wztablet.png
2015.01.15 15:09:14 1: DEBUG>1: rss N: / o: wztablet.png
2015.01.15 15:09:37 1: DEBUG>arg: /fhem/rss/wztablet.html
2015.01.15 15:09:37 1: DEBUG>1: rss N: / o: wztablet.html
2015.01.15 15:09:37 1: DEBUG>arg: /fhem/pgm2/cordova-2.3.0.js
2015.01.15 15:09:37 1: DEBUG>1: pgm2 N: / o: cordova-2.3.0.js
2015.01.15 15:09:37 1: DEBUG>arg: /fhem/js/webviewcontrol.js
2015.01.15 15:09:37 1: DEBUG>1: js N: / o: webviewcontrol.js
2015.01.15 15:09:37 1: DEBUG>arg: /fhem/rss/wztablet.png
2015.01.15 15:09:37 1: DEBUG>1: rss N: / o: wztablet.png
Ob das RSS Modul aufgerufen wird, muss ich noch prüfen.
2015.01.15 15:18:14 1: DEBUG>RSS requested: /rss/wztablet.html
2015.01.15 15:18:14 1: DEBUG>RSS requested: /rss/wztablet.png
2015.01.15 15:18:38 1: DEBUG>RSS requested: /rss/wztablet.html
2015.01.15 15:18:38 1: DEBUG>RSS requested: /rss/wztablet.png
2015.01.15 15:19:00 1: DEBUG>RSS requested: /rss/wztablet.html
2015.01.15 15:19:00 1: DEBUG>RSS requested: /rss/wztablet.png
Die ersten beiden Calls funktionieren, der dritte nicht.
Der Hund scheint in dieser Funktion begraben zu liegen:
sub
RSS_getScript() {
my $scripts= "";
my $jsTemplate = '<script type="text/javascript" src="%s"></script>';
if(defined($data{FWEXT})) {
foreach my $k (sort keys %{$data{FWEXT}}) {
my $h = $data{FWEXT}{$k};
next if($h !~ m/HASH/ || !$h->{SCRIPT});
my $script = $h->{SCRIPT};
$script = ($script =~ m,^/,) ? "$FW_ME$script" : "$FW_ME/pgm2/$script";
$scripts .= sprintf($jsTemplate, $script) . "\n";
}
}
return $scripts;
}
Damit wird in die von RSS generierte html Datei eine Liste mit zu ladenden JS-Dateien eingebunden.
Wenn ich den Aufruf dieser Funktion im RSS Modul unterbinde, funktioniert auch der RSS wieder völlig störungsfrei.
Wenn ich mich recht erinnere, hatte ich beim Einbau dieser Funktion seinerzeit schon eine per Attribut gesteuerte Abschaltmöglichkeit dieser Funktion gewünscht 8)
Diese Funktion ist mir auch suspekt, ich verstehe auch nicht, was fuer ein Problem sie loesen soll. Bei der aktuellen Verwendung geht es um das regelmaessige Neuladen eines Bildes, ich habe z.Zt. nicht genug Fantasie um vorzustellen, was man hier mit einem JavaScript anstellen koennte.
Aber um das Problem zu loesen, was evtl. auch an anderen Stellen Auswirkungen hat), haette ich gerne von dir die Liste deiner FWEXTs bzw. SCRIPTS:
{ join(",", keys %{$data{FWEXT}}) }
{ join(",", map { $data{FWEXT}{$_}{SCRIPT} } grep { $data{FWEXT}{$_}{SCRIPT} } keys %{$data{FWEXT}}) }
<script type="text/javascript" src="/fhem/pgm2/cordova-2.3.0.js"></script>
<script type="text/javascript" src="/fhem/js/webviewcontrol.js"></script>
<script type="text/javascript">var wvcDevices = {12345: 'wz_Tablet'}</script>
<script type="text/javascript" charset="UTF-8"></script>
Die Funktion macht an sich schon Sinn. Sie bindet die von webviewcontrol benötigten Scripte in die html-Seite mit ein, damit man per wvc von fhem aus beispielsweise das Tablet steuern kann.
ABER:
Aus irgendeinem Grund wird die Datei webviewcontrol.js im Verzeichnis /fhem/js/ gesucht anstatt in /fhem/pgm2
2015.01.15 15:07:23 1: DEBUG>arg: /fhem/pgm2/cordova-2.3.0.js
2015.01.15 15:07:23 1: DEBUG>arg: /fhem/js/webviewcontrol.js
Und dort wird die Datei natürlich nicht gefunden.
Verantwortlich dafür ist das wvc-Modul selbst:
sub webViewControl_modifyJsInclude() {
my @appsArray;
foreach my $appName (keys %{ $modules{webViewControl}{defptr} } ) {
push(@appsArray, $modules{webViewControl}{defptr}{$appName}->{appID} . ': \'' . $appName . '\'');
}
my $vars = 'var wvcDevices = {' . join(', ', @appsArray) . '}';
$data{FWEXT}{$fhemUrl}{SCRIPT} = 'cordova-2.3.0.js"></script>' .
'<script type="text/javascript" src="/fhem/js/webviewcontrol.js"></script>' .
'<script type="text/javascript">' . $vars . '</script>' .
'<script type="text/javascript" charset="UTF-8';
}
Ich werde dort den Pfad mal auf pgm2 ändern und schauen, was passiert.
achso, hab ich vergessen...
Zitat von: rudolfkoenig am 15 Januar 2015, 20:31:33
haette ich gerne von dir die Liste deiner FWEXTs bzw. SCRIPTS:
das hatte ich mir schon per Data::Dumper angeschaut:
2015.01.15 20:40:37 1: DEBUG>$VAR1 = {
'CONTENTFUNC' => 'FileLog_logWrapper'
};
2015.01.15 20:40:37 1: DEBUG>$VAR1 = {
'CONTENTFUNC' => 'FileLog_toSVG'
};
2015.01.15 20:40:37 1: DEBUG>$VAR1 = {
'CONTENTFUNC' => 'SVG_WriteGplot'
};
2015.01.15 20:40:37 1: DEBUG>$VAR1 = {
'FORKABLE' => 1,
'FUNC' => 'SVG_showLog'
};
2015.01.15 20:40:37 1: DEBUG>$VAR1 = {
'NAME' => 'GDS gds Files',
'LINK' => 'gds',
'FUNC' => 'HTTPSRV_CGI',
'deviceName' => 'gds_web_gds'
};
2015.01.15 20:40:37 1: DEBUG>$VAR1 = {
'NAME' => 'RSS',
'LINK' => 'rss',
'FORKABLE' => 0,
'FUNC' => 'RSS_CGI'
};
2015.01.15 20:40:37 1: DEBUG>$VAR1 = {
'SCRIPT' => 'cordova-2.3.0.js"></script><script type="text/javascript" src="/fhem/js/webviewcontrol.js"></script><script type="text/javascript">var wvcDevices = {12345: \'wz_Tablet\'}</script><script type="text/javascript" charset="UTF-8',
'FUNC' => 'webViewControl_Cgi'
};
Zitat von: betateilchen am 15 Januar 2015, 20:53:38
Ich werde dort den Pfad mal auf pgm2 ändern und schauen, was passiert.
Diese kleine Änderung scheint das Problem tatsächlich zu lösen :) Bisher hatte ich keine Ausfälle mehr.
Ich glaube du kannst es auch zurueckaendern, ich habe FHEMWEB angepasst, damit sowas wieder gefunden wird.
Es gab mal eine Zeit, wo wir noch mit vielen Leuten an FHEMWEB herumgekoechelt haben. Damals haben wir (leider) beschlossen, dass alle .css Dateien in den virtuellen /fhem/css Ordner, alle Bilder in /fhem/icons, usw, sind. Das war meiner Ansicht nach falsch, und hat deutlich mehr Nachteile als Vorteile, hat sich aber an zu vielen Stellen (FLOORPLAN, WebViewControl, etc) festgesetzt. Und ich erwische beim Testen nicht immer diese Module bzw. deren Features, meine habe ich davon weitgehend befreit.
Ich würde es begrüßen, wenn wir solche Dinge nicht immer mit Workarounds in FHEMWEB lösen müssten. Entweder ein Verzeichnis, das angegeben wird, existiert wirklich oder eben nicht. Solche virtuellen mappings machen eine Fehlersuche für jemanden, der den historischen Hintergrund nicht kennt, nahezu unmöglich.
Letztendlich bin ich auf die Fehlerursache gestoßen, als ich die RSS Seite mit geöffneter JS-Konsole in Google Chrome aufgerufen habe.
Ich habe das Thema hier an Dirk adressiert: http://forum.fhem.de/index.php/topic,10628.msg246419.html
Leider ist es nicht so einfach diese Auszubauen, weil neben WebViewControl mind. noch in den Module FRITZBOX, FLOORPLAN, WWO, und MPD betroffen sind, d.h. Dateien ueber /fhem/icons, /fhem/css oder /fhem/js ansprechen.
FLOORPLAN sollte bei js und css mit dem aktuellen patch nicht mehr betroffen sein. icons sollte man meiner meinung nach auch reparieren wenn das noch ein problem ist.
Zitat von: rudolfkoenig am 16 Januar 2015, 08:18:40
weil neben WebViewControl mind. noch in den Module FRITZBOX, FLOORPLAN, WWO, und MPD betroffen sind
Dann sollten die verantwortlichen Entwickler sich eben darum kümmern, das aus den betroffenen Modulen auszubauen. Fhem ist ein lebendes System, da können solche Umbauten immer mal notwendig werden. Es kann doch nicht der Sinn sein, immer wieder Hilfskrücken zu bauen, um sämtliche Altlasten am Leben zu erhalten. (Nur meine persönliche Meinung)
/js/ wird verwendet in 72_FRITZBOX und 95_FLOORPLAN
/css/ wird verwendet in dito
/icons/ wird verwendet in 01_FHEMWEB (in FW_IconURL()), 59_WWO, 73_MPD und 98_weblink
Das ist doch eine überschaubare Menge an Änderungen.
so ist es.
vielleicht kann man das etwas einfacher machen wenn es ein paar wiederverwendbare routinen dafür gibt. z.b. die js/css initialisierung am seitenanfang die im floorplan fast identisch zu fhemweb gebraucht wird.