Hallo Rudi!
Ich hab seit dem FHEMWEB Update auf r7212 ein eigenartiges Problem, tritt nur mit Safari und nur bei gesetztem longpollSVG Attribut.
Wenn in einem Raum mehrere Plots vorhanden sind fangen diese zum Blinken an. Bei einem einzelnen Plot, Raum- oder Detail Ansicht, passiert nichts. Wenn ich die Datei zurückspiele passt wieder alles.
FHEM läuft auch MacMini 10.10.1, schon mehrfach neugestartet
Zugriff mit MacBook Air mit Safari, auch schon mehrfach neugestartet
Mit iOS Safari auch kein Problem.
Hast du eine Idee?
Grüße
Hi,
da könnte ein Zusammenhang mit den non-blocking Änderungen bestehen...
Hast du dazu vieleicht ein paar Details zu dem Problem? Ist bei der benutzten fhemweb Instanz SSL aktiv?
Wie sieht's mit Meldungen im Logfile aus?
Bitte auch dem fhemweb mittels verbose 5 Attribut mehr Details entlocken während du das Problem nachstellst.
Rainer
Hi,
hmm, bekomme die SVGs nur zum flackern wenn ich böse Dinge tue. Sprich... wenn in den .gplot files nicht wie dokumentiert der devicename steht sondern eine regexp.
Dann macht firefox nach ungefähr 500kb updates vom fhem die connection zu um es nochmal zu probieren. Wie gesagt - böse Dinge die ich da tue - explizit entgegen der Doku.
Normal kann ich das nicht reproduzieren. Brauche also wirklich mehr Details... vieleicht auch ein packet capture?
Rainer
Ich sehe im Log leider auch nichts besonderes, und habe erstmal keine Idee.
Hi,
so, Update... erstmal ein paar Korrekturen:
- ist garnicht so böse was ich tue: Der filter=.* wird von fhemweb.js unabhängig vom gplot gesetzt. Das passiert sobald longpollSVG gesetzt ist und ein SVG in der Seite eingebettet ist. Meine "Bösartigkeit" (Pattern statt Device Name im gplot) führt nur dazu dass die SVGs nicht aktuallisiert werden.
- es sind genau 300kb nach denen fhemweb.js die connection zu macht.
Inzwischen ist klar, was
bei mir zum flackern führt: Beim Aufbau der longpoll Verbindung wird erstmal mittels FW_roomStatesForInform der Status für alles auf den filter passende geliefert. Darin enthalten sind auch SVG devStateIcons. Passt der longpoll Filter auf sehr viele Devices mit SVG Icons wird die Antwort also schnell seeehr gross. Wie oben beschrieben führt eine übergrosse Antwort dazu, daß fhemweb.js es nochmal probiert. Bei jedem dieser Versuche sieht fhemweb_svg.js die events und lädt die SVGs neu und verursacht das flackern.
Soweit so gut... unklar ist mir aber noch, warum das vorher funktioniert hat. Vor dem change wurde die initiale Antwort komplet an print() gegeben - und wenns schief gegangen ist wurde das still ignoriert. Jetzt wird dagegen sicher gestellt, daß die Daten auch wirklich gesendet werden. Eigentlich hätte das per print aber auch ausgeliefert werden müssen. Untersuche ich noch.
Ich verstehe noch nicht, warum überhaupt mittels FW_roomStatesForInform der initiale Status verteilt wird. @Rudi, kannst du mir da helfen?
Für das identifizierte Problem sehe ich spontan folgende Lösungsoptionen - kann aber nicht einschätzen welche die am wenigsten schlechte ist:
- keinen initialen Status mehr ausliefern
- das 300kb Limit in fhemweb.js hochdrehen
- kann man den responseString vieleicht vorzeitig irgendwie freigeben um das im Kommentar erwähnte Memory Problem zu vermeiden
- einen magischen Weg finden, den Filter passender zu gestalten. zB über ein händisch (bahpfui) zu pflegendes Attribut im SVG modul.
Ob das auch
Euer Problem ist, weiss ich noch nicht. Ohne Logs ist ausgeschlossen das zu sagen. Also... bitte verbose einschalten und Logs liefern:
attr TYPE=FHEMWEB verbose 5Danke
Hallo!
Sry, ich bin erst jetzt dazu gekommen.
Zitat von: geek am 16 Dezember 2014, 20:54:09
Ist bei der benutzten fhemweb Instanz SSL aktiv?
Nein.
Zitat von: geek am 16 Dezember 2014, 20:54:09
Wie sieht's mit Meldungen im Logfile aus?
Keine Auffälligkeiten mit verbose 3. Das Log mit verbose 5 hänge ich an.
Ich verstehe noch nicht ganz was du mit "böser" syntax meinst. Kannst du mir vielleicht zeigen was du meinst?
# Created by FHEM/98_SVG.pm, 2014-05-18 10:15:33
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title '<L1>'
set ytics
set y2tics
set grid ytics
set ylabel "Aktuell"
set y2label "Aktuell"
set yrange [0:1000]
set y2range [0:1000]
#FileLog 4:stromverbrauchAllgemein.power\x3a::$fld[3]>300?300:$fld[3]
#FileLog 4:stromverbrauchAllgemein.power\x3a::$fld[3]>500?500:$fld[3]
#FileLog 4:stromverbrauchAllgemein.power\x3a::
#FileLog 4:stromverbrauchAllgemein.power\x3a::
#FileLog 4:stromverbrauchAllgemein.power\x3a::
plot "<IN>" using 1:2 axes x1y2 title '0 - 300 W' ls l1fill lw 0.2 with lines,\
"<IN>" using 1:2 axes x1y2 title '300 - 500 W' ls l4fill lw 0.2 with lines,\
"<IN>" using 1:2 axes x1y2 title '> 500 W' ls l0fill lw 0.2 with lines,\
"<IN>" using 1:2 axes x1y2 title '.' ls l4fill lw 0.2 with lines,\
"<IN>" using 1:2 axes x1y2 title '.' ls l7 lw 0.2 with linesIch bin mir auch (fast) sicher das ich die Plots damals mit Buttom "Create SVG Plot" angelegt hab. Die Plots bearbeite ich immer mit dem Plot Editor. Die .gplot Dateien greife ich nie an.
Grüße
Hi,
so, kein SSL ist gut. Dann ists keine der dafür nötigen Sonderbehandlungen. Dein Log sagt, du läufst in das Problem was ich beschrieben habe: Die wiederholten XHR requests und das EOF (client hat connection zu gemacht) zeigen das.
"böse" syntax haste nicht. In deinem gplot steht ja "stromverbrauchAllgemein.irgendwas". Der Devicename ist also drin. Mein Kommentar war auch eher an die gegebenenfalls mitlesenden Entwickler gerichtet. Egal. spielt hier jetzt auch keine Rolle mehr.
Damit haben wir geklärt was dein jetztiges Problem ist und welche Optionen es zum reparieren gibt.
@Rudi: Mir fehlt da etwas der Überblick welche Option am sinnvollsten ist - baue aber gerne einen patch wenn ich die Richtung weiß.
Wenn du magst kannst du ja mal in www/pgm2/fhemweb.js das Limit in Zeile 117 hochdrehen:
// reset the connection to avoid memory problems
if(FW_pollConn.responseText.length > 300*1024)
Danach die Seite neu laden ... und schauen obs besser wird. Wie der Kommentar sagt, ist das aber auch nicht ohne Probleme.
Völlig unklar ist mir dagegen warum das vorher funktioniert hat. Kannst du mir vieleicht von "vorher" ein verbose 5 log schicken?
Ich hänge auch mal 2 verschiedene Versionen von 01_FHEMWEB.pm mit debug code an. Wenn's geht würde ich mich da auch jeweils über ein verbose 5 log freuen.
Rainer
Hallo geek,
könnte das evtl hiermit zu tun haben ?
http://forum.fhem.de/index.php/topic,23774.msg183266.html#msg183266
vg
jörg
Hi,
ja, laut svn blame ist das in r6243 eingepflegt worden - und das Referenziert deinen Thread.
JavaScript hab' ich bisher immer n großen Bogen drum gemacht... aber wenn der responseText readonly ist, lässt sich das auf dem client nicht fixen. Dann muß dem server beigebracht werden, initial nur events auszuliefern die seit dem generieren der Seite oder dem letzten longpoll entstanden sind.
Selbst wenn man dashboard, longpollSVG und floorplan (...) ne Möglichkeit gibt, ihren ".*" filter durch was selektiveres zu ersetzen, ist das nur ein Aufschub des Problems.
Ich schau mal, ob ich die events nach ner timestamp filtern kann.
Rainer
doch, doch - der patch ist leider nicht eingecheckt sondern nur ein Teil davon, meiner Meinung nach auch fehlerhaft.
Das Problem könnte mglw daran liegen das der longpoll nach 300k brutal zurückgesetzt wird ohne das geprüft wird ob die letzte Nachricht komplett ist.
Es gibt ja keine Garantie das der XHR state 3 nur dann aufgerufen wird wenn das letzte event auch komplett im Puffer liegt.
Das Szenario das der Schere des Zensors zum Opfer gefallen ist lautet so:
fhemweb liefert die events als stream, ein event ist zur Hälfte ausgeliefert, XHR triggert stage 3, fhemweb.js sieht die Schwelle von 300k überschritten und macht den cut im longpoll. Das könntest du das jetzt unbewusst (und schuldlos) durch Deinen patch getriggert haben, evtl entsteht ja ein Zeitslot innerhalb eines events (puffer voll, Teilauslieferung, dann zweiter step). Schlussendlich ist mMn nirgendwo spezifiziert zu welchem Zeitpunkt der XHR den stage 3 weiterreicht.
Das ist nur ein Verdacht, beim überfliegen des threads schien mir ein Zusammenhang aber sehr möglich.
In der Konsequenz würde ein hoch setzen der 300k Schwelle das Problem nur verlagern - imho korrekt ist einzig den Longpoll (clientseitig) nur dann zu schliessen wenn das letzte event komplett empfangen und verarbeitet ist (lastchar "\n").
Generell darf die Menge der Daten (sprich filter .*) keine Rolle spielen, warum auch. Gemessen an der zur Verfügung stehenden Bandbreite ist das doch ein Klacks.
vg
Jörg
Hi,
wenn ich deinen patch richtig verstanden habe, löst der nur das Speicherproblem wenn die events natürlich über die Zeit entstanden sind.
Hier ist aber das Problem, daß fhem beim connect schon so viel ausliefert, daß das limit überschritten wird. Sprich, selbst wenn der client erst die initialen events komplett verarbeitet bevor er die connection zu macht, entsteht das gleiche problem beim nächsten connect wieder wenn fhem wieder die gleiche riesen-antwort als Begrüßung schickt.
Vorraussetzung ist also, daß fhem den Status von sehr vielen Devices per longpoll ausliefern soll... also wenn der filter auf sehr viele devices passt (zb. das .* von longpollSVG, floorplan oder dashboard). Per longpoll werden aber auch die SVG devStateIcons ausgeliefert ... und damit wird die initiale Response von fhem auch schon bei einer überschaubaren Anzahl Devices zu groß.
Habe die initiale Response auf nen commit zurückgeführt, der das Loch zwischen Generierung der Seite und erstem XHR request schließt. Kann man also nicht rauswerfen - sondern muß "repariert" werden.
Vor meiner Änderung wurde die initiale reponse am Stück mittels "print" auf den blocking Socket geschrieben... Ob das erfolgreich war wurde nicht geprüft.
Nach der Änderung werden die Daten so lange an syswrite gegeben, bis alles geschrieben ist. Der Rest von meinem Patch hat keine Auswirkung auf diesen codepfad.
Möglich ist also eigentlich nur, daß print nicht alles ausgeliefert hat. Kann ich bei mir aber nicht reproduzieren, bei mir tut das auch vor der Änderung nicht. Ich verstehe ehrlich gesagt auch nicht warum print auf einem blocking socket Daten hätte unterschlagen sollen.
Rainer
Hi,
so, anbei ist ein Patch als "proof of concept". Erstmal nur das Senden der initialen Informs ab einer Timestamp (mit fallback auf now-5sec). Apply geht mit "patch -p1 < initial-longpoll-proof-of-concept.diff" im fhem Verzeichniss.
Theoretisch reicht das so... verpasst aber Informs wenn der client > 5sec zwischen Generieren der Seite und erstem longpoll Request braucht. Ebenso verpasst der client Informs wenn zwischen 2 longpolls mehr als 5sec vergehen.
Beides ist nicht sooo trivial zu fixen (zumindest nicht für mich als javascript/html Noob):
- Wo kann fhem beim Generieren einer Seite die Timestamp unterbringen dass der Client die sieht? Das müßte dann an allen Stellen passieren, die longpoll aktivieren (schneller grep finden neben FHEMWEB auch FLOORPLAN).
- Die Informs für STATE haben keine Timestamp vom Server. Nimmt der Client seine eigene Timestamp vom Empfang eines Informs erfasst das also nicht die Zeit von Versand + Auswertung.
Rainer
Hallo Rainer,
ich habe Deinen Post leider nicht ganz verstanden .. :) aber während ich darüber nachdenke ist mir tatsächlich ein zweites, fundamentales, Problem im longpoll klar geworden (das meinst Du vmtl)
Zitatwenn ich deinen patch richtig verstanden habe, löst der nur das Speicherproblem wenn die events natürlich über die Zeit entstanden sind.
evtl. Weil Du gesagt hast das Du um js einen Bogen machst, mache ich einen kurzen Ausflug zum XHR Objekt damit wir den gleichen Stand haben (verzeih mit wenn Du das alles schon weißt)
Das XHR wurde in die browser eingebaut um, idR asynchrony und vom js aus,
eine x-beliebige (damals meist XML) Datei vom Server zu holen.
Dazu wird eine ganz normale Anfrage an den Server initiiert und der Server sollte diese Datei
am Stück aus liefern. Wenn die Datei komplett geladen ist wird ein event (das ist stage 4) generiert und die Datei kann vom script verarbeitet werden.
Das sich das ganze überhaupt für longpoll verwenden lässt liegt daran das die Entwickler von Mozilla eine Funktion eingebaut haben die
während des ladens der Datei ab und zu mal aufgerufen wird. Die war im Ursprung dazu gedacht das der Entwickler einen Fortschrittsbalken anzeigen kann. Deshalb bekommt man in dieser Funktion auch Zugriff auf responseText (der Balken muss ja wissen wie viele kb/mb schon geladen sind).
Der lonpoll (auf Serverseite) macht ja jetzt nichts anderes als eine unendlich große Datei, ganz langsam auszuliefern.
Deshalb entsteht der Speicheraufwand
immer "natürlich über die Zeit". Mal schneller, mal langsamer.
Genau genommen haben wir also zwei Probleme:
* das initiale Laden des state (auch svg, völlig korrekt!) ist strukturell (in den longpoll Daten) nicht von der Aktualisierung getrennt.
* beim aktualisieren der states wird nicht darauf geachtet das ein event komplett empfangen wird bevor der longpoll (beim erreichen der Schwelle) den re-connect ausführt.
Die daraus entstehende Schleife hast Du (wenn ich Dich an dieser Stelle richtig verstehe ?) richtig diagnostiziert: nach jedem reconnect werden wieder alle initial states gepusht - die Schwelle wird erreicht - reconnect - push - reconnect - ...
Wenn man die (300k) - Schwelle höher setzt lassen sich die Auswirkungen (auf #1) vmtl verringern - das Problem bleibt aber bestehen weil es im Design von fhemweb angelegt ist.
vg
jörg
off-topic: ich bin bei dem Thema noch ein wenig emotional weil es "damals" über 2 Monate gedauert bis Rudi (bei allem Respekt und Anerkennung für seine Verdienste) sich den patch überhaupt angeschaut hat - und dann fachlich falsch und unvollständig umgesetzt hat.
Andere Themen (das initial pushen hatte ich damals genau auch, post vom 31.5) gab es nie eine response. ... jquery loader ist, offen gesagt Schrott, - am Ende hat mich das gezwungen ein fhemweb Erweiterungsprojekt in das schon viel Arbeit geflossen war komplett in die Tonne zu treten. Am Ende sind die Wege des Schicksals unergründlich - ich hätte sonst nie das smartVisu Projekt übernommen das heute (völlig unabhängig vom der fhemweb Stabilität) schon eine ganz andere Liga ist.
Hi,
ja, hast du richtig verstanden, da sind mehrere Probleme mit fhem/-web (ich würde mich da nicht auf 2 Beschränken ;) )
Was ich sehe, versuche ich zu fixen... und freue mich, wenns nicht nur in meiner lokalen Version ist.
Als ich bei mir die Hänger vom Fhemweb gesehen habe, war das für mich eigentlich nur der Anstoß non-blocking IO zu reparieren... zumindest in den von mir genutzten modulen. Ist nicht wirklich einfach, weil wir für alles das Rad neu erfinden müssen ... oder man fhem auf eine "gängige" mainloop a'la AnyEvent umbauen müßte.
Habe auch schon begeistert Deinen SmartVisu Thread gesehen :D
Rainer
Zitat von: geek am 19 Dezember 2014, 13:40:22
ja, hast du richtig verstanden, da sind mehrere Probleme mit fhem/-web (ich würde mich da nicht auf 2 Beschränken ;) )
check 8)
ZitatAls ich bei mir die Hänger vom Fhemweb gesehen habe, war das für mich eigentlich nur der Anstoß non-blocking IO zu reparieren... zumindest in den von mir genutzten modulen. Ist nicht wirklich einfach, weil wir für alles das Rad neu erfinden müssen ... oder man fhem auf eine "gängige" mainloop a'la AnyEvent umbauen müßte.
8)
vg
jörg
longpollSVG habe ich nur eingebaut, um Boris zu zeigen, dass das so nicht funktioniert, weil bei einem Rerfresh es zu auffaellig blinkt. Fuer mich ist das ein Quick-Hack, solange ich (oder sonstwer) die SVG-Plot generierung in JavaScript neu implementiert.
Mit longpollSVG stehen zwar die benoetigten Filter im HTML, aber diese alle zu sammeln, und mit dem Raum eine Menge zu bilden ist weder in JS, noch in fhem.pl (devspc2array) implementiert. Es waere beides noetig.
ZitatIch verstehe noch nicht, warum überhaupt mittels FW_roomStatesForInform der initiale Status verteilt wird.
Das ist ein (bzw. einer der) HomeMatic workarounds, es kann aber theoretisch auch andere betreffen.
Wenn der Benutzer bei einem HM-Geraet auf "on" klickt, dann wird erst der Status auf "set_on" gesetzt. Erst wenn das HM-Geraet das bestaetigt, wird es auf "on" gesetzt. D.h. in FHEMWEB wird "set_on" gerendert, bis fhemweb.js aber die Verbindung wg. longpoll aufbaut, steht der Status schon auf on, das wird aber per event nicht gesendet, und die Anzeige bleibt auf set_on (Lampe mit Ausrufezeichen).
Jedenfalls war das frueher so. Mit dem aktuellen Version von fhemweb.js eigentlich nicht mehr, weil alle set Kommandos ohne erneutes Abholen der HTML-Seite gesendet werden, d.h. das initiale Abfragen aller Werte ist nur in den seltensten Faellen relevant. Das Abschalten koennte Nebeneffekte verursachen, wenn einzelne Widgets fuer die Anfangsdarstellung auf das JavaScript-Rendern per Event verlassen, mir ist aber keine solche Stelle bekannt.
Eigentlich wollte ich FW_roomStatesForInform komplett entfernen, aber das haette in manchen Faellen zu race-condition gefuehrt.
Deswegen habe ich geeks Idee aufgegriffen, und etwas modifiziert: nur Geraete mit einem gesetzten OldTimestamp werden beruecksichtigt, da OldTimestamp (nur) bei Events gesetzt wird.
@joerg: es tut mir Leid wg. des "falschen" Patchens, obwohl ich nicht sicher bin, dass es in diesem Fall helfen wuerde. Ich bin aber froh wg. SmartVisu: ich freue mich ueber schoene Alternativen, und finde doof, wenn ich als Blockierer dastehe, wozu ich bei grossen Patches sehr leicht tendiere.
fhemweb.js mit jquery neu zu bauen steht oben auf meiner TODO-Liste.
Ja Du hast recht - nach Diagnose: hier (initiale Datenmenge) würde es hier nicht helfen, trotzdem denke ich des es einen sporadisch auftretenden Fehler generiert.
Die Notwendigkeit der Trennung vom initialen state zu den Aktualisierung durch longpoll ist hier (einmal mehr) deutlich geworden . Das wäre mein Vorschlag, aus diesem post (http://forum.fhem.de/index.php/topic,23774.msg173038.html#msg173038)
ZitatHier wäre es extrem hilfreich wenn FW_Summary einen weiteren Parameter bekommen könnte der im Device eine Unterscheidung ermöglicht ob der longpoll fragt (dann muss ich den Initialisierungscode nicht mitschicken und kann schick Bandbreite sparen) oder ob die Anfrage vom pageLoad kommt.
fhemweb:
line 2176
- my ($allSet, $cmdlist, $txt) = FW_devState($dn, "", \%extPage);
+ my ($allSet, $cmdlist, $txt) = FW_devState($dn, "", \%extPage, 1);
line 2221
- my ($d, $rf, $extPage) = @_;
+my ($d, $rf, $extPage, $longpoll) = @_;
line 2300
- my $newtxt = &{$sfn}($FW_wname, $d, $FW_room, $extPage);
+my $newtxt = &{$sfn}($FW_wname, $d, $FW_room, $extPage, $longpoll);
Das dürfte mAn kein bestehendes Modul beeinflussen und man könnte in der device FW_summary zukünftig $longpoll == true auswerten. Wenn der pagelLoad fragt dann sollte $longpoll == undef sein.
Zu jquery, (das hatten wir auch schon mehrfach)
Der Umbau von fhemweb.js ist sicher wünschenswert, aktuell ist der loader für alle *.js aber ... suboptimal
Das loadscript scheitert wenn der code inline von fwsummary kommt und mehr als ein device das wollen. device a stößt das laden an, device b bekommt unmittelbar darauf schon ein true weil auf script source geprüft wird ohne das jquery initialisiert ist (und scheitert).
Ein laden aus dem Modul via: http://forum.fhem.de/index.php/topic,30294.msg229458.html#msg229458 (zur Benutzung mit jquery ui) produziert einen Fehler wenn ein anderes Modul seinerseits jquery nachfolgend lädt - weil dann "$" neu und ohne jquery ui initialisiert wird. Schlussendlich muss ich also jquery im "noconflict" laden (nicht grad toll ...)
Spielt jetzt nur noch bedingt in die topic
dieses post - aber: viel bug .. viel patch. Wegducken bringt nix , auch wenn patch lang ;)
vg
jörg
Muss meinem ganzen Gemecker noch diesen Nachtrag hinzufügen:
FHEM ist cool, macht verdammt viel Spaß unn ist die Summe von verdammt viel guter Arbeit, Engagement und know-how.
Das bedeutet nicht das jede Zeile code stimmt - das ist auch mal ein Aufreger drin :) was am Gesamtpaket nichts ändert 8)
so denn, vg
jörg
Hi,
@rudi: cool. Bleibt eigentlich nur noch, die "generated" timestamp in fhemweb.js irgendwie zu aktuallisieren. Sonst werden nach nem reconnect ja wieder alle events seit page load angefragt... was dann wieder zum reconnect führt.
Habe jetzt erst gesehen/kapiert, daß über FW_roomStatesForInform + FW_devState ja auch der FW_summaryFn aufgefufen wird - und im Falle von SVG_FwFn kann da auch das komplette SVG eingestopft werden. Ist das durch Deinen Check auf die Existenz einer OldTimestamp abgedeckt? (sorry, habe ich nicht so ganz verstanden).
Und ja, Jörg hat Recht. Wenn fhem nicht die beste Lösung für meine Bedürfnisse wäre, wäre ich nicht hier :D
Rainer
Danke für euren Einsatz, bei mir funktioniert es wieder!
Grüße
Bei mir seit gestern:
2014.12.20 08:00:08 1: reload: Error:Modul 01_FHEMWEB deactivated:
Too many arguments for main::FW_roomStatesForInform at ./FHEM/01_FHEMWEB.pm line 595, near "$sinceTimestamp)"
BEGIN not safe after errors--compilation aborted at ./FHEM/01_FHEMWEB.pm line 630, <$fh> line 22.
2014.12.20 08:00:08 0: Too many arguments for main::FW_roomStatesForInform at ./FHEM/01_FHEMWEB.pm line 595, near "$sinceTimestamp)"
BEGIN not safe after errors--compilation aborted at ./FHEM/01_FHEMWEB.pm line 630, <$fh> line 22.
2014.12.20 08:00:08 3: Please define WEB first
Seltsamerweise nur auf dem Ubuntu 14.04.1 LTS System, auf der Fritzbox 7390 läuft noch alles.
Hallo HolyMoly,
Reload hatte bei mir auch nicht gereicht, ging nur mit shutdown restart.
Gruß
Karl
Sent from my iPad using Tapatalk
shutdown restarts habe ich schon einige erfolglose hinter mir.
Auch ein update force hat nichts gebracht. Version ist:
$Id: 01_FHEMWEB.pm 7264 2014-12-19 16:13:11Z rudolfkoenig $
@HolyMoly: welche Perl Version verwendest du? Bei mir (und etlichen anderen) kommt diese Meldung nicht.
Ich habe ein "forwad declaration" eingebaut, vlt. hilft es.
perl -v
This is perl 5, version 18, subversion 2 (v5.18.2) built for arm-linux-gnueabihf-thread-multi-64int
(with 41 registered patches, see perl -V for more detail)
Ich meld mich morgen nach dem Update zurück...
Leider mit # $Id: 01_FHEMWEB.pm 7284 2014-12-21 16:18:32Z rudolfkoenig $
immer noch:
2014.12.22 11:17:56 1: reload: Error:Modul 01_FHEMWEB deactivated:
Too many arguments for main::FW_roomStatesForInform at ./FHEM/01_FHEMWEB.pm line 596, near "$sinceTimestamp)"
BEGIN not safe after errors--compilation aborted at ./FHEM/01_FHEMWEB.pm line 631, <$fh> line 24.
2014.12.22 11:17:56 0: Too many arguments for main::FW_roomStatesForInform at ./FHEM/01_FHEMWEB.pm line 596, near "$sinceTimestamp)"
BEGIN not safe after errors--compilation aborted at ./FHEM/01_FHEMWEB.pm line 631, <$fh> line 24.
2014.12.22 11:17:56 3: Please define WEB first
Ich habe es mit perl 5.18.2 getestet, und ueber die Definition gegruebelt: ich habe keine Idee, woran das Problem bei dir liegen kann, bei mir tut es.
Du kannst versuchen als Workaround den Aufruf in FHEMWEB.pm zu loeschen, die Funktion sorgt nur dafuer, dass Events zwischen Rendern der HTML-Daten und den Aufruf im Browser nicht verloren gehen.
Ohne den call geht es wieder. Trotzdem irgendwie komisch :'(
Irgendwie ungut wenn nach jedem FHEMWEB update das Webinterface weg ist. Gibt es nicht doch eine Möglichkeit das zu fixen?
Ich vermute, dass du ein weiteres Modul vorher geladen hast, der diese Funktion definiert.
Kannst du bitte danach suchen?
Hilft es, wenn du die Deklaration (nicht den Aufruf) entfernt?
Selbst wenn ich die Forward und Methodendefinition FW_roomStatesForInform in FHEMWEB entferne bleibt der Fehler bestehen was ja deine Theorie bestätigen dürfte. Vor FHEMWEB stehen bei mir nur die attr global definitionen in der fhem.cfg. Was wird denn noch vor der cfg ausgeführt wo FW_roomStatesForInform definiert worden sein könnte?
"attr global verbose 5" ist dein Freund.
Komisch, ich sehe davor nix wo roomStatesForInform definiert sein könnte:
2015.01.17 11:28:40 5: Initializing Type Library:
2015.01.17 11:28:40 1: Including fhem.cfg
2015.01.17 11:28:40 5: Cmd: >attr global userattr Beleuchtung Beleuchtung_map DbLogExclude alarmDevice alarmSettings devStateIcon devStateStyle fp_Augstr homestatus_structure homestatus_structure_map icon lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0 sortby structexclude webCmd widgetOverride<
2015.01.17 11:28:40 5: Cmd: >attr global autoload_undefined_devices 1<
2015.01.17 11:28:40 5: Cmd: >attr global group System<
2015.01.17 11:28:40 5: Cmd: >attr global latitude 48.144<
2015.01.17 11:28:40 5: Cmd: >attr global logfile ./log/fhem-%Y-%m.log<
2015.01.17 11:28:40 5: Cmd: >attr global longitude 11.558<
2015.01.17 11:28:40 5: Cmd: >attr global modpath .<
2015.01.17 11:28:40 5: Cmd: >attr global room hidden<
2015.01.17 11:28:40 5: Cmd: >attr global sendStatistics onUpdate<
2015.01.17 11:28:40 5: Cmd: >attr global statefile ./log/fhem.save<
2015.01.17 11:28:40 5: Cmd: >attr global uniqueID ./FHEM/FhemUtils/uniqueID<
2015.01.17 11:28:40 5: Cmd: >attr global verbose 5<
2015.01.17 11:28:40 5: Cmd: >define WEB FHEMWEB 8083 global<
2015.01.17 11:28:40 5: Loading ./FHEM/01_FHEMWEB.pm
2015.01.17 11:28:40 1: reload: Error:Modul 01_FHEMWEB deactivated:
Too many arguments for main::FW_roomStatesForInform at ./FHEM/01_FHEMWEB.pm line 603, near "$sinceTimestamp)"
BEGIN not safe after errors--compilation aborted at ./FHEM/01_FHEMWEB.pm line 637, <$fh> line 14.
2015.01.17 11:28:40 0: Too many arguments for main::FW_roomStatesForInform at ./FHEM/01_FHEMWEB.pm line 603, near "$sinceTimestamp)"
BEGIN not safe after errors--compilation aborted at ./FHEM/01_FHEMWEB.pm line 637, <$fh> line 14.
Bleiben nach dem "shutdown restart" noch die alten Definitionen im perl environment?
Edit: nach einem globalen System reboot hat sich nichts verändert
Wenn sowas nach einem FHEM-Restart "persistent" waere, dann wuerde ich einen unruhigen Tag haben.
Ich bin ratlos, und solange keiner es mir erklaeren kann, habe ich es auskommentiert, mit dem Hinweis auf diese Diskussion.
Möglicherweise habe ich mich missverständlich ausgedrückt, aber das Auskommentieren der Perl forward declaration behebt das Problem nicht. Nur das Auskommentieren des tatsächlichen Funktionsaufrufes hilft. In http://forum.fhem.de/index.php?topic=30910.0 ist auch so ein Fall beschrieben, bei mir hat diese Lösung jedoch nicht geholfen...
Ich gehe mittlerweile davon aus, dass es mehr mit meinem System zu tun hat als mit fhem >:(