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

[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

[lesiflo]

@humidor sagte in ioB auf mehrere Installationen verteilen?:

influx und grafana erst per DU sein, sonst sind alle meine schönen Anzeigen im VIS tot.

Die kannst du weiterhin nutzen. Musst dann nur die Datenquelle von history auf influxdb stellen.

[Humidor]

@lesiflo stimmt, muss ich mir ansehen

es hoppelt so dahin

die subscribes laufen alle 60s, das könnte so ein Indiz sein
allerdings werden bei mqtt (resourcen schonend?) nur geänderte topics gesendet und diese sind dann fortlaufend am akutalisieren

[lesiflo]

@humidor sagte in ioB auf mehrere Installationen verteilen?:

beim go-e steuere ich über mqtt die Ladung

Das mach bei mir fast komplett die openWB Software.

[Humidor]

@lesiflo ja, ist auch gut so wenn es fkt., bei mir fkt. das nicht. ist aber nicht das thema hier.

es hat sich in einem Maß nun eingebremst, das soweit mM akzeptabel ist, was meint ihr?

kann man alle adapter auf error stellen, oder muss man das bei jedem einzelnen durchklicken?

[Humidor]

ohne history und alle adapter auf error sind es jetzt durchgängig 50% auslastung mit peaks

ich überlege doch die ganzen modbus, mqtt in ein multihost zu packen, dass die Bedienung und VIS einfach wieder schneller laufen, bzw. das Smart-Home nicht ausgebremst wird. noch keinen Plan wie man das genau macht.

[warp735]

@humidor
Versteh nicht, was das bringen soll? Wenn die Syno nur idelt, dann weise dem Docker mehr Schmackes zu und fertig.

[ubecker]

@humidor bei mir läuft iob auch auf einer Sysology DS920+
mit mqtt und history laufen bei mir nur 12 Instanzen.
Das ist meine Auslastung.
Die erste Spitze ist Start iob WebUI, die zweite Spize ist Start VIS1.

nur mal zur Info

[Samson71]

@warp735 sagte in ioB auf mehrere Installationen verteilen?:

Versteh nicht, was das bringen soll?

Genau gar nichts, solange er nicht den Hinweisen nachgeht, die ihm z.B. @Marc-Berg in Post 17 gegeben hat und seine MQTT Daten in Ordnung bringt. In Post 29 postet er einen Screenshot eines Logs (Log in Code Tags wäre da besser gewesen), in dem ihm der Hinweis auf zu lange Topics gegeben wird.