wichtiges UPDATE für controller 7.2.2 im stable

[Humidor]

Nein, wurde in Syno-Forum geklärt. die Dauerlast von ca20MB/s hat die SSD aufgearbeitet.
mit 143 DB sind es jetzt 3-4MB, was immer noch zu hoch ist und nur ein Bruchteil von dem ich eigentlich aufzeichnen will..... mom. stehe ich vor einem Rätsel und muss über den Tellerrand schauen (HA ?) ...

[Ro75]

OK dann gib bitte detailiert folgende Daten:

• 1. Wieviele Datenpunkte werden historisiert
• 2. In welchem Abstand werden die Datenpunkte beschrieben
• 3. Welche Adapter in dem Zusammenhang.

Hinweis: Selbst bei 20 MB/s killt das nicht gleich deine SSD, da vergeht schon bissel Zeit.

UND, bisher hast du keinerlei Infotmationen zu deinem System gezeigt.

iob diag

Ro75.

[Marc Berg]

@Humidor sagte:

stehe ich vor einem Rätsel

In einem anderen Thread hattest du erwähnt, dass du mal versehentlich ALLE Objekte im ioB-Baum in die InfluxDB geschrieben hattest. Gibt es dieses Bucket mit den Massendaten noch? Das kann für eine InfluxDB zum Problem werden. (Thema Kardinalität)

Zum Test könntest du in der Instanz einfach mal in ein neues Bucket schreiben und prüfen, ob sich was ändert.

[Humidor]

... mann, wie kriegt man wieder die Ausgabe vom Terminal hier rein, copy paste klappt ja mal wieder gar nicht...

Stabel, alles aktuell. die SSD gehen ja nicht sofort kaputt, aber nach Zeit.
DB so viele wie es geht, tausend.

PlatformBetriebssystem:linux
Architektur:x64
CPUs:8
Geschwindigkeit:2123 MHz
Modell:AMD Ryzen Embedded V1500B
RAM:15.5 GB
System-Betriebszeit:9 T. 08:25:41
Node.js:v22.22.3
Zeit:1781721558302
Zeitversatz:-120
NPM:10.9.8
Adapter-Anzahl:617
Datenträgergröße:889.8 GB
Freier Festplattenspeicher:571.0 GB
Aktive Instanzen:16
Pfad:/opt/iobroker/
Betriebszeit:3 T. 10:41:48
aktiv:true
_nodeCurrent:22.22.3
_nodeNewest:22.22.3
_nodeNewestNext:22.22.3
_npmCurrent:10.9.8
_npmNewest:10.9.8
_npmNewestNext:10.9.8

läuft auf der Synology im Docker

so schauts aus, sobald man den influx adapter aktiviert

[Ro75]

@Humidor sagte:

Stabel, alles aktuell. die SSD gehen ja nicht sofort kaputt, aber nach Zeit.
DB so viele wie es geht, tausend.

Vielleicht wäre es möglich, dass du mal zur Abwechslung konkrete Informationen lieferst.

Mit "Stabel" kann man nichts anfangen. Und eine SSD braucht bei 20MB/s Dauerveanspruchung etwa 3 Jahre bi die hin sein kann.

"DB so viele wie es geht, tausend". Da beschreibst du doch dein Problem selber! Man braucht doch nur die wirklichen Datenpunkte und nicht alles was möglich ist.

Ro75.

EDIT: Liefere das Ergebnis von iob diag.

[Ro75]

Echt jetzt? Jetzt nochmal das gleiche Bild wie in Post #1?

Ro75.

[Humidor]

iob diag kann ich nicht liefern, copy paste aus dem terminal vom Syno Docker funktioniert nicht.
Da wird viel hingeschrieben, was genau willst du davon wissen, dann bringe ich das nach.

Stabel aktuell, was verstehst du darunter nicht, alles auf aktuellem Stand, soll ich jetzt noch die Adapterversion aufschreiben ?? Also welche konkreten Information brauchst du denn?

Ja, ich will viele DP loggen, das ist auch Sinn einer Smarten Hausautomation, dass man nachsehen kann, was passiert ist und auch einen Vergleich mit den Vorjahren machen kann! Sonst machen Aufzeichnungen keinen Sinn!

Vergiss das mit der SSD, das wurd im Syno Forum durchgekaut, mach ich hier sich nicht nochmal.

[Ro75]

@Humidor sagte:

Ja, ich will viele DP loggen, das ist auch Sinn einer Smarten

Korrekt! Nur ich sammel keine Daten auf Verdacht! OT AN: Dann liebst du auch die Vorratsdatenspeicherung? OT AUS Man sammelt das was man braucht. Da kommt man vielleicht auf 100 Datenpunkte. Man kann sich das Leben auch wirklich schwer machen.

Ja, das gesamte Log von iob diag! Wenn du nicht weist wie es geht (wie man was rauskopiert) dann musst du ggfs. an anderer Stelle nachfragen wie es geht.

