[vz-users] vzlogger an zweite middleware

Mon Jan 23 00:24:41 CET 2017

Hallo André, hallo Andreas,

ich habe gerade meinen master per pull auf den aktuellen Stand gebracht und
somit auch den gestern gemergten PR bekommen.
Der ursprüngliche Fehler (leere Tabelle bei push-updates) ist weg, sehr
schön:-)

Ich hab da allerdings noch ein paar Verständnisschwierigkeiten:
* wenn ich einen Kanal abonniere, wird er unabhängig vom active-property in
der DB mit inaktiver Checkbox angezeigt
* wenn ich die Seite dann neu lade, erhalten die abonnierten Kanäle aber
wieder den active-state aus der DB
* im Frontend gibt es jetzt keine Möglichkeit mehr, den active-state in der
DB zu ändern
* den aktuellen Checkbox-Zustand per Cookie zu speichern, ist mir noch nie
gelungen - der Button "Einstellungen speichern" hat bei mir auf die
angezeigten Kanäle keinen Einfluss

Grüße
Frank

Am 22. Januar 2017 um 21:52 schrieb Andre Bernemann <
andre.bernemann at gmail.com>:

> Müssen wir evtl. noch dafür sorgen, dass "active" bei den Usern aus der DB
> verschwindet wenn es über die Serialisierung schon reingekommen ist?
>
> Gruß
> André
>
>
>
> Andreas Götz <cpuidle at gmail.com> schrieb am So., 22. Jan. 2017 um
> 20:28 Uhr:
>
>> Perfekt, ist drin.
>>
>> Viele Grüße, Andreas
>>
>> Am 22.01.2017 um 19:41 schrieb Andre Bernemann <andre.bernemann at gmail.com
>> >:
>>
>> 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/20170123/2f5e042f/attachment-0001.html>