Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[Samson71]

@humidor
Alles gut. Ich kann Dich verstehen, bzw. habe Dich verstanden. Ich wollte halt nur die "Empfehlung" geben, statt einen zusätzlichen Slave an die Installation zu nageln, eine ganz andere Basis als "Komplettsystem" auszuprobieren. Ich habe z.B. vor kurzem auf einen Lenovo M920q Tiny (6-Kerner mit 32GB und 512GB SSD) mit Proxmox umgestellt und absolut keine Performance Probleme. Da läuft u.a. ioBroker als LXC, neben Wireguard, PiHole und Co und es ist immer noch Luft nach oben.

[Humidor]

@samson71 kein Problem! ich sehe die Syno hier als mind. gleichwertig an. Daran wirds nicht liegen. Woran dann, der ioB läuft im Docker und lastet den Container zu 100-200% aus, die Syno selbst rappelt um 20%. Da ist mM der Hund begraben.
Dennoch, es gibt doch so Linux Befehle mit der man die Auslastung analysieren kann, ich habe nur leider kA von Linux.

[lesiflo]

@humidor Schau mal auf linux mit z.B. "htop" oder "top" wenn installiert ist. Kannst du aber mit

sudo apt install htop

nachinstallieren

[Humidor]

@lesiflo danke!

[Humidor]

@humidor das ist der Rasp3B+ mit nur einem Adapter

[Marc Berg]

@humidor

Ich würde fast darauf wetten, dass du dir in deinen vielen MQTT Instanzen irgendwo eine Schleife reingebaut hast. (wenn ich mich richtig erinnere, hast du in deinen Victrons noch weitere Broker und Clients am Laufen?)
Das Ganze wird dann wohl auch noch fleißig vom History-Adapter mitgeloggt, und schon hast du ein System, das vorrangig mit sich selbst beschäftigt ist.

[lesiflo]

@humidor Ich würde mal nacheinander den history, web und javascript Adapter aus und einschalten und schauen was passiert. Schon mal "iob fix" laufen lassen?

[Humidor]

@lesiflo iob fix frisst er mir grad nicht im Docker Terminal, muss da zuerst alle Adapter stoppen

History habe ich bei den Mqtt noch nicht am laufen, ja das mit Mqtt ist ein Thema, ich kapier das anscheinend nicht richtig. 1 Broker(andere Dinge), 3 Slaves zu Victron Cerbos bwz. 1 Raspi.
Node Red läuft nicht (mehr) am ioB nur auf den Victron Cerbos. Per Blockly starte ich das zykl. subscribe von Allem (system #), dann schreibe ich auf 5 Werte, mehr ist da nicht.
Aber ob da eine Schleife drin ist, kA ?

top wirft aber die mqtt gar nicht als die Fresser aus, history scheint mir da ganz vorne
da werden Werte gesichert, auch in influxdb.

[Humidor]

hab mal jetzt einige Adapter gestoppt, mit top schaut das für mich normal aus?

die docker auslastung hat sich von 100 auf 40% reduziert, allerdings noch diese spikes

ohne mqtt Adapter:

ohne mqtt hat sich der docker beruhigt

sobald ich irgendwas im iob mache, adaper starte, schießt mir die Aulastung hoch, OK für einen Startmoment ja kein Problem, aber ist hier einfach ein Flaschenhals irgenwo drin?

[lesiflo]

@humidor Dann tippe ich mal auf mqtt. Schon mal alles außer mqtt aktiviert? Für was nutzt du mqtt?
Ich würde auch mal im iobroker den Log-Level für mqtt auf "info" setzen. Dann kannst du eventuell sehen was
die Last erzeugt. Normal ist aber aber "error" damit er nur die Fehler ausgibt.

[lesiflo]

@Humidor Den "iob fix" würde ich trotzdem mal laufen lassen. Ist dein System auf dem neuesten Stand?

[Humidor]

@lesiflo anhand der grafen und der testreihenfolge, sehe ich nicht das große Problem bei mqtt, nur die sparkes.

iob fix kann ich im docker nicht anwenden, dazu muss iob stop sein, das geht aber nicht, dann habe ich kein Terminal, ist ja kein raspi odgl.

wie gesagt, mqtt.0 Broker zu div. Endgeräten, Wallboxen usw.
mqtt.1-3 zu den Victron Cerbo Brokern

ich werde mal nur den mqtt.0 anwerfen und alle anderen Adapter mal sehen.

[Humidor]

@humidor das ist jetzt mit allen notwendigen Adaptern, ohne History und mqtt

[Humidor]

@humidor das jetzt mit History, ohne mqtt

[Humidor]

@humidor das jetzt mit mqtt.0 Broker

im log sehe ich keine Auffälligkeiten

[Humidor]

die Auslastung bleibt im Rahmen, es spitzt sich nun doch zu auf die mqtt Clients...

die history scheint aber den iob gut zu beanspruchen....
wenn ich schon die influxdb habe, macht mir dann history noch sinn, ich habe mich mit influx und grafana noch nicht groß beschäftigt, sehe ich als Zufunkt und deswegen logge ich schon in die influx
auf der history hängen die E-Charts und solches VIS Zeugs drauf
history und javascripts haben die meisten Ereignisse (über 2000)

ohne history fällt es gleich wieder ab

[Humidor]

mit allen mqtt, ohne history
der spark wird durch einnen client verursacht, denke ich mal, da gibts was zu tun
der letzte Berg vor dem spark war das Starten der adapter

[Humidor]

auf mqtt Client kommt sowas daher, kA was das sein soll, diese Einträge werden im Objektbaum auch nicht erzeugt, sind das die Sparks?

[lesiflo]

history und influxdb macht keinen Sinn. Beides dient zum Archivieren von Daten. Ich würde history rausschmeißen und nur noch die influxdb nutzen. Hatte bis vor kurzem die gleiche Kombination und history entfernt. Nutze jetzt nur noch influxdb mit grafana.

Stand mqtt schon auf "info"? Wenn ja wieder auf "error" setzen. Die ständigen Meldungen von mqtt belasten das System auch schon. Ich würde beim go-echarger aber auf den go-e Adapter statt mqtt setzen. Der schickt ja so alle paar Sekunden Meldungen an den iobroker.

Bei mqtt ist das so, das der Client ständig Daten an den iobroker sendet. Das kann mitunter schon mal etwas zu viel werden.

Hast du dich schon mal wegen Speicher, Wallbox und PV mit "OpenWB" beschäftigt. Hier mal ein Link auf meinen Beitrag dazu: https://forum.iobroker.net/topic/43655/wallbox-pv-mit-openwb-in-iobroker-einbinden
Gibt für den go-eCharger und Victron auch Module in openWB.
Dann brauchst du auch deine vielen mqtt-Instanzen nicht mehr. Reicht bei PV und Wallbox nur noch eine für openWB.

[Humidor]

@lesiflo danke für die Info, ja so sehe ich das jetzt auch, die History hat im Prinzip ausgedient, allerdings muss ich da mit influx und grafana erst per DU sein, sonst sind alle meine schönen Anzeigen im VIS tot.

habe alle mqtt adaper auf error gestellt, scheint tatsächlich schon was zu bringen

beim go-e steuere ich über mqtt die Ladung