mosquitto als MQTT2 Server

Beta-User · 12 Dezember 2020, 18:19:08

event-on-.* bzw. timestamp-on-irgendwas.Empfehle den Shelly-Beitrag im "MQTT-workshop" als Einstieg.

LuckyDay · 13 Dezember 2020, 01:02:08

Rudi, nur zur Info
deine heutige änderung ist bei mir fast ein Geschindigkeitsfaktor von 10!
ca 3 ms pro Nachricht, jetzt seit heute

muss mal wieder danke sagen

Code Auswählen

2020.12.13 00:41:48.232 5: mqttclient_localhost: dispatch autocreate=no\000localhost\000/haus/Inet/Proplantana/fc1_wind06\00010.8
2020.12.13 00:41:48.232 5: mqttclient_localhost: received PUBLISH (0)!/haus/Inet/Proplantana/fc1_wind0610.8
2020.12.13 00:41:48.230 5: mqttclient_localhost: dispatch autocreate=no\000localhost\000/haus/Inet/Proplantana/fc3_weather15\000Nebel
2020.12.13 00:41:48.230 5: mqttclient_localhost: received PUBLISH (0)$/haus/Inet/Proplantana/fc3_weather15Nebel
2020.12.13 00:41:48.228 5: mqttclient_localhost: dispatch autocreate=no\000localhost\000/haus/Inet/Proplantana/fc3_chOfRain09\0005
2020.12.13 00:41:48.227 5: mqttclient_localhost: received PUBLISH (0)%/haus/Inet/Proplantana/fc3_chOfRain095
2020.12.13 00:41:48.225 5: mqttclient_localhost: dispatch autocreate=no\000localhost\000/haus/Inet/Proplantana/fc0_weatherDay\000Sprühregen
2020.12.13 00:41:48.225 5: mqttclient_localhost: received PUBLISH (0)%/haus/Inet/Proplantana/fc0_weatherDaySpr(195)(188)hregen

seither ca 28 ms pro Nachricht

Code Auswählen

2020.08.02 13:32:29.820 5: mqttclient_localhost: dispatch autocreate=no\000localhost\000/haus/Inet/Proplantana/fc3_wind03\0003.6
2020.08.02 13:32:29.819 5: mqttclient_localhost: received PUBLISH (0)!/haus/Inet/Proplantana/fc3_wind033.6
2020.08.02 13:32:29.793 5: mqttclient_localhost: dispatch autocreate=no\000localhost\000/haus/Inet/Proplantana/fc3_rain\0000
2020.08.02 13:32:29.793 5: mqttclient_localhost: received PUBLISH (0)(31)/haus/Inet/Proplantana/fc3_rain0
2020.08.02 13:32:29.766 5: mqttclient_localhost: dispatch autocreate=no\000localhost\000/haus/Inet/Proplantana/fc3_windDir09\000106
2020.08.02 13:32:29.766 5: mqttclient_localhost: received PUBLISH (0)$/haus/Inet/Proplantana/fc3_windDir09106
2020.08.02 13:32:29.739 5: mqttclient_localhost: dispatch autocreate=no\000localhost\000/haus/Inet/Proplantana/fc2_gust03\00018
2020.08.02 13:32:29.739 5: mqttclient_localhost: received PUBLISH (0)!/haus/Inet/Proplantana/fc2_gust0318

Code Auswählen

2020.12.12 00:05:35.330 1: Perfmon: possible freeze starting at 00:05:33, delay is 2.33
2020.12.12 00:05:32.649 1: Perfmon: possible freeze starting at 00:05:29, delay is 3.649
2020.12.11 22:05:32.031 1: Perfmon: possible freeze starting at 22:05:29, delay is 3.031
2020.12.11 16:05:32.077 1: Perfmon: possible freeze starting at 16:05:29, delay is 3.077
2020.12.11 11:05:32.931 1: Perfmon: possible freeze starting at 11:05:30, delay is 2.931
2020.12.11 00:05:37.622 1: Perfmon: possible freeze starting at 00:05:34, delay is 3.622

und hoffe das diese delays Geschichte sind.
bei Tageswechsel hilft auch kein eocr

riker1 · 13 Dezember 2020, 10:54:42

Hallo Rui,

hier noch paar Logs falls Interesse.

Habe nochmal die gleichen Fehler.

also beospielsweise TA_G4 war die ganze zeit per wlan erreichbar . WEBUI Console war aktive
IP:192.168.1.166

Habe auch TA_G$ restarted wia Webgui

gleiches gilt für TA_PIR_KTM war die ganze Zeit per wlan erreichbar . WEBUI Console war aktive
IP /192.168.6.109/

auch kein Reconnect nach neustart von FHEM.

habe auch versucht MQTT command mit MQTT_SPY an das Device abzusetzen. Da es aber nicht verbunden war keine Reaktion.
MQTT2_Server erkennt zwh100ltw10 als MQTT Client.

Code Auswählen

2020.12.13 07:51:57.616 5: MQTT2_TR_UB9: dispatch autocreate=no\000zwh100ltw10\000cmnd/TA_G4/STATUS\0001

Grundsätzlichhabe die ganzen Client IDs bei den ReadingsList rausgenommen.

Nach mehrmehilgen Restart von FHEM haben sich die Devices dann besser verbunden.

VG T

Grep TA_G4

Code Auswählen


