Ankündigung

**aschwith** · 02.11.2022, 20:56

Hallo wvhn,

aktuell werden die Datenreihen folgendermaßen gepackt:

Code:

result = {
            'cmd': 'series', 'series': tuples, 'sid': sid,
            'params': {'update': True, 'item': item, 'func': func, 'start': logs['iend'], 'end': end,
                       'step': logs['step'], 'sid': sid},
            'update': self.shtime.now() + datetime.timedelta(seconds=int(logs['step'] / 1000))
        }

Vorschlag: Wir bereinigen die tuples des Attributes "series" auf eine Minimalanzahl (noch zu definieren) und führen die erweiterten Werte in einem neuen Attribut "series_extended" mit. Z.B. so:

Code:

result = {
            'cmd': 'series', 'series': tuples, 'series_extended': tuples_extended, 'sid': sid,
            'params': {'update': True, 'item': item, 'func': func, 'start': logs['iend'], 'end': end,
                       'step': logs['step'], 'sid': sid},
            'update': self.shtime.now() + datetime.timedelta(seconds=int(logs['step'] / 1000))
        }

Wäre dieses Konstrukt für dich auf SmartVisu Seite so auswertbar? Für die klassischen Linienplots müsstest Du die tuples_extended dann zeitlich in die regulären tuples einsortieren. Für die Balkendiagramme würde aus auf eine Nutzung der regulären tuples hinauslaufen.

Später müssten wir nochmal die Abwärtskompatibilität besprechen.

VG
Alex

**wvhn** · 03.11.2022, 14:05

Hi aschwith

series_extended müsste sich schon so auswerten lassen. Ich frage mich aber, ob es nicht noch einfacher geht.

Grundidee:
an jedem Ende des Plots jeweils einen Wert anfügen, der um das definierte Abtastintervall außerhalb des abgefragten Wertebereichs liegt
(Abtastintervall = (tmax - tmin) / count). Evtl. reicht es sogar, die jetzt schon vorhandenen Korrekturen (Zeilen 861-876 im Master v1.9.3) in dieses Zeitraster zu bringen.

Ich denke, dass Highcharts die Darstellung dann schon richtig macht. Das versuche ich mal zu simulieren und melde mich wieder.

Gruß
Wolfram

**aschwith** · 05.11.2022, 16:59

Hi wvhn,

verstehe deinen Ansatz. Hier ist allerdings das Problem, dass diese Werte bei relativ kleinem count weiter außerhalb des abgefragten Wertebereichs liegen und damit interporliert werden müssten. Das ergibt unplausible Werte. Am Beginn des Plots wird aktuell auch schon eine Näherung gemacht. Der Wert, der aktuell am Ende hinzugefügt wird, passt aber extaxt mit Zeitstempel und Wert. Das wäre ein großer Kompromiss in meinen Augen.

Die Balkendiagramme müssen in der Lage sein, die zusätzlichen Werte außerhalbt des abgefrage Wertebereichs auszusortieren.

Gruß
Alex

**wvhn** · 05.11.2022, 19:08

Hi Alex,
ich habe mir gestern nochmal angesehen, wie Highcharts mit den Punkten außerhalb des Darstellungsbereichs umgeht. Bei Linienplots verbindet es die Punkte (interpoliert also selbständig) und schneidet die Linie außerhalb des Darstellungsbereichs ab. Bei Säulenplots zeichnet es einfach nur die Säulen im Darstellungsbereich und lässt die anderen weg. Das ist eigentlich das gewünschte Verhalten.

Dann habe ich mir angesehen, was beim Update des items passiert. smartVISU schiebt den dargestellten Plot auf der Zeitachse, indem die neuen Punkte hinten angefügt werden und alle Punkte außerhalb des Darstellungsbereichs am Anfang des Plots gelöscht werden - außer dem letzten(!). Somit beginnt die Datenreihe nach dem ersten Update immer mit einem Wert, der um ein Abtastintervall vor dem ersten dargestellten Punkt liegt. Und der letzte Punkt liegt zwangsläufig auf dem Ende des Darstellungsbereichs.

Das bringt mich zu einem Kompromissvorschlag: Am Anfang der Datenreihe wird wie oben vorgeschlagen zusätzlich ein Wert aus der DB gelesen, der um ein Abtastintervall vor dem ersten dargestellten Punkt liegt. Für das Ende der Daten kann man den aktuellen item-Wert separat mitliefern ("Series_extended" oder einfach "actual"). Bei Linienplots kann ich den Wert dann hinten anfügen und dadurch werden keine unplausiblen Werte produziert.

Wäre das aus Deiner Sicht ein Ansatz? Wir müssen dann übrigens auch nochmal genau ansehen, welche Werte beim item-Update geschickt werden und ob die plausibel sind.

Gruß
Wolfram

**aschwith** · 05.11.2022, 20:25

Hallo Wolfram, finde ich gut, machen wir so.

**aschwith** · 06.11.2022, 17:32

