[vz-users] vzlogger an zweite middleware

Sun Jan 22 19:41:23 CET 2017

Hi Andreas,

sieht gut aus, klappt wie erwartet. War es am Ende doch das active Flag. In
der DB ergibt das wenig Sinn - sehe ich auch so.

Danke für den Support!

Gruß
André
Andreas Goetz <cpuidle at gmail.com> schrieb am Mi. 18. Jan. 2017 um 18:57:

> Hall Andre,
>
> hier ist der vollständige Fix:
> https://github.com/volkszaehler/volkszaehler.org/pull/560
>
> Damit wird active nicht mehr gespeichert, gespeichertes active ignoriert
> und beim landen der “public” channels active explizit auf false gesetzt
> damit keine Subscription erzeugt wird.
>
> Aus meiner Sicht ist das das Wunschverhalten: active speichern ist
> unsinnig da ich ja auf verschiedenen Geräten unterschiedliche Stände haben
> könnte- genau dafür sind die Cookies da.
>
> Bitte um Test und Freigabe in Github- da etwas frickelig sollten da 4
> Augen draufschauen.
>
> Vielen Dank, Andreas
>
>
> On 18 Jan 2017, at 09:53, Andreas Goetz <cpuidle at gmail.com> wrote:
>
> 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/20170122/8c9b2185/attachment-0001.html>