Last login: Sun Dec 13 06:34:36 2020 from 192.168.0.26
2020.12.13 07:48:32.628 5: MQTT2_TR_UB9: dispatch autocreate=no\000DVES_F3F8D6\000tele/TA_G4/LWT\000Offline
2020.12.13 07:49:05.480 5: in:  CONNECT: (16)F(0)(4)MQTT(4)(238)(0)(30)(0)(11)DVES_F3F8D6(0)(14)tele/TA_G4/LWT(0)(7)Offline(0)(9)DVES_USER(0)(9)DVES_PASS
2020.12.13 07:49:05.480 4:   MQTT2_TR_UB9_192.168.1.166_52444 cid:DVES_F3F8D6 CONNECT V:4 keepAlive:30 LWT:tele/TA_G4/LWT:Offline usr:DVES_USER
2020.12.13 07:49:06.368 5:   MQTT2_TR_UB9_192.168.0.26_65191 zwh100ltw10 => tele/TA_G4/LWT:Offline
2020.12.13 07:49:06.368 5: out: PUBLISH: 0(23)(0)(14)tele/TA_G4/LWTOffline
2020.12.13 07:49:06.369 5: MQTT2_TR_UB9: dispatch autocreate=no\000DVES_F3F8D6\000tele/TA_G4/LWT\000Offline
2020.12.13 07:49:28.428 5: in:  CONNECT: (16)F(0)(4)MQTT(4)(238)(0)(30)(0)(11)DVES_F3F8D6(0)(14)tele/TA_G4/LWT(0)(7)Offline(0)(9)DVES_USER(0)(9)DVES_PASS
2020.12.13 07:49:28.428 4:   MQTT2_TR_UB9_192.168.1.166_65360 cid:DVES_F3F8D6 CONNECT V:4 keepAlive:30 LWT:tele/TA_G4/LWT:Offline usr:DVES_USER
2020.12.13 07:49:29.375 5:   MQTT2_TR_UB9_192.168.0.26_65191 zwh100ltw10 => tele/TA_G4/LWT:Offline
2020.12.13 07:49:29.375 5: out: PUBLISH: 0(23)(0)(14)tele/TA_G4/LWTOffline
2020.12.13 07:49:29.375 5: MQTT2_TR_UB9: dispatch autocreate=no\000DVES_F3F8D6\000tele/TA_G4/LWT\000Offline
2020.12.13 07:49:52.195 5: in:  CONNECT: (16)F(0)(4)MQTT(4)(238)(0)(30)(0)(11)DVES_F3F8D6(0)(14)tele/TA_G4/LWT(0)(7)Offline(0)(9)DVES_USER(0)(9)DVES_PASS
2020.12.13 07:49:52.196 4:   MQTT2_TR_UB9_192.168.1.166_53775 cid:DVES_F3F8D6 CONNECT V:4 keepAlive:30 LWT:tele/TA_G4/LWT:Offline usr:DVES_USER
2020.12.13 07:49:52.721 5:   MQTT2_TR_UB9_192.168.0.26_65191 zwh100ltw10 => tele/TA_G4/LWT:Offline
2020.12.13 07:49:52.721 5: out: PUBLISH: 0(23)(0)(14)tele/TA_G4/LWTOffline
2020.12.13 07:49:52.721 5: MQTT2_TR_UB9: dispatch autocreate=no\000DVES_F3F8D6\000tele/TA_G4/LWT\000Offline
2020.12.13 07:50:24.009 5: in:  CONNECT: (16)F(0)(4)MQTT(4)(238)(0)(30)(0)(11)DVES_F3F8D6(0)(14)tele/TA_G4/LWT(0)(7)Offline(0)(9)DVES_USER(0)(9)DVES_PASS
2020.12.13 07:50:24.010 4:   MQTT2_TR_UB9_192.168.1.166_62649 cid:DVES_F3F8D6 CONNECT V:4 keepAlive:30 LWT:tele/TA_G4/LWT:Offline usr:DVES_USER
2020.12.13 07:50:24.578 5:   MQTT2_TR_UB9_192.168.0.26_65191 zwh100ltw10 => tele/TA_G4/LWT:Offline
2020.12.13 07:50:24.578 5: out: PUBLISH: 0(23)(0)(14)tele/TA_G4/LWTOffline
2020.12.13 07:50:24.578 5: MQTT2_TR_UB9: dispatch autocreate=no\000DVES_F3F8D6\000tele/TA_G4/LWT\000Offline
2020.12.13 07:51:01.591 5: in:  CONNECT: (16)F(0)(4)MQTT(4)(238)(0)(30)(0)(11)DVES_F3F8D6(0)(14)tele/TA_G4/LWT(0)(7)Offline(0)(9)DVES_USER(0)(9)DVES_PASS
2020.12.13 07:51:01.592 4:   MQTT2_TR_UB9_192.168.1.166_51027 cid:DVES_F3F8D6 CONNECT V:4 keepAlive:30 LWT:tele/TA_G4/LWT:Offline usr:DVES_USER
2020.12.13 07:51:05.091 5:   MQTT2_TR_UB9_192.168.0.26_65191 zwh100ltw10 => tele/TA_G4/LWT:Offline
2020.12.13 07:51:05.092 5: out: PUBLISH: 0(23)(0)(14)tele/TA_G4/LWTOffline
2020.12.13 07:51:05.092 5: MQTT2_TR_UB9: dispatch autocreate=no\000DVES_F3F8D6\000tele/TA_G4/LWT\000Offline
2020.12.13 07:51:31.656 5: in:  CONNECT: (16)F(0)(4)MQTT(4)(238)(0)(30)(0)(11)DVES_F3F8D6(0)(14)tele/TA_G4/LWT(0)(7)Offline(0)(9)DVES_USER(0)(9)DVES_PASS
2020.12.13 07:51:31.657 4:   MQTT2_TR_UB9_192.168.1.166_55478 cid:DVES_F3F8D6 CONNECT V:4 keepAlive:30 LWT:tele/TA_G4/LWT:Offline usr:DVES_USER
2020.12.13 07:51:32.100 5:   MQTT2_TR_UB9_192.168.0.26_65191 zwh100ltw10 => tele/TA_G4/LWT:Offline
2020.12.13 07:51:32.101 5: out: PUBLISH: 0(23)(0)(14)tele/TA_G4/LWTOffline
2020.12.13 07:51:32.101 5: MQTT2_TR_UB9: dispatch autocreate=no\000DVES_F3F8D6\000tele/TA_G4/LWT\000Offline
2020.12.13 07:51:52.093 5: in:  CONNECT: (16)F(0)(4)MQTT(4)(238)(0)(30)(0)(11)DVES_F3F8D6(0)(14)tele/TA_G4/LWT(0)(7)Offline(0)(9)DVES_USER(0)(9)DVES_PASS
2020.12.13 07:51:52.093 4:   MQTT2_TR_UB9_192.168.1.166_52066 cid:DVES_F3F8D6 CONNECT V:4 keepAlive:30 LWT:tele/TA_G4/LWT:Offline usr:DVES_USER
2020.12.13 07:51:52.933 5:   MQTT2_TR_UB9_192.168.0.26_65191 zwh100ltw10 => tele/TA_G4/LWT:Offline
2020.12.13 07:51:52.933 5: out: PUBLISH: 0(23)(0)(14)tele/TA_G4/LWTOffline
2020.12.13 07:51:52.933 5: MQTT2_TR_UB9: dispatch autocreate=no\000DVES_F3F8D6\000tele/TA_G4/LWT\000Offline
2020.12.13 07:51:57.616 5: in:  PUBLISH: 0(20)(0)(17)cmnd/TA_G4/STATUS1
2020.12.13 07:51:57.616 4:   MQTT2_TR_UB9_192.168.0.26_65191 zwh100ltw10 PUBLISH cmnd/TA_G4/STATUS:1
2020.12.13 07:51:57.616 5:   MQTT2_TR_UB9_192.168.0.26_65191 zwh100ltw10 => cmnd/TA_G4/STATUS:1
2020.12.13 07:51:57.616 5: out: PUBLISH: 0(20)(0)(17)cmnd/TA_G4/STATUS1
2020.12.13 07:51:57.616 5: MQTT2_TR_UB9: dispatch autocreate=no\000zwh100ltw10\000cmnd/TA_G4/STATUS\0001

