Monatsrückblick Juli / August 2026 ist online!

[Ro75]

@Homoran musst du mal schauen wie genau die installation ist. Auf alle Fälle beides umstellen. NUR wenn dir der RAM ausgeht, wird die ggfs. Redis crashen und deine Daten, sofern Redis sie nach Konfig, noch nicht auf deinem Datenträger gespeichert hat, verloren sind. Was SWAP angeht. Da gibt es unterschiedlichste Ansichten, wie Redis. Fakt ist, bei mir hat jedes Gerät eine SWAP in der Größe 50% vom RAM. Wenn gebraucht OK, wenn nicht auch OK.

Ro75.

[Homoran]

@paul53 sagte:

ohne Lüfter?

Und

@paul53 sagte:

die vermutlich irgendwo im RAM gepuffert werden.

Da wird ja auf jeden Fall die Aggregation stattfinden

[Homoran]

Der Umzug der history auf due SSD hat erwartungsgemäß leider nicht wirklich funktioniert.

2026-08-29 09:28:04.892  - error: history.0 (10517) Cannot store file /mnt/usbplatte/archiv/backup_history/20260829/history.Messwerte.0.Stromzaehler.Summenwerte.Tagesverbrauch.json: Error: EACCES: permission denied, open '/mnt/usbplatte/archiv/backup_history/20260829/history.Messwerte.0.Stromzaehler.Summenwerte.Tagesverbrauch.json'

Da fehlen mir Grundlagen

[paul53]

@Homoran [sagte]: Der Umzug der history auf due SSD hat erwartungsgemäß leider nicht wirklich funktioniert.

Offenbar hat der user "iobroker" keine Schreibrechte auf das Verzeichnis.
Weshalb "/mnt/usbplatte/archiv/backup_history" und nicht "/mnt/usbplatte/data/history"?

@Homoran sagte in Load average am Anschlag -> Neustart:

Da fehlen mir Grundlagen

sudo chmod +w /mnt/usbplatte/data/history

erlaubt allen Usern das Schreiben in das Verzeichnis.

[Homoran]

@paul53 sagte:

Weshalb "/mnt/usbplatte/archiv/backup_history" und nicht "/mnt/usbplatte/data/history"?

Weil ich das schon alles als backup dort angelegt hatte.

...und ich bekam auch nicht als user per sftp wegen der Rechte auf /opt/iobroker/iobroker-data/ history die Ordner verdchoben und gelöscht. Da musste ich es per console mit sudo cp... machen.
Mangels wissens und Routine habe ich mir dann in beiden Verzeichnissen die gesicherten Daten von 2021 und 22 gelöscht.
Nicht wirklich schlimm, wollte das aber mit den aktuellen Daten nich auch noch riskieren.

@paul53 sagte:

sudo chmod +w /mnt/usbplatte/data/history
erlaubt allen Usern das Schreiben in das Verzeichnis.

DANKE!
Das versuch ich dann

[OliverIO]

@Homoran

Der Mount muss für den User iobroker verfügbar sein.

Mit

sudo -u iobroker bash

Kannst du mit der Konsole (am prompt steht dann iobroker, anstatt deines normalen Users) schauen ob der Mount sichtbar ist
Ansonsten dann die Rechte des Mount Verzeichnis anpassen

Wenn tatsächlich der Gesamtspei her das Problem ist, wird Redis und Datenbank das Problem uU nicht verbessern.
Beide benötigen ebenfalls RAM, was dann wiederum dem iobroker fehlt.
Wenn du noch deinen alten pi hast, könntest du die history dorthin auslagern. Bei bspw dem mysql Adapter gibst du dann nicht localhost an sondern die Adresse des anderen Geräts an.
Dann findet dorthin nur noch netzverkehr statt.

