Hallo
stehe hier etwas auf dem Schlauch.
kann ich MQtt2 Clients mit den Mosquitto Server als IO Device betreiben oder geht das nur mit MQTT und den entsprechenden Clients?
Habe diverse Tasmotas und merkwürdigerweise laufend connect Fehler an den Fhem MQTT2 Server.
06:59:20 MQT: Attempting connection...
06:59:35 MQT: Connect failed to 192.168.0.9:1893, rc -4. Retry in 10 sec
06:59:45 MQT: Attempting connection...
07:00:00 MQT: Connect failed to 192.168.0.9:1893, rc -4. Retry in 10 sec
07:00:11 MQT: Attempting connection...
07:00:26 MQT: Connect failed to 192.168.0.9:1893, rc -4. Retry in 10 sec
07:00:37 MQT: Attempting connection...
07:00:52 MQT: Connect failed to 192.168.0.9:1893, rc -4. Retry in 10 sec
07:01:03 MQT: Attempting connection...
07:01:08 MQT: Connect failed to 192.168.0.9:1893, rc -2. Retry in 10 sec
Danke
Mal abgesehen davon, dass ich deinen Text nicht verstehe der Versuch einer Antwort:
Ja, man kann mosquitto als Server verwenden und auf der FHEM-Seite MQTT2_DEVICE für die Geräte verwenden. Das Bindeglied heißt MQTT2_CLIENT, für was es dann auch einen eigenen Artikel im Wiki gibt, und auch im Artikel "MQTT" sind die verschiedenen Varianten zu finden.
Falls du Hilfe oder eine Erklärung für deinen "Code" erwartest, solltest du wenigstens erklären, was das ist (Tasmota-console-log?)...
Glaskugel: Irgendwas blockiert FHEM oder das WLAN ist überlastet.
Zitat von: Beta-User am 08 Dezember 2020, 08:04:09
Mal abgesehen davon, dass ich deinen Text nicht verstehe der Versuch einer Antwort:
Ja, man kann mosquitto als Server verwenden und auf der FHEM-Seite MQTT2_DEVICE für die Geräte verwenden. Das Bindeglied heißt MQTT2_CLIENT, für was es dann auch einen eigenen Artikel im Wiki gibt, und auch im Artikel "MQTT" sind die verschiedenen Varianten zu finden.
Falls du Hilfe oder eine Erklärung für deinen "Code" erwartest, solltest du wenigstens erklären, was das ist (Tasmota-console-log?)...
Glaskugel: Irgendwas blockiert FHEM oder das WLAN ist überlastet.
Hallo Beta-User, danke für die Antwort.
Ja sorry etwas wirr eventuell,
also ich versuche die Ursache zu finden die FHEM blockt. WLAN sollte ok sein. kann ja an die Tasmotas super per webgui. Aber Fhem nicht an die Tasmotas, bzw andersherum.
-> wo würde ich da noch suchen können/müssen. Wühle mich durchs log , aber noch nichts konkretes gefunden.
Der obige log ist aus der Tasmota Console. In Fhem sind die MQTT2_DEVICES offline.
Eigentlich hatte ich alle Tasmotas mittels MQTT2_Devices definiert und mit MQTT2_Server verbunden.
Mit war jetzt nicht ganz klar ob ich da einfach das IODev der MQTT2_Clients gegen Mosquitto Server als MQTT Device, werde nun mal MQTT2_Clients prüfen.
Habe folgendes gemacht:
-Tasmota config mit MQTT Mosquitto
-Mosquito Broker mit Type MQTT -> oder muss ich den als MQTT2_SErver anlegen? das g
List Mosquitto:
Internals:
DEF 192.168.0.9:1883
DeviceName 192.168.0.9:1883
FD 415
FUUID 5cc87d9e-f33f-74bb-487f-1f8c9a27f63c97ce
NAME MQ_TR_Broker_UB9
NOTIFYDEV global
NR 2756
NTFY_ORDER 50-MQ_TR_Broker_UB9
PARTIAL
STATE opened
TYPE MQTT
buf
msgid 15
ping_received 1
timeout 60
READINGS:
2020-12-08 09:10:05 connection active
2020-12-08 08:58:21 state opened
messages:
Attributes:
room 09_Rollladen,09_Rollladen_23,MQTT,Z_Control
verbose 5Danke für die Tipps
VG T
PS. unklar ist mir die Verwendung :
MQTT_GENERIC_BRIDGE versus MQTT2_Client als Gateway
Dies konnte ich aus den Wikis nicht so genau entnehmen, bzw. habe es wohl nicht verstanden.
Wollte also ;
MQTT ( Mosquitto) als MQTT -> MQTT2_Client-> MQTT2_Device einrichten
oder habe ich da einen Denkfehler
Bevor man zum mosquitto+MQTT_CLIENT wechselt, wuerde mich ein FHEM Log mit "attr MQTT2_SERVER verbose 5" interessieren, um moegliche Implementationsprobleme in MQTT2_SERVER auszuschliessen.
Fuer die MQTT Grundlagen in FHEM empfehle ich die FHEMwiki Seite https://wiki.fhem.de/wiki/MQTT
Bitte unbedingt beachten:
Zitat von: rudolfkoenig am 08 Dezember 2020, 09:51:10
Bevor man zum mosquitto+MQTT_CLIENT wechselt, wuerde mich ein FHEM Log mit "attr MQTT2_SERVER verbose 5" interessieren, um moegliche Implementationsprobleme in MQTT2_SERVER auszuschliessen.
Fuer die MQTT Grundlagen in FHEM empfehle ich die FHEMwiki Seite https://wiki.fhem.de/wiki/MQTT (https://wiki.fhem.de/wiki/MQTT)
Da schon fertig, noch ein paar Anmerkungen von meiner Seite:
Sorry, aber lies erst mal, was ich versucht habe zu verlinken. Da sind noch große Verständnislücken!
https://wiki.fhem.de/wiki/MQTT#Installation_in_FHEM (https://wiki.fhem.de/wiki/MQTT#Installation_in_FHEM)
https://wiki.fhem.de/wiki/MQTT2_CLIENT (https://wiki.fhem.de/wiki/MQTT2_CLIENT)
Kurz: "MQTT2" ist ein FHEM-internes Kürzel für eine Modul-Familie, "außerhalb" FHEM ist das Protokoll schlicht "MQTT", und ein Device vom TYPE=MQTT ist als IO-Modul für Devices vom TYPE=MQTT2_DEVICE ungeeignet!
Falls also das "als MQTT" in dem folgenden Zitat bedeuten soll, dass du das in FHEM brauchst: NEIN!
ZitatMQTT ( Mosquitto) als MQTT -> MQTT2_Client-> MQTT2_Device einrichten
Wenn man das so notieren will, dann (genau das zeigen doch die Schaubildchen, oder...?):
Zitat(externer) MQTT-Server ( Mosquitto) -> MQTT2_CLIENT -> MQTT2_DEVICE
Die Groß- und Kleinschreibung sollte man korrekt machen, weil das Wörtchen "Client" in der MQTT-Welt ausgesprochen "schillernd" ist; z.B. sind deine Tasmota-ESP's auch "client"-Geräte (eben keine Server)...
Und MQTT_GENERIC_BRIDGE ist wieder was anderes, vermutlich brauchst du das nicht, es hat jedenfalls nichts mit den Tasmotas zu tun.
Was WLAN-Probleme angeht, bin ich der falsche, aber nur, weil das WEB-Interface erreichbar ist, heißt das noch lange nicht, dass alles gut ist...
Dein Tasmota-Konsolen-log deute ich so, dass ein MQTT2_SERVER-Device auf Port 1893 (mit der Einstellung global) definiert ist und FHEM auf der Maschine mit der IP-Adresse 192.168.0.9 läuft? (Grummel, eigentlich sollte man nichts mehr beantworten, wenn nicht die Fragen aus
Welche Informationen sollte man bei Fragen zu MQTT-Geräten bereitstellen? (https://forum.fhem.de/index.php/topic,112327.0.html) beantwortet sind; immer das gleiche...)
Zitat von: rudolfkoenig am 08 Dezember 2020, 09:51:10
Bevor man zum mosquitto+MQTT_CLIENT wechselt, wuerde mich ein FHEM Log mit "attr MQTT2_SERVER verbose 5" interessieren, um moegliche Implementationsprobleme in MQTT2_SERVER auszuschliessen.
Fuer die MQTT Grundlagen in FHEM empfehle ich die FHEMwiki Seite https://wiki.fhem.de/wiki/MQTT
Hallo Rudolf,
vielen Dank für die Hilfe.
die Logs sind riesig. wie mache ich das am besten das es übersichtlich bleibt?
ein kurzer Zeitraum?
Oder nur mal ein MQTT2_DEVICE?
Zur Fehlersuche nutze ich auch MQTT_Spy . Wenn ich da was machen kann?
für das WLAN benutzte ich Unifi APs . der Client beispielsweise hat eine gute Verbindung sagt der Unifi-controller
Habe bei dem MQTT2_DEVICE (Beispielhaft): Tritt bei vielen auf. Es kommt keine , bzw. nur manchmal Verbindung.
Dieses verhalten tritt nun ziemlich häufig auf . Habe aber Verbindung via WebUI mit den Tasmotas. nur MQTT klemmt.
15:10:38 MQT: tele/TA_SOR2/STATE = {"Time":"2020-12-08T15:10:38","Uptime":"0T15:08:29","UptimeSec":54509,"Heap":26,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":45,"POWER1":"ON","POWER2":"OFF","Wifi":{"AP":2,"SSId":"TR_ESP","BSSId":"56:A4:3C:DD:17:FA","Channel":4,"RSSI":100,"Signal":-43,"LinkCount":2,"Downtime":"0T00:00:13"}}
15:11:35 MQT: Attempting connection...
15:11:40 MQT: Connect failed to 192.168.0.9:1893, rc -2. Retry in 10 sec
15:11:51 MQT: Attempting connection...
15:11:56 MQT: Connect failed to 192.168.0.9:1893, rc -2. Retry in 10 sec
15:12:07 MQT: Attempting connection...
15:12:12 MQT: Connect failed to 192.168.0.9:1893, rc -2. Retry in 10 sec
15:12:23 MQT: Attempting connection...
15:12:28 MQT: Connect failed to 192.168.0.9:1893, rc -2. Retry in 10 sec
15:12:39 MQT: Attempting connection...
15:12:44 MQT: Connect failed to 192.168.0.9:1893, rc -2. Retry in 10 sec
15:12:55 MQT: Attempting connection...
15:13:00 MQT: Connect failed to 192.168.0.9:1893, rc -2. Retry in 10 sec
15:13:11 MQT: Attempting connection...
15:13:16 MQT: Connect failed to 192.168.0.9:1893, rc -2. Retry in 10 sec
15:13:26 MQT: Attempting connection...
15:13:32 MQT: Connect failed to 192.168.0.9:1893, rc -2. Retry in 10 sec
15:13:42 MQT: Attempting connection...
15:13:57 MQT: Connect failed to 192.168.0.9:1893, rc -4. Retry in 10 sec
15:14:08 MQT: Attempting connection...
15:14:23 MQT: Connect failed to 192.168.0.9:1893, rc -4. Retry in 10 sec
15:14:34 MQT: Attempting connection...
15:14:46 MQT: Connected
der zeitgleiche LOG aus FHEM:
als Datei dran
List des Devices (merkwürdig die Tags stimmen irgendwie nicht )?
habe es nun besser als Anhang dran. Wahrscheinlich war es zu gross.
VG T
Zitat von: Beta-User am 08 Dezember 2020, 09:53:08
Bitte unbedingt beachten:
Da schon fertig, noch ein paar Anmerkungen von meiner Seite:
Sorry, aber lies erst mal, was ich versucht habe zu verlinken. Da sind noch große Verständnislücken!
https://wiki.fhem.de/wiki/MQTT#Installation_in_FHEM (https://wiki.fhem.de/wiki/MQTT#Installation_in_FHEM)
https://wiki.fhem.de/wiki/MQTT2_CLIENT (https://wiki.fhem.de/wiki/MQTT2_CLIENT)
Kurz: "MQTT2" ist ein FHEM-internes Kürzel für eine Modul-Familie, "außerhalb" FHEM ist das Protokoll schlicht "MQTT", und ein Device vom TYPE=MQTT ist als IO-Modul für Devices vom TYPE=MQTT2_DEVICE ungeeignet!
Falls also das "als MQTT" in dem folgenden Zitat bedeuten soll, dass du das in FHEM brauchst: NEIN!Wenn man das so notieren will, dann (genau das zeigen doch die Schaubildchen, oder...?):Die Groß- und Kleinschreibung sollte man korrekt machen, weil das Wörtchen "Client" in der MQTT-Welt ausgesprochen "schillernd" ist; z.B. sind deine Tasmota-ESP's auch "client"-Geräte (eben keine Server)...
Und MQTT_GENERIC_BRIDGE ist wieder was anderes, vermutlich brauchst du das nicht, es hat jedenfalls nichts mit den Tasmotas zu tun.
Was WLAN-Probleme angeht, bin ich der falsche, aber nur, weil das WEB-Interface erreichbar ist, heißt das noch lange nicht, dass alles gut ist...
Dein Tasmota-Konsolen-log deute ich so, dass ein MQTT2_SERVER-Device auf Port 1893 (mit der Einstellung global) definiert ist und FHEM auf der Maschine mit der IP-Adresse 192.168.0.9 läuft? (Grummel, eigentlich sollte man nichts mehr beantworten, wenn nicht die Fragen aus Welche Informationen sollte man bei Fragen zu MQTT-Geräten bereitstellen? (https://forum.fhem.de/index.php/topic,112327.0.html) beantwortet sind; immer das gleiche...)
vielen vielen Dank. Bin noch dran und räume auch Fhem was auf.
Versuche nun mal MQTT2_CLIENT für einige Tasmota.
VG T
Zitatein kurzer Zeitraum?
Das klingt gut. Ein-zwei Sekunden vor und nach der "Connect failed" Meldung reicht. In der Hoffnung, dass die Uhrzeiten synchronisiert sind.
P.S.: Wer ist Ludwig?
Zitat von: rudolfkoenig am 08 Dezember 2020, 16:19:51
Das klingt gut. Ein-zwei Sekunden vor und nach der "Connect failed" Meldung reicht. In der Hoffnung, dass die Uhrzeiten synchronisiert sind.
P.S.: Wer ist Ludwig?
Hi Rudolf, sorry, war so in dem MQTT Thema:-)
mache nachher nochmal solche Mitschnitte.
VG T
Hallo Rudolf,
habe nun scheinbar einen Fehler beim Aufräumen gemacht,
Fhem looped und restarted.
2020.12.09 08:44:46.733 1: PERL WARNING: Use of uninitialized value in hash element at fhem.pl line 2204, <$fh> line 24491.
2020.12.09 08:44:46.733 1: stacktrace:
2020.12.09 08:44:46.734 1: main::__ANON__ called by fhem.pl (2204)
2020.12.09 08:44:46.734 1: main::AssignIoPort called by ./FHEM/00_MQTT.pm (784)
2020.12.09 08:44:46.734 1: MQTT::Client_Define called by ./FHEM/10_MQTT_DEVICE.pm (93)
2020.12.09 08:44:46.734 1: MQTT::DEVICE::Define called by fhem.pl (3810)
2020.12.09 08:44:46.734 1: main::CallFn called by fhem.pl (2096)
2020.12.09 08:44:46.734 1: main::CommandDefine called by fhem.pl (1247)
2020.12.09 08:44:46.734 1: main::AnalyzeCommand called by fhem.pl (1098)
2020.12.09 08:44:46.734 1: main::AnalyzeCommandChain called by fhem.pl (1385)
2020.12.09 08:44:46.734 1: main::CommandInclude called by fhem.pl (609)
2020.12.09 08:44:46.735 1: PERL ERROR: Undefined subroutine &MQTT::DEVICE::client_attr called at ./FHEM/10_MQTT_DEVICE.pm line 232, <$fh> line 24493.
versuche nun mal alle alten MQTT Server und clients aus der Config zu nehmen.
Sonst eine Idee zu der Fehlermeldung?
Danke VG T
Hallo
fhem looped und restarted constant.
im Log ist auch noch NUKI und MQTT2 als Fehler.
werde mal ne alte cfg versuchen. Aber hättet ihr hier einen Vorschlag zu der Ursache?
2020.12.09 08:43:03.303 1: NUKIDevice (NUKI2_Holztuere) - no I/O device
2020.12.09 08:43:03.303 1: PERL WARNING: Use of uninitialized value $iodev in hash element at ./FHEM/74_NUKIDevice.pm line 270.
2020.12.09 08:43:03.304 1: stacktrace:
2020.12.09 08:43:03.304 1: main::__ANON__ called by ./FHEM/74_NUKIDevice.pm (270)
2020.12.09 08:43:03.304 1: FHEM::NUKIDevice::Define called by fhem.pl (3810)
2020.12.09 08:43:03.304 1: main::CallFn called by fhem.pl (2096)
2020.12.09 08:43:03.304 1: main::CommandDefine called by fhem.pl (1247)
2020.12.09 08:43:03.304 1: main::AnalyzeCommand called by fhem.pl (1098)
2020.12.09 08:43:03.304 1: main::AnalyzeCommandChain called by fhem.pl (1385)
2020.12.09 08:43:03.304 1: main::CommandInclude called by fhem.pl (609)
2020.12.09 08:43:03.304 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/74_NUKIDevice.pm line 288.
2020.12.09 08:43:03.304 1: stacktrace:
2020.12.09 08:43:03.305 1: main::__ANON__ called by ./FHEM/74_NUKIDevice.pm (288)
2020.12.09 08:43:03.305 1: FHEM::NUKIDevice::Define called by fhem.pl (3810)
2020.12.09 08:43:03.305 1: main::CallFn called by fhem.pl (2096)
2020.12.09 08:43:03.305 1: main::CommandDefine called by fhem.pl (1247)
2020.12.09 08:43:03.305 1: main::AnalyzeCommand called by fhem.pl (1098)
2020.12.09 08:43:03.305 1: main::AnalyzeCommandChain called by fhem.pl (1385)
2020.12.09 08:43:03.305 1: main::CommandInclude called by fhem.pl (609)
2020.12.09 08:43:03.314 1: PERL WARNING: Use of uninitialized value in numeric comparison (<=>) at fhem.pl line 2199, <$fh> line 24274.
2020.12.09 08:43:03.314 1: stacktrace:
2020.12.09 08:43:03.314 1: main::__ANON__ called by fhem.pl (2199)
2020.12.09 08:43:03.314 1: main::AssignIoPort called by ./FHEM/74_NUKIDevice.pm (258)
2020.12.09 08:43:03.314 1: FHEM::NUKIDevice::Define called by fhem.pl (3810)
2020.12.09 08:43:03.315 1: main::CallFn called by fhem.pl (2096)
2020.12.09 08:43:03.315 1: main::CommandDefine called by fhem.pl (1247)
2020.12.09 08:43:03.315 1: main::AnalyzeCommand called by fhem.pl (1098)
2020.12.09 08:43:03.315 1: main::AnalyzeCommandChain called by fhem.pl (1385)
2020.12.09 08:43:03.315 1: main::CommandInclude called by fhem.pl (609)
2020.12.09 08:43:03.317 1: PERL WARNING: Use of uninitialized value in numeric comparison (<=>) at fhem.pl line 2199, <$fh> line 24274.
2020.12.09 08:43:03.317 1: stacktrace:
2020.12.09 08:43:03.317 1: main::__ANON__ called by fhem.pl (2199)
2020.12.09 08:43:03.317 1: main::AssignIoPort called by ./FHEM/74_NUKIDevice.pm (258)
2020.12.09 08:43:03.317 1: FHEM::NUKIDevice::Define called by fhem.pl (3810)
2020.12.09 08:43:03.317 1: main::CallFn called by fhem.pl (2096)
2020.12.09 08:43:03.317 1: main::CommandDefine called by fhem.pl (1247)
2020.12.09 08:43:03.318 1: main::AnalyzeCommand called by fhem.pl (1098)
2020.12.09 08:43:03.318 1: main::AnalyzeCommandChain called by fhem.pl (1385)
2020.12.09 08:43:03.318 1: main::CommandInclude called by fhem.pl (609)
2020.12.09 08:43:03.318 1: PERL WARNING: Use of uninitialized value in numeric comparison (<=>) at fhem.pl line 2199, <$fh> line 24274.
2020.12.09 08:43:03.318 1: stacktrace:
2020.12.09 08:43:03.318 1: main::__ANON__ called by fhem.pl (2199)
2020.12.09 08:43:03.318 1: main::AssignIoPort called by ./FHEM/74_NUKIDevice.pm (258)
2020.12.09 08:43:03.318 1: FHEM::NUKIDevice::Define called by fhem.pl (3810)
2020.12.09 08:43:03.318 1: main::CallFn called by fhem.pl (2096)
2020.12.09 08:43:03.318 1: main::CommandDefine called by fhem.pl (1247)
2020.12.09 08:43:03.318 1: main::AnalyzeCommand called by fhem.pl (1098)
2020.12.09 08:43:03.319 1: main::AnalyzeCommandChain called by fhem.pl (1385)
2020.12.09 08:43:03.319 1: main::CommandInclude called by fhem.pl (609)
2020.12.09 08:43:03.319 1: PERL WARNING: Use of uninitialized value in numeric comparison (<=>) at fhem.pl line 2199, <$fh> line 24274.
2020.12.09 08:43:03.319 1: stacktrace:
2020.12.09 08:43:03.319 1: main::__ANON__ called by fhem.pl (2199)
2020.12.09 08:43:03.319 1: main::AssignIoPort called by ./FHEM/74_NUKIDevice.pm (258)
2020.12.09 08:43:03.319 1: FHEM::NUKIDevice::Define called by fhem.pl (3810)
2020.12.09 08:43:03.319 1: main::CallFn called by fhem.pl (2096)
2020.12.09 08:43:03.319 1: main::CommandDefine called by fhem.pl (1247)
2020.12.09 08:43:03.319 1: main::AnalyzeCommand called by fhem.pl (1098)
2020.12.09 08:43:03.319 1: main::AnalyzeCommandChain called by fhem.pl (1385)
2020.12.09 08:43:03.320 1: main::CommandInclude called by fhem.pl (609)
2020.12.09 08:43:03.320 1: PERL WARNING: Use of uninitialized value in numeric comparison (<=>) at fhem.pl line 2199, <$fh> line 24274.
2020.12.09 08:43:03.320 1: stacktrace:
2020.12.09 08:43:03.320 1: main::__ANON__ called by fhem.pl (2199)
2020.12.09 08:43:03.320 1: main::AssignIoPort called by ./FHEM/74_NUKIDevice.pm (258)
2020.12.09 08:43:03.320 1: FHEM::NUKIDevice::Define called by fhem.pl (3810)
2020.12.09 08:43:03.320 1: main::CallFn called by fhem.pl (2096)
2020.12.09 08:43:03.320 1: main::CommandDefine called by fhem.pl (1247)
2020.12.09 08:43:03.320 1: main::AnalyzeCommand called by fhem.pl (1098)
2020.12.09 08:43:03.320 1: main::AnalyzeCommandChain called by fhem.pl (1385)
2020.12.09 08:43:03.320 1: main::CommandInclude called by fhem.pl (609)
2020.12.09 08:43:03.321 1: PERL WARNING: Use of uninitialized value in numeric comparison (<=>) at fhem.pl line 2199, <$fh> line 24274.
2020.12.09 08:43:03.321 1: stacktrace:
2020.12.09 08:43:03.321 1: main::__ANON__ called by fhem.pl (2199)
2020.12.09 08:43:03.321 1: main::AssignIoPort called by ./FHEM/74_NUKIDevice.pm (258)
2020.12.09 08:43:03.321 1: FHEM::NUKIDevice::Define called by fhem.pl (3810)
2020.12.09 08:43:03.321 1: main::CallFn called by fhem.pl (2096)
2020.12.09 08:43:03.321 1: main::CommandDefine called by fhem.pl (1247)
2020.12.09 08:43:03.321 1: main::AnalyzeCommand called by fhem.pl (1098)
2020.12.09 08:43:03.321 1: main::AnalyzeCommandChain called by fhem.pl (1385)
2020.12.09 08:43:03.321 1: main::CommandInclude called by fhem.pl (609)
2020.12.09 08:43:03.322 1: PERL WARNING: Use of uninitialized value in numeric comparison (<=>) at fhem.pl line 2199, <$fh> line 24274.
2020.12.09 08:43:03.322 1: stacktrace:
2020.12.09 08:43:03.322 1: main::__ANON__ called by fhem.pl (2199)
2020.12.09 08:43:03.322 1: main::AssignIoPort called by ./FHEM/74_NUKIDevice.pm (258)
2020.12.09 08:43:03.322 1: FHEM::NUKIDevice::Define called by fhem.pl (3810)
2020.12.09 08:43:03.322 1: main::CallFn called by fhem.pl (2096)
2020.12.09 08:43:03.322 1: main::CommandDefine called by fhem.pl (1247)
2020.12.09 08:43:03.322 1: main::AnalyzeCommand called by fhem.pl (1098)
2020.12.09 08:43:03.323 1: main::AnalyzeCommandChain called by fhem.pl (1385)
2020.12.09 08:43:03.323 1: main::CommandInclude called by fhem.pl (609)
2020.12.09 08:43:03.329 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/74_NUKIDevice.pm line 288, <$fh> line 24274.
2020.12.09 08:43:03.329 1: stacktrace:
2020.12.09 08:43:03.329 1: main::__ANON__ called by ./FHEM/74_NUKIDevice.pm (288)
2020.12.09 08:43:03.329 1: FHEM::NUKIDevice::Define called by fhem.pl (3810)
2020.12.09 08:43:03.329 1: main::CallFn called by fhem.pl (2096)
2020.12.09 08:43:03.329 1: main::CommandDefine called by fhem.pl (1247)
2020.12.09 08:43:03.329 1: main::AnalyzeCommand called by fhem.pl (1098)
2020.12.09 08:43:03.329 1: main::AnalyzeCommandChain called by fhem.pl (1385)
2020.12.09 08:43:03.329 1: main::CommandInclude called by fhem.pl (609)
2020.12.09 08:43:03.333 1: PERL WARNING: Use of uninitialized value in numeric comparison (<=>) at fhem.pl line 2199, <$fh> line 24296.
2020.12.09 08:43:03.333 1: stacktrace:
2020.12.09 08:43:03.333 1: main::__ANON__ called by fhem.pl (2199)
2020.12.09 08:43:03.333 1: main::AssignIoPort called by ./FHEM/10_MQTT2_DEVICE.pm (89)
2020.12.09 08:43:03.333 1: main::MQTT2_DEVICE_Define called by fhem.pl (3810)
2020.12.09 08:43:03.333 1: main::CallFn called by fhem.pl (2096)
2020.12.09 08:43:03.333 1: main::CommandDefine called by fhem.pl (1247)
2020.12.09 08:43:03.333 1: main::AnalyzeCommand called by fhem.pl (1098)
2020.12.09 08:43:03.333 1: main::AnalyzeCommandChain called by fhem.pl (1385)
2020.12.09 08:43:03.334 1: main::CommandInclude called by fhem.pl (609)
2020.12.09 08:43:03.336 1: PERL WARNING: Use of uninitialized value in numeric comparison (<=>) at fhem.pl line 2199, <$fh> line 24296.
2020.12.09 08:43:03.336 1: stacktrace:
2020.12.09 08:43:03.336 1: main::__ANON__ called by fhem.pl (2199)
2020.12.09 08:43:03.336 1: main::AssignIoPort called by ./FHEM/10_MQTT2_DEVICE.pm (89)
2020.12.09 08:43:03.337 1: main::MQTT2_DEVICE_Define called by fhem.pl (3810)
2020.12.09 08:43:03.337 1: main::CallFn called by fhem.pl (2096)
2020.12.09 08:43:03.337 1: main::CommandDefine called by fhem.pl (1247)
2020.12.09 08:43:03.337 1: main::AnalyzeCommand called by fhem.pl (1098)
2020.12.09 08:43:03.337 1: main::AnalyzeCommandChain called by fhem.pl (1385)
2020.12.09 08:43:03.337 1: main::CommandInclude called by fhem.pl (609)
2020.12.09 08:43:03.337 1: PERL WARNING: Use of uninitialized value in numeric comparison (<=>) at fhem.pl line 2199, <$fh> line 24296.
2020.12.09 08:43:03.337 1: stacktrace:
2020.12.09 08:43:03.337 1: main::__ANON__ called by fhem.pl (2199)
2020.12.09 08:43:03.337 1: main::AssignIoPort called by ./FHEM/10_MQTT2_DEVICE.pm (89)
2020.12.09 08:43:03.337 1: main::MQTT2_DEVICE_Define called by fhem.pl (3810)
2020.12.09 08:43:03.338 1: main::CallFn called by fhem.pl (2096)
2020.12.09 08:43:03.338 1: main::CommandDefine called by fhem.pl (1247)
2020.12.09 08:43:03.338 1: main::AnalyzeCommand called by fhem.pl (1098)
2020.12.09 08:43:03.338 1: main::AnalyzeCommandChain called by fhem.pl (1385)
2020.12.09 08:43:03.338 1: main::CommandInclude called by fhem.pl (609)
2020.12.09 08:43:03.338 1: PERL WARNING: Use of uninitialized value in numeric comparison (<=>) at fhem.pl line 2199, <$fh> line 24296.
2020.12.09 08:43:03.338 1: stacktrace:
2020.12.09 08:43:03.338 1: main::__ANON__ called by fhem.pl (2199)
2020.12.09 08:43:03.338 1: main::AssignIoPort called by ./FHEM/10_MQTT2_DEVICE.pm (89)
2020.12.09 08:43:03.338 1: main::MQTT2_DEVICE_Define called by fhem.pl (3810)
2020.12.09 08:43:03.338 1: main::CallFn
Die Meldungen zeigen, dass irgendwer (vermutlich einer der Module) einen %defs Eintrag ohne NR Feld angelegt hat.
Um die Ursache zu lokalisieren startet man fhem mit "attr global verbose 5" (oder mit perl fhem.pl -d fhem.cfg), und zeigt hier die Ausgaben vor dem ersten Auftreten dieses Fehlers.
Es duerfte aber nicht im Zusammenhang mit dem urspruenglichen Fehler sein, da MQTT2_SERVER auch ohne diese IODev Zuweisung Client Verbindungen akzeptiert.
Zu dem restart bzw. Problem im MQTT Modul (ohne 2) kann ich nichts sagen, ist nicht meine Baustelle.
Zitat von: rudolfkoenig am 09 Dezember 2020, 09:48:01
Die Meldungen zeigen, dass irgendwer (vermutlich einer der Module) einen %defs Eintrag ohne NR Feld angelegt hat.
Um die Ursache zu lokalisieren startet man fhem mit "attr global verbose 5" (oder mit perl fhem.pl -d fhem.cfg), und zeigt hier die Ausgaben vor dem ersten Auftreten dieses Fehlers.
Es duerfte aber nicht im Zusammenhang mit dem urspruenglichen Fehler sein, da MQTT2_SERVER auch ohne diese IODev Zuweisung Client Verbindungen akzeptiert.
Zu dem restart bzw. Problem im MQTT Modul (ohne 2) kann ich nichts sagen, ist nicht meine Baustelle.
Hallo Rudolf, konnte es dank deiner Tipps wiederbeleben.
hier die relevanten Zeitpunkte:
[b]Tasmota WEBUI LOG [/b]
13:12:25 MQT: tele/TA_SOR2/STATE = {"Time":"2020-12-09T13:12:25","Uptime":"0T15:07:21","UptimeSec":54441,"Heap":26,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":28,"POWER1":"OFF","POWER2":"OFF","Wifi":{"AP":1,"SSId":"TR7272","BSSId":"46:A4:3C:DD:17:FA","Channel":4,"RSSI":100,"Signal":-44,"LinkCount":1,"Downtime":"0T00:00:07"}}
13:17:25 MQT: tele/TA_SOR2/STATE = {"Time":"2020-12-09T13:17:25","Uptime":"0T15:12:21","UptimeSec":54741,"Heap":26,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":28,"POWER1":"OFF","POWER2":"OFF","Wifi":{"AP":1,"SSId":"TR7272","BSSId":"46:A4:3C:DD:17:FA","Channel":4,"RSSI":100,"Signal":-43,"LinkCount":1,"Downtime":"0T00:00:07"}}
13:17:27 MQT: Attempting connection...
13:17:42 MQT: Connect failed to 192.168.0.9:1893, rc -4. Retry in 10 sec
13:17:53 MQT: Attempting connection...
13:18:08 MQT: Connect failed to 192.168.0.9:1893, rc -4. Retry in 10 sec
13:18:19 MQT: Attempting connection...
13:18:37 MQT: Connect failed to 192.168.0.9:1893, rc -4. Retry in 10 sec
13:18:48 MQT: Attempting connection...
13:19:03 MQT: Connect failed to 192.168.0.9:1893, rc -4. Retry in 10 sec
13:19:14 MQT: Attempting connection...
13:19:29 MQT: Connect failed to 192.168.0.9:1893, rc -4. Retry in 10 sec
13:19:39 MQT: Attempting connection...
13:19:54 MQT: Connect failed to 192.168.0.9:1893, rc -4. Retry in 10 sec
13:20:05 MQT: Attempting connection...
13:20:16 MQT: Connected
13:20:16 MQT: tele/TA_SOR2/LWT = Online (retained)
13:20:16 MQT: cmnd/TA_SOR2/POWER =
13:24:07 MQT: tele/TA_SOR2/STATE = {"Time":"2020-12-09T13:24:0
[b]
fhem log :[/b]
2020.12.09 13:17:33.100 5: MQTT2_TR_UB9: dispatch autocreate=complex\000DVES_A53E29\000tele/TA_SOR2/LWT\000Offline
2020.12.09 13:20:15.346 5: in: PUBLISH: 1(25)(0)(17)tele/TA_SORF2/LWTOnline
2020.12.09 13:20:15.346 4: MQTT2_TR_UB9_192.168.6.126_49967 DVES_8CE2E6 PUBLISH tele/TA_SORF2/LWT:Online
fhem log als attachment
Danke fürs Schauen.
VG T
Hallo
also ich habe auch mehrfach zerschlagene Readingslist attribute und Readings
.
Weiss nicht woher die kommen? Irgendwas verschluckt sich da, oder?
attr TA_G2 readingList 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) }\
DVES_F466C9:stat/TA_G2/LOGGING:.* LOGGING\
DVES_F466C9:fgHolder\x22_4617\x2c\x22BootCount\x22_290\x2c\x22BCResetTim:.* fgHolder__4617__BootCount__290__BCResetTim\
DVES_F466C9:4\x22\x2c\x22Sleep\x22_50\x2c\x22CfgHolder\x22_4617\x2c\x22BootCount\x22_295\x2c\x22B:.* 4___Sleep__50__CfgHolder__4617__BootCount__295__B\
DVES_F466C9:oday\x22_0\x5c\x2e007\x2c\x22Power\x22_5\x2c\x22ApparentPower\x22_7\x2c\x22R:.* oday__0.007__Power__5__ApparentPower__7__R\
DVES_F466C9:\x22FlashSize\x22_1024\x2c\x22FlashChipId\x22_\x22144051\x22\x2c\x22FlashFr:.* _FlashSize__1024__FlashChipId___144051___FlashFr\
DVES_F466C9:9\x2c20\x2c21\x2c22\x2c24\x2c26\x2c27\x2c29\x2c30\x2c35\x2c37\x22\x2c\x22Sensors\x22_\x221\x2c2\x2c3\x2c4\x2c5\x2c:.* 9_20_21_22_24_26_27_29_30_35_37___Sensors___1_2_3_4_5_\
DVES_F466C9:0\x97\x03:.* 0__\
DVES_F466C9:stat\xc0:.* stat_\
DVES_F466C9:DeviceName\x22_\x22TA_G2\x22\x2c\x22FriendlyName\x22_\x5c\x5b\x22TA_G2\x22\x5c\x5d\x2c\x22Topic:.* DeviceName___TA_G2___FriendlyName____TA_G2____Topic\
DVES_F466C9:01\x2c\x22Power\x22_0\x2c\x22ApparentPower\x22_0\x2c\x22ReactivePower\x22:.* 01__Power__0__ApparentPower__0__ReactivePower_\
DVES_F466C9:Factor\x22_0\x5c\x2e00\x2c\x22Voltage\x22_0\x2c\x22Current\x22_0\x5c\x2e000\x7d\x7d\x7d0\xc4\x02:.* Factor__0.00__Voltage__0__Current__0.000___0__\
DVES_F466C9:_46_59\x22\x2c\x22ENERGY\x22_\x7b\x22TotalStartTime\x22_\x222020-02-09T07_45_20\x22\x2c\x22Total\x22_3\x5c\x2e673\x2c\x22Yesterday\x22:.* _46_59___ENERGY____TotalStartTime___2020-02-09T07_45_20___Total__3.673__Yesterday_\
DVES_F466C9:15\x2c\x22Today\x22_0\x5c\x2e001\x2c\x22Power\x22_0\x2c\x22ApparentPower\x22_0\x2c\x22:.* 15__Today__0.001__Power__0__ApparentPower__0__\
DVES_F466C9:\x22Total\x22_3\x5c\x2e673\x2c\x22Yesterday\x22_0\x5c\x2e015\x2c\x22Today\x22_0\x5c\x2e001\x2c:.* _Total__3.673__Yesterday__0.015__Today__0.001_\
DVES_F466C9:LoadAvg\x22_33\x2c\x22MqttCount\x22_3\x2c\x22POWER\x22_\x22OFF\x22\x2c\x22Wifi\x22:.* LoadAvg__33__MqttCount__3__POWER___OFF___Wifi_\
DVES_F466C9:P\x22_1\x2c\x22SSId\x22_\x22TR7272\x22\x2c\x22BSSId\x22_\x2246_A4_3C_DD_17_FA\x22\x2c\x22Channel\x22_4\x2c\x22RSSI\x22_100\x2c\x22Signal\x22_-49\x2c\x22LinkCount\x22_1\x2c\x22Downtime\x22_\x220T00_00_09:.* P__1__SSId___TR7272___BSSId___46_A4_3C_DD_17_FA___Channel__4__RSSI__100__Signal__-49__LinkCount__1__Downtime___0T00_00_09\
DVES_F466C9:07\x2c\x22Yesterday\x22_0\x2e010\x2c\x22Today\x22_0\x2e003\x2c\x22Power\x22_0\x2c\x22App:.* 07__Yesterday__0.010__Today__0.003__Power__0__App\
DVES_F466C9:0\xf0\x01:.* 0__\
DVES_F466C9:oday\x22_0\x2e001\x2c\x22Power\x22_0\x2c\x22ApparentPower\x22_0\x2c\x22R:.* oday__0.001__Power__0__ApparentPower__0__R\
DVES_F466C9:-11-26T11_16_02\x22\x2c\x22ENERGY\x22_\x7b\x22TotalStartTime\x22_\x222:.* -11-26T11_16_02___ENERGY____TotalStartTime___2\
DVES_F466C9:02-09T07_45_20\x22\x2c\x22Total\x22_3\x2e779\x2c\x22Yesterday\x22_0\x2e009\x2c:.* 02-09T07_45_20___Total__3.779__Yesterday__0.009_\
DVES_F466C9:LoadAvg\x22_38\x2c\x22MqttCount\x22_1\x2c\x22POWER\x22_\x22OFF\x22\x2c\x22Wifi\x22:.* LoadAvg__38__MqttCount__1__POWER___OFF___Wifi_\
DVES_F466C9::.* UNDEFINED\
DVES_F466C9:-30T09_50_33\x22\x2c\x22ENERGY\x22_\x7b\x22TotalStartTime\x22_\x222:.* -30T09_50_33___ENERGY____TotalStartTime___2\
DVES_F466C9:02-09T07_45_20\x22\x2c\x22Total\x22_3\x2e822\x2c\x22Yesterday\x22_0\x2e012\x2c:.* 02-09T07_45_20___Total__3.822__Yesterday__0.012_\
DVES_F466C9:\x2c\x2200006000\x22\x2c\x2200000000\x22\x5d\x7d\x7d0\xf4\x02:.* __00006000___00000000____0__\
DVES_F466C9:0000005A00000000000000\x22\x2c\x22008000C8\x22\x2c\x2200006000\x22\x2c:.* 0000005A00000000000000___008000C8___00006000__\
DVES_F466C9:\x22\x2c\x22FlashFrequency\x22_40\x2c\x22FlashMode\x22_3\x2c\x22Features\x22:.* ___FlashFrequency__40__FlashMode__3__Features_\
DVES_F466C9:0000809\x22\x2c\x228FDAE797\x22\x2c\x2204368001\x22\x2c\x22000000CD\x22\x2c\x22010013C0\x22\x2c\x22C000F981\x22\x2c\x2200004004\x22\x2c\x2200000000\x22\x5d\x2c\x22D:.* 0000809___8FDAE797___04368001___000000CD___010013C0___C000F981___00004004___00000000____D
attr TA_G2 room 1_WZ_Licht,9_DekoLicht,9_Tasmota,MQTT2_DEVICE
Ja, irgendwas verschluckt sich da, das erinnert mich an https://forum.fhem.de/index.php/topic,114911.msg1091325.html#msg1091325. Auch bei dem ist es so, dass das WLAN evtl. nicht optimal ist oder der ESP(32, in dem Fall) einen Hau hat.
Grundsätzlich weiß ich auch nicht, warum du unbedingt "complex" für autocreate am Server eingestellt hast (hatten wir das Themanicht schon mal? simple ist in der Regel ausreichend, den Rest kann man bei Bedarf nachsteuern); da Tasmota neuerdings (9.x?) ziemlich viele STATUSn-Pfade verwendet, wurde das halt zusätzlich angelegt, früher was dasselbe (oder etwas weniger) in INFO[1-3].
Ist dein FHEM aktuell?
In den 5 Minuten des Logs befindet sich 42-mal die Meldung "Closing second connection for...", fuer 14 unterschiedliche Geraete. Die Meldung kommt dann, wenn das Endgeraet eine zweite(!) Verbindung mit der gleichen ClientID und IP aufmacht, und danach die erste ohne "Auf wiedersehen" zu sagen schliesst. Ich vermute, dass irgendwas mit dem Netzwerk nicht in Ordnung ist.
Ich habe im Log 30 unterschiedliche IP-Adressen gezaehlt: bist Du sicher, dass du nicht das klassische "zu viele WLAN-Geraete fuer den WLAN-AP" Problem hast?
Ich sehe auch 4211 dispatch Zeilen, d.h. 14 MQTT-Nachrichten/sec. Wie ist die Auslastung (CPU) des FHEM Servers?
Beim DVES_F466C9 readingList scheint wirklich was kaputtgegangen zu sein, allerdings ist im anderen Log dieses Geraet auch merkwuerdig:
- irgendwann Verbindung zu wg. keepalive check
- CONNECT eine Minute spaeter, allerdings ohne SUBSCRIBE.
- danach EOF: Verbindung zu, ohne "Auf wiedersehen".
Zitat von: Beta-User am 09 Dezember 2020, 16:44:38
Ja, irgendwas verschluckt sich da, das erinnert mich an https://forum.fhem.de/index.php/topic,114911.msg1091325.html#msg1091325. Auch bei dem ist es so, dass das WLAN evtl. nicht optimal ist oder der ESP(32, in dem Fall) einen Hau hat.
Grundsätzlich weiß ich auch nicht, warum du unbedingt "complex" für autocreate am Server eingestellt hast (hatten wir das Themanicht schon mal? simple ist in der Regel ausreichend, den Rest kann man bei Bedarf nachsteuern); da Tasmota neuerdings (9.x?) ziemlich viele STATUSn-Pfade verwendet, wurde das halt zusätzlich angelegt, früher was dasselbe (oder etwas weniger) in INFO[1-3].
ah danke das hatte ich noch nicht gesehen. Werde mal autocreate reduzieren auf simple.
Frage hier, wie die Abhängigkeit von device autocreate und in dem Attribute autocreate bei MQTT2_DEVICES genau ist.
Device autocreate habe ich meist auf disabled 1 .
Denke das
attr MQTT2_DEVICES autocreate ist unabhängig und nur für MQTT"_Devices gültig.
Danke VG T
Also, "autocreate":
Habe grade noch was in https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele#autocreate_funktioniert_anscheinend_nicht.3F ergänzt; da steht es hoffentlich jetzt halbwegs verständlich, wie die einzelnen Ebenen zusammenspielen.
Zitat von: rudolfkoenig am 09 Dezember 2020, 16:56:33
Ist dein FHEM aktuell?
In den 5 Minuten des Logs befindet sich 42-mal die Meldung "Closing second connection for...", fuer 14 unterschiedliche Geraete. Die Meldung kommt dann, wenn das Endgeraet eine zweite(!) Verbindung mit der gleichen ClientID und IP aufmacht, und danach die erste ohne "Auf wiedersehen" zu sagen schliesst. Ich vermute, dass irgendwas mit dem Netzwerk nicht in Ordnung ist.
Ich habe im Log 30 unterschiedliche IP-Adressen gezaehlt: bist Du sicher, dass du nicht das klassische "zu viele WLAN-Geraete fuer den WLAN-AP" Problem hast?
Ich sehe auch 4211 dispatch Zeilen, d.h. 14 MQTT-Nachrichten/sec. Wie ist die Auslastung (CPU) des FHEM Servers?
Beim DVES_F466C9 readingList scheint wirklich was kaputtgegangen zu sein, allerdings ist im anderen Log dieses Geraet auch merkwuerdig:
- irgendwann Verbindung zu wg. keepalive check
- CONNECT eine Minute spaeter, allerdings ohne SUBSCRIBE.
- danach EOF: Verbindung zu, ohne "Auf wiedersehen".
Hallo Rudi,
vielen Dank erstmal.
ich habe 6 Unifi APs , denke das sollte nicht das Problem des WLANs sein, würde ich aber dann gerne eingrenzen wollen. Hast du da einen Tipp?
Ja es sind viele Tasmotas im Einsatz.
Einige auch noch als ESP_Easy Devices, die aber über Mosquitto oder der ESPBridge.
Um Fhem zu entlasten wollte ich ja Mosquito auslagern.
Fhem ist aktuell, bis auf einige HM Module die zurückgehalten sind wegen TSCULF.
Bezüglich redundanten Clients forsche ich mal. Denke es entsteht durch nicht korrekte LW Status Werte.
die Auslastung muss ich mal genau schauen. Es läuft eigentlich nur FHEM und Unifi controller auf dem Linux Server. Alte HW.
Danke VG T
Auch ich habe u.a. viele esps 8266 mit Tasmota im Einsatz.
In Kombination Mosquitto (auf Synology) --> MQTT2_CLIENT --> MQTT2_DEVICE
und auch in Kombination Mosquitto --> MQTT2_CLIENT --> MQTT_GENERIC_BRIDGE
Die Umstellung auf MQTT2_CLIENT --> MQTT2_DEVICE hat bei mir problemlos funktioniert.
Anmerkung: ich verwende kein autocreate.
Letzte Woche hatte ich grössere Probleme mit meinem WLAN nachdem ich meinem UNIFI Controller ein Update verpasst hatte.
Dies hatte auch Auswirkung auf FHEM.
Beim Update wurde mir angeboten für 2,4GHz und 5GHz die gleiche SSID zu verwenden.
Seitdem ich diese Änderung rückgängig gemacht habe läuft wieder alle bestens.
Vielleicht hifts?
Zitat von: Billy am 10 Dezember 2020, 16:15:37
Auch ich habe u.a. viele esps 8266 mit Tasmota im Einsatz.
In Kombination Mosquitto (auf Synology) --> MQTT2_CLIENT --> MQTT2_DEVICE
und auch in Kombination Mosquitto --> MQTT2_CLIENT --> MQTT_GENERIC_BRIDGE...
Beim Update wurde mir angeboten für 2,4GHz und 5GHz die gleiche SSID zu verwenden.
Seitdem ich diese Änderung rückgängig gemacht habe läuft wieder alle bestens.
Vielleicht hifts?
Hatte auch schon diverse Probleme mit Unifi, wurden aber nie gelöst. Meist lag es wohl an den ESP8266, bei dem einen, der sich laufend auslogged hatte ich gestern die gleiche Firmware noch mal drauf gemacht, dann ging es wieder besser.
das mit den SSID 2.4 und 5 verstehe ich nicht ganz, die ESP8266 verbinden sich doch eh nur mit dem 2.4? hast du dann 2 SSIDs für 5 und 2.4 Ghz?
bezüglich:
Zitat--> MQTT2_CLIENT --> MQTT2_DEVICE
und auch in Kombination Mosquitto --> MQTT2_CLIENT --> MQTT_GENERIC_BRIDGE...
hier bin ich noch am Schauen. Denke werde auch wieder zu Mosquitto wechseln, dann dann ich das besser kontrollieren als in FHEM mit dem MQTT2_Server . Allerdings habe ich noch nicht den richtigen Migrationspfad heraus. Wie sind deine Erfahrungen mit der generic Bridge?
Merkwürdigerweise hat er bei mir gestern, nachdem ich das Device MQTT2_CLIENT mit Type MQTT2_CLIENT , dann noch MQTT2_Devices mit Prefix MQTT2_MQTT2_CLIENT als MQTT2_DEVICE angelegt.
Aber da bin ich noch am Aufschlauen. Richtig einfach ist das nicht mir den Readings die teilweise entstehen.
Muss aber erstmal die Stabilität wieder hinbekommen.Momentan zu viele MQTT disconnects.
VG Thomas
Zitat von: riker1 am 10 Dezember 2020, 17:19:17
das mit den SSID 2.4 und 5 verstehe ich nicht ganz, die ESP8266 verbinden sich doch eh nur mit dem 2.4? hast du dann 2 SSIDs für 5 und 2.4 Ghz?
...hier im Haus sind auch schon viele verwundert über die vielen WLAN-Netze, die man so haben kann...
Aber wenn man so einem ESP ziemlich genau sagen kann, auf welchen AP er sich aufschalten soll, hilft das ungemein (es sei denn, der AP ist zu weit weg, dann bekommt man uU. komische readingList-Einträge, s.o.).
Zitatdann dann ich das besser kontrollieren als in FHEM mit dem MQTT2_Server .
Besseren support als durch Rudi wirst du vermutlich kaum bekommen, mein Verdacht ist eher, dass mosquitto viele Probleme versteckt und du irgendwann aufwachen wirst mit einem genauso großen Stall voll Probleme, wenn sich mal jemand daran macht, mosquitto "exakter" zu machen und du danach ein update von dem Teil machst ;) .
Jedenfalls ist mir völlig unklar, wie man einen mosquitto "kontrolliert".
Zitat
Allerdings habe ich noch nicht den richtigen Migrationspfad heraus. Wie sind deine Erfahrungen mit der generic Bridge?
Nochmal: in deinem setup brauchst du keine MQTT_GENERIC_BRIDGE... Du kannst damit allerdings mit ihr und dem unbedachten Setzen von ein paar Attributen richtig "Spaß" erzeugen. Lass also bitte erst mal die Finger weg von diesem Modul, im mindesten Fall bis dir klar ist, wann man sie wofür braucht.
Zitat
Merkwürdigerweise hat er bei mir gestern, nachdem ich das Device MQTT2_CLIENT mit Type MQTT2_CLIENT , dann noch MQTT2_Devices mit Prefix MQTT2_MQTT2_CLIENT als MQTT2_DEVICE angelegt.
Das ist nicht merkwürdig, sondern die ganz normale Folge, wenn man MQTT2_CLIENT betreibt und autocreate aktiviert.
Auch wenn es ggf. sehr verwirrend ist: du musst dich im Wiki mit dem MQTT2_CLIENT-Artikel vertraut machen und dann auch passende ignoreRegexp setzen, sonst gibt das heilloses Chaos, wenn du autocreate weiter verwenden willst.
(Kopfschüttel)
Zitat von: Beta-User am 10 Dezember 2020, 17:31:52
Besseren support als durch Rudi wirst du vermutlich kaum bekommen, mein Verdacht ist eher, dass mosquitto viele Probleme versteckt und du irgendwann aufwachen wirst mit einem genauso großen Stall voll Probleme, wenn sich mal jemand daran macht, mosquitto "exakter" zu machen und du danach ein update von dem Teil machst ;) .
Jedenfalls ist mir völlig unklar, wie man einen mosquitto "kontrolliert".
Hallo
ja der support ist absolut super, mit ist der MQTT2 Server nur etwas intransparent...liegt sicher an meinem mangelnden Wissen.
Mosquitto kann ich halt auf einen anderen Server verlagern und als eigenen unix process monitoren und einfacher eine Testinstanz betreiben.
Wie kann ich denn die Auslastung des MQTT2 Servers monitoren? Wahrscheinlich habe ich hier was verpasst?
vielen Dank dir auch für deine Darstellungen und die WIKI Einträge.
Zitat
Zitat
Merkwürdigerweise hat er bei mir gestern, nachdem ich das Device MQTT2_CLIENT mit Type MQTT2_CLIENT , dann noch MQTT2_Devices mit Prefix MQTT2_MQTT2_CLIENT als MQTT2_DEVICE angelegt.
Das ist nicht merkwürdig, sondern die ganz normale Folge, wenn man MQTT2_CLIENT betreibt und autocreate aktiviert.
Auch wenn es ggf. sehr verwirrend ist: du musst dich im Wiki mit dem MQTT2_CLIENT-Artikel vertraut machen und dann auch passende ignoreRegexp setzen, sonst gibt das heilloses Chaos, wenn du autocreate weiter verwenden willst.
Deswegen hatte ich ja eigentlich immer autocreate als Type disabled. nur wenn ich ein neues Device einhänge mal kurz an. Ich war nur überrascht das der MC Client auch als eigenes MC Device angelegt wurde. Bei den anderen Devices war es mir klar.
Hatte auch die entsprechenden Ignore Regex gesetzt.
...eventuell ging durch die Fehlersuche auch einiges Durcheinander.
ZitatZitat von: riker1 am Heute um 17:19:17
das mit den SSID 2.4 und 5 verstehe ich nicht ganz, die ESP8266 verbinden sich doch eh nur mit dem 2.4? hast du dann 2 SSIDs für 5 und 2.4 Ghz?
...hier im Haus sind auch schon viele verwundert über die vielen WLAN-Netze, die man so haben kann...
Aber wenn man so einem ESP ziemlich genau sagen kann, auf welchen AP er sich aufschalten soll, hilft das ungemein (es sei denn, der AP ist zu weit weg, dann bekommt man uU. komische readingList-Einträge, s.o.).
Ich hatte hier extra bei Unifi eigene SSID für die ESPs eingerichtet, damit ich die gut kontrollieren kann. Leider ist die WLAN Stabilät der ESP manchmal auch schlecht. Hängt wohl auch oft mit mangelnder Stromversorgung zusammen. Hatte früher alles mit ESPEASY , die schienen mir aber instabiler als die Tasmotas in Bezug auf WLAN und Load.
Da bin ich weiter am experimentieren.
Vielen Dank nochmal an Dich und Rudi, und natürlich allen im Forum echt Klasse
Du kannst ohne weiteres eine Instanz mit FHEMWEB+MQTT2_SERVER bauen und "sonst nichts", dann kannst du nach Belieben testen oder schauen, wie viel Speicher+CPU das in etwa benötigt.
Tendenziell ist es so, dass FHEM die Daten so oder so (unabhängig von MQTT/MQTT2_CLIENT oder MQTT2_SERVER) irgendwann entgegennehmen soll/muss, um sie zu verarbeiten. So wie ich das verstanden habe, beschränkt sich der eigentliche Overhead von MQTT2_SERVER auf die Verwaltung der offenen TCP/IP-Verbindungen (wenn man den Server nur für FHEM-Zwecke nutzt).
Einzig, dass das alles innerhalb des FHEM-Hauptprozesses abläuft, kann ein Problem darstellen, aber das tendenziell auch nur, wenn entweder sehr große Datenmengen umhergeschaufelt werden (sehr uncool via MQTT, das lightweight sein will!) oder viele Events erzeugt werden, die dann zudem noch in FHEM ineffizient verarbeitet werden (fehlende NOTIFYDEV und so).
Von daher wäre es interessant, mal mit den top von außen zu sehen, wie der tatsächliche Unterschied ist, und zum anderen mit freezemon&Co zu checken, ob es Hänger gibt, die mit SERVER in Verbindung stehen könnten.
Ansonsten scheint es einfach so zu sein, dass die ESP-Dinger eben nicht nur billig, sondern auch schlecht designed sind, weswegen es jetzt geschlagene 5+ Jahre gedauert hat, bis die halbwegs stabil laufen (die beobachteten Instabilitäten dürften nicht unbedingt nur von der jeweiligen Variante ESPEasy oder Tasmota (oder Shelly) abhängen, sondern eher von der Version das zugrundeliegenden Frameworks...).
Hallo Rudi,
bin weiter am Schauen und hatte nun noch folgende Fehlermeldungen:
2020.12.11 07:07:56.045 1 : ERROR: Unhandled packet PUBCOMP, disconneting MQTT2_TR_UB9_192.168.6.101_62780
2020.12.11 07:07:56.492 1 : ERROR: Unhandled packet CONNACK, disconneting MQTT2_TR_UB9_192.168.6.101_62780
2020.12.11 07:07:56.662 1 : ERROR: Unhandled packet CONNACK, disconneting MQTT2_TR_UB9_192.168.6.101_62780
2020.12.11 07:07:57.929 1 : ERROR: Unhandled packet PUBCOMP, disconneting MQTT2_TR_UB9_192.168.1.177_64980
2020.12.11 07:07:58.036 1 : PERL WARNING: Use of uninitialized value $pid in pack at ./FHEM/00_MQTT2_SERVER.pm line 359.
2020.12.11 07:07:58.037 1 : stacktrace:
2020.12.11 07:07:58.037 1 : main::__ANON__ called by ./FHEM/00_MQTT2_SERVER.pm (359)
2020.12.11 07:07:58.037 1 : main::MQTT2_SERVER_Read called by ./FHEM/00_MQTT2_SERVER.pm (430)
2020.12.11 07:07:58.037 1 : main::__ANON__ called by ./FHEM/97_timerTS.pm (60)
2020.12.11 07:07:58.037 1 : main::HandleTimeout called by fhem.pl (677)
2020.12.11 07:07:58.037 1 : ERROR: addToWritebuffer for MQTT2_TR_UB9_192.168.1.177_64980 without FD
2020.12.11 07:07:58.037 1 : callstack: addToWritebuffer:219 MQTT2_SERVER_out:359 MQTT2_SERVER_Read:430 __ANON__:60 HandleTimeout:677
2020.12.11 07:07:58.037 1 : FD closed in TcpServer_Close:105 MQTT2_SERVER_Undef:3810 CallFn:2244 CommandDelete:426 MQTT2_SERVER_Read:430 __ANON__:60 HandleTimeout:677
2020.12.11 07:07:59.244 1 : ERROR: Unhandled packet CONNACK, disconneting MQTT2_TR_UB9_192.168.6.101_62780
2020.12.11 07:08:04.023 1 : ERROR: Unhandled packet PUBCOMP, disconneting MQTT2_TR_UB9_192.168.1.150_62377
2020.12.11 07:08:04.526 1 : ERROR: Unhandled packet CONNACK, disconneting MQTT2_TR_UB9_192.168.1.150_62377
2020.12.11 07:08:06.658 1 : ERROR: Unhandled packet CONNACK, disconneting MQTT2_TR_UB9_192.168.1.157_57206
2020.12.11 07:08:06.982 1 : ERROR: Unhandled packet CONNACK, disconneting MQTT2_TR_UB9_192.168.1.150_62377
2020.12.11 07:08:07.092 1 : ERROR: Unhandled packet CONNACK, disconneting MQTT2_TR_UB9_192.168.1.157_57206
2020.12.11 07:08:07.147 1 : ERROR: Unhandled packet PUBCOMP, disconneting MQTT2_TR_UB9_192.168.1.157_57206
Danke T
- "Unhandled packet": der Server liest Muell. Entweder durch Netzwerkprobleme (unwahrscheinlich), oder durch Programmierfehler im MQTT2_SERVER Modul (wahrscheinlich).
- "uninitialized value": Seiteneffekt beim "Muell verstehen". 97_timerTS.pm sagt mir nichts, und es gefaellt mir nicht, dass es hier involviert ist, da ich nicht sicher sein kann, dass es nicht der Verursacher ist.
- "ERROR: addToWriteBuffer": da wird versucht noch was zu parsen, nachdem die Verbindung zugemacht ist. Es fehlt mir z.Zt. die Fantasie vorzustellen, wie das sein kann.
Ich vermute die Clients ueberlasten den Server, debuggen wird aufwendig (sowohl fuer dich, wie fuer mich).
Wenn Du trotzdem Lust dazu hast (oder netter vormuliert: dem Community helfen willst, ein Bug zu finden): bitte "attr MQTT2_SERVER verbose 5" setzen, und ein FHEM-Log Ausschnitt hier anhaengen: ich brauche ca 5 Minuten vor der ersten Meldung, und bitte nichts dazwischen loeschen, damit ich nicht auf die falsche Faehrte gefuehrt werde.
Hi Rudi,
Danke
klar mache ich den Mitschnitt.
Kannst du das Device einschränken welches den Müll sendet?
Dann könnte ich gezielter loggen?
VG T
Alle "unhandled Packet" Meldungen deuten auf Muell hin, kannst eins aussuchen, IP/Name des Clients ist hinten in der Meldung enthalten.
Zitat von: rudolfkoenig am 11 Dezember 2020, 13:21:04
Alle "unhandled Packet" Meldungen deuten auf Muell hin, kannst eins aussuchen, IP/Name des Clients ist hinten in der Meldung enthalten.
Hi Rudi, sorry, ich bin blind ......
Zitat von: rudolfkoenig am 11 Dezember 2020, 12:44:14
- "Unhandled packet": der Server liest Muell. Entweder durch Netzwerkprobleme (unwahrscheinlich), oder durch Programmierfehler im MQTT2_SERVER Modul (wahrscheinlich).
- "uninitialized value": Seiteneffekt beim "Muell verstehen". 97_timerTS.pm sagt mir nichts, und es gefaellt mir nicht, dass es hier involviert ist, da ich nicht sicher sein kann, dass es nicht der Verursacher ist.
- "ERROR: addToWriteBuffer": da wird versucht noch was zu parsen, nachdem die Verbindung zugemacht ist. Es fehlt mir z.Zt. die Fantasie vorzustellen, wie das sein kann.
Ich vermute die Clients ueberlasten den Server, debuggen wird aufwendig (sowohl fuer dich, wie fuer mich).
Wenn Du trotzdem Lust dazu hast (oder netter vormuliert: dem Community helfen willst, ein Bug zu finden): bitte "attr MQTT2_SERVER verbose 5" setzen, und ein FHEM-Log Ausschnitt hier anhaengen: ich brauche ca 5 Minuten vor der ersten Meldung, und bitte nichts dazwischen loeschen, damit ich nicht auf die falsche Faehrte gefuehrt werde.
Hallo Rudi,
hier mal paar Fehler.
Log ist dann von 14:55 bis 15:05 im Anhang
zwh100@ub9:/opt/fhem/log$ sudo grep --binary-files=text 'nhandled' 0-fhem-ub9-2020-12-11.log.error_unhandled
2020.12.11 14:58:46.454 1: ERROR: Unhandled packet CONNACK, disconneting MQTT2_TR_UB9_192.168.1.201_57160
2020.12.11 14:58:48.986 1: ERROR: Unhandled packet CONNACK, disconneting MQTT2_TR_UB9_192.168.1.201_57160
2020.12.11 15:00:17.879 1: ERROR: Unhandled packet PUBREL, disconneting MQTT2_TR_UB9_192.168.1.201_57160
2020.12.11 15:00:29.336 1: ERROR: Unhandled packet PUBREC, disconneting MQTT2_TR_UB9_192.168.6.105_53418
2020.12.11 15:00:29.992 1: ERROR: Unhandled packet PUBCOMP, disconneting MQTT2_TR_UB9_192.168.6.105_53418
2020.12.11 15:00:30.043 1: ERROR: Unhandled packet CONNACK, disconneting MQTT2_TR_UB9_192.168.6.105_53418
2020.12.11 15:00:31.481 1: ERROR: Unhandled packet PUBCOMP, disconneting MQTT2_TR_UB9_192.168.6.105_53418
2020.12.11 15:00:35.662 1: ERROR: Unhandled packet PUBREL, disconneting MQTT2_TR_UB9_192.168.1.163_50786
2020.12.11 15:00:35.757 1: ERROR: Unhandled packet CONNACK, disconneting MQTT2_TR_UB9_192.168.1.163_50786
2020.12.11 15:00:37.103 1: ERROR: Unhandled packet CONNACK, disconneting MQTT2_TR_UB9_192.168.1.163_50786
2020.12.11 15:00:39.466 1: ERROR: Unhandled packet CONNACK, disconneting MQTT2_TR_UB9_192.168.1.163_50786
2020.12.11 15:00:43.818 1: ERROR: Unhandled packet PUBCOMP, disconneting MQTT2_TR_UB9_192.168.1.167_53733
2020.12.11 15:00:44.933 1: ERROR: Unhandled packet PUBCOMP, disconneting MQTT2_TR_UB9_192.168.1.156_52165
2020.12.11 15:00:45.122 1: ERROR: Unhandled packet CONNACK, disconneting MQTT2_TR_UB9_192.168.1.167_53733
2020.12.11 15:00:45.133 1: ERROR: Unhandled packet CONNACK, disconneting MQTT2_TR_UB9_192.168.1.156_52165
2020.12.11 15:00:45.269 1: ERROR: Unhandled packet PUBREL, disconneting MQTT2_TR_UB9_192.168.1.156_52165
2020.12.11 15:01:34.389 1: ERROR: Unhandled packet PUBCOMP, disconneting MQTT2_TR_UB9_192.168.1.167_53733
2020.12.11 15:01:34.400 1: ERROR: Unhandled packet CONNACK, disconneting MQTT2_TR_UB9_192.168.1.156_52165
2020.12.11 15:01:40.503 1: ERROR: Unhandled packet PUBREC, disconneting MQTT2_TR_UB9_192.168.1.130_54467
2020.12.11 15:01:40.669 1: ERROR: Unhandled packet PUBREC, disconneting MQTT2_TR_UB9_192.168.1.130_54467
2020.12.11 15:01:40.814 1: ERROR: Unhandled packet PUBREC, disconneting MQTT2_TR_UB9_192.168.1.130_54467
Wenn ich noch Daten liefern soll mache ich das gerne. Hoffe du kannst etwas finden.
VG T
Wenn man im Log vom Unhandled Meldung rueckwaerts nach dem letzten "richtigen" Datensatz vom gleichen Client sucht, findet man sowas wie:
Zitat(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:
cat /proc/sys/net/ipv4/tcp_mem
cat /proc/sys/net/core/rmem_max
Hallo Rudi,
danke für deine Bemühungen.
cat /proc/sys/net/ipv4/tcp_mem
39189 52254 78378
cat /proc/sys/net/core/rmem_max
212992der MQTT2_Server läuft ohne SSL
bezüglich:
Zitatnn 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?
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 0htop 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
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.
Zitatdu 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.
Zitat von: rudolfkoenig am 11 Dezember 2020, 19:10:20
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.
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
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.
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.
Zitat von: rudolfkoenig am 12 Dezember 2020, 14:46:01
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:
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?
ZitatEs 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
Zitat von: rudolfkoenig am 12 Dezember 2020, 12:01:26
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
Zitatalso 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 :)
ZitatBzw. 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%.
Zitatdas ist komisch, alle haben ein Filelog dran und auch notifys.
Ich meinte mein Test-Setup, die Zeiten beziehen sich auch auf meinem Rechner.
@riker1: Kannst du mal bei den notify schauen, ob da viele mit "suboptimaler" DEF dabei sind: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.
Zitatauß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.
Zitat von: Beta-User am 12 Dezember 2020, 16:51:57
@riker1: Kannst du mal bei den notify schauen, ob da viele mit "suboptimaler" DEF dabei sind: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
Zitatcount TYPE=notify:FILTER=NOTIFYDEV!~.+
Count: 136 devices for devspec TYPE=notify:FILTER=state=active:FILTER=NOTIFYDEV!~.+
Zitatlist TYPE=notify:FILTER=NOTIFYDEV!~.+ DEF
also alle definitionen sind jetzt ziemlich viele. :-)
wonach soll ich hier suchen um es einzuschränken?
VG T
Zitat von: rudolfkoenig am 12 Dezember 2020, 16:49:02
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.:-)
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):
{ 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.
Zitat von: rudolfkoenig am 12 Dezember 2020, 16:56:30
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 :) ).
Zitat von: Beta-User am 12 Dezember 2020, 17:36:43
dass deine "eocr"-Attribute bei den Tasmotas nicht optimal
Hallo Beta-User,
was ist das denn?
Cool die Regex-check kannte ich noch nicht.
event-on-.* bzw. timestamp-on-irgendwas.Empfehle den Shelly-Beitrag im "MQTT-workshop" als Einstieg.
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 :D
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
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
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
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.
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
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
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
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
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.
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
MQTT2_DEVICE hast du demnach nicht aktualisiert?
Dann solltest du jetzt nochmal ein update machen.
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.
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
"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.
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
"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
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:
fhem("sleep 5");;\
fhem("set Lampe an")
und sollte so geschrieben werden:
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
{ 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):
fhem> { notifyRegexpCheck('TA_G.*') }
TA_G.*: devspec TA_G1,TA_G2,TA_G3 (OK)
Beispiel (schlecht):
fhem> { notifyRegexpCheck('MAX_WT.*:(desiredTemperatur|temperature|batterie).*') }
MAX_WT.*:(desiredTemperatur: devspec MAX_WT_XX (OK)
temperature: unknown (ignored)
batterie).*: no match (ignored)
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:
fhem("sleep 5");;\
fhem("set Lampe an")
und sollte so geschrieben werden:
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
{ 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):
fhem> { notifyRegexpCheck('TA_G.*') }
TA_G.*: devspec TA_G1,TA_G2,TA_G3 (OK)
Beispiel (schlecht):
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.
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:
fhem("sleep 5");;\
fhem("set Lampe an")
und sollte so geschrieben werden:
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
{ 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):
fhem> { notifyRegexpCheck('TA_G.*') }
TA_G.*: devspec TA_G1,TA_G2,TA_G3 (OK)
Beispiel (schlecht):
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):
fhem> { notifyRegexpCheck('TA_G.*') }
TA_G.*: devspec TA_G1,TA_G2,TA_G3 (OK)
Beispiel (schlecht):
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?
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.)