FHEM Log Grep ERROR

Code Auswählen


2020.12.13 07:11:02.740 1: ERROR: addToWritebuffer for MQTT2_TR_UB9_192.168.1.130_63675 without FD
2020.12.13 07:11:11.210 1: ERROR: addToWritebuffer for MQTT2_TR_UB9_192.168.6.116_54948 without FD
2020.12.13 07:27:53.302 1: ERROR: Unhandled packet PUBREL, disconnecting MQTT2_TR_UB9_192.168.1.102_50817
2020.12.13 07:27:54.415 1: ERROR: Unhandled packet CONNACK, disconnecting MQTT2_TR_UB9_192.168.1.102_50817
2020.12.13 07:27:54.797 1: ERROR: addToWritebuffer for MQTT2_TR_UB9_192.168.1.102_50817 without FD
2020.12.13 07:27:54.818 2: ERROR: MQTT2_TR_UB9_192.168.1.102_50817 DVES_B741D8 received bogus data, disconnecting
2020.12.13 07:27:54.882 1: ERROR: Unhandled packet PUBCOMP, disconnecting MQTT2_TR_UB9_192.168.6.106_63894
2020.12.13 07:27:56.726 1: ERROR: Unhandled packet PUBCOMP, disconnecting MQTT2_TR_UB9_192.168.1.102_50817
2020.12.13 07:27:56.972 1: ERROR: Unhandled packet CONNACK, disconnecting MQTT2_TR_UB9_192.168.6.106_63894
2020.12.13 07:27:57.683 1: ERROR: addToWritebuffer for MQTT2_TR_UB9_192.168.6.106_63894 without FD
2020.12.13 07:27:58.210 1: ERROR: Unhandled packet PUBREL, disconnecting MQTT2_TR_UB9_192.168.1.156_53037
2020.12.13 07:28:00.083 1: ERROR: Unhandled packet CONNACK, disconnecting MQTT2_TR_UB9_192.168.1.156_53037
2020.12.13 07:28:00.676 1: ERROR: addToWritebuffer for MQTT2_TR_UB9_192.168.1.156_53037 without FD
2020.12.13 07:28:00.790 1: ERROR: Unhandled packet CONNACK, disconnecting MQTT2_TR_UB9_192.168.6.106_63894
2020.12.13 07:28:02.281 1: ERROR: Unhandled packet PUBREC, disconnecting MQTT2_TR_UB9_192.168.6.116_52948
2020.12.13 07:28:03.174 1: ERROR: Unhandled packet PUBREC, disconnecting MQTT2_TR_UB9_192.168.6.116_52948
2020.12.13 07:28:03.316 1: ERROR: Unhandled packet CONNACK, disconnecting MQTT2_TR_UB9_192.168.6.109_59132
2020.12.13 07:28:03.485 1: ERROR: addToWritebuffer for MQTT2_TR_UB9_192.168.1.156_53037 without FD
2020.12.13 07:28:03.504 2: ERROR: MQTT2_TR_UB9_192.168.1.156_53037 DVES_B6167A received bogus data, disconnecting
2020.12.13 07:28:03.647 1: ERROR: Unhandled packet PUBCOMP, disconnecting MQTT2_TR_UB9_192.168.6.116_52948
2020.12.13 07:28:03.803 1: ERROR: Unhandled packet CONNACK, disconnecting MQTT2_TR_UB9_192.168.6.109_59132
2020.12.13 07:28:03.839 1: ERROR: Unhandled packet CONNACK, disconnecting MQTT2_TR_UB9_192.168.6.116_52948
2020.12.13 07:28:03.898 1: ERROR: Unhandled packet PUBCOMP, disconnecting MQTT2_TR_UB9_192.168.6.109_59132
2020.12.13 07:28:03.910 1: ERROR: Unhandled packet CONNACK, disconnecting MQTT2_TR_UB9_192.168.6.109_59132
2020.12.13 07:28:29.053 1: ERROR: Unhandled packet PUBREC, disconnecting MQTT2_TR_UB9_192.168.1.163_51422
2020.12.13 07:28:29.511 1: ERROR: Unhandled packet PUBREC, disconnecting MQTT2_TR_UB9_192.168.6.109_59132
2020.12.13 07:28:30.021 1: ERROR: Unhandled packet CONNACK, disconnecting MQTT2_TR_UB9_192.168.1.163_51422
2020.12.13 07:28:30.304 1: ERROR: addToWritebuffer for MQTT2_TR_UB9_192.168.1.163_51422 without FD
2020.12.13 07:28:30.317 2: ERROR: MQTT2_TR_UB9_192.168.1.163_51422 DVES_F466C9 received bogus data, disconnecting
2020.12.13 07:28:45.204 1: ERROR: Unhandled packet PUBREL, disconnecting MQTT2_TR_UB9_192.168.1.177_52413
2020.12.13 07:28:45.956 1: ERROR: addToWritebuffer for MQTT2_TR_UB9_192.168.1.177_52413 without FD
2020.12.13 07:28:48.883 2: ERROR: MQTT2_TR_UB9_192.168.1.177_52413 DVES_33F959 received bogus data, disconnecting
2020.12.13 07:28:49.729 1: ERROR: Unhandled packet PUBREC, disconnecting MQTT2_TR_UB9_192.168.1.177_52413
2020.12.13 07:28:53.088 1: ERROR: Unhandled packet PUBREL, disconnecting MQTT2_TR_UB9_192.168.1.167_56285
2020.12.13 07:28:53.248 1: ERROR: Unhandled packet CONNACK, disconnecting MQTT2_TR_UB9_192.168.1.167_56285
2020.12.13 07:28:55.186 1: ERROR: addToWritebuffer for MQTT2_TR_UB9_192.168.1.167_56285 without FD
2020.12.13 07:28:55.198 2: ERROR: MQTT2_TR_UB9_192.168.1.167_56285 DVES_453278 received bogus data, disconnecting
2020.12.13 07:28:55.235 2: ERROR: MQTT2_TR_UB9_192.168.1.167_56285 DVES_453278 received bogus data, disconnecting
2020.12.13 07:28:56.536 1: ERROR: Unhandled packet CONNACK, disconnecting MQTT2_TR_UB9_192.168.1.167_56285
2020.12.13 07:30:32.958 1: ERROR: Unhandled packet PUBREL, disconnecting MQTT2_TR_UB9_192.168.1.130_50070
2020.12.13 07:30:33.265 1: ERROR: Unhandled packet PUBCOMP, disconnecting MQTT2_TR_UB9_192.168.1.130_50070
2020.12.13 07:30:33.453 1: ERROR: Unhandled packet CONNACK, disconnecting MQTT2_TR_UB9_192.168.1.130_50070
2020.12.13 07:30:33.584 1: ERROR: Unhandled packet PUBCOMP, disconnecting MQTT2_TR_UB9_192.168.1.130_50070
2020.12.13 07:31:07.481 1: ERROR: Unhandled packet CONNACK, disconnecting MQTT2_TR_UB9_192.168.6.126_51890
2020.12.13 07:31:08.793 1: ERROR: Unhandled packet PUBREL, disconnecting MQTT2_TR_UB9_192.168.6.126_51890
2020.12.13 07:31:09.010 1: ERROR: Unhandled packet CONNACK, disconnecting MQTT2_TR_UB9_192.168.6.126_51890