Wenn du hier Hilfe willst, dann solltest du auch auf das was gefragt wurde antworten.

@Humidor sagte:

Vergiss das mit der SSD, das wurd im Syno Forum durchgekaut, mach ich hier sich nicht nochmal.

Ist deine Sache. Aber es muss hier alles betrachtet werden und nicht nur 70%.

Letztlich ist es deine Sache. Ich halte mich jetzt raus, wenn hier nichts brauchbares kommt.

Ro75.

[Humidor]

ich habe alle Infos gebracht, wenn welche offen sind, dann bitte spezifisch nachfragen
diese Pauschalinfoanforderung soll jetzt für was gut sein ?? gibst ja keine Antwort drauf. so bringt das nichts und ist auch nicht gefragt.

Nochmal, die Frage ist, warum Infux so einen Datengau verursacht
und 143 DP sind alleine die Zellspannungen der Batterien.....

[Ro75]

@Humidor sagte:

ich habe alle Infos gebracht

NEIN, hast du nicht

@Humidor sagte:

welche offen sind, dann bitte spezifisch nachfragen

log von iob diag

@Humidor sagte:

Pauschalinfoanforderung

für deine Problemlösung

@Humidor sagte:

so bringt das nichts

ich habe keine Probleme mit meinem Smarthome, du anscheinend schon

@Humidor sagte:

Nochmal, die Frage ist, warum Infux so einen Datengau verursacht

InfluxDB mit Sicherheit nicht!

@Humidor sagte:

und 143 DP sind alleine die Zellspannungen

schön

Ro75.

[da_Woody]

@Humidor sagte:

Ja, ich will viele DP loggen, das ist auch Sinn einer Smarten Hausautomation

kannst du ja gerne machen. kommt auf deine hardware an.
hab mir am anfang auch gedacht, geil, ich logge alles mit. die VM ist dann schnell in die knie gegangen. (bin immer noch bei influx1, grafana und tasmoadmin sind da auch drinnen)
alles gelöscht über die objekte und nur mehr wichtige sachen loggen. seither ist alles i.o.

[Marc Berg]

Bei mir resultieren aus ca. 300 geloggten Datenpunkten im Schnitt ca. 1 kB/sek.

Aber vielleicht bekomme ich ja auch noch eine Antwort auf meine Frage: https://forum.iobroker.net/post/1345001

[Homoran]

@Marc-Berg sagte:

300 geloggten

Das sind ja auch keine 47100!
https://forum.iobroker.net/assets/uploads/files/1781420126975-bildschirmfoto-2026-06-14-um-08.55.15.png

[Thomas Braun]

@Humidor sagte:

... mann, wie kriegt man wieder die Ausgabe vom Terminal hier rein, copy paste klappt ja mal wieder gar nicht...

Aus einem richtigen, gescheiten Terminalprogramm kann man ganz geschmeidig c&p hier rein kopieren.
Du bist vermutlich mit dem in Synology vorhandenden Kladderadatsch unterwegs, da gibt es wohl u. U. so ein Verhalten.

[Humidor]

neuer DB Name, keine Änderung an den MB, bei den 143 sofort über 3MB/s rauf, beim deaktivieren des Adapter wieder unter 1MB/s

kann man iob diag in eine datei oder ins clipboard umleiten, markieren und cp fkt. nicht. auch ist es nicht vollständig, der Anfang ist nicht mehr da, kein weiteres zurückscrollen möglich. Das fkt. im Docker Terminal nicht.

• Ausgabe in file umgeleitet, copiert
  iob_diag.txt

[Thomas Braun]

@Humidor

Das liegt auch automatisch schon in /home/iobroker drin.
Aber du solltest dir dringend ein richtiges Terminal anschaffen...

[Humidor]

kenne keinen Ersatz für ein Docker Terminal?
steht was drin im diag?

ja, im docker/iob liegts drin

[OliverIO]

@Humidor

Wenn das Problem bei „in die Datenbank“ schreiben liegen würde, dann gäbe es hier mehr Berichte darüber.

Liest du den auch aus der Datenbank?
Als evtl. mit grafana oder JavaScript?
Evtl hast du nicht optimierte abfragen, welche zwar funktionieren, aber die Datenbank nötigen Tabellen von vorne bis hinten zu durchsuchen. Das kann auch viel Festplatten Traffic erzeugen.
Auch beim abfragen schreibt uU die Datenbank. Meist bei komplexeren Abfragen und großen Datenmengen. Dann wird erst abgefragt, in eine temporäre Tabelle geschrieben und dann Filter und gruppierungsregeln angewendet.

[Humidor]

nein, hatte mal versucht aus der Influx was auszulesen, hat aber nicht geklappt.
ansich wird nur in die Influx gespeichert, Grafana holt sich diese zur Visualisierung.

gäbs ev. eine Methode das zu prüfen oder zu ergründen, was da sobald der Adapter läuft an Aufgaben laufen?

