[KEIN BUG] sqlite liefert bei series "zuviel" Werte

[Shai]

Hey,

ich bin mir nicht sicher ob es ein Bug ist, aber mir kommt folgendes Verhalten des "sqlite" Plugins zumindest merkwürdig vor:

Beim Abfragen von "Series" wird im Response ein Wert 2x zum Ende des Arrays hinzugefügt. Einmal hat der Wert offenbar die Timestamp vom "last_change" des Items und einmal von "now" bzw. "end".

Beispiel-Response:

Tue Mar 03 2015 18:22:36 GMT+0100 (CET) 20.96
Tue Mar 03 2015 21:00:06 GMT+0100 (CET) 18.97
Wed Mar 04 2015 05:00:05 GMT+0100 (CET) 20.96
Wed Mar 04 2015 08:00:07 GMT+0100 (CET) 18.97
[COLOR="Red"]Wed Mar 04 2015 15:00:07 GMT+0100 (CET) 20.96 < "last_changed"
Wed Mar 04 2015 18:22:36 GMT+0100 (CET) 20.96 < "now"[/COLOR]

Das Verhalten hat soweit ich das beobachtet habe keine negativen Auswirkungen auf Plots wie "period" oder "rtr", offenbar aber in Verbindung mit dem "Count-Patch" der es erlaubt die Anzahl der Rückgabewerte zu begrenzen. (z.B. für max 1 Wert pro Tag)


Aufgefallen ist mir das beim "Stacked Plot" Widget und bei meinem Custom "Min-Max-Avg"-Plot - da in der Ausgabe die angezeigten Columns verrutschen, aber mit dem Offline-Treiber alles okay ist.
Im JavaScript hab ich mir dann mal die Responses angesehen und das oben beschriebene Verhalten entdeckt.

Vermutlich liegt der Hund im Code des Plugins in den Zeilen 341-348 begraben.

if item_change < iend:
            value = float(_item())
            if item_change < istart:
                tuples.append((istart, value))
            elif init:
                tuples.append((item_change, value))
            if init:
                tuples.append((iend, value))

Ich denke aber das das eigentlich auch nicht grundlos so im Plugin drin ist, kann das nicht interpretieren, dafür fehlen mir einfach Details zum Hintergrund der Implementierung.


Kann das evtl. noch jemand verifizieren oder auch mal prüfen?
Vielleicht ist das Verhalten auch richtig und die Count-Funktion muss noch etwas angepasst werden....


Grüße,

Lars


PS: Bin auf dem aktuellen Development Stand von SH.py - der Count-Patch ändert nur die Zeilen 307 und 312:

307:  sid = item + '|' + func + '|' + start + '|' + end + '|' + str(count)
312:  step = int((iend - istart) / int(count))

[callidomus]

Hallo,

das ist so beabsichtigt, damit der Graph bis "jetzt" geht. Sonst wäre er abgeschnitten.

Bis bald

Marcus

[Shai]

Hey,

okay das macht durchaus Sinn.

Birgt dann natürlich für Plots die z.B. nur 1 Wert pro Tag brauchen (z.B. für den Max Wert) die Herausforderung das diese nicht einfach blind den Response verwenden könnten sondern es Clientseitig ausgleichen müssen.

Pauschal den Response um 2 Werte kürzen macht wenig Sinn, da ein anderes Backend es nicht so liefert.

Muss ich mir mal durch den Kopf gehen lassen.


Danke & Grüße,

Lars

[Shai]

Nabend,

ich hab mir da jetzt mal ein bisschen den Kopf zerbrochen und komme immer auf den Nenner das die Lösung für das Bedürfnis "damit der Graph is jetzt geht" eigentlich die Plots verfälscht.

Egal ob "min", "max" oder "avg" abgefragt wird, so ist die Chance das die letzten Beiden Werte im Plot falsch sind relativ groß.

Abstraktes Beispiel für "min":

Wir haben ein Item was entweder 0 oder 100 Werte hat. Nun fragen wir "min" ab, der letzte Wert des Items war aber 100, also werden 2 Einträge mit 100 ans Frontend geliefert und der Plot macht n Sprung.

"max" und "avg" haben im Prinzip die selbe Chance das Ergebnis verfälscht zu bekommen.

Je niedriger nun die Anzahl der abgefragten Datenpunkte ist, desto größer wird die Fehlerquote. Bzw. andersrum: bei dem Standard Count von 100 fällt es offenbar weniger auf.


Könnte man das mit dem "der Graph geht bis zum Ende" nicht evtl. damit lösen in dem man den letzten ermittelten Datenpunkt auf "end" setzt?
Bei "min" / "max" / "avg" Abfragen ist ja der "last_change" Wert schon in der Query berücksichtigt worden, also würde der ermittelte Wert auch für "now" zutreffen, da es offenbar ja zwischen dem letzten Wert aus der Query und dem Abfrage Ende keine Änderung des Ergebnisses mehr gab.


Hab ich noch einen Denkfehler?
Eventuell macht es ja Sinn die aktuelle Lösung zu überdenken um auch die Anzahl von Datenpunkten an das Frontend zu liefern die es angefragt hat.


Grüße,

Lars

[callidomus]

Hallo Lars,

etwas grundsätzliches. Es werden Werte für Zeitscheiben angefragt/geliefert.
Wenn für die Zeitscheibe kein Wert vorliegt, wird auch keiner geliefert.

Ich könnte prüfen, ob für die letzte Scheibe ein Wert vorliegt und nur wenn keiner vorliegt den aktuellen Wert ergänzen.
Ich werde mir das mal für die nächste Überarbeitung des Plugins notieren.
Vorher kommt aber das Release.

Bis bald

Marcus