sql 2.0.0 verfügbar - eine Zusammenfassung

[apollon77]

Und damit es nicht ganz langweilig wird hier noch ein kleines Update auf die 2.1.2 ... Ich habe nochmal in so einige Performancethemen vor allem bei GetHistory reingeschau und optimiert.

Wenn alles klappt geht das dann demnächst auch in Stable.

[apollon77]

Hey all,

von sql gibts jetzt die 2.1.5 mit letzten Fixes. Wenn keiner mehr was meldet wäre das die Version die die Tage in Stable geht.
Hier hatte sich noch ein Bug eingeschlichen das neue Datenpunkte vielleicht nicht korrekt initialisiert wurden.

Bitte checkt es nochmal

Ingo

[Sneak-L8]

@apollon77 Hab meinen ioBroker von einer alten Stretch-Version auf bullseye umgezogen mit Backitup.
Neben den bekannten Problemem mit vis hänge ich aktuell am SQL-Adapter.
Er scheint ähnliche Probleme zu haben, die sich aber nicht nach dem glecihen Schema lösen lassen.
Ich hab den Adapter schon mit

iob del sql

gelöscht und dann über die Oberfläche wieder installieren wollen.
Aber er hängt immer an der gleichen Stelle:

$ iobroker upgrade sql@2.1.7
Update sql from @0.0.0 to @2.1.7
NPM version: 8.11.0
Installing iobroker.sql@2.1.7... (System call)

Danach friert das System ein, nicht mal über SSH reagiert er noch auf Eingaben.
Hast Du einen Tipp, wie ich den SQL-Adapter wieder sauber zum Laufen bekomme?

[haselchen]

@sneak-l8

Wenn er gelöscht wäre würdest du kein Upgrade machen.
Sieht man auch an der Version 0.0.0
Da musste vermutlich nochmal Hand anlegen .

[Sneak-L8]

@haselchen Ok, danke.
Ich probiere es nun nochmal von der Konsole aus. Aber bleibt dabei, die Installation läuft enfahcn icht an:

pi@raspberrypi:~ $ iob stop
pi@raspberrypi:~ $ iob del sql
Delete adapter "sql"
host.raspberrypi object sql deleted
host.raspberrypi object sql.admin deleted

removed 182 packages, and changed 2 packages in 16s

105 packages are looking for funding
  run `npm fund` for details
pi@raspberrypi:~ $ iob install sql
NPM version: 8.11.0
Installing iobroker.sql@2.1.7... (System call)

An dieser Stelle geht es nicht weiter ...

[Thomas Braun]

@sneak-l8

ioveoker add sql --debug

[Sneak-L8]

@thomas-braun Mist, ich war wohl nur zu ungeduldig. Jetzt von der Konsole hatte er sql nach ca. 5-10 Minuten (war nicht am Rechner) installiert. Und jetzt läuft es...

[apollon77]

@sneak-l8 Meine Empfehlung wäre gewesen ioBroker mal zu beenden für die Installation. Am Ende kompiliert der sqlite3 und das kann je nach System durchaus mal bissl dauern und auch RAM brauchen ...

[Sneak-L8]

@apollon77 Danke für den Tipp. Treffer . Genau das hatte ich getan. Da es keinen Grund gab, warum die Installation nicht klappen sollte, habe ich den ioBroekr wie oben beschrieben erst gestoppt. Dadurch lief er dann wohl durch.

[apollon77]

@sneak-l8 dann war es zu wenig RAM und swapping.

[mlapp]

@apollon77 Hy, gibt es eine Möglichkeit, historische Werte (die nicht aus ioBroker stammen) im entsprechenden Format in die Datentabellen der ioBroker Datenbank zu schreiben um diese dann mit Flot zu nutzen? Ich würde mir gerne Charts meiner PV-Anlage konsolidiert auf Tage, Monate und Jahre graphisch anzeigen lassen.
Die Daten im entsprechenden Format kann ich problemlos in die Tabellen einfügen, nur Flot nutzt diese Daten einfach nicht.
Ich hab mir dazu z.B. auch schon einen Datenpunkt angelegt und im Admin zum speichern eingestellt. Werte die ich nach der Erstellung in die DB speichere werden angezeigt. Daten davor leider nicht. Gibt es dafür eine Lösung außer Grafana zu verwenden?

