[vz-users] vzlogger an zweite middleware

Wed Jan 18 09:53:04 CET 2017

Hi Andre,

ich habe auch den Root Cause gefunden. Durch die Optimierung des UIs wird
"active" plötzlich bei Serialisierung der Properties mit einbezogen-
ziemlich unerwartet für den armen Programmierer :O

Das baue ich aus und dann sehen wir weiter...

vg
Andreas

2017-01-17 22:03 GMT+01:00 Andreas Goetz <cpuidle at gmail.com>:

> Probiers- wir brauchen aber keinen zweiten Workaround wenn das unten
> funktioniert? Die Entity kanns halt mehrmals geben- eine ganze Liste dienst
> nur der Dropdownbox im “Add Channel” Dialog.
>
> Wenn Du Zeit hast könntest Du nochmal testen was passiert wenn die gleiche
> Entity mehrmals in der Tabelle ist, z.B. einzeln als auch in einer Gruppe.
> Der Übersichtichkeit halber mach mir auch gerne ein Issue auf, wird dann
> gefixt…
>
> Viele Grüße, Andreas
>
> On 17 Jan 2017, at 21:51, Andre Bernemann <andre.bernemann at gmail.com>
> wrote:
>
> Hallo Andreas,
>
> also ich schau mir das gerne auch noch im Push-Server an, wird aber diese
> Woche nicht mehr klappen. Die Entity sollte ja auf im FE schon erkennen,
> dass es schon eine Subscription gibt - (Observer? Singleton?).
>
> Spricht was dagegen das Table-Clear im DOM Update zunächst mit ins if zu
> ziehen? Dann hätten wir einen Workaround...
>
> Gruß
> André
>
> Andreas Goetz <cpuidle at gmail.com> schrieb am Di., 17. Jan. 2017 um
> 09:22 Uhr:
>
>> Moin Frank,
>>
>> schau mal hier: https://github.com/volkszaehler/volkszaehler.org/
>> blob/master/htdocs/frontend/javascripts/middleware.js#L49
>>
>> Probier mal ob Du einfach active auf false setzen kannst:
>>
>>         json.entities.forEach(function(json) {
>>             entity.active = false;
>>             this.public.push(new Entity(json, this.url));
>>         }, this);
>>
>> Viele Grüße,
>> Andreas
>>
>>
>> 2017-01-16 23:13 GMT+01:00 Andreas Goetz <cpuidle at gmail.com>:
>>
>> Hallo,
>>
>> On 16 Jan 2017, at 22:30, Andre Bernemann <andre.bernemann at gmail.com>
>> wrote:
>>
>> Hi Andreas,
>>
>> Andreas Goetz <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>:
>>
>> 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> 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
>>
>> Viele Grüße,
>> Andreas
>>
>>
>> 2017-01-14 20:59 GMT+01:00 Andre Bernemann <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> 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
>> >:
>>
>> Push funktioniert mit 2 Einträgen, das reicht mir erstmal.
>>
>> Danke.
>>
>> Gruß
>> André
>>
>>
>> Frank Richter <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/20170118/ffe6b8e3/attachment-0001.html>