Neuer ioBroker-Blog online: Monatsrückblick März/April 2026

[peterfido]

Hallo,

ich habe zwischenzeitlich influxdb 1.8 und Grafana auf den NUC gebracht. Wie @Dutchman in seinem Video bereits anmerkt, soll man nicht "alte" Videos als Anleitung nutzen. So lief es auch nicht wie in seinem Video gezeigt. Ich wollte es in einem LXC Container unter Proxmox installieren. Die Installation von influxdb erfordert den Befehl

lsb_release -cs

Diesen gibt es unter dem Debian 10 Container nicht. Mal eben schnell installieren lassen wollte der sich auch nicht. Also nicht lange gesucht, sondern eine VM angelegt. Wenn man die Befehle auf den Seiten der influxdb und Grafana per Copy and Paste nutzen möchte, ist es von Vorteil, vorher noch sudo zu installieren.

Nachdem dann influxdb und Grafana installiert waren, wollte ich die Daten vom History-Adapter in die influxdb kopieren. Das erwies sich als schwerer als Gedacht. Die Anleitung an sich ist nicht das Problem. Eher das Netzwerk. Über Netzwerk von einem NUC zum anderen NUC musste ich den Faktor der Zeitberechnung bis auf 6 hochdrehen und selbst dann ist es "irgendwann" abgebrochen. Da das Kopieren eine Ewigkeit dauert, die VM influxdbGrafana auf den selben NUC wie iobroker kopiert. Da klappte das Kopieren der Daten dann soweit. Allerdings werden vorhandene Daten in der influxdb wohl nur tageweise und nicht jedes Datum verglichen. So fehlt mir aktuell noch vom Tag des Umzugs die Daten von 00:00 Uhr bis etwa 16:00 Uhr, wo ich bereits Daten in die influxdb hab schreiben lassen. Ich könnte wohl alle Daten löschen und dann nochmal alles kopieren lassen. Allerdings klappte der Import in die influxdb nur, wenn es die Datenpunkte in dieser bereits gibt. Die Option, alle Daten, auch wenn nicht vorhanden zu kopieren, hat, zumindest bei mir, keinen Erfolg gebracht.

--processAllDPs

Dann lief die influxdb nur eine kurze Zeit lang. Dann war die virtuelle 20GB Festplatte voll.

Leider habe ich für die Suche der Ursache erstmal die Platte vergrößert gehabt, damit ich auf dem System arbeiten konnte. Zum Vergrößern musste ich die Snapshots entfernen...

Das Ergebnis der Suche, was da die Platte zugemüllt hatte, waren zwei Logdateien. daemon.log und syslog.

Darin wurde jeder Vorgang der Datenmigration mitgeloggt. Also erstmal in der influxdb.config gesucht. Dort das Loggen abzuschalten hat nicht gereicht. Im Netz eine Anleitung gefunden, wie man das Loggen der influxdb verhindert.

 nano /etc/rsyslog.d/influxdb.conf

erstellt eine Datei, welche dann die Regel dazu enthält.

### InfluxDB Rules ###
if $programname == 'influxd' then {
   action(type="omfile" file="/dev/null")
   stop
}

Seit dem bleibt der genutzte Plattenplatz im Rahmen von 2,1 bis 2,2 GB.

Also die Platte wieder verkleinert. Das geht nur über Umwege. Eine gparted - Iso heruntergeladen, die Platte verkleinert. Dann aus der qcow2 eine raw gemacht, diese verkleinert und wieder zurück in eine qcow2.

Dann müssen die Flots für die VIS noch angepasst werden. Die Art der Daten musste ich überall auf minmax ändern, sonst waren Lücken in den Linien.

[Dutchman]

@peterfido

danke fuer die erklaehrung und loesung eines bekannten Problems welches ich öfter in de community gehoert habe ! :)
Das video brauch ein update, zum teil weil Linux Sachen sich geaendert haben, aber auch Grafana und Ubuntu selber.

Der winter kommt, mal schauen was man da wieder alles schafft hab aber auch noch andere Baustellen die up-to-date pflege haben möchten :D