mosquitto als MQTT2 Server

[rudolfkoenig]

Wenn man im Log vom Unhandled Meldung rueckwaerts nach dem letzten "richtigen" Datensatz vom gleichen Client sucht, findet man sowas wie:

(239)(2)(0)(23)stat/TA_ESP0128/STATUS1{"StatusPRM":{"Baudrate":115200,"SerialConfig":"8N1","GroupTopic":"tasmotas","OtaUrl":"http://ota.tasmota.com/tasmota/release/tasmota.bin","RestartReason":"E0(250)(1)(0)(23)stat/TA_ESP0128/STATUS5{"StatusNET":{"Hostname":"TA_ESP0128-7003","IPAddress":"192.168.6.105","Gateway":"192.168.0.31","Subnetmask":"255.255.240.0","DNSServer":"192.168.0.31","Mac"

Auffallend ist der Muell mitten im Message, nach "RestartReason", das sind die Zeichen im Klammern, die nicht ASCII Zeichen darstellen. Dass die Meldung abgeschnitten ist, ist nur noch ein Nebeneffekt.

Laeuft der MQTT2_SERVER mit SSL?

Wenn nicht, dann kann ich nur einen Fehler im Client-Code vorstellen: evtl. greift im Tasmotas TCP-Implementation  (oder eins drueber) Flowcontrol nicht, und dein FHEM-Server ist gleichzeitig ueberlastet. Apropos: dafuer habe ich noch keine Zahlen bekommen!

Falls(!) diese Theorie stimmt, dann wuerde ein externer MQTT Server (ob MQTT2_SERVER oder mosquitto egal) und Umstieg auf MQTT2_CLIENT das Problem entschaerfen. FHEM puffert zusaetzlich zum Kernel-TCP-Puffer pro Verbindung bis zu 1MB. Wie gross dieser Puffer bei Mosquitto ist, weiss ich nicht. Die bessere Loesung waere den FHEM-Server zu entlasten, entweder durch mehr Hardware, oder (besser) durch weniger MQTT-Verkehr.

Apropos Kernel Puffer: wieviel Speicher hat der Rechner, und was sagt:

Code Auswählen Erweitern

cat /proc/sys/net/ipv4/tcp_mem
cat /proc/sys/net/core/rmem_max


[riker1]

Hallo Rudi,

danke für deine Bemühungen.

Code Auswählen Erweitern

cat /proc/sys/net/ipv4/tcp_mem
39189   52254   78378

cat /proc/sys/net/core/rmem_max
212992

der MQTT2_Server läuft ohne SSL


bezüglich:

nn wuerde ein externer MQTT Server (ob MQTT2_SERVER oder mosquitto egal) und

du meinst eine eigene FHEM Instanz auf einem anderen Server mit quasi nur MQTT2_Server als Broke?  Hänge nicht an Mosquitto.
das wäre auch am einfachsten da ich die MQTT_Devices einfach weiter verwenden kann.


Bezüglich CPU Auslastung: . Welche Informationen benötigst du da genau?

Code Auswählen Erweitern

vmstat 10
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
4  0      0 509768 153836 1400324    0    0    28    20   83   67 28  1 69  2  0
0  1      0 509764 153848 1400360    0    0     0    48 1031 1275 44  2 52  1  0
1  0      0 401708 153852 1400376    0    0     0    34 1011 1344 25  1 73  1  0
0  0      0 339536 153856 1400404    0    0     0    43  990 1274 33  4 62  1  0
0  0      0 509388 153860 1400420    0    0     0    18 1009 1331 21  2 76  1  0


htop als Bild im Anhang.

Habe ja noch den Mediaserver von Logitech da drauf laufen...kann ich auch mal wegmachen.

Dann scheint mir manchmal der telegram Bot auch can not fork  issues zu liefern.

Aber so  wie es aussieht ist es scheinbar ein Performance Problem habe ich verstanden.

Schönen Abend

VG T

[rudolfkoenig]

Laut top braucht FHEM gar nichts (0.0 CPU%), womit meine Theorie ad-acta gelegt werden kann.
Es sei denn, du hast den falschen Zeitpunkt erwischt.

du meinst eine eigene FHEM Instanz auf einem anderen Server mit quasi nur MQTT2_Server als Broke?  Hänge nicht an Mosquitto. das wäre auch am einfachsten da ich die MQTT_Devices einfach weiter verwenden kann.

Der MQTT2_Server sollte nicht mit autocreate laufen (um keine Last zu erzeugen), und auch aus anderen Gruenden wuerde ich einen anderen Server (wie mosquitto) vorziehen.

Die MQTT2_DEVICEs kannst du alle behalten bloss das IODev (jetzt ein MQTT2_SERVER) muss gegen eine neue MQTT2_CLIENT Definition ausgetauscht werden.
Falls die readingList Attribute ein ClientID enthalten, dann muessen entweder diese IDs aus dem readingList geloescht werden, oder ein bridgeRegexp Attribut muss gesetzt werden, was aus den Topics die alten ClientIDs berechnet.

[riker1]

Laut top braucht FHEM gar nichts (0.0 CPU%), womit meine Theorie ad-acta gelegt werden kann.
Es sei denn, du hast den falschen Zeitpunkt erwischt....

Hi Rudi,

...falscher Zeitpunkt. Fhem läuft schon mit viel Last

laufende Peaks.

Code Auswählen Erweitern

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
14114 fhem      20   0  646792 549580   8788 R 100.0 15.7 814:43.53 perl
18584 fhem      20   0  646792 543848   3056 S   1.0 15.5   0:00.06 perl
18586 fhem      20   0   15104   1192   1088 S   1.0  0.0   0:00.03 ping
18587 fhem      20   0   15104   1144   1036 S   1.0  0.0   0:00.03 ping
18582 fhem      20   0  646792 543848   3056 S   0.7 15.5   0:00.05 perl
18581 fhem      20   0  646792 543848   3056 S   0.0 15.5   0:00.05 perl
18585 fhem      20   0   15104   1228   1124 S   0.0  0.0   0:00.03 ping

[rudolfkoenig]

Damit waere meine Theorie wieder im Rennen.
Laut Screenshot hat dein Rechner 3.3GB RAM, was noch nicht ausgeschoepft ist

Kannst Du bitte die Befehle aus https://wwwx.cs.unc.edu/~sparkst/howto/network_tuning.php (ganz unten) testen?
Wenn diese Puffer nur fuer die TCPClient <-> Linuxkernel Kommunikation relevant sind, dann werden sie nicht helfen, meine Hoffnung ist aber, dass sie auch fuer Linuxkernel <-> Userlevel (aka FHEM) eine Rolle spielen, dann sollte das die Probleme entschaerfen.

[rudolfkoenig]

Sind deine readingsList Attribute mit oder ohne ClientID?
Die Version ohne ClientID wird fuer MQTT2_CLIENT benoetigt, MQTT2_SERVER kann mit beiden umgehen.

Ich habe aus deinem letzten Log die Topics bei mir reingeladen: es sind 6127 Nachrichten aufgeteilt auf 29 Geraete.
Bei readingsList mit ClientID hat FHEM auf meinem Rechner 5.1 sec gebraucht, ohne ClientID 11.5sec.
In dieser Zeit wurde die "richtige" MQTT2_DEVICE Instanz gefunden, das JSON geparst, 3970 Readings 70470 mal gesetzt und genausoviele Events generiert.
Es gab keine Abnehmer (notify/FileLog/etc) fuer diese Events.

Die "mit ClientID" Version war auch bisher optimiert, ich habe versucht die Version ohne ClientID jetzt auch zu optimieren, und bin jetzt in beiden Faellen auf 4.6sec gekommen. Voraussetzung ist, dass das Regexp im readingsList dem automatisch erzeugten Muster entspricht, also cid:topic:.* oder topic:.*.

Habe die neue Version eingecheckt, ich hoffe dass es keine Nebeneffekte hat. Wenn doch, bitte melden.

[riker1]

Sind deine readingsList Attribute mit oder ohne ClientID?
Die Version ohne ClientID wird fuer MQTT2_CLIENT benoetigt, MQTT2_SERVER kann mit beiden umgehen.

Ich habe aus deinem letzten Log die Topics bei mir reingeladen: es sind 6127 Nachrichten aufgeteilt auf 29 Geraete.
Bei readingsList mit ClientID hat FHEM auf meinem Rechner 5.1 sec gebraucht, ohne ClientID 11.5sec.
In dieser Zeit wurde die "richtige" MQTT2_DEVICE Instanz gefunden, das JSON geparst, 3970 Readings 70470 mal gesetzt und genausoviele Events generiert.
Es gab keine Abnehmer (notify/FileLog/etc) fuer diese Events.

Die "mit ClientID" Version war auch bisher optimiert, ich habe versucht die Version ohne ClientID jetzt auch zu optimieren, und bin jetzt in beiden Faellen auf 4.6sec gekommen. Voraussetzung ist, dass das Regexp im readingsList dem automatisch erzeugten Muster entspricht, also cid:topic:.* oder topic:.*.

Habe die neue Version eingecheckt, ich hoffe dass es keine Nebeneffekte hat. Wenn doch, bitte melden.

Hallo Rudi,

die readingslistattribute sind teilweise gemischt. Ist irgendwie historisch und durchs experimentieren entstanden.
Devices teilweise mit autocreate und speziellen Templates erstellt und dann auf andere kopiert.
Meist hatte ich die Client ID dann weggelassen wenn ich die readingslist für andere Devices kopiert hatte.

Über die Seiteneffekte war ich mir unklar, eigentlich immer noch .

Beispiel: Attr Readingslist:

Code Auswählen Erweitern

tele/TA_G2/LWT:.* LWT
tele/TA_G2/STATE:.* { json2nameValue($EVENT) }
tele/TA_G2/SENSOR:.* { json2nameValue($EVENT) }
tele/TA_G2/INFO.:.* { json2nameValue($EVENT) }
stat/TA_G2/RESULT:.* { json2nameValue($EVENT) }
tele/TA_G2/UPTIME:.* { json2nameValue($EVENT) }
tele/TA_G2/POWER:.* { json2nameValue($EVENT) }
stat/TA_G2/POWER:.* POWER
DVES_F466C9:cmnd/TA_G2/POWER:.* POWER
DVES_F466C9:stat/TA_G2/STATUS:.* { json2nameValue($EVENT, 'STATUS_', $JSONMAP) }
DVES_F466C9:stat/TA_G2/STATUS10:.* { json2nameValue($EVENT, 'STATUS10_', $JSONMAP) }
DVES_F466C9:stat/TA_G2/STATUS1:.* { json2nameValue($EVENT, 'STATUS1_', $JSONMAP) }
DVES_F466C9:stat/TA_G2/STATUS2:.* { json2nameValue($EVENT, 'STATUS2_', $JSONMAP) }
DVES_F466C9:stat/TA_G2/STATUS3:.* { json2nameValue($EVENT, 'STATUS3_', $JSONMAP) }
DVES_F466C9:stat/TA_G2/STATUS4:.* { json2nameValue($EVENT, 'STATUS4_', $JSONMAP) }
DVES_F466C9:stat/TA_G2/STATUS5:.* { json2nameValue($EVENT, 'STATUS5_', $JSONMAP) }
DVES_F466C9:stat/TA_G2/STATUS6:.* { json2nameValue($EVENT, 'STATUS6_', $JSONMAP) }
DVES_F466C9:stat/TA_G2/STATUS7:.* { json2nameValue($EVENT, 'STATUS7_', $JSONMAP) }
DVES_F466C9:stat/TA_G2/STATUS11:.* { json2nameValue($EVENT, 'STATUS11_', $JSONMAP) }
DVES_F466C9:stat/TA_G2/STATUS8:.* { json2nameValue($EVENT, 'STATUS8_', $JSONMAP) }
DVES_F466C9:stat/TA_G2/STATUS12:.* { json2nameValue($EVENT, 'STATUS12_', $JSONMAP) }
DVES_F466C9:stat/TA_G2/UPGRADE:.* { json2nameValue($EVENT, 'UPGRADE_', $JSONMAP) }
DVES_F466C9:stat/TA_G2/STATUS9:.* { json2nameValue($EVENT, 'STATUS9_', $JSONMAP) }



also sollte ich lieber überall die CID mit ranbauen?


Bzw. werde mal das Update machen und schauen. Wie kann ich das bei mir dann am Besten checken? Messen?

Es gab keine Abnehmer (notify/FileLog/etc) fuer diese Events.

das ist komisch, alle haben ein Filelog dran und auch notifys. Da ist aber überall verbose 0 dran an den Devices um die Last zu reduzieren.  Viele haben auch Plots dabei.

VG_bei dem_Shitwetter hier  T

[riker1]

Damit waere meine Theorie wieder im Rennen.
Laut Screenshot hat dein Rechner 3.3GB RAM, was noch nicht ausgeschoepft ist

Kannst Du bitte die Befehle aus https://wwwx.cs.unc.edu/~sparkst/howto/network_tuning.php (ganz unten) testen?
Wenn diese Puffer nur fuer die TCPClient <-> Linuxkernel Kommunikation relevant sind, dann werden sie nicht helfen, meine Hoffnung ist aber, dass sie auch fuer Linuxkernel <-> Userlevel (aka FHEM) eine Rolle spielen, dann sollte das die Probleme entschaerfen.

habe das mal alles eingegeben. Mache nochmal Debug mit Verbose 5 und schaue.

Danke für deine tolle Hilfe

VG T

[rudolfkoenig]

also sollte ich lieber überall die CID mit ranbauen?

Mit CID hat den Vorteil, dass FHEM mit MQTT2_SERVER bei mehreren Geraeten mit gleicher Topic-Voreinstellung (TASMOTA?) zurechtkommt, und bis "gestern" hat das auch weniger CPU gekostet.
Ohne CID hat den Vorteil, dass man einfach von MQTT2_SERVER zu MQTT2_CLIENT (== externer MQTT Server) und zurueck wechseln kann.
Gemischt vereint die Nachteile beider

Bzw. werde mal das Update machen und schauen. Wie kann ich das bei mir dann am Besten checken? Messen?

Habe keine Methode fuer Dich parat, womoeglich ist die CPU-Last unter 100%.

das ist komisch, alle haben ein Filelog dran und auch notifys.

Ich meinte mein Test-Setup, die Zeiten beziehen sich auch auf meinem Rechner.

[Beta-User]

@riker1: Kannst du mal bei den notify schauen, ob da viele mit "suboptimaler" DEF dabei sind:

Code Auswählen Erweitern

count TYPE=notify
count TYPE=notify:FILTER=NOTIFYDEV!~.+
list TYPE=notify:FILTER=NOTIFYDEV!~.+ DEF

@Rudi:
Danke für diese Optimierungsrunde.
Was ClientID angeht, bin ich immer noch der Überzeugung, dass das außerhalb von FHEM _in der Auswertung der Informationen_ praktisch nur auf Topic und Payload geschaut wird. Von daher ist das hilfreich (nicht nur, weil die meisten attrTemplate so gestrickt sind, sondern auch, weil das Wechseln der IO-Module sonst richtig schwierig wäre.).
Steige auch gleich mit Testen ein.

[rudolfkoenig]

außerhalb von FHEM _in der Auswertung der Informationen_ praktisch nur auf Topic und Payload geschaut wird.

Das haut mich jetzt nicht vom Hocker , da ClientID nur dem Server zur Verfuegung steht.

[riker1]

@riker1: Kannst du mal bei den notify schauen, ob da viele mit "suboptimaler" DEF dabei sind:

Code Auswählen Erweitern

count TYPE=notify
count TYPE=notify:FILTER=NOTIFYDEV!~.+
list TYPE=notify:FILTER=NOTIFYDEV!~.+ DEF

Hi Betauser,
hier mal die Zählungen.



Count: 403 devices for devspec TYPE=notify:FILTER=state=active

count TYPE=notify:FILTER=NOTIFYDEV!~.+

Count: 136 devices for devspec TYPE=notify:FILTER=state=active:FILTER=NOTIFYDEV!~.+

list TYPE=notify:FILTER=NOTIFYDEV!~.+ DEF

also alle definitionen sind jetzt ziemlich viele.
wonach soll ich hier suchen um es einzuschränken?

VG T

[riker1]

Mit CID hat den Vorteil, dass FHEM mit MQTT2_SERVER bei mehreren Geraeten mit gleicher Topic-Voreinstellung (TASMOTA?) zurechtkommt, und bis "gestern" hat das auch weniger CPU gekostet.
Ohne CID hat den Vorteil, dass man einfach von MQTT2_SERVER zu MQTT2_CLIENT (== externer MQTT Server) und zurueck wechseln kann.
Gemischt vereint die Nachteile beider
...

Hi Rudi,
werde mal die Client IDs rausnehmen:-)

Deswegen haben die Devices auch nicht funktioniert mit dem MQTT_Client.

[Beta-User]

Na ja, die Zählung hat einfach ergeben, dass du ziemlich viele nicht opimierte notify hast (das gilt für andere Eventhandler genauso, btw.).

Du kannst ja mal eines nehmen und dir die regexp ansehen und dann mal versuchen, das zu verbessern. Ist zwar ein Aufwand, aber das könnte sich lohnen.
Es gibt dazu eine Funktion, da wirft man einfach seine regexp rein und sieht, ob die in allen Teilen "ok" ist (oder eben nicht):

Code Auswählen Erweitern

{ notifyRegexpCheck('[DF].*enster_.*:.*|.+tuer_.+:.*') }

Falls dazu Fragen sind, würde ich empfehlen, im Anfängerbereich einen eigenen Thread dazu aufzumachen; das interessiert sicher noch mehr Leute.

Außerdem vermute ich, dass deine "eocr"-Attribute bei den Tasmotas nicht optimal sind und dazu oft Events generiert werden, obwohl sich der Status nicht ändert, sondern nur der Zeitstempel.

Das haut mich jetzt nicht vom Hocker , da ClientID nur dem Server zur Verfuegung steht.

Ebend. Wollte auch nur sagen, dass nach meinem Eindruck das ClientID-Thema zwar ein Vorteil von M2Server ist, aber eben zweischneidig, da "nicht allgemeingültig" für MQTT an sich. (wir brauchen das nicht zu vertiefen ).

[riker1]

dass deine "eocr"-Attribute bei den Tasmotas nicht optimal

Hallo Beta-User,

was ist das denn?

Cool die Regex-check kannte ich noch nicht.