Weblog TA_G4

Code Auswählen


07:42:10 HTP: Web server active on TA_G4-6358 with IP address 192.168.1.166
07:42:11 MQT: Attempting connection...
07:42:26 MQT: Connect failed to 192.168.0.9:1893, rc -4. Retry in 10 sec
07:42:26 RSL: stat/TA_G4/RESULT = {"POWER1":"on"}
07:42:26 RSL: stat/TA_G4/POWER1 = on
07:42:26 RSL: stat/TA_G4/RESULT = {"POWER1":"off"}
07:42:26 RSL: stat/TA_G4/POWER1 = off
07:42:26 RSL: stat/TA_G4/RESULT = {"POWER1":"on"}
07:42:26 RSL: stat/TA_G4/POWER1 = on
07:42:36 MQT: Attempting connection...
07:42:51 MQT: Connect failed to 192.168.0.9:1893, rc -4. Retry in 10 sec
07:42:51 CMD: power1 2
07:42:51 RSL: stat/TA_G4/RESULT = {"POWER1":"off"}
07:42:51 RSL: stat/TA_G4/POWER1 = off
07:42:52 CMD: power1 2
07:42:52 RSL: stat/TA_G4/RESULT = {"POWER1":"on"}
07:42:52 RSL: stat/TA_G4/POWER1 = on
07:43:02 MQT: Attempting connection...
07:43:17 MQT: Connect failed to 192.168.0.9:1893, rc -4. Retry in 10 sec
07:43:28 MQT: Attempting connection...
07:43:43 MQT: Connect failed to 192.168.0.9:1893, rc -4. Retry in 10 sec
07:43:43 CMD: power1 2
07:43:43 RSL: stat/TA_G4/RESULT = {"POWER1":"off"}
07:43:43 RSL: stat/TA_G4/POWER1 = off
07:43:54 MQT: Attempting connection...
07:44:09 MQT: Connect failed to 192.168.0.9:1893, rc -4. Retry in 10 sec
07:44:20 MQT: Attempting connection...
07:44:35 MQT: Connect failed to 192.168.0.9:1893, rc -4. Retry in 10 sec
07:44:46 MQT: Attempting connection...
07:45:01 MQT: Connect failed to 192.168.0.9:1893, rc -4. Retry in 10 sec
07:45:11 MQT: Attempting connection...
07:45:26 MQT: Connect failed to 192.168.0.9:1893, rc -4. Retry in 10 sec
07:45:37 MQT: Attempting connection...
07:45:52 MQT: Connect failed to 192.168.0.9:1893, rc -4. Retry in 10 sec
07:46:03 MQT: Attempting connection...
07:46:18 MQT: Connect failed to 192.168.0.9:1893, rc -4. Retry in 10 sec
07:46:29 MQT: Attempting connection...
07:46:44 MQT: Connect failed to 192.168.0.9:1893, rc -4. Retry in 10 sec
07:46:55 MQT: Attempting connection...
07:47:13 MQT: Connect failed to 192.168.0.9:1893, rc -4. Retry in 10 sec
07:47:24 MQT: Attempting connection...
07:47:39 MQT: Connect failed to 192.168.0.9:1893, rc -4. Retry in 10 sec
07:47:50 MQT: Attempting connection...
07:47:55 MQT: Connect failed to 192.168.0.9:1893, rc -2. Retry in 10 sec
07:48:06 MQT: Attempting connection...
07:48:21 MQT: Connect failed to 192.168.0.9:1893, rc -4. Retry in 10 sec
07:48:32 MQT: Attempting connection...
07:48:50 MQT: Connect failed to 192.168.0.9:1893, rc -4. Retry in 10 sec
07:49:00 MQT: Attempting connection...
07:49:19 MQT: Connect failed to 192.168.0.9:1893, rc -4. Retry in 10 sec
07:49:29 MQT: Attempting connection...
07:49:44 MQT: Connect failed to 192.168.0.9:1893, rc -4. Retry in 10 sec
07:49:55 MQT: Attempting connection...
07:50:10 MQT: Connect failed to 192.168.0.9:1893, rc -4. Retry in 10 sec
07:50:21 MQT: Attempting connection...
07:50:26 MQT: Connect failed to 192.168.0.9:1893, rc -2. Retry in 10 sec
07:50:37 MQT: Attempting connection...
07:50:52 MQT: Connect failed to 192.168.0.9:1893, rc -4. Retry in 10 sec
07:51:03 MQT: Attempting connection...
07:51:21 MQT: Connect failed to 192.168.0.9:1893, rc -4. Retry in 10 sec
07:51:32 MQT: Attempting connection...
07:51:47 MQT: Connect failed to 192.168.0.9:1893, rc -4. Retry in 10 sec
07:51:58 MQT: Attempting connection...
07:52:13 MQT: Connect failed to 192.168.0.9:1893, rc -4. Retry in 10 sec
07:52:23 MQT: Attempting connection...
07:52:38 MQT: Connect failed to 192.168.0.9:1893, rc -4. Retry in 10 sec
07:52:49 MQT: Attempting connection...
07:53:04 MQT: Connect failed to 192.168.0.9:1893, rc -4. Retry in 10 sec
07:53:15 MQT: Attempting connection...
07:53:30 MQT: Connect failed to 192.168.0.9:1893, rc -4. Retry in 10 sec
07:53:41 MQT: Attempting connection...
07:53:56 MQT: Connect failed to 192.168.0.9:1893, rc -4. Retry in 10 sec
07:53:58 RSL: tele/TA_G4/STATE = {"Time":"2020-12-13T07:53:58","Uptime":"0T00:11:58","UptimeSec":718,"Heap":27,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":232,"MqttCount":0,"POWER1":"off","Wifi":{"AP":1,"SSId":"TR7272","BSSId":"16:18:D6:27:CA:64","Channel":6,"RSSI":80,"Signal":-60,"LinkCount":1,"Downtime":"0T00:00:09"}}
07:53:58 RSL: tele/TA_G4/SENSOR = {"Time":"2020-12-13T07:53:58","ENERGY":{"TotalStartTime":"2020-02-09T08:21:57","Total":21.246,"Yesterday":0.000,"Today":0.000,"Period":0,"Power":0,"ApparentPower":0,"ReactivePower":0,"Factor":0.00,"Voltage":0,"Current":0.000}}
07:54:07 MQT: Attempting connection...
07:54:07 MQT: Connect failed to 192.168.0.9:1893, rc -2. Retry in 10 sec
07:54:18 MQT: Attempting connection...
07:54:18 MQT: Connect failed to 192.168.0.9:1893, rc -2. Retry in 10 sec
07:54:29 MQT: Attempting connection...
07:54:29 MQT: Connect failed to 192.168.0.9:1893, rc -2. Retry in 10 sec
07:54:40 MQT: Attempting connection...
07:54:40 MQT: Connect failed to 192.168.0.9:1893, rc -2. Retry in 10 sec
07:54:51 MQT: Attempting connection...
07:54:51 MQT: Connect failed to 192.168.0.9:1893, rc -2. Retry in 10 sec
07:55:02 MQT: Attempting connection...
07:55:02 MQT: Connect failed to 192.168.0.9:1893, rc -2. Retry in 10 sec
07:55:13 MQT: Attempting connection...
07:55:13 MQT: Connect failed to 192.168.0.9:1893, rc -2. Retry in 10 sec
07:55:24 MQT: Attempting connection...
07:55:24 MQT: Connect failed to 192.168.0.9:1893, rc -2. Retry in 10 sec
07:55:35 MQT: Attempting connection...
07:55:35 MQT: Connect failed to 192.168.0.9:1893, rc -2. Retry in 10 sec
07:55:46 MQT: Attempting connection...
07:55:46 MQT: Connect failed to 192.168.0.9:1893, rc -2. Retry in 10 sec
07:55:57 MQT: Attempting connection...
07:55:57 MQT: Connect failed to 192.168.0.9:1893, rc -2. Retry in 10 sec

rudolfkoenig · 13 Dezember 2020, 12:06:47

Waren diese Logs mit dem neuen 10_MQTT2_DEVICE.pm erstellt?
Das FHEM update hat die Datei erst nach ca 8:00 heute ausgeliefert.

Ansonsten sagen mir die Logs leider nichts Neues: ich vermute weiterhin dass FHEM (zeitweise?) ueberlastet ist, und die TASMOTAs kein TCP-Flowcontrol beherrschen, was zu Datenmuell/"Unhandled packet" und Disconnect fuehrt. Zu addToWritebuffer, habe ich weiterhin keine Idee.

Die Loesung ist entweder die FHEM Ueberlastung zu vermeiden, oder den MQTT Server auszulagern.
Ich waere bereit dein fhem.cfg anzuschauen (per PM bitte), wenn Du meinst, dass das sinnvoll ist.
Ich erhoffe dadurch evtl. Optimierungen fuer grosse Installationen, wovon auch andere profitieren koennten.

riker1 · 13 Dezember 2020, 12:14:09

Zitat von: rudolfkoenig am 13 Dezember 2020, 12:06:47
Waren diese Logs mit dem neuen 10_MQTT2_DEVICE.pm erstellt?
Das FHEM update hat die Datei erst nach ca 8:00 heute ausgeliefert.

Ansonsten sagen mir die Logs leider nichts Neues: ich vermute weiterhin dass FHEM (zeitweise?) ueberlastet ist, und die TASMOTAs kein TCP-Flowcontrol beherrschen, was zu Datenmuell/"Unhandled packet" und Disconnect fuehrt. Zu addToWritebuffer, habe ich weiterhin keine Idee.

Die Loesung ist entweder die FHEM Ueberlastung zu vermeiden, oder den MQTT Server auszulagern.
Ich waere bereit dein fhem.cfg anzuschauen (per PM bitte), wenn Du meinst, dass das sinnvoll ist.
Ich erhoffe dadurch evtl. Optimierungen fuer grosse Installationen, wovon auch andere profitieren koennten.

Hi Rudi,

ja hatte gestern per update den neuen FHEM MQTT2_Server installiert. Heute kein neues Update gemacht.

Schicke dir gerne die FHEM CFG.

Vielen Dank dafür

VG T

Beta-User · 13 Dezember 2020, 12:19:41

MQTT2_DEVICE hast du demnach nicht aktualisiert?

Dann solltest du jetzt nochmal ein update machen.

riker1 · 13 Dezember 2020, 12:32:05

Zitat von: Beta-User am 13 Dezember 2020, 12:19:41
MQTT2_DEVICE hast du demnach nicht aktualisiert?

Dann solltest du jetzt nochmal ein update machen.

stimmt, war aber beim update check gestern noch nicht dabei. mache ich dann.

rudolfkoenig · 13 Dezember 2020, 14:37:49

Mit deinem fhem.cfg dauert das Laden der 6k MQTT Nachrichten auf meinem Rechner mit dem
- alten Modul und apptime: 91.2 Sekunden
- alten Modul ohne apptime: 86.4 Sekunden
- neuen Modul ohne apptime: 60.5 Sekunden

Das System blockiert bei mir oft, wobei ich nicht alles erklaeren kann, vmtl. haengt es mit fehlenden Endgeraeten und schlecht geschriebenen Modulen zusammen.

Sowas wie fhem("sleep 5");;\ ist sicher nicht hilfreich, die dazugehoerige Meldung

Code Auswählen

"WARNING: sleep without additional commands is deprecated and blocks FHEM"

wird vmtl. bei den vielen Fehlermeldungen uebersehen.

Das Optimieren aller(!) der ca 300 unoptimierten notify und FileLog Regexps wuerde geschaetzt 20-30% bringen, ob es den Aufwand lohnt, will ich nicht beurteilen. Beim unoptimierten Regexps wird bei jedem Event jedes dieser 300 Definitionen nochmal geprueft. Bei den Optimierten nur dann, wenn das Event von der gesuchten Quelle stammt.

Insgesamt ist das System mit 1900 Definitionen (300+ Timer, 360 FileLogs, 550 Notifies) zu viel fuer ein RPi3, besonders wenn nur die MQTT Clients schon 100+ Nachrichten/sec generieren. Ich wuerde diese Datenflut verkleinern und ein Hardware-Upgrade einplanen.

riker1 · 13 Dezember 2020, 16:58:54

Zitat von: rudolfkoenig am 13 Dezember 2020, 14:37:49
Mit deinem fhem.cfg dauert das Laden der 6k MQTT Nachrichten auf meinem Rechner mit dem
- alten Modul und apptime: 91.2 Sekunden
- alten Modul ohne apptime: 86.4 Sekunden
- neuen Modul ohne apptime: 60.5 Sekunden

Das System blockiert bei mir oft, wobei ich nicht alles erklaeren kann, vmtl. haengt es mit fehlenden Endgeraeten und schlecht geschriebenen Modulen zusammen.

Sowas wie fhem("sleep 5");;\ ist sicher nicht hilfreich, die dazugehoerige Meldung
Code Auswählen Erweitern
"WARNING: sleep without additional commands is deprecated and blocks FHEM"wird vmtl. bei den vielen Fehlermeldungen uebersehen.

Das Optimieren aller(!) der ca 300 unoptimierten notify und FileLog Regexps wuerde geschaetzt 20-30% bringen, ob es den Aufwand lohnt, will ich nicht beurteilen. Beim unoptimierten Regexps wird bei jedem Event jedes dieser 300 Definitionen nochmal geprueft. Bei den Optimierten nur dann, wenn das Event von der gesuchten Quelle stammt.

Insgesamt ist das System mit 1900 Definitionen (300+ Timer, 360 FileLogs, 550 Notifies) zu viel fuer ein RPi3, besonders wenn nur die MQTT Clients schon 100+ Nachrichten/sec generieren. Ich wuerde diese Datenflut verkleinern und ein Hardware-Upgrade einplanen.

Hallo Rudi,

super vielen Dank.
Das läuft bei mir unter Ubuntu 18.04 auf einem alten IBM thinkcentre.

Hast du mal ein Beispiel für eine unoptimierte und optimierte Regex. Da stehe ich auf dem Schlauch. .
Viele der sleep habe ich schon rausgenommen.

Sorry für die recht unstrukturierte - historisch gewachsene - Konfiguration. Bedingt auch durch erst ESPEasy Devices und nun Tasmota. Da ist einiges doppelt und muss raus.

Dito für HM und MAX Module.

Apptime hatte ich deaktivert und freezemon, die stammen noch aus alten Fehlersuchen.

VG T

rudolfkoenig · 13 Dezember 2020, 18:04:31

Es gibt keinen Grund zum Entschuldigen, ich habe nur meine Meinung gesagt. Ich bin auch nicht die Sittenpolizei, es kann jeder die Module verwenden, die er will. Auf dem RPi3 bin ich wegen dem Signature gekommen.

FHEM-sleep ist kein Problem, wenn(!) es von anderen FHEM Befehlen gefolgt wird, weil es dann in eine Art "mini-at" umgebaut wird. Folgendes blockiert FHEM:

Code Auswählen

fhem("sleep 5");;\
fhem("set Lampe an")

und sollte so geschrieben werden:

Code Auswählen

fhem("sleep 5;; set Lampe an")

Ob der Regex "optimiert" ist sieht man daran, dass FileLog/Notify/etc ein Internal NOTIFYDEV hat, mit der Liste der betroffenen Quellen. Pruefen kann man den Regex mit

Code Auswählen

{ notifyRegexpCheck('...meinRegexp...') }

das Ergebnis zeigt, wie FHEM versucht das Ding auseinanderzunehmen, und welche Teile wie versteht.
Der Parser dafuer ist primitiv, und versteht nur sowas wie dev1 oder dev1:event1 oder dev1:event1|dev2:event2. Folgendes kapiert er nicht: dev:(event1|event2), und sowas wie dev.*event schon gar nicht. Nicht exisitierende dev's oder "Teilprobleme" fuehren auch zu einem "unoptimierten" Regex.

Beispiel (gut):

Code Auswählen

fhem> { notifyRegexpCheck('TA_G.*') }
TA_G.*: devspec TA_G1,TA_G2,TA_G3 (OK)

Beispiel (schlecht):

Code Auswählen

fhem> { notifyRegexpCheck('MAX_WT.*:(desiredTemperatur|temperature|batterie).*') }
MAX_WT.*:(desiredTemperatur: devspec MAX_WT_XX (OK)
temperature: unknown (ignored)
batterie).*: no match (ignored)

riker1 · 13 Dezember 2020, 20:33:41

Zitat von: rudolfkoenig am 13 Dezember 2020, 18:04:31
Es gibt keinen Grund zum Entschuldigen, ich habe nur meine Meinung gesagt. Ich bin auch nicht die Sittenpolizei, es kann jeder die Module verwenden, die er will. Auf dem RPi3 bin ich wegen dem Signature gekommen.

FHEM-sleep ist kein Problem, wenn(!) es von anderen FHEM Befehlen gefolgt wird, weil es dann in eine Art "mini-at" umgebaut wird. Folgendes blockiert FHEM:
Code Auswählen Erweitern
fhem("sleep 5");;\ fhem("set Lampe an")und sollte so geschrieben werden:
Code Auswählen Erweitern
fhem("sleep 5;; set Lampe an")

Ob der Regex "optimiert" ist sieht man daran, dass FileLog/Notify/etc ein Internal NOTIFYDEV hat, mit der Liste der betroffenen Quellen. Pruefen kann man den Regex mit
Code Auswählen Erweitern
{ notifyRegexpCheck('...meinRegexp...') }das Ergebnis zeigt, wie FHEM versucht das Ding auseinanderzunehmen, und welche Teile wie versteht.
Der Parser dafuer ist primitiv, und versteht nur sowas wie dev1 oder dev1:event1 oder dev1:event1|dev2:event2. Folgendes kapiert er nicht: dev:(event1|event2), und sowas wie dev.*event schon gar nicht. Nicht exisitierende dev's oder "Teilprobleme" fuehren auch zu einem "unoptimierten" Regex.

Beispiel (gut):
Code Auswählen Erweitern
fhem> { notifyRegexpCheck('TA_G.*') } TA_G.*: devspec TA_G1,TA_G2,TA_G3 (OK)Beispiel (schlecht):
Code Auswählen Erweitern
fhem> { notifyRegexpCheck('MAX_WT.*:(desiredTemperatur|temperature|batterie).*') } MAX_WT.*:(desiredTemperatur: devspec MAX_WT_XX (OK) temperature: unknown (ignored) batterie).*: no match (ignored)

super Rudi, danke für die Hilfe.

riker1 · 14 Dezember 2020, 07:20:26

Zitat von: rudolfkoenig am 13 Dezember 2020, 18:04:31
Es gibt keinen Grund zum Entschuldigen, ich habe nur meine Meinung gesagt. Ich bin auch nicht die Sittenpolizei, es kann jeder die Module verwenden, die er will. Auf dem RPi3 bin ich wegen dem Signature gekommen.

FHEM-sleep ist kein Problem, wenn(!) es von anderen FHEM Befehlen gefolgt wird, weil es dann in eine Art "mini-at" umgebaut wird. Folgendes blockiert FHEM:
Code Auswählen Erweitern
fhem("sleep 5");;\ fhem("set Lampe an")und sollte so geschrieben werden:
Code Auswählen Erweitern
fhem("sleep 5;; set Lampe an")

Ob der Regex "optimiert" ist sieht man daran, dass FileLog/Notify/etc ein Internal NOTIFYDEV hat, mit der Liste der betroffenen Quellen. Pruefen kann man den Regex mit
Code Auswählen Erweitern
{ notifyRegexpCheck('...meinRegexp...') }das Ergebnis zeigt, wie FHEM versucht das Ding auseinanderzunehmen, und welche Teile wie versteht.
Der Parser dafuer ist primitiv, und versteht nur sowas wie dev1 oder dev1:event1 oder dev1:event1|dev2:event2. Folgendes kapiert er nicht: dev:(event1|event2), und sowas wie dev.*event schon gar nicht. Nicht exisitierende dev's oder "Teilprobleme" fuehren auch zu einem "unoptimierten" Regex.

Beispiel (gut):
Code Auswählen Erweitern
fhem> { notifyRegexpCheck('TA_G.*') } TA_G.*: devspec TA_G1,TA_G2,TA_G3 (OK)Beispiel (schlecht):
Code Auswählen Erweitern
fhem> { notifyRegexpCheck('MAX_WT.*:(desiredTemperatur|temperature|batterie).*') } MAX_WT.*:(desiredTemperatur: devspec MAX_WT_XX (OK) temperature: unknown (ignored) batterie).*: no match (ignored)

Hallo Rudi, Beta-User,
das habe ich nun erst richtig durchdrungen, eine Frage. Wieso wird das nicht beim anlegen der Regex als Fehlermeldung oder Warning angezeigt. Da weiss man dann gleich bescheid?
Dachte immer wenn ich die modify speichere, die Regex wäre ok .

Mache wie vorgeschlagen im Anfängerbereich einen Threat dazu auf
https://forum.fhem.de/index.php?topic=116701

Vielen Dank T

PS. Noch ne Nachfrage hier:

ZitatBeispiel (gut):
Code Auswählen Erweitern
fhem> { notifyRegexpCheck('TA_G.*') } TA_G.*: devspec TA_G1,TA_G2,TA_G3 (OK)Beispiel (schlecht):
Code Auswählen Erweitern
fhem> { notifyRegexpCheck('MAX_WT.*:(desiredTemperatur|temperature|batterie).*') } MAX_WT.*:(desiredTemperatur: devspec MAX_WT_XX (OK) temperature: unknown (ignored) batterie).*: no match (ignored)

Ist schlecht automatisch auch nichtoptimiert?

Beta-User · 14 Dezember 2020, 07:57:11

Na ja, es ist kein "Beinbruch", wenn NOTIFYDEV nicht angelegt wird, das funktioniert ja schon auch ohne. Es ist nur nicht so effizient. "Früher" war es vermutlich auch nicht so das Riesen-Problem, weil z.B. die Zahl der Events eines Homematic-Thermostats (der macht schon vergleichsweise viele...) deutlich geringer war wie das, was Shelly und Tasmota so treiben (ok, das sind teilweise bulk-updates, aber dann teils mit extrem viel Infos drin).
Und 30% (das scheint eine gute Hausnummer zu sein) Effizienzgewinn ist zwar einiges, aber eben auch "nur" 30%...

Und ob es angelegt wurde, sieht man ja in den Internals (kann sein, dass das einen Seitenrefresh-braucht); wenn man sensibilisiert ist, schaut man da drauf. Allerdings kennen das Thema m.E. zu wenige User (auch von den Power-Usern). Jedenfalls werden immer noch viele Vorschläge ala "Device:(on|off)" gemacht statt "Device:o[nf]+)" oder "Device:on|Device:off".

Mir selbst kam das auch erst ins Bewußtsein, nachdem sich Rudi mal über meine "tiefergelegten regexp" amüsiert hatte, und auch die Funktion notifyRegexpCheck() existiert noch nicht soooo lange, afaik. (Könnte sogar sein, dass deren Einführung eine indirekte Reaktion von Rudi auf solche Optimierungsversuche war...)

Ein nicht mehr vorhandenes NOTIFYDEV kann btw. auch entstehen, wenn Devices umbenannt werden. Manchmal kann man das vorher wissen, wenn die Verbindung so eng ist, dass der betreffende Event-Handler bei "probably associated with" in der Detailansicht zu sehen ist, aber sobald man generalisiert, wird das schwieriger.

Ergänzend: Das Problem betrifft ziemlich viele Event-Handler, insbesondere auch FileLog und (zwischenzeitlich und vermutlich) DOIF.

Das "Grundproblem" sind aber m.E. eigentlich eher die "geschwätzigen" Geräte, allen voran eben Tasmota/Shelly. Und da bin ich noch nicht sicher, ob man nicht in den attrTemplate noch weitere Maßnahmen aufzeigen sollte, um das etwas gleich an der Quelle zu begrenzen, siehe z.B. die Fragen in diesem Beitrag: https://forum.fhem.de/index.php/topic,116658.msg1110215.html#msg1110215.
(Bitte aber ggf. den Links folgen und dann am Quell-Thread Rückmeldung geben, damit andere User dieser Gerätegattung da auch "in die Pötte" kommen.)