Es kommt allerdings auch darauf an wie die Adapter oder Admin optimiert sind. Letztens habe ich hier ein Bericht gelesen, was auch mit aggregation von history und influx zu tun hatte.
Da hat sich gezeigt, das versucht worden ist alle Daten (seit 1999) zu laden, obwohl nur die letzten 24h gefragt wurden.
Wenn das sehr viel ist und die aggregation selbst in JavaScript gemacht wird ist das problematisch.

https://forum.iobroker.net/topic/85203/gelöst-ram-läuft-beim-öffnen-der-verlaufsdaten-voll/7?_=1787996576164

Leider finde ich die codestelle nicht mehr um zu schauen ob der history Adapter mit beteiligt ist, evtl ist es auch schon behoben, Version dürft aber noch nicht live sein.

@marc-berg
Weißt du noch wo das war?

Zum Thema ram werte stimmen nicht
Ich vermute, der iobroker kann da auch nur die systemdienste fragen. Da der ram bedarf je Prozess in Millisekunden sich ändert, kann er nur verzögert betrachten. Bei vielen Prozessen können sich kleine Abweichungen mathematisch aufsummieren.

[Homoran]

@paul53 klappt leider auch nicht

2026-08-29 12:10:46.863  - error: history.0 (8573) Cannot store file /mnt/usbplatte/data/history/20260829/history.alias.0.Stromzaehler.Bezug_aktuell.json: Error: EACCES: permission denied, open '/mnt/usbplatte/data/history/20260829/history.alias.0.Stromzaehler.Bezug_aktuell.json'
2026-08-29 12:10:46.921  - error: history.0 (8573) Cannot store file /mnt/usbplatte/data/history/20260829/history.Messwerte.0.Solaranlage.Momentanwerte.Leistung_AC_aktuell.json: Error: EACCES: permission denied, open '/mnt/usbplatte/data/history/20260829/history.Messwerte.0.Solaranlage.Momentanwerte.Leistung_AC_aktuell.json'
2026-08-29 12:10:46.949  - info: history.0 (8573) Delete old history "/mnt/usbplatte/data/history/20240828/history.Messwerte.0.Solaranlage.Momentanwerte.Leistung_AC_aktuell.json"
2026-08-29 12:10:46.950  - error: history.0 (8573) Cannot delete file "/mnt/usbplatte/data/history/20240828/history.Messwerte.0.Solaranlage.Momentanwerte.Leistung_AC_aktuell.json": Error: EACCES: permission denied, unlink '/mnt/usbplatte/data/history/20240828/history.Messwerte.0.Solaranlage.Momentanwerte.Leistung_AC_aktuell.json'
2026-08-29 12:10:46.956  - error: history.0 (8573) Cannot store file /mnt/usbplatte/data/history/20260829/history.Messwerte.0.Solaranlage.Momentanwerte.DC1Spannung.json: Error: EACCES: permission denied, open '/mnt/usbplatte/data/history/20260829/history.Messwerte.0.Solaranlage.Momentanwerte.DC1Spannung.json'
2026-08-29 12:10:46.994  - info: history.0 (8573) Delete old history "/mnt/usbplatte/data/history/20260826/history.Messwerte.0.Solaranlage.Momentanwerte.DC1Spannung.json"
2026-08-29 12:10:46.995  - error: history.0 (8573) Cannot delete file "/mnt/usbplatte/data/history/20260826/history.Messwerte.0.Solaranlage.Momentanwerte.DC1Spannung.json": Error: EACCES: permission denied, unlink '/mnt/usbplatte/data/history/20260826/history.Messwerte.0.Solaranlage.Momentanwerte.DC1Spannung.json'
2026-08-29 12:10:47.003  - error: history.0 (8573) Cannot store file /mnt/usbplatte/data/history/20260829/history.Messwerte.0.Solaranlage.Momentanwerte.Leistung_String1.json: Error

Erst fehler beim löschen, han dann noch chmod +x gemacht.

Hilft aber anscheinend für die Unterverzeichnisse nicht.

Eine recursive Ausführung hab ich nicht hinbekommen

[Homoran]