hab mal Loglevel silly gestartet
daran sieht man, dass er alle Datenpunkte aufzeichnet, somit hat der Adapter diese nicht aus seiner Datenbank gelöscht und nur die besagten 143 drin.
das wird die Ursache sein.

ein minimaler Auszug:

2026-06-19 12:20:24.597  - silly: influxdb.0 (9365) States user redis pmessage */mqtt.1.N.c0619ab336ed.temperature.21.Temperature:{"val":"{\"value\":34.18102264404297}","ack":true,"ts":1781864424596,"q":0,"from":"system.adapter.mqtt.1","user":"system.user.admin","lc":1781864424596}
2026-06-19 12:20:24.597  - silly: influxdb.0 (9365) States user redis pmessage */mqtt.1.N.c0619ab336ed.temperature.20.Temperature:{"val":"{\"value\":31.486989974975586}","ack":true,"ts":1781864424596,"q":0,"from":"system.adapter.mqtt.1","user":"system.user.admin","lc":1781864424596}
2026-06-19 12:20:24.629  - silly: influxdb.0 (9365) States user redis pmessage */modbus.1.holdingRegisters.3.40023_Cell_Voltage_8:{"val":3330,"ack":true,"ts":1781864424628,"q":0,"from":"system.adapter.modbus.1","user":"system.user.admin","lc":1781864424628}
2026-06-19 12:20:24.647  - silly: influxdb.0 (9365) States user redis pmessage */mqtt.1.N.c0619ab336ed.solarcharger.0.History.Daily.0.TimeInBulk:{"val":"{\"value\":467}","ack":true,"ts":1781864424645,"q":0,"from":"system.adapter.mqtt.1","user":"system.user.admin","lc":1781864424645}
2026-06-19 12:20:24.647  - silly: influxdb.0 (9365) States user redis pmessage */mqtt.1.N.c0619ab336ed.solarcharger.0.Pv.1.V:{"val":"{\"value\":262.3900146484375}","ack":true,"ts":1781864424646,"q":0,"from":"system.adapter.mqtt.1","user":"system.user.admin","lc":1781864424646}
2026-06-19 12:20:24.648  - silly: influxdb.0 (9365) States system redis pmessage mqtt.1.N.c0619ab336ed.solarcharger.0.Pv.1.P/mqtt.1.N.c0619ab336ed.solarcharger.0.Pv.1.P:{"val":"{\"value\":2176.070068359375}","ack":true,"ts":1781864424646,"q":0,"from":"system.adapter.mqtt.1","user":"system.user.admin","lc":1781864424646}
2026-06-19 12:20:24.649  - silly: influxdb.0 (9365) States user redis pmessage */mqtt.1.N.c0619ab336ed.solarcharger.0.Pv.1.P:{"val":"{\"value\":2176.070068359375}","ack":true,"ts":1781864424646,"q":0,"from":"system.adapter.mqtt.1","user":"system.user.admin","lc":1781864424646}
2026-06-19 12:20:24.649  - silly: influxdb.0 (9365) States user redis pmessage */mqtt.1.N.c0619ab336ed.solarcharger.0.Pv.0.V:{"val":"{\"value\":261.1400146484375}","ack":true,"ts":1781864424646,"q":0,"from":"system.adapter.mqtt.1","user":"system.user.admin","lc":1781864424646}
2026-06-19 12:20:24.649  - silly: influxdb.0 (9365) States system redis pmessage mqtt.1.N.c0619ab336ed.solarcharger.0.Pv.0.P/mqtt.1.N.c0619ab336ed.solarcharger.0.Pv.0.P:{"val":"{\"value\":2227.1298828125}","ack":true,"ts":1781864424646,"q":0,"from":"system.adapter.mqtt.1","user":"system.user.admin","lc":1781864424646}
2026-06-19 12:20:24.650  - silly: influxdb.0 (9365) States user redis pmessage */mqtt.1.N.c0619ab336ed.solarcharger.0.Pv.0.P:{"val":"

[OliverIO]

@Humidor

Also grafana liest aus der Datenbank?

Dann dort mal alles durchgehen und prüfen ob da zu oft große Datenmengen gelesen werden.
Nicht optimierte Abfragen kann man daran erkennen wenn bspw Werte in nicht indizierten Feldern gesucht werden müssen. Es gibt aber noch mehr Möglichkeiten sowas zu produzieren, aber ich gehe mal davon aus das du diese Möglichkeiten mit grafana nicht ausschöpfst.
Als ersten schnellen Test, kannst du mal Grafana stoppen, also den eigentlichen Dienst, nichts in IOBroker. Dann wirst du sehen, ob der Festplatten Traffic runtergeht.

Und zusätzlich, nur eine Vermutung, unabhängig von dem vorhergehenden und auch bitte nicht gleichzeitig, den Javascript Adapter stoppen.
Nicht, dass du da noch ein Skript laufen hast