[vz-users] vzlogger an zweite middleware

Tue Jan 17 09:06:23 CET 2017

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/20170117/d5771360/attachment-0001.html>