@oliverio
Erst mal danke für die Grundlagen!
Backitup schreibt auf den mount!
Schon beim alten pi5

EDIT:

puh@BrokerRaspi:/ $ sudo -u iobroker bash
iobroker@BrokerRaspi:/ $ mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,relatime)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=4088272k,nr_inodes=255517,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=600,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=1651184k,mode=755)
/dev/mmcblk0p2 on / type ext4 (rw,noatime)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
none on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=37,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=2585)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
tracefs on /sys/kernel/tracing type tracefs (rw,nosuid,nodev,noexec,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run/credentials/systemd-journald.service type tmpfs (ro,nosuid,nodev,noexec,relatime,nosymfollow,size=1024k,nr_inodes=1024,mode=700,noswap)
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
/dev/nvme0n1p1 on /mnt/usbplatte type ext4 (rw,relatime,stripe=32)
/dev/mmcblk0p1 on /boot/firmware type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,nr_inodes=1048576)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,nosuid,nodev,noexec,relatime)
sunrpc on /run/rpc_pipefs type rpc_pipefs (rw,relatime)
tmpfs on /run/credentials/getty@tty1.service type tmpfs (ro,nosuid,nodev,noexec,relatime,nosymfollow,size=1024k,nr_inodes=1024,mode=700,noswap)
tmpfs on /run/credentials/serial-getty@ttyAMA10.service type tmpfs (ro,nosuid,nodev,noexec,relatime,nosymfollow,size=1024k,nr_inodes=1024,mode=700,noswap)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=825584k,nr_inodes=206396,mode=700,uid=1000,gid=1000)
iobroker@BrokerRaspi:/ $

Der mount (/mnt/usbplatte) ist sichtbar

@OliverIO sagte:

Zum Thema ram werte stimmen nicht

Da bin ich auch weitergekommen!

Es gibt zwei Datenpunkte mit einer irreführenden Bezeichnung!

Einmal freeMem und einmal memAvailable

Beides sind anscheinend Werte für available, ermittelt über verschiedene Methoden

[paul53]

@Homoran [sagte]: Eine recursive Ausführung hab ich nicht hinbekommen

Ändere mal rekursiv den Besitzer aller Dateien in "iobroker".

sudo chown -R iobroker /mnt/usbplatte/data/history

[Homoran]

@paul53 sagte:

rekursiv

Mit großem R

Danke

[Homoran]

@paul53 aber hilft auch nicht

history.0
2026-08-29 12:32:21.369	warn	Error reading data directory /mnt/usbplatte/data/history/: Error: EACCES: permission denied, scandir '/mnt/usbplatte/data/history/'

DANKE euch allen

Muss jetzt mal was anderes machen

[paul53]

@Homoran [sagte]:
EACCES: permission denied, scandir

Was sagt?

ls -l /mnt/usbplatte/data

[Homoran]

@paul53 sagte:

@Homoran [sagte]:
EACCES: permission denied, scandir

Was sagt?

ls -l /mnt/usbplatte/data

puh@BrokerRaspi:/ $ ls -l /mnt/usbplatte/data
total 40
d-wx-wx--x 1335 iobroker puh 36864 Aug 29 12:07 history

Falsche Gruppe?

Edit
...und kein r 😱

[paul53]

@Homoran [sagte]: kein r

sudo chmod +r /mnt/usbplatte/data/history

Das Plus vor dem r nicht vergessen!

Es ist wohl beim Versuch der rekursiven Änderung (-r statt -R) verschwunden?

[Homoran]

@paul53 sagte:

Es ist wohl beim Versuch der rekursiven Änderung (-r statt -R) verschwunden?

Aaah!
Ja, das wird's sein

Bis gleich

puh@BrokerRaspi:/ $ sudo chmod +r /mnt/usbplatte/data/history
puh@BrokerRaspi:/ $ ls -l /mnt/usbplatte/data
total 40
drwxrwxr-x 1335 iobroker puh 36864 Aug 29 12:07 history

Ich stell nochmal die Verzeichnisse in history um

