[vz-users] vzlogger an zweite middleware

[Andreas Goetz]

Hallo,

> On 16 Jan 2017, at 22:30, Andre Bernemann <andre.bernemann at gmail.com> wrote:
> 
> Hi Andreas,
> 
> Andreas Goetz <cpuidle at gmail.com <mailto:cpuidle at gmail.com>> schrieb am Mo., 16. Jan. 2017 um 18:06 Uhr:
> Hi Andre,
> 
> 2017-01-16 17:24 GMT+01:00 Andre Bernemann <andre.bernemann at gmail.com <mailto:andre.bernemann at gmail.com>>:
> Hi Andreas,
> 
> in Entity.prototype.updateDOMRow wird die Tabellenzeile zunächst geleert, um sie dann mit neuen Daten zu befüllen. In meinem Fall hat das übergeben JS Objekt keinen Member "rows" [if (this.data && this.data.rows > 0)]. Die Tabelle wird bei mir korrekt geleert, aber es werden keine neuen Daten geparsed. Unabhängig von der Ursache könnte das clear mit ins if, damit umgeht man den Fehler aber natürlich nur.
> ...
>  
>  
> parseJSON erzeugt bei mir beim Laden Subscriptions auch für nicht angezeigte - aber aktive Channels.
> 
> Was meinst Du damit? Was für Kanäle sollen das sein?
> 
> parseJSON wird beim Startup für alle Kanäle durchlaufen, unabhängig davon ob es überhaupt im FE angezeigt wird.

Verdammt- ich fürchte Du hast recht. Das ist das im letzten Update rein gekommene laden der Public Entities. Idee war nicht bei jedem Dialogfenster erstmal warten zu müssen. Soweit ich sehe ist parseJson im Prinzip ok bis auf das abschließende subscribe(). Jetzt fehlt nur noch eine gute Idee wo das hin kommt.

Leider muss ich zugeben dass das Frontend einfach viel zu komplex und leider kaum modular ist :O

> Das führt zu Updates, auch wenn gar kein Kanal im FE ist. Scheinbar geht er direkt auf die Kanäle der DB. Zusätzlich wird parseJSON auch vom "Kanal hinzufügen"-Dialog gecalled - vielleicht um die CB zu füllen. Ist this.active == true, wird Entity.prototype.subscribe() gecalled.
> 
> Das Problem ist seit dem Commit 293dd76 vorhanden, da ist was am MW Lookup gemacht worden:
> ...
> 
> In der alten Version ist mw.session==false für die Calls über parseJSON, daher ist an der Stelle Ende - die Calls aus ab.connect(...) hingegen haben eine Session. In der neuen Version haben beide Aufrufe eine Session.
> 
> Jetzt Du :-)
> 

Ich glaub die Ursache ist eine andere, aber könnte sein. Allerdings- auch wenn das die Ursache ist- sollten dennoch in den Updates Daten ankommen und dann wäre das Phänomen auch weg. Sieht nach  einer Macke im Pushserver aus. Also was fixen?

Wenn Du so nett sein willst mach bitte ein Issue mit dieser Beschreibung auf, heute fällt mir keine Halbwegs elegante Lösung mehr ein.

Viele Grüße, Andreas


>  
>  
> Zusätzlich werden in init.js nach dem WAMP connect noch die "richtigen" Subscriptions erzeugt, wenn der Channel aktiv und sichtbar ist. Vom Timing her hab ich die korrupte Subscription immer als zweites, ich bekomme also ein korrektes Update und dann sofort das leere. Setze ich in der db active=0 funktioniert es übrigens. 
> 
> Alles sehr merkwürdig. Könntest Du mit Logging (console.log) in entity.subscribe mal versuchen herauszufinden wer/was/wo diese Subscriptions erzeugt werden?
>  
> 
> HTH, sonst sag nochmal Bescheid!
> 
> Ich fürchte da musst Du erstmal ran bis die Ursache klar ist da ichs nicht reproduzieren kann. Wenn gar nix hilft u/p per pm an mich.
>  
> 
> Gruß
> 
> Viele Grüße,
> Andreas
> 
> Gruß André
>  
>  
> 
> 
> Andreas Goetz <cpuidle at gmail.com <mailto:cpuidle at gmail.com>> schrieb am Mo., 16. Jan. 2017 um 11:44 Uhr:
> Moin,
> 
> kannst Du das eingrenzen? Mal nur einen Kanal aktivieren und schauen welche Requests da an die MW geschickt werden? Wenn sich das Fehlerbild konkretisieren lässt bitte hier hinzufügen: https://github.com/volkszaehler/volkszaehler.org/issues <https://github.com/volkszaehler/volkszaehler.org/issues>
> 
> Viele Grüße,
> Andreas
> 
> 
> 2017-01-14 20:59 GMT+01:00 Andre Bernemann <andre.bernemann at gmail.com <mailto:andre.bernemann at gmail.com>>:
> Ja stimmt :-) Ich sende jetzt an die MW der produktiven Umgebung und per Push an die die produktive und eine weitere zum testen, klappt wunderbar. 
> 
> Mein eigentliches Problem ist es, dass ich bei aktiviertem Push keine Werte in der Tabelle bekommen:
> 
> <pasted1.png>
> Die Werte tauchen kurz auf wenn das Frontend geladen ist, verschwinden dann aber beim ersten Push vom push-server. Zusätzlich hab ich dann sinnlose Werte für den Gesamtverbrauch. Sowas schon mal einer gesehen?
> 
> Gruß
> 
> 
> Frank Richter <frank.richter83 at gmail.com <mailto:frank.richter83 at gmail.com>> schrieb am Sa., 14. Jan. 2017 um 19:37 Uhr:
> Cool, wieder was gelernt:-)
> Daten nur per push senden, aber nicht an Middleware/DB klappt übrigens auch: dafür in der Kanaldefinition "api": null setzen
> Das mach ich so mit den Momentanleistungen meiner Zähler.
> 
> Gruß
> 
> 
> Frank
> 
> Am 14.01.2017 18:57 schrieb "Andre Bernemann" <andre.bernemann at gmail.com <mailto:andre.bernemann at gmail.com>>:
> Push funktioniert mit 2 Einträgen, das reicht mir erstmal.
> 
> Danke.
> 
> Gruß
> André
> 
> 
> Frank Richter <frank.richter83 at gmail.com <mailto:frank.richter83 at gmail.com>> schrieb am Sa., 14. Jan. 2017 um 17:17 Uhr:
> Hallo Andre,
> 
> mehrere Middlewares sollte gehen, wenn man den Kanal mehrfach anlegt. Bei push bin ich allerdings überfragt. Allerdings ist push ja immerhin ein JSON-Array - mach doch mal einen 2. URL-Eintrag, probieren kostet ja nix...
> 
> Gruß
> 
> 
> Frank
> 
> Hi,
> 
> ich würde gerne ein paar Sachen mit dem Push-Server testen. Ist der vzlogger irgendwie in der Lage die gleichen Kanäle an 2 Middlewares und an zwei Push-Server gleichzeitig zu senden? 
> 
> Gruß,
> André

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20170116/2decc6dc/attachment-0001.html>