wichtiges UPDATE für controller 7.2.2 im stable

[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

[Humidor]

es sind im Objektbaum nur die 143 drin

den Adapter nun gelöscht und neu installiert

beim start fragt er wieder alle! DP ab.

Gut, Ursachen nun klar, wie kann man es beheben?

in Influx habe ich alles Datenbanken gelöscht, sonst ist in keinem Reiter etwas drin

Grafana hat nur die Verbindung zur Influx DB
da ich nur einzeln die Qerys aus Influx raus kopiere und in Grafana eintrage, gibt es nur direkte Werte die angezeigt werden

[Humidor]

nochmal alles gelöscht und kein Objekt zur Aufzeichnung ausgewählt, also alles und keine Aufzeichnung

im Log zeigt er mir aber was an, das mich stutzig macht.

der Raspi4 ist für eine USB Verbindung zwischen Endgeräten im Lan. was macht der da?
die Meldung kommt jede Sekunde.

• hab dazu chatgpt befragt und der meint, das ist nichts.

[Humidor]

ich habe jetzt nur ein Objekt in der Influx aktiviert

und die Auslastung bleibt unbedeutend, erkenn keine signifikante MB/S Änderung in der Syno

kann es sein dass die Globale Funktion, wo man viele Objekte in der Influx eintragen kann - alle einträgt?

Test, mache jetzt wieder einen Objektbaum mit dem Schraubenschlüssel

im Log hat er die 143 eingetragen, angelegt
MB/s hoch auf 25, runter auf 4MB/s
also da läuft was schief!

alle Influx Objekte wieder gelöscht und Datenbank gelöscht und
sofort runter unter 1MB/S

wieder nur ein Objekt in die Influx eingetragen und es bleibt nicht relevant.

jetzt die ersten 16 Zellspannung eingetragen
es bleibt unauffällig

damit ist die Sache für mich klar, mehr kann ich da auch nicht weiter testen.
sobald man global die Einstellungen für Influxaufzeichnungen in den Objekten nutzt, reißt es die MB/s hoch. Warum, wiso, weshalb... kA.

[Marc Berg]

@Humidor sagte:

beim start fragt er wieder alle! DP ab.

Nein, er fragt nicht alle DP ab. Der Adapter abonniert nur alle Änderungen an den States. Nach jeder Änderung wird dann geprüft, ob für diesen DP eine Historierung konfiguriert ist. Falls nicht, bricht er sofort ab. Das hat keinerlei Auswirkungen auf die InfluxDB

im Log zeigt er mir aber was an, das mich stutzig macht.

Auch ganz normal. Der Adapter hat alle Objektänderungen abonniert, damit er mitbekommt, falls man zur Laufzeit zusätzliche DPs historisieren möchte. Keinerlei Auswirkung auf die InfluxDB.

wieder nur ein Objekt in die Influx eingetragen und es bleibt nicht relevant.

928 KB/sek sind auch schon viel zu viel für nur ein DP!

An deiner Stelle würde ich das Debug Log der InfluxDB auf "debug" stellen, damit man mal sieht, was dort abgeht.