EDIT:

Sieht gut aus

history.0
2026-08-29 13:22:34.174	info	enabled logging of system.host.ioBrokerpi5.outputCount (Count=474), Alias=true

history.0
2026-08-29 13:22:46.277	info	Delete old history "/mnt/usbplatte/data/history/20240828/history.Messwerte.0.Solaranlage.Momentanwerte.Leistung_DC_aktuell.json"

history.0
2026-08-29 13:23:43.109	info	Delete old history "/mnt/usbplatte/data/history/20240828/history.Messwerte.0.Solaranlage.Momentanwerte.Leistung_AC_aktuell.json"

history.0
2026-08-29 13:23:43.190	info	Delete old history "/mnt/usbplatte/data/history/20260826/history.Messwerte.0.Solaranlage.Momentanwerte.Leistung_String1.json"

history.0
2026-08-29 13:23:43.245	info	Delete old history "/mnt/usbplatte/data/history/20260826/history.Messwerte.0.Solaranlage.Momentanwerte.Leistung_String2.json"

history.0
2026-08-29 13:23:43.275	info	Delete old history "/mnt/usbplatte/data/history/20240828/history.Messwerte.0.Solaranlage.Momentanwerte.Wirkungsgrad.json"

history.0
2026-08-29 13:23:43.772	info	Delete old history "/mnt/usbplatte/data/history/20240828/history.Messwerte.0.Solaranlage.Momentanwerte.Eigenverbrauch.json"

history.0
2026-08-29 13:23:57.345	info	Delete old history "/mnt/usbplatte/data/history/20260826/history.Messwerte.0.Stromzaehler.Summenwerte.Tagesverbrauch.json"

history.0
2026-08-29 13:24:10.341	info	Delete old history

Danke!

Mal sehen ob das was hilft

[Homoran]

@paul53 es läuft!

Für @oliverio

Werde ich jetzt mal das memFree im Auge behalten.
Ich denke das ist bei schnellem Speicherbedarf das entscheidende

Und dass es jetzt endlich auf der SSD ist sieht man hier

dass es sich da auf eine aktuelle Uhrzeit ändert

[OliverIO]

@Homoran

Free ist der wirklich unbenutzte Speicher
Available ist der Speicher den das Betriebssystem nutzt und kurzfristig für Prozesse bereitstellen kann + free. Linux nutzt das mit als Cache. Daher kann free sehr niedrig sein, während available höher liegen kann.
Wenn dann musst du auf available mem schauen.
Die Unterschiede kommen wahrscheinlich durch die zeitdifferenzen. Besseren Einblick liefert
top
Auf der Shell.
Da siehst du auch wie schnell teilweise das hoch und runtergeht, wenn im System gerade viel passiert.

[Homoran]

@OliverIO sagte:

Daher kann free sehr niedrig sein, während available höher liegen kann.

So weit die Theorie!

Wenn die load sich veränderte, änderte sich das memAvailable nahezu gar nicht, während das memFree sehr schnell von fast 2GB auf fast 0 und zurück schwankte, in deutlicher Korrelation mit dem CPU Takt.

Ich komme langsam immer mehr zu der Überzeugung dass die Ursache in der (geänderten) Speicherverwaltung des OS zu suchen sein wird.

Es konnte auch durchaus eine Load kurzzeitig um die 20 liegen, ohne dass iobroker abgestürzt ist solange ausreichend memFree vorhanden war.
memAivalable lag immer über 2GB.

@OliverIO sagte:

top
Auf der Shell.
Da siehst du auch wie schnell teilweise das hoch und runtergeht, wenn im System gerade viel passiert.

Aber nicht so schnell und so stark wie unter system.host..load

Ich hab mittlerweile Stunden vor den gauges gesessen und versucht Zusammenhänge zu erkennen

[paul53]

@Homoran [sagte]:
endlich auf der SSD

Wie groß sind SSD und SD-Card?
Worauf läuft die (open)CCU?