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

[Ro75]

Das ist doch nur ein Ausschnitt?
Ro75.

[guitardoc]

Bei mir gibts dann nur noch Username, Client-ID und Passwort. Mehr Einstellungen hab ich nicht?

[crunchip]

@guitardoc sagte:

Dort sind knapp 350000 Objekte drin.

sollte doch eigentlich ne Meldung direkt vom Controller kommen, dass das Limit überschritten ist

[guitardoc]

Nein, hab leider keine Nachricht bekommen.
Der Viessmann-Adapter hat das System mit Objekten zugemüllt, und zwar hat der jedesmal, wenn ein Fehler in der WP aufgetreten ist, einen kompletten neuen Objektbaum mit allen Fehlerdetails angelegt.
Bei mir war es der Fehler 2c in der WP, zu welchem Viessmann geschrieben hatte, dass dieser Fehler ignoriert werden kann und bei der nächsten Wartung durch einen Monteur zurück gesetzt werden kann. Der Fehler trat quasi im Stundentakt seit Anfang des Jahres auf, da kamen einige Objekte zusammen. Mittlerweile wer der Monteur da, der Fehler tritt nicht mehr auf, aber ich hatte knapp 350000 Objekte mit diesem Fehler im ioB.

[guitardoc]

Jetzt ist die Staubsaugerattacke auch beendet. Zum Glück... Danke für die Hilfe an alle - ich hätte das Problem alleine nie gefunden.

[OliverIO]

@guitardoc sagte:

Egal ob der Zigbee-Adapter aktiv oder deaktiviert ist, beim ioB-Controller schwankt die CPU-Auslastung zwischen 2% und 160% in regelmäßigen Abständen von ca. 15 Sekunden. Manchmal länger, manchmal kürzer.

Bei den Nachrichten wird es interessant. Da haben wir abweichend von 11 schwankende Werte bei:

• Hydrawise 14-38
• Javascript 37-44
• Logparser 12-14
• Modbus 106-261
• MQTT 21-34
• Shelly 50-235
• Sonoff 30-35
• Tuya 33-185
• Web 19-26

Dann ist mir aufgefallen, dass immer mal wieder die meisten Instanzen rot sind und nach ein paar Sekunden wieder grün. Erst dachte ich, es ist nur ein Darstellungsfehler, aber in der Rot-Zeit stehen auch die Nachrichten auf 0.

Keine Ahnung was das alles bedeutet?

Das sind die Anzahl der Nachrichten, die der Adapter zum io Roger oder umgekehrt schickt. Also mehr oder weniger. Wie viel States werden tatsächlich pro Sekunde geschrieben oder gelesen.

Angefangen mit den hohen Werten könntest du jetzt der Reihe nach Adapter pausieren und schauen, ob sich das auf die Auslastung des Brokers auswirkt.
Wenn ja, hast du den Adapter gefunden, der viel Last auf den Rechner ausübt und wahrscheinlich den Engpass zum Schreiben nach inFlux auslöst

[ticaki]

1. Hast du den javascript adapter mal ausgeschaltet.
2. zeig mal das hier:
   
   der i-o delay vom host - hat bei mir schon für manch nerviges "wtf" gesorgt.

Als 3. Frage ich mich ob jsonl tatsächlich mit so einer Anzahl an States klar kommt - das weiß ich aber nicht. Auf jeden Fall steht im diagnose teil, das da was nicht geantwortet hat:

No connection to databases possible ...

205M	/opt/iobroker/iobroker-data/objects.jsonl
84M	/opt/iobroker/iobroker-data/states.jsonl

Dazu soll aber bitte @thomas-braun was sagen

[Homoran]

@ticaki
@oliverio

Soweit ich das gesehen habe ist das Problem gelöst:

@guitardoc sagte:

Der Viessmann-Adapter hat das System mit Objekten zugemüllt,

#28/29

[guitardoc]

Ja, das Problem ist gelöst, es war der Viessmann-Adapter.

Allerdings fängt der Adapter wieder an, permanent irgendwelche Messages zu sammeln. Aber das ist ein Thema für einen separaten Thread.

Ebenso auch die Frage, ob ich an dem Mountpoint was ändern sollte oder nicht. Werde mal einen separaten Thread dazu aufmachen.

[ticaki]

@guitardoc sagte:
Ich möchte wirklich mal wissen, wie es Viessmann geschafft hat, mir 350000 Objekte zu verpassen. Das ist ja wirklich der Hammer.

Bei der Entwicklung von espresense hatte ich in 24h 90000 objecte mehr auf meinem system - dann hab ich nen filter eingebaut :)
Bei weather warnings hatte ich nen state mit einer history drin, sobald der angezeigt wurde ist der Admin eingefroren

geht alles :)