[vz-users] Fehlende Datenpunkte im vz master branch

Oliver Feilner maillist.volkszaehler at oliver.4of.de
Thu Aug 1 13:17:55 CEST 2019 

Hallo Daniel,

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

Danke dass Du Dir die Zeit nimmst!

> 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/90f6bf9f/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/90f6bf9f/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/90f6bf9f/attachment-0003.png>

More information about the volkszaehler-users mailing list