longpollSVG Problem mit 01_FHEMWEB.pm r7212

[rudolfkoenig]

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.

Ich 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.

[herrmannj]

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)

Hier 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.

Code Auswählen Erweitern


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

[herrmannj]

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 

so denn, vg
jörg

[geek]

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

Rainer

[fhainz]

Danke für euren Einsatz, bei mir funktioniert es wieder!

Grüße

[HolyMoly]

Bei mir seit gestern:

Code Auswählen Erweitern

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.

[schka17]

Hallo HolyMoly,

Reload hatte bei mir auch nicht gereicht, ging nur mit shutdown restart.

Gruß

Karl


Sent from my iPad using Tapatalk

[HolyMoly]

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 $

[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.

[HolyMoly]

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...

[HolyMoly]

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

[rudolfkoenig]

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.

[HolyMoly]

Ohne den call geht es wieder. Trotzdem irgendwie komisch 

[HolyMoly]

Irgendwie ungut wenn nach jedem FHEMWEB update das Webinterface weg ist. Gibt es nicht doch eine Möglichkeit das zu fixen?

[rudolfkoenig]

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?