[vz-users] Fehlende Datenpunkte im vz master branch

Thu Aug 1 11:02:30 CEST 2019

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>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20190801/f51d05bc/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/f51d05bc/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/f51d05bc/attachment-0003.png>