Hallo Wolfram,

ich habe eine erste Modifikation des DB plugins in das lokale Repo geschoben:
https://github.com/aschwith/plugins_db/tree/develop

Die optionalen Tuples, die angehängt werden, habe ich von series in series_ext verschoben. Weiterhin habe ich die Anhänge unterdrückt, die extakt identische Einträge zu bestehenden Tuples hatten (Diff Time 0). Kannst Du damit testen?

Mir ist bei genauerer Untersuchung aufgefallen, dass das Anhängen des aktuellen Werts (jetzt in der series_ext) auch für Linienplots nicht immer gewünscht ist. Ein gutes Beispiel sind wieder Items, die nur sehr selten aktualisiert werden, z.B. Zählerstände. Bisher wird hier einfach der aktuelle Wert (Zählerstand) am Ende mit des Abfragezeitraums nochmal eingefügt und suggiert damit wieder ein Informationsupdate Plot, die es in Wirklichkeit nicht gegeben hat. Das zeigt sich dann im Linienplot mit einem Plateau am Ende der Linie, welches nicht korrekt ist:

Plateu.jpg

Bezüglich item update: Was erwartet die Visu bei einem update von der Time Series? Was ist der Unterschied zu der erstmaligen Anfrage?

**wvhn** · 06.11.2022, 22:00

Hi Alex,

ich hab mal ein Update auf v1.9.3 gemacht und Deine Dateien eingespielt (__init__.py und plugin.yaml).

Dann habe ich im WebIF des Database-Plugins die tatsächlich vorhandenen Einträge angezeigt und dann einen Plot des items "env.system.load" in der VISU aufgerufen.

Datensatz "series":

erster Wert liegt exakt auf dem Start des Plots, ist aber vom Plugin künstlich erzeugt
zweiter Wert ist der erste reale Wert aus der Datenbank im abgefragten Zeitraum
letzter Wert ist der letzte reale Wert in der Datenbank (mit duration None)

Datensatz "series_ext":

erster Wert ist überwiegend (nicht immer) identisch mit dem letzen Wert des "series" Datensatzes
zweiter Wert ist ein vom Plugin ergänzter Wert genau am Ende des abgefragten Zeitraums

Die Debug-Ausgabe enthält noch einen Fehler:

Code:

DEBUG 2a _series: item=env.system.load, overwriting first tuple[0] from (0.14,0.14) to (1667680043972, 0.14)

hier muss in Zeile 872 tuples[0][0] für den Zeitstempel ausgegeben werden.

Ich muss in den nächsten Tagen noch einmal testen, unter welchen Bedingungen die beiden Werte in "series_ext" mal nützlich sein können

Gruß
Wolfram

**aschwith** · 07.11.2022, 17:49

Hallo Wolfram,

der Fehler Zeile 872 wurde gestern im RePo schon gefixt.

Deinen Punkt "erster Wert ist überwiegend (nicht immer) identisch mit dem letzen Wert des "series" Datensatzes" hatte ich auch schon gesehen und unterdrückt. Ist auch schon im RePo.

Noch ein paar Klärungspunkte:

1) Erwartest Du die Tuples in serie_ext zeitlich sortiert? Das war bis jetzt nicht immer der Fall.
2) Mein Vorschlag ist, alle vom Plugin generierten extra Tuples in die series_ext zu schreiben:
Das ist zum Beispiel dieser hier: "erster Wert liegt exakt auf dem Start des Plots, ist aber vom Plugin künstlich erzeugt". Passt das, wenn dieser in die series_ext verschoben wird? Weiterhin erzeugt das Plugin auch extra Werte mitten in den Datenreihe, wenn aufgrund eines sehr geringen DB Abtastintervals ein Item Change nicht hoch genug aufgelöst wird. Auch diesen würde ich in die series_ext schreiben.
Abschließend gibt es den aktuellen Wert am Ende, auch diesen würde ich in die series_ext schreiben.
3) Damit wären wir bei dem Ergebnis, dass die series nur noch Tuples aus der DB Abfrage beinhaltet und die series_ext dann die ergänzenden Werte.
4) Zu Deiner Frage, wofür die series_ext dann nützlich sein könnte, siehst Du sofort, wenn Du nur die series plottest. Hier fehlend dann je nach Abfrage am Anfang und Ende des Plots Daten.
5) Zum Update Modus: Verstehst Du, warum aktuell die series unterschiedlich befüllt wird, je nachdem ob eine Serie von der Visu erstmalig angefragt wird (update==false) oder ein Update (update==true) getriggert wird? Aktuelle wird z.B. der aktuelle Wert nur bei der erstmaligen Anfrage mit angehängt. Wie soll sich das zukünftig verhalten?
6) Wie fliegen wir die Kompatibilität DB plugin/smartVisu an? Zwei series Funktionen vorbereiten, die je nach smartVisu Version getriggert werden?

VG
Alex

**wvhn** · 09.11.2022, 22:45