MQTT Daten einschränken == weniger Traffic

[schwatter]

Tag,

es wäre toll, wenn ich die Daten die von OpenDTU-OnBattery per MQTT versendet werden einschränken könnte.
Entweder alles oder nur die wichtigsten Daten pro Wechselrichter jeweils separat saldiert. Ohne einzelne Panels.
Bin auf einer älteren Version von OpenDTU-OnBattery die ca. 1/2 bis 1 Jahr alt ist.
Hatte bis eben einen zu hohen Intervall auf 5sek.
Gibt es bei neueren Versionen schon so etwas wie Daten einschränken? Oder bei einem Fork was ich testen kann?

Grund:
Mein Broker hat zu kämpfen. Daher möchte ich insgesamt schauen wo ich Traffic reduzieren kann.

Gruß

[NinjaEde]

Klingt für mich nach zu schwacher Hardware und bin der Ansicht, dass weniger payload dein Problem nicht beheben würde.
Wenn du Hardware-Probleme hast, dann solltest du die Hardware-seitig lösen.
Welcher MQTT-Broker hast du denn am Laufen und auf welcher Hardware?

[schwatter]

Mh, dem wieder spreche ich erstmal. Unabhängig von meiner Hardware.
Im Moment habe ich 3 Wechselrichter mit mit 192 Topics. Jeder Wechselrichter hat 57 Topics.
OnBattery kann 5 Stück? Dann wären das nochmal + 114. Sind in Summe 306. Und das nur,
wenn Wechselrichter ausgelesen werden ohne die Extras. Wenn da ein Intervall von 5 sek. gesetzt wird,
dann flutet das doch ganz schön den Broker. Unabhängig welcher.

Ich selber nutze den internen Broker von Fhem. Und ja, der ist nicht Highend.
Mein Fhem hängt in Proxmox und idelt bei 4 bis kurz 11% mit allen Topics von OnBattery Intervall 15sek.
Daran hängen Shellys, zigbee2mqtt, 2 x Valetudo, Tasmota, WLED und noch nen paar. Das funktioniert tadelos,
bis ich anfange zu fluten. Egal von wo. Retrain habe ich generell aus. Egal ob Sender, Broker oder Empfänger.

Also mein Verständnis ist, der Broker ist erstmal gezwungen, alles anzunehmen was er bekommt. Ungefragt.
Und ungewollte Infos werden immer erst an der Quelle eingedämmt. Nicht am Ende. Oder wie seht ihr das?

Gruß

[spcqike]

Und ungewollte Infos werden immer erst an der Quelle eingedämmt. Nicht am Ende. Oder wie seht ihr das?

sehe ich anders.

Bei wie vielen Geräten kannst du denn die publish topics einstellen? Bei shellys geht das bspw. Auch nicht. Und davon hab ich einige zu Hause, die alles mögliche senden.

Man filtert halt am Ende beim verarbeitenden System.

Ich fände es nur ganz nett, wenn man die payloads in einem topic zusammen senden könnte. Also in nem passenden JSON. Wie es bei tasmota bspw ist. Aber ich denke das ist Geschmacks Sache. Ob das am Ende einen Vorteil hat zwecks weniger overhead oder so, weiß icu bei MQTT nicht. Bei http wäre es sicher etwas performanter.

[NinjaEde]

Also ich hab 3 WR am Laufen und auch sonst ballert einiges an anderen Geräten in meine Mosquitto MQTT queue. Tasmotas hab ich nicht.

Ich selber nutze den internen Broker von Fhem. Und ja, der ist nicht Highend. Mein Fhem hängt in Proxmox und idelt bei 4 bis kurz 11% mit allen Topics von OnBattery Intervall 15sek. Daran hängen Shellys, zigbee2mqtt, 2 x Valetudo, Tasmota, WLED und noch nen paar. Das funktioniert tadelos, bis ich anfange zu fluten. Egal von wo. Retrain habe ich generell aus. Egal ob Sender, Broker oder Empfänger.

Hier schreibt auch ein User, dass er den FHEM MQTT nutzt und mit Tasmota immense Probleme hat. Er machte die Tasmotas als Ursache aus und stieg dann auf Mosquitto um - und seine Probleme waren Geschichte.
https://community.simon42.com/t/tasmota-loest-ueberlastung-des-mqtt-brokers-aus/28751

Setz doch auch mal einen Mosquitto auf und teste, ob du damit auch die Probleme hast. Oder du schaltest mal alle anderen Topics, in die du sonst noch via MQTT so rein schreibst, ab, um das Problem isolieren zu können.
Hast du das schon mal versucht?

[schwatter]

Topics werde ich im Subscriber trotzdem mal reduzieren. Vielleicht gibt es auch noch eine Wechselwirkung intern zwischen den 2 Modulen
bei mir in Fhem.

Gruß