CPU-Last MQTT_GENERIC_BRIDGE

Begonnen von FunkOdyssey, 29 Oktober 2020, 16:30:43

Vorheriges Thema - Nächstes Thema

FunkOdyssey

Ich habe vor wenigen Tagen eine MQTT_GENERIC_BRIDGE angelegt.
Heute fiel mir auf, dass die CPU-Last dadurch sehr hoch gegangen ist.

defmod mqttGenBridge MQTT_GENERIC_BRIDGE
attr mqttGenBridge IODev mqtt2Server
attr mqttGenBridge globalPublish *:topic={"fhem/$device/$reading"}


Noch schlimmer wurde es mit:

attr globalDefaults sub:qos=2 pub:qos=0 retain=1

Ist das normal?

Das IODev mqtt2Server ist FHEM selbst.

Beta-User

Na ja, wenn du alle Reading/Aktualisierungen pauschal raushaust und dann den Server auch noch zwingst, darüber nachzudenken, ob er intern die Infos ggf. weiterreichen muß, kann das ggf. in größeren Installationen schon zu einer deutlichen Mehrbelastung führen.

Tendenziell würde ich meinen, dass insbesondere das "gobalPublish" keine gute Idee ist. Siehe dazu auch ab hier: https://forum.fhem.de/index.php/topic,109192.msg1096411.html#msg1096411.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

FunkOdyssey

Danke für deine Hilfe.
Ich fange an, MQTT zu verstehen.  :D

Beta-User

Danke für die Rückmeldung. Hatte schon die Befürchtung, dass das (v.a. für einen FHEM-Neuling wie den "Freibeuter" in dem anderen Thread) nur sehr schwer zu verstehen ist, weil man schon irgendeine Vorstellung von der Verarbeitung von Events in FHEM haben muß, um den Datenverarbeitungsfluss nachvollziehen zu können.
Und das mit den (ignore|bridge)Regexp-Ausdrücken ist auch nicht so easy... (Hatte die Hoffnung, dass das dann auch andere interessierte User lesen und ggf. dann weitergeben würden, daher ist das dort ziemlich ausführlich geworden).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

FunkOdyssey

Ehrlich gesagt habe ich mich auch gefragt, warum mir das nicht selber klar geworden ist.
Ich habe QOS bereits ausgeklammert und hier einen Rückgang der CPU-Last festgestellt.
Ich hatte, obwohl der Name es eigentlich erklären sollte, den Sinn des Attributs globalPublish nicht verstanden.
Alles Events per MQTT zu veröffentlichen war nie mein Intention. Ich habe mich auch schon über die Counter im Device gewundert.  Ich hätte es merken müssen.  :D

Beta-User

Na ja, ist doch häufiger so: Man richtet was ein und ist dann froh und glücklich, dass es funktioniert. Und wenn man dafür irgendwo eine Anleitung von einem "Trainer" (oder anderem vermeintlich "Wissenden") gefunden hat, geht man eben erst mal davon aus, dass das alles seine Richtigkeit hat - häufig eben ohne die Details zu beachten.

Dass das dann ggf. doch (für den eigenen Anwendungfall) nicht das Gelbe vom Ei ist, merkt man entweder nie oder eben erst dann, wenn man sich nochmal intensiv mit der Sache beschäftigt. Geht mir auch immer mal wieder so...

Und gerade wegen MQTT (ganz ohne MGB) habe ich den Eindruck, dass sich die Zahl der Events und Readings deutlich erhöht hat; mich wundert sehr, wieviel die betreffenden Geräte teils so senden (Shelly & Tasmota vorneweg), ohne dass sich unsere User hier große Gedanken dazu machen, ob und wann das sinnvoll ist. Wenn es jemand merkt, kommt dann das "eocr .*"-Totschlag-Ding zur Anwendung (über das man sich auch noch nie intensiver Gedanken gemacht hat)...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files