[apollon77]

@mlapp also idealerweise nutzt du Adapter wie sourceanalytics oder statistics und hast damit die aggregierten Werte wieder in States die du historisieren und ggf nutzen kannst. Oder was genau meinst du?

Welche Daten kamen da wie in die db?

[mlapp]

@apollon77 Ne, ich möchte die Daten schon aggregiert in die Datenbank schreiben.
Ich hab die ganzen Tageswerte und zeig sie mir aktuell in einer Tabelle an. Das funktioniert problemlos. Aber, ein altes Sprichwort sagt... Ein Bild sagt mehr als tausend Worte.
Ich würde mir diese Daten eben auch gerne in einer Graphik anzeigen lassen. Nach vorne verschieben, rein zoomen usw.
Die PV Tagesdaten hab ich mal aus einem Onlineportal extrahiert und in die DB (eigene Tabelle) geschrieben. Flot weigert sich aber hartnäckig diese Daten als Quelle anzuerkennen.
Wenn das ginge, wäre alles geritzt. Aber da kommt mir gerade eine Idee... vielleicht geht es ja mit einem JSON Chart Objekt... Ich spiel damit mal ein wenig rum....

[apollon77]

@mlapp Naja das ganze History Ansatz basirt darauf das der Adapterdas zu States und so zuordnen kann und weiß wie die Daten strukturiert und gespeichert sind. Wenn du irgendwo selbst Dinge in die DB schreibst dann ist die "getHistory" Funktion und damit die History Adapter raus und ja dann bleibt Dir nur Grafana ... oder machst es so wie beschrieben. Kann ja sein das Du die Werte selbst aggrgierst ... aber warum nicht in passenden States in die DB schreiben "lassen" ... dann haste wieder alles

[BananaJoe]

@mlapp Ja, du kannst auch historische Daten schreiben.
Du brauchst einen Datenpunkt für den SQL aktiviert wurde und per sendTo kannst du Daten an diesen senden - mit Zeitstempel. Beispiele findest du auf der GitHub Seite zum SQL-Adapter.

Ich nutze das z.B. beim pvforcast-Adapter um die abgerufenen Daten in die SQL zu schreiben und im echart-Adapter zu nutzen.

[mlapp]

@bananajoe danke für den Tip. as mit dem Zeitstempel klingt grundsätzlich interessant.
Aber die Daten als solches liegen ja schon in einer Tabelle als Tageswerte vor. Ich muss also lediglich in einer SQL Abfrage die Daten entsprechend aggregieren und anzeigen lassen.
Mein erster Ansatz, die berechneten Daten wieder in die DB zu schreiben, war eigentlich dämlich und nur dem Umstand geschuldet, dass ich keine Idee hatte diese Daten irgendwie anders anzeigen zu können. Es gibt aber VIS Objekte, die Daten aus einem JSON-String anzeigen können.
Damit wird es relativ einfach das umzusetzen, was ich mir vorgestellt habe. Es ginge zwar vermutlich mit Grafana hübscher, aber die Lösung reicht mir voll und ganz und ist relativ flexibel.
So sieht es jetzt aus und das passt so für mich:

[mlapp]

@apollon77 Der Ansatz an sich ist mir schon klar und der ist im Grunde ja auch gut so.
Meine Idee, Daten in die DB zu schreiben, war im Grunde sowieso nur eine Krücke, weil ich keine andere Möglichkeit gesehen habe als über den FLOT Adapter zu gehen. Aber die Daten direkt über SQL auszuwerten und als JSON String zurück geben zu lassen ist natürlich viel eleganter.
Man kann sich zwar sicher über die Optik streiten, aber für meine Zwecke reicht das alle mal.
Danke dir trotzdem für die Antworten.