[vz-users] Fehlende Datenpunkte im vz master branch

[Andreas Goetz]

Hi Oliver!

On Thu, Aug 1, 2019 at 1:17 PM Oliver Feilner <
maillist.volkszaehler at oliver.4of.de> wrote:

> Hallo Daniel,
>
> Ich glaube wir müssen noch mal ganz von vorne Anfangen ;-).
>

Müssen wir. Ich heisse nämlich Andreas ;)


>
> Danke dass Du Dir die Zeit nimmst!
>

Das ist tatsächlich ein Problem- ich hab im Moment fast keine :/. Deshalb-
ohne nochmal in die Daten einzusteigen- nochmal meine Frage: warum stellst
Du die Darstellung nciht einfach auf Stufen wenn Du Stufen möchtest?

vg
Andreas

> Das heisst die neue Darstellung (=master) ist erstmal richtig. Dein
> Rolladen spring ja nicht sondern bewegt sich kontinuierlich und genau das
> loggst Du auch.
>
> Aus Sicht des Volkszählers springt der Rollo in Relativ kurzer Zeit:
> Beispiel Abends runterfahren, Rollo ist offen Position 0
> - Letzer Datenpunkt der 0 vor 30 min
> - Durch Aktivierung wird noch mal die aktuelle Position geschrieben 0
> - Nach 10 sec wird Position 70 geschrieben
> - Nach weiteren 8 sec Position 100
>
> Der Unterschied master/next bzgl. Middleware bzgl. tuples=xyz liegt in
> Folgendem:
> - next: es werden immer n aufeinander folgende Tupel zusammen gematscht.
> Dadurch werden dort wo viele Datenpunkte bestehen auch viele Ergebnispunkte
> erzeugt.
> - master: es werden immer gleich grosse Zeiträume zusammen gematscht.
> Dadurch können unterschiedlich viele Datenpunkte je Zeitraum entfallen-
> genau diesen Effekt siehst Du.
>
> Letzteres Verfahren ist performanter und erzeugt i.A. auch visuell bessere
> Ergebnisse, sollte m.E. also so bleiben.
>
> Das verfahren des masters ist laut den Zeitmessungen die mir Chrome
> anzeigt deutlich langsamer als das verfahren im next.
>
> Meines Erachtens liefert das verfahren im Next branch auch deutlich
> bessere Darstellungen (weil mehr tuples) und das nicht nur bei dem
> atypischen loggen eines Rollos, sondern gerade auch bei Strom wo im next
> branch auch einzelne Spitzen dargestellt werden.
> Auch bei den  Wasserzählern führt der Algorithmus vom master zumindest bei
> meiner Art und weise wie die Daten in der Datenbank abgelegt sind zu
> Darstellungsproblemen. (Lücken und 0 Werte "kurz" vor nach der
> Wasserentnahme)
>
> *In welchen Funktionen wird denn die Aggregation gemacht damit ich mir die
> Unterschiede mal im Code ansehen kann?*
>
> Wenn Du die Darstellung wie master haben möchtest, setz doch einfach den
> Kurventyp auf "steps" statt "lines".
>
> Ich hab ein Problem mit der Darstellung des masters und nicht des next
> branches.
>
> PS: Schau Dir bitte auch noch mal den Rows wert von der Ausgabe vom master
> an (siehe letzer Post von mir)  der ist denke ich falsch.
>
> Viele Grüße
>
> Oliver
>
>
>
> Am Do, 1. Aug 2019, um 11:02, schrieb Andreas Goetz:
>
> Hallo Oliver,
>
> ich hab alles nochmal durchgelesen und fange mal vorne an:
>
> > ...Logge ich mit Lücken. Die Daten stammen aus meiner
> Rolladensteuerrung  von dort aus wird die aktuelle Rollo Position mittels
> http Request bie folgenden Ereignissen an die Middleware gesendet:
> - Bei einer Änderrung vom Status (z.B. Übergang in Status Beschattung)
> - bei Bewegung alle 10 sec
>
> Das heisst die neue Darstellung (=master) ist erstmal richtig. Dein
> Rolladen spring ja nicht sondern bewegt sich kontinuierlich und genau das
> loggst Du auch.
>
> Der Unterschied master/next bzgl. Middleware bzgl. tuples=xyz liegt in
> Folgendem:
> - next: es werden immer n aufeinander folgende Tupel zusammen gematscht.
> Dadurch werden dort wo viele Datenpunkte bestehen auch viele Ergebnispunkte
> erzeugt.
> - master: es werden immer gleich grosse Zeiträume zusammen gematscht.
> Dadurch können unterschiedlich viele Datenpunkte je Zeitraum entfallen-
> genau diesen Effekt siehst Du.
>
> Letzteres Verfahren ist performanter und erzeugt i.A. auch visuell bessere
> Ergebnisse, sollte m.E. also so bleiben.
>
> Wenn Du die Darstellung wie master haben möchtest, setz doch einfach den
> Kurventyp auf "steps" statt "lines".
>
> Falls ich das alles falsch verstanden habe müssen wir nochmal von vorne
> anfangen :O
>
> vg
> Andreas
>
> On Tue, Jul 30, 2019 at 11:45 PM Oliver Feilner <
> maillist.volkszaehler at oliver.4of.de> wrote:
>
>
> Hallo Andreas,
>
> diesen Kanal bei dem mir es aufgefallen ist Logge ich mit Lücken. Die
> Daten stammen aus meiner Rolladensteuerrung  von dort aus wird die aktuelle
> Rollo Position mittels http Request bie folgenden Ereignissen an die
> Middleware gesendet:
> - Bei einer Änderrung vom Status (z.B. Übergang in Status Beschattung)
> - bei Bewegung alle 10 sec
> - bei Stop und
> - sonst alle 60 min
>
> An diesem Tag gibt es nur *40 *Datensätze.
> Zusammenfassung:
> *next branch:*
> ohne tuples: 41 Datensätze
> *mit tuples=320*: 41 Datensätze
>
> *master branch:*
> ohne tuples: 40 Datensätze (Letzer Datenpunkt vom vortag fehlt)
> *mit tuples=320*: 32 Datensätze
>
> Die Daten für den Vergleich den du  anfragst waren in der Mail von mir (25.07.2019
> um 10:18) angehängt.
> Das Bild in der Mail (25.07.2019 um 10:18) zeigte den Vergleich master
> branch mit und ohne tuples=320.
>
> Zu deiner Frage ob es ein Prinzipielles verhalten ist oder nicht: Ja,  das
> Verhalten ist grundsätzlich so. Nur bei Kanälen mit definiertem
> Kurvenverlauf und wenig Datenpunkten fällt es halt besonders auf, dass der
> Verlauf nicht der Erwartung entspricht.
>
> Hier ist beispielsweise eine Stromkurve Datenpunkte bei jedem S0 Impuls.
> Ich habe es geschafft im Master Frontend die Daten von *next middleware
> (gelb) und master middleware (rot)* gleichzeitig anzuzeigen. Hier sieht
> man ebenfalls einen anderen Kurvenverlauf bedingt durch unterschiedliche
> Akkumulation.
>
>
> Dabei Fällt auf dass sich beide beim akkumulieren grundsätzlich
> unterschiedlich verhalten. 320 tuples waren angefragt.
> Im Zeitraum waren *481 *Datenpunkte enthalten:
> Die master middleware liefert:  {"version":"0.3","data":{"tuples":
> ..."rows":241}} die Anzahl der übermittelten *tuples *ist *240*
> Die next middleware liefert:  {"version":"0.4","data":{"tuples":
> ..."rows":482}}die Anzahl der übermittelten *tuples *ist *438 *(kein
> Zahlendreher)
>
>
> *Noch ein Beispiel Stromkurve 1 Woche: *ebenfalls next middleware (gelb)
> und master middleware (rot)
>
> Im Zeitraum sind *20097 *Datenpunkte enthalten, der parameter tuples war
> auch wieder auf 320 gestanden:
> Die master middleware liefert:  {"version":"0.3","data":{"tuples":
> ..."rows":170}} die Anzahl der übermittelten *tuples *ist *169*
> Die next middleware liefert:  {"version":"0.4","data":{"tuples":
> ..."rows":20099}}die Anzahl der übermittelten *tuples *ist *576*
>
> PS: Die middleware des next branches (100ms)  liefert die Daten z.B. für
> eine Woche deutlich schneller als der master branch (170ms).
>
> Kannst du mit den Informationen was anfangen?
>
> Viele Grüße
>
> Oliver
>
> 25.07.2019 um 10:18
>
> Am Mo, 29. Jul 2019, um 08:18, schrieb Andreas Goetz:
>
>
> Hallo Oliver,
>
> Mal noch eine Frage zu den Grundlagen. Was und wie oft loggst Du hier denn
> eigentlich? Und tust Du das kontinuierlich oder mit Lücken?
> Ist die beobachtete andere Kurvenform ein grundsätzliches Verhalten oder
> beobachtest Du das nur bei einzelnen Kanälen?
>
> Ich wundere mich etwas, dass Du bei tuples=320 nur 40 Ergebnisse bekommst.
> Das sollten (tm) eigentlich so um 320 sein. Ich hab da eine Vermutung, die
> würde aber Dein Problem vmtl. nicht lösen.
>
> Bitte vergleich nochmal- wie schon angefragt- alte und neue MW mit je 320
> tuples (ohne o).
>
> Viele Grüße, Andreas
>
> Bitte entschuldige wenn die Analyseaufgaben zu Dir zurück kommen. Bin
> gerade arg im Stress und dann das hier nur aus dem Augenwinkel beobachten.
>
>
> Am 25.07.2019 um 10:18 schrieb Oliver Feilner <
> maillist.volkszaehler at oliver.4of.de>:
>
> Hallo Andreas,
>
> Ich kann das Rätsel aufklären, der Json Output war wie du beschrieben hast
> mit dem "Data" Button erzeugt. Hier werden alle Datenpunkte für diesen
> Zeitraum angefragt. Hier sind die Json outputs identisch!
>
> Für den Graph wird abhängig von der Monitorauflösung nur ein Teil der
> Datenpunkte angefragt. z.B. mit &touples=320. Dann Aggregiert die
> Middleware und genau hier verhält sich der trunk gegenüber dem Master
> anders.
>
> Im Beispiel werden 320 Datenpunkte angefragt. Der master branch aggregiert
> hier 40 Datenpunkte zu 32 Datenpunkten.
> Während der next branch alle 41 Datenpunkte liefert. (einen mehr weil er
> noch den letzen Punkt vom Vortag liefert.)
>
> Diff zwischen antwort von der master middleware mit und ohne &touples=320
> http://
> vz.hausnetz.xyz/middleware.php/data/4f87e9a0-a7ef-11e9-a857-a7c9872c5748.json?from=1563832800000&to=1563919200000
> =
> http://
> vz.hausnetz.xyz/middleware.php/data/4f87e9a0-a7ef-11e9-a857-a7c9872c5748.json?from=1563832800000&to=1563919200000
> &tuples=320
> {"version":"0.3","data":{"tuples":[
>
> {"version":"0.3","data":{"tuples":[
> [1563835999743,89.4,1],
>
> [1563835999743,89.4,1],
> [1563839599751,89.4,1],
>
> [1563839599751,89.4,1],
> [1563843199755,89.4,1],
>
> [1563843199755,89.4,1],
> [1563846799762,89.4,1],
>
> [1563846799762,89.4,1],
> [1563849332000,89.4,1],
> <>
> [1563849334125,89.409,2],
> [1563849334125,100,1],
>
>
> [1563852934135,100,1],
> =
> [1563852934135,100,1],
> [1563854807687,100,1],
> <>
>
> [1563854817696,50.5,1],
>
> [1563854817696,99.737,2],
> [1563854827701,1,1],
>
>
> [1563854827895,0,1],
>
> [1563854827895,0.981,2],
> [1563855124535,0,1],
> =
> [1563855124535,0,1],
> [1563855595842,0,1],
>
> [1563855595842,0,1],
> [1563858000001,0,1],
>
> [1563858000001,0,1],
> [1563861600012,0,1],
>
> [1563861600012,0,1],
> [1563863001002,0,1],
> <>
>
> [1563863011007,50.2,1],
>
> [1563863012750,0.428,3],
> [1563863012750,59,1],
>
>
> [1563866612757,59,1],
> =
> [1563866612757,59,1],
> [1563870212762,59,1],
>
> [1563870212762,59,1],
> [1563873812770,59,1],
>
> [1563873812770,59,1],
> [1563877412777,59,1],
>
> [1563877412777,59,1],
> [1563880257004,59,1],
>
> [1563880257004,59,1],
> [1563880267013,9.5,1],
> <>
> [1563880268930,7.973,2],
> [1563880268930,0,1],
>
>
> [1563883868938,0,1],
> =
> [1563883868938,0,1],
> [1563887468945,0,1],
>
> [1563887468945,0,1],
> [1563891068950,0,1],
>
> [1563891068950,0,1],
> [1563894671955,0,1],
>
> [1563894671955,0,1],
> [1563898271961,0,1],
>
> [1563898271961,0,1],
> [1563901871966,0,1],
>
> [1563901871966,0,1],
> [1563905471971,0,1],
>
> [1563905471971,0,1],
> [1563909071976,0,1],
>
> [1563909071976,0,1],
> [1563909616109,0,1],
> <>
>
> [1563909626117,50.2,1],
>
>
> [1563909636016,100,1],
>
> [1563909636016,2.646,3],
> [1563913236022,100,1],
> =
> [1563913236022,100,1],
> [1563916836027,100,1],
>
> [1563916836027,100,1],
> [1563920436033,100,1]],
>
> [1563920436033,100,1]],
> "uuid":"4f87e9a0-a7ef-11e9-a857-a7c9872c5748",
>
> "uuid":"4f87e9a0-a7ef-11e9-a857-a7c9872c5748",
> "from":1563832399739,
>
> "from":1563832399739,
> "to":1563920436033,
>
> "to":1563920436033,
> "min":[1563854827895,0],
> <>
> "min":[1563855124535,0],
> "max":[1563849334125,100],
>
> "max":[1563852934135,100],
> "average":47.27,
> =
> "average":47.27,
> "rows":40}}
> <>
> "rows":32}}
>
> =
>
>
> Im Anhang die Original Dateien.
>
> Am Do, 25. Jul 2019, um 07:11, schrieb Andreas Götz:
>
> Hallo Oliver,
>
> Jetzt bin ich verwirrt. Vorher hattest Du getestet, dass der Json Output
> identisch ist. Jetzt sagst Du es liegt an der Middleware.
>
> Eine der beiden Diagnosen muss falsch sein. Welche?
>
> Viele Grüße,
> Andreas
>
> Am 25.07.2019 um 00:39 schrieb Oliver Feilner <
> maillist.volkszaehler at oliver.4of.de>:
>
> Hallo,
>
> Ich habe jetzt erst mal das Frontend vom Deinem next branch verwendet und
> die middleware von normalen master branch verwendet. Ich habe mich
> vergewissert, dass ich die jeweilige richtige middleware verwende anhand
> der Versions bei den daten.
>
> Im Anhang sind die zwei abgespeicherten Screenshots (diesmal in einer
> besseren Farbe). Hier inline habe ich einen Bild diff reingemacht. Die
> roten Punkte zweigen die Unterschiede zwischen den
> <image.png>
>
> Dann habe ich noch den umgedrehten versuch gemacht und FE vom master
> branch und mal die Punkte vom master und einmal die Punkte vom master und
> next branch gleichzeitig anzeigen lassen (so kann man zwischen den Bildern
> auch leicht hin und herschalten um die Unterschiede zu sehen.
>
> Es liegt wohl eindeutig an der Middleware.
>
> Irgendeine Idee?
>
> Viele Grüße
>
> Oliver Feilner
>
>
> Am Mi, 24. Jul 2019, um 19:18, schrieb Andreas Götz:
>
> Könntest Du nochmal Werte und Grafik abgleichen wo es nicht passt?
> Und mal altes Frontend auf neue Middleware zeigen lassen oder umgekehrt?
>
> Dann wären wir 100% sicher dass der Fehler im FE liegt.
>
> Könntest Du mir via pm Remote Zugang geben?
>
> Viele Grüße,
> Andreas
>
> Am 24.07.2019 um 13:27 schrieb Oliver Feilner <
> maillist.volkszaehler at oliver.4of.de>:
>
> Hallo,
>
> Die beiden Installationen arbeiten mit der gleichen Datenbank.
> Demnach sind die Daten die angezeigt werden auch die gleichen. Ich bin auf
> die Ansicht Tag gegangen . Beim next branch wird dann noch der letze Wert
> vom Vortag hinzugenommen dass die Linie bei 0 Uhr und nicht erst um 0:53
> anfängt.
> Für die Zeiten Interessanten Zeitstempel wo beim master branch die Anzeige
> etwas eigenwillig ist habe ich die Zeitstempel umgerechnet.
> Aus meiner Sicht sind die Rohdaten ok.
> Volkszähler master branch
> <>
> AndiG next branch
> {"version":"0.3","data":{"tuples":[
>
> {"version":"0.4","data":{"tuples":[
>
>
> [1563832399739,89.4,1],  //22.07.2019 - 23:53:19.739 < Vortag
> [1563835999743,89.4,1],
> =
> [1563835999743,89.4,1],  //23.07.2019 - 00:53:19.743
> [1563839599751,89.4,1],
>
> [1563839599751,89.4,1],
> [1563843199755,89.4,1],
>
> [1563843199755,89.4,1],
> [1563846799762,89.4,1],
>
> [1563846799762,89.4,1],
> [1563849332000,89.4,1],
>
> [1563849332000,89.4,1], //23.07.2019 - 04:35:32.000
> [1563849334125,100,1],
>
> [1563849334125,100,1],  //23.07.2019 - 04:35:34.125
> [1563852934135,100,1],
>
> [1563852934135,100,1],  //23.07.2019 - 05:35:34.135
> [1563854807687,100,1],
>
> [1563854807687,100,1],  //23.07.2019 - 06:06:47.687
> [1563854817696,50.5,1],
>
> [1563854817696,50.5,1], //23.07.2019 - 06:06:57.696
> [1563854827701,1,1],
>
> [1563854827701,1,1],    //23.07.2019 - 06:07:07.701
> [1563854827895,0,1],
>
> [1563854827895,0,1],    //23.07.2019 - 06:07:07.895
> [1563855124535,0,1],
>
> [1563855124535,0,1],
> [1563855595842,0,1],
>
> [1563855595842,0,1],
> [1563858000001,0,1],
>
> [1563858000001,0,1],
> [1563861600012,0,1],
>
> [1563861600012,0,1],
> [1563863001002,0,1],
>
> [1563863001002,0,1],    //23.07.2019 - 08:23:21.002
> [1563863011007,50.2,1],
>
> [1563863011007,50.2,1], //23.07.2019 - 08:23:31.007
> [1563863012750,59,1],
>
> [1563863012750,59,1],   //23.07.2019 - 08:23:32.750
> [1563866612757,59,1],
>
> [1563866612757,59,1],
> [1563870212762,59,1],
>
> [1563870212762,59,1],
> [1563873812770,59,1],
>
> [1563873812770,59,1],
> [1563877412777,59,1],
>
> [1563877412777,59,1],
> [1563880257004,59,1],
>
> [1563880257004,59,1],   //23.07.2019 - 13:10:57.004
> [1563880267013,9.5,1],
>
> [1563880267013,9.5,1],  //23.07.2019 - 13:11:07.013
> [1563880268930,0,1],
>
> [1563880268930,0,1],    //23.07.2019 - 13:11:08.930
> [1563883868938,0,1],
>
> [1563883868938,0,1],    //23.07.2019 - 14:11:08.938
> [1563887468945,0,1],
>
> [1563887468945,0,1],
> [1563891068950,0,1],
>
> [1563891068950,0,1],
> [1563894671955,0,1],
>
> [1563894671955,0,1],
> [1563898271961,0,1],
>
> [1563898271961,0,1],
> [1563901871966,0,1],
>
> [1563901871966,0,1],
> [1563905471971,0,1],
>
> [1563905471971,0,1],
> [1563909071976,0,1],
>
> [1563909071976,0,1],
> [1563909616109,0,1],
>
> [1563909616109,0,1],    //23.07.2019 - 21:20:16.109
> [1563909626117,50.2,1],
>
> [1563909626117,50.2,1], //23.07.2019 - 21:20:26.117
> [1563909636016,100,1],
>
> [1563909636016,100,1],  //23.07.2019 - 21:20:36.016
> [1563913236022,100,1],
>
> [1563913236022,100,1],
> [1563916836027,100,1],
>
> [1563916836027,100,1],
> [1563920436033,100,1]],
>
> [1563920436033,100,1]],
> "uuid":"4f87e9a0-a7ef-11e9-a857-a7c9872c5748",
>
> "uuid":"4f87e9a0-a7ef-11e9-a857-a7c9872c5748",
> "from":1563832399739,
> <>
> "from":1563828799730,
> "to":1563920436033,
> =
> "to":1563920436033,
> "min":[1563854827895,0],
>
> "min":[1563854827895,0],
> "max":[1563849334125,100],
>
> "max":[1563849334125,100],
> "average":47.27,
> <>
> "average":48.925,
> "rows":40}}
>
> "rows":41}}
>
> =
>
>
> Anmerkung:
> Die Positionen stammen aus meiner Rolladensteuerrung, von dort aus wird
> die aktuelle Rollo Position mittels http Requestbie folgenden Ereignissen
> an die Middleware gesendet:
> - Bei einer Änderrung vom Status (z.B. Übergang in Status Beschattung)
> - bei Bewegung alle 10 sec
> - bei Stop und
> - sonst alle 60 min
>
>
> Viele Grüße
>
> Oliver
>
>
> Am Mi, 24. Jul 2019, um 10:23, schrieb Andreas Goetz:
>
> Genau wie Daniel vorschlägt: wir müssen erstmal herausfinden ob
> Darstellung falsch ist oder die Daten falsch ankommen. Also:
>
> - Zeitfenster Mittels Export->Permalink fixieren und in beiden
> Installationen öffnen
> - auf fraglichem Kanal jeweils (I)nfo->Daten
>
> Beide Daten vergleichen- sind die identisch? Immer unter der Annahme dass
> Du 2x Frontend/Middleware auf der gleichen Datenbank laufen hast.
>
> vg
> Andreas
>
> On Wed, Jul 24, 2019 at 9:47 AM Daniel Lauckner <vz at jahp.de> wrote:
>
> Hallo,
>
>
> am Dienstag, 23. Juli 2019 um 22:41 hat Oliver Feilner geschrieben:
> > Mit ist aufgefallen dass die Darstellung
> > auf dem Master branch irgendwie nicht so wie gewohnt war.
>
> Was mir auf jeden Fall spanisch vorkommt: Warum hast du beim
> next-branch Datenpunkte bei augenschienlich identischem Zeitstempel?
>
> Mach bitte nochmal einen ähnlichen Vergleich, zeig uns aber keine
> Screenshots sondern die Daten wenn du oben rechts in der
> drop-down-Liste "JSON" auswählst.
>
>
> mfg Daniel
>
>
>
> <FE next, MW next.png>
>
> <FE next, MW master.png>
>
> <FE master, MW master + next.png>
>
> <FE master, MW master.png>
>
>
> <master.txt>
>
> <master_touples=320.txt>
>
> <next.txt>
>
> <next_touples=320.txt>
>
>
>
> *Dateianhänge:*
>
>    - Screenshot (4).png
>    - Screenshot (5).png
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20190801/f0cd3535/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot (4).png
Type: image/png
Size: 228564 bytes
Desc: not available
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20190801/f0cd3535/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot (5).png
Type: image/png
Size: 181336 bytes
Desc: not available
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20190801/f0cd3535/attachment-0003.png>