Autor Thema: 00_MQTT.pm - Connection timed-out obwohl Server erreichbar  (Gelesen 1121 mal)

Offline kennymc.c

  • Full Member
  • ***
  • Beiträge: 183
00_MQTT.pm - Connection timed-out obwohl Server erreichbar
« am: 03 September 2021, 20:03:46 »
Seit dem heutige Update des mosquitto Docker Containers bekomme ich im Fhem MQTT Modul bei Connection nur ein timed-out angezeigt. Neustart und Update von Fhem und Mosquitto bringen keine Besserung. Nach einer Minute auf connecting steht es wieder auf timed-out. Der State steht aber auf opened. Seltsamerweise haben zigbee2mqtt und auch andere Clients keine Probleme mit dem Zugriff auf den MQTT-Server. Schalter lassen sich auch noch über Fhem steuern, nur bekomme ich keine Rückmeldung darüber und auch Sensoren funktionieren dadurch nicht mehr.
Woran kann das liegen? Ich finde es irgendwie seltsam, dass ich Schalter trotzdem steuern kann. Aus dem Fhem Container lässt sich die MQTT Broker IP auch anpingen.
« Letzte Änderung: 03 September 2021, 20:05:43 von kennymc.c »

Offline buliwyf

  • New Member
  • *
  • Beiträge: 16
Antw:00_MQTT.pm - Connection timed-out obwohl Server erreichbar
« Antwort #1 am: 03 September 2021, 20:31:36 »
Ich habe hier ein ähnliches Problem nach dem heutigen Update.

Hier versucht FHEM ständig eine Verbindung aufzubauen aber das schlägt fehlt.

MQTT Log auszug
1630693714: New client connected from 192.168.xx.xx:60116 as fhem (p1, c1, k5).
1630693714: Client fhem disconnected due to malformed packet.

MQTT Explorer kann aber weiterhin problemlos eine Verbindung aufbauen.
Genau wie einige Tasmotageräte.

Offline kennymc.c

  • Full Member
  • ***
  • Beiträge: 183
Antw:00_MQTT.pm - Connection timed-out obwohl Server erreichbar
« Antwort #2 am: 03 September 2021, 20:41:36 »
Ok, fast gelöst: Device gelöscht und neu angelegt. Dann ging es wieder. Allerdings scheint sich der Broker nach einem weiteren Neustart nun im Sekundentakt zu connecten und dann wieder disconnecten. Erst ein manuelles disconnect bringt Ruhe. Neu anlegen hilft dieses Mal leider nicht.

Offline buliwyf

  • New Member
  • *
  • Beiträge: 16
Antw:00_MQTT.pm - Connection timed-out obwohl Server erreichbar
« Antwort #3 am: 03 September 2021, 20:43:07 »
Ok, fast gelöst: Device gelöscht und neu angelegt. Dann ging es wieder. Allerdings scheint sich der Broker nach einem weiteren Neustart nun im Sekundentakt zu connecten und dann wieder disconnecten. Erst ein manuelles disconnect bringt Ruhe. Neu anlegen hilft dieses Mal leider nicht.
Genau so sieht es bei mir aktuell auch aus.

Offline kennymc.c

  • Full Member
  • ***
  • Beiträge: 183
Antw:00_MQTT.pm - Connection timed-out obwohl Server erreichbar
« Antwort #4 am: 03 September 2021, 21:41:38 »
Ich habe nach dem neu Anlegen des Brokers auch Probleme mit dem Fhem Neustart. Bis ich eine Fhem Config aus meinem Backup einspiele, kommt es zu einem Bootloop mit folgender Meldung:
Undefined subroutine &XiaomiMQTT::DEVICE::send_publish called at ./FHEM/72_XiaomiMQTTDevice.pm line 484Leider verbindet sich der Broker nach jedem Neustart wieder automatisch und spamt den Log zu. Lässt sich das irgendwie ändern?

Offline buliwyf

  • New Member
  • *
  • Beiträge: 16
Antw:00_MQTT.pm - Connection timed-out obwohl Server erreichbar
« Antwort #5 am: 03 September 2021, 21:45:58 »
Ich habe nach dem neu Anlegen des Brokers auch Probleme mit dem Fhem Neustart. Bis ich eine Fhem Config aus meinem Backup einspiele, kommt es zu einem Bootloop mit folgender Meldung:
Undefined subroutine &XiaomiMQTT::DEVICE::send_publish called at ./FHEM/72_XiaomiMQTTDevice.pm line 484Leider verbindet sich der Broker nach jedem Neustart wieder automatisch und spamt den Log zu. Lässt sich das irgendwie ändern?
Ich habe es erst einmal manuell aus der fhem.cfg entfernt. Dann abe rmit einem einfachen
define mqttbroker MQTT 192.168.203.78:1883hinzugefügt, danach startete er wieder. Das Reconnect Problem blieb aber.

Offline kennymc.c

  • Full Member
  • ***
  • Beiträge: 183
Antw:00_MQTT.pm - Connection timed-out obwohl Server erreichbar
« Antwort #6 am: 03 September 2021, 21:59:02 »
Zumindest die Log Nachrichten lassen sich mit dem attr verbose 0 ausblenden. Wird aber wohl trotzdem nicht so gut sein, wenn da dauernd neu verbunden wird.

Hier gab es schon die selben Probleme aber wirklich gelöst ist das nicht: https://forum.fhem.de/index.php/topic,73242.0.html
In Post https://forum.fhem.de/index.php/topic,73242.msg732520.html#msg732520 steht auch, dass beim Löschen und Neuanlagen alle MQTT Devices gelöscht werden. Das könnte den Bootloop danach erklären.
Ich tippe mittlerweile auch irgendeine Änderung in Mosquitto bei der Authentifizierung, die das Fhem Modul nicht unterstützt. Werde mal versuche auf einen alte Version zurück zu gehen.

Update: Leider auch mit der vorherigen 2.0.11 das selbe Problem.
« Letzte Änderung: 03 September 2021, 22:05:52 von kennymc.c »

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15809
Antw:00_MQTT.pm - Connection timed-out obwohl Server erreichbar
« Antwort #7 am: 03 September 2021, 22:05:28 »
Ich habe es erst einmal manuell aus der fhem.cfg entfernt. Dann abe rmit einem einfachen
define mqttbroker MQTT 192.168.203.78:1883hinzugefügt, danach startete er wieder. Das Reconnect Problem blieb aber.
Ihr habt aber nicht zufällig beide das (ungepatchte) 72_XiaomiMQTTDevice im Einsatz (und eine Vielzahl dieser "undefined subroutine"-Meldungen im Log)?

Wenn ja, ist eher das das Problem wie 00_MQTT.pm.

Vielleicht hilft es, nicht nur die o.g. Datei zu patchen, sondern v.a. auch, das IO-Modul nicht zu löschen, sondern _an der richtigen Stelle_ in die cfg einzufügen (ausnahmsweise händisch, weil das "Fremdmodul" das noch so braucht).

Ergänzend: Es wäre evtl. clever, in dem github-issue deutlicher zu machen, dass der (Konstruktions-) Fehler in dem Modul fatal ist...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline kennymc.c

  • Full Member
  • ***
  • Beiträge: 183
Antw:00_MQTT.pm - Connection timed-out obwohl Server erreichbar
« Antwort #8 am: 03 September 2021, 22:11:21 »
In der 72_XiaomiMQTTDevice habe ich nach dem letzten Update vor ein paar Wochen nur die 2 Stellen, die hier erwähnt wurden geändert: https://forum.fhem.de/index.php/topic,120794.msg1161044.html#msg1161044
Und dann das Modul mit exclude_from_update ausgeschlossen. Seitdem lief es eigentlich.

Der Broker ist in der cfg aus dem Backup vor allen anderen MQTT Devices definiert.

Beim Starten von Fhem sind mir bisher nur diese Zeilen zu dem Modul aufgefallen:
PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/72_XiaomiMQTTDevice.pm line 209.
PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/72_XiaomiMQTTDevice.pm line 198.
...
PERL WARNING: Use of uninitialized value in string eq at ./FHEM/72_XiaomiMQTTDevice.pm line 332.
PERL WARNING: Use of uninitialized value in string eq at ./FHEM/72_XiaomiMQTTDevice.pm line 335.
« Letzte Änderung: 03 September 2021, 22:13:24 von kennymc.c »

Offline buliwyf

  • New Member
  • *
  • Beiträge: 16
Antw:00_MQTT.pm - Connection timed-out obwohl Server erreichbar
« Antwort #9 am: 03 September 2021, 22:17:46 »
Ihr habt aber nicht zufällig beide das (ungepatchte) 72_XiaomiMQTTDevice im Einsatz (und eine Vielzahl dieser "undefined subroutine"-Meldungen im Log)?

Wenn ja, ist eher das das Problem wie 00_MQTT.pm.

Vielleicht hilft es, nicht nur die o.g. Datei zu patchen, sondern v.a. auch, das IO-Modul nicht zu löschen, sondern _an der richtigen Stelle_ in die cfg einzufügen (ausnahmsweise händisch, weil das "Fremdmodul" das noch so braucht).

Ergänzend: Es wäre evtl. clever, in dem github-issue deutlicher zu machen, dass der (Konstruktions-) Fehler in dem Modul fatal ist...

Nein ich habe keine Xiaomi Devices per Mqtt angebunden. Das sind nur drei Shellys sowie ein C2-Monitor. Da ich die letzten tage kein Update von FHEM gemacht habe ist die Ursache sicherlich das moquitto Update. Eventuell behandelt mosquitto die  Paket die fhem sendet jetzt schickt strikter.

Offline kennymc.c

  • Full Member
  • ***
  • Beiträge: 183
Antw:00_MQTT.pm - Connection timed-out obwohl Server erreichbar
« Antwort #10 am: 03 September 2021, 22:20:24 »
...sondern v.a. auch, das IO-Modul nicht zu löschen, sondern _an der richtigen Stelle_ in die cfg einzufügen (ausnahmsweise händisch, weil das "Fremdmodul" das noch so braucht).

Das Modul nach dem neu Anlegen an die vorherige Position zu verschieben, verhindert schon mal die Bootloops. Aber leider kommt es weiterhin zu den Reconnects im Sekundentakt.

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15809
Antw:00_MQTT.pm - Connection timed-out obwohl Server erreichbar
« Antwort #11 am: 03 September 2021, 22:22:42 »
Ok, dann scheint das bei @buliwyf nicht (mehr) das Problem zu sein - war nur wegen des Log-Auszugs oben und dem "Löschen/Wiederanlegen", das nämlich dazu führt, dass die "optimale Reihenfolge" nicht eingehalten ist. @kennymc.c: Trotz des "Reihenfolge-Fixes durch Verschieben" wäre patchen sinnvoll.

Evtl. wäre es gut, wenn ihr hexenmeister mit Infos versorgt, welche Version euer mosquitto jetzt hat und wie die sonstigen Einstellungen am MQTT-IO sind (samt version-Infos zu FHEM selbst + die cpan-Modul und Perl-Versions-Infos)?

Das läuft alles unter docker (also auch FHEM)?
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline buliwyf

  • New Member
  • *
  • Beiträge: 16
Antw:00_MQTT.pm - Connection timed-out obwohl Server erreichbar
« Antwort #12 am: 03 September 2021, 22:36:42 »
Ok, dann scheint das bei @buliwyf nicht (mehr) das Problem zu sein - war nur wegen des Log-Auszugs oben und dem "Löschen/Wiederanlegen", das nämlich dazu führt, dass die "optimale Reihenfolge" nicht eingehalten ist. @kennymc.c: Trotz des "Reihenfolge-Fixes durch Verschieben" wäre patchen sinnvoll.

Evtl. wäre es gut, wenn ihr hexenmeister mit Infos versorgt, welche Version euer mosquitto jetzt hat und wie die sonstigen Einstellungen am MQTT-IO sind (samt version-Infos zu FHEM selbst + die cpan-Modul und Perl-Versions-Infos)?

Das läuft alles unter docker (also auch FHEM)?

Hier läuft beides als Docker. FHEM habe ich heute aktualisiert als das Problem aufgetreten ist. Ich hatte gehofft, es würde damit behoben.
Ich habe auch im FHEM Container ein apt upgrade gemacht was das Problem aber auch nicht behoben hat.
Mosquitto läuft ebenfalls als Docker. Version (2.0.12)
Mosquitto config:
listener 1883
allow_anonymous true
persistence true
persistence_location /mosquitto/data/
log_dest file /mosquitto/log/mosquitto.log

Offline kennymc.c

  • Full Member
  • ***
  • Beiträge: 183
Antw:00_MQTT.pm - Connection timed-out obwohl Server erreichbar
« Antwort #13 am: 04 September 2021, 00:00:16 »
@kennymc.c: Trotz des "Reihenfolge-Fixes durch Verschieben" wäre patchen sinnvoll.

Ich dachte mit den 2 Zeilen ändern wäre das Patchen gemeint? Das habe ich bereits vor Wochen gemacht und auch nicht geändert. Oder gibt es noch andere Stellen? Die erwähnten Perl Warnings treten auch mit der gepatchten Version noch auf.



Evtl. wäre es gut, wenn ihr hexenmeister mit Infos versorgt, welche Version euer mosquitto jetzt hat und wie die sonstigen Einstellungen am MQTT-IO sind (samt version-Infos zu FHEM selbst + die cpan-Modul und Perl-Versions-Infos)?

Das läuft alles unter docker (also auch FHEM)?

Sowohl Fhem als auch Mosquitto laufen über Docker auf einem Unraid Server. Die Mosquitto Version bisher müsste 2.0.11 gewesen sein zu der es heute ein Update auf 2.0.12 gab. Genau nach diesem Update trat das Time Out Problem auf. Habe es aber wie erwähnt schon mit 2.0.11 versucht und wieder die selben Probleme bekommen mit den Reconnects.

Mosquitto Config:
persistence true
persistence_location /mosquitto/data/
autosave_on_changes true
autosave_interval 3600

listener 1883

log_dest file /mosquitto/log/mosquitto.log
log_type all

password_file /mosquitto/config/pwfile
allow_anonymous false

fhem.pl: 24810/2021-07-29
cpan Version: 1.7044
Perl Version: 5.028001

Docker Image Parameter:
CPAN_PKGS IO::Socket::SSL IO::Socket::Multicast XML::Simple Data::Peek Net::FTPSSL


Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15809
Antw:00_MQTT.pm - Connection timed-out obwohl Server erreichbar
« Antwort #14 am: 04 September 2021, 06:55:23 »
OK, dann seid ihr betreffend dem Xiaomi-Ding auf dem "letzten Stand".

@Rudi (falls du hier mitliest):
Könnte es sein, dass das Problem eventuell auch was mit DevIo zu tun hat? Hintergrund dieser sehr vorsichtigen (!) Frage ist Folgendes: Ich hatte neulich etwas mit dem UBUS-Code (peer review in der Perl-Ecke) gespielt und festgestellt, dass UBUS iVm. DevIo mehrfach pro Sekunde einen Verbindungsversuch unternommen hat - erwartet hätte ich den default (alle 60 Sekunden, wenn ich das dem Code richtig entnommen habe). Hatte das auf das OS geschoben, aber evtl. ist das doch generell anders und das hier hängt damit zusammen?
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 24516
Antw:00_MQTT.pm - Connection timed-out obwohl Server erreichbar
« Antwort #15 am: 04 September 2021, 08:25:43 »
Mir ist eine "Endlosschleife" bekannt, leider konnte ich das selbst nach stundenlangen Versuchen nicht nachstellen, ich brauche also Hilfe.

Eilt nicht, ich komme erst nächste Woche dazu mich länger mit Debugging zu beschäftigen.

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15809
Antw:00_MQTT.pm - Connection timed-out obwohl Server erreichbar
« Antwort #16 am: 04 September 2021, 08:45:19 »
Danke für die Antwort.

Der Code ist mir auch zu hoch, aber falls ich irgendwas testen kann?
Auf die Schnelle ist mir nur aufgefallen, dass uU. ein PingPong mit der $callback-Funktion entstehen könnte, wenn die ihrerseits dann wieder (zu früh) ein "Open" versucht. Die Doku der von DevIo abgefragten $hash-Referenzen im Wiki zu DevIo ist auch nicht unbedingt aufschlussreich.
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline kennymc.c

  • Full Member
  • ***
  • Beiträge: 183
Antw:00_MQTT.pm - Connection timed-out obwohl Server erreichbar
« Antwort #17 am: 04 September 2021, 18:58:37 »
Ich habe testweise mal einen zweiten Mosquitto Server auf einen anderen Port aufgesetzt. Zuerst habe ich die selbe Config genommen aber password_file weg gelassen und allow_anonymous auf true. Damit konnte ich in Fhem ein Device erstellen, dass die keine Verbindungsprobleme hat. Setze ich password_file aber wieder ein, allow_anonymous auf false und lege erneut ein Device mit User und Passwort an, tritt der selbe Fehler wieder auf.
Wo werden die Login Daten in Fhem eigentlich gespeichert? Man gibt sie beim define ein, in der Config erscheinen sie dann aber nicht mehr.
« Letzte Änderung: 04 September 2021, 19:05:17 von kennymc.c »

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15809
Antw:00_MQTT.pm - Connection timed-out obwohl Server erreichbar
« Antwort #18 am: 05 September 2021, 09:39:04 »
Die Passwörter werden in der in keyFileName (global) zu findenden Datei gespeichert - wer "umzieht", sollte diese Datei auch mitnehmen.

Habe mal etwas im Code gestöbert und festgestellt, dass man (falls ich den Code richtig interpretiere) die Zugangsdaten nicht mehr über den DEF-Weg ändern kann, was ggf. auch zu Problemen führt.

Anbei mal ein Versuch, das zu ändern (Löschen geht aber weiter nur, wenn man den richtigen Weg über setKeyValue() kennt) - hab's aber ausdrücklich nicht weiter getestet!

Dann habe ich die commandref bei der Gelegenheit noch modernisiert und auch  Hinweise auf MQTT_GENERIC_BRIDGE bzw. MQTT_BRIDGE (outdated) aufgenommen...

Soweit ich das verstehe, versucht das Modul alle 60 Sekunden (einstellbar) einen reconnect. Habe nicht geschaut, ob das zu euren log-Einträgen paßt...
« Letzte Änderung: 05 September 2021, 12:53:18 von Beta-User »
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline kennymc.c

  • Full Member
  • ***
  • Beiträge: 183
Antw:00_MQTT.pm - Connection timed-out obwohl Server erreichbar
« Antwort #19 am: 05 September 2021, 12:32:43 »
keyFileName ist bei mir nicht gesetzt. Aber in FHEM/FHemUtils/uniqueID sind bei mir die Logindaten zu finden. Ich hatte tatsächlich einen Fehler bei der Angabe gemacht und user und Passwort mit einem : statt Leerzeichen getrennt. Danach konnte ich alle Geräte steuern und bekomme Rückmeldung auch wenn es weiterhin Verbindungsabbrüche gibt.
Nach einem Neustart trat dann wieder der ursprüngliche Time Out Fehler auf. Ich hab das Device dann mit der richtigen Syntax neu angelegt und dann blieb die Verbindung auch konstant. Allerdings war das Device jetzt wieder am Ende der Config. Sobald ich das ändere, stürzt Fhem ab und startet neu. Danach bekomme ich wieder ein Time Out. Schalten geht, Rückmeldung und Sensoren funktionieren nicht.


Mit der neuen. 00_MQTT.pm gibt es nach einem reload leider noch folgende Fehlermeldung und Fhem stützt ab:
021.09.05 11:55:05.277 1: PERL WARNING: Prototype mismatch: sub main::MQTT_Initialize ($) vs none at ./FHEM/00_MQTT.pm line 65.

2021.09.05 11:55:05.277 1: PERL WARNING: Constant subroutine MQTT::MQTT_DISCONNECT redefined at /usr/local/share/perl/5.28.1/Net/MQTT/Constants.pm line 44.

2021.09.05 11:55:05.277 1: PERL WARNING: Constant subroutine MQTT::MQTT_PINGREQ redefined at /usr/local/share/perl/5.28.1/Net/MQTT/Constants.pm line 44.

2021.09.05 11:55:05.277 1: PERL WARNING: Constant subroutine MQTT::MQTT_CONNECT_REFUSED_BAD_USER_NAME_OR_PASSWORD redefined at /usr/local/share/perl/5.28.1/Net/MQTT/Constants.pm line 44.

2021.09.05 11:55:05.277 1: PERL WARNING: Constant subroutine MQTT::MQTT_QOS_AT_MOST_ONCE redefined at /usr/local/share/perl/5.28.1/Net/MQTT/Constants.pm line 44.

2021.09.05 11:55:05.277 1: PERL WARNING: Constant subroutine MQTT::MQTT_CONNECT_REFUSED_IDENTIFIER_REJECTED redefined at /usr/local/share/perl/5.28.1/Net/MQTT/Constants.pm line 44.

2021.09.05 11:55:05.278 1: PERL WARNING: Constant subroutine MQTT::MQTT_QOS_EXACTLY_ONCE redefined at /usr/local/share/perl/5.28.1/Net/MQTT/Constants.pm line 44.

2021.09.05 11:55:05.278 1: PERL WARNING: Constant subroutine MQTT::MQTT_UNSUBSCRIBE redefined at /usr/local/share/perl/5.28.1/Net/MQTT/Constants.pm line 44.

2021.09.05 11:55:05.278 1: PERL WARNING: Constant subroutine MQTT::MQTT_SUBACK redefined at /usr/local/share/perl/5.28.1/Net/MQTT/Constants.pm line 44.

2021.09.05 11:55:05.278 1: PERL WARNING: Constant subroutine MQTT::MQTT_PUBACK redefined at /usr/local/share/perl/5.28.1/Net/MQTT/Constants.pm line 44.

2021.09.05 11:55:05.278 1: PERL WARNING: Constant subroutine MQTT::MQTT_SUBSCRIBE redefined at /usr/local/share/perl/5.28.1/Net/MQTT/Constants.pm line 44.

2021.09.05 11:55:05.278 1: PERL WARNING: Constant subroutine MQTT::MQTT_UNSUBACK redefined at /usr/local/share/perl/5.28.1/Net/MQTT/Constants.pm line 44.

2021.09.05 11:55:05.278 1: PERL WARNING: Constant subroutine MQTT::MQTT_QOS_AT_LEAST_ONCE redefined at /usr/local/share/perl/5.28.1/Net/MQTT/Constants.pm line 44.

2021.09.05 11:55:05.278 1: PERL WARNING: Constant subroutine MQTT::MQTT_CONNECT_REFUSED_NOT_AUTHORIZED redefined at /usr/local/share/perl/5.28.1/Net/MQTT/Constants.pm line 44.

2021.09.05 11:55:05.278 1: PERL WARNING: Constant subroutine MQTT::MQTT_PUBREC redefined at /usr/local/share/perl/5.28.1/Net/MQTT/Constants.pm line 44.

2021.09.05 11:55:05.278 1: PERL WARNING: Constant subroutine MQTT::MQTT_CONNECT_REFUSED_SERVER_UNAVAILABLE redefined at /usr/local/share/perl/5.28.1/Net/MQTT/Constants.pm line 44.

2021.09.05 11:55:05.278 1: PERL WARNING: Constant subroutine MQTT::MQTT_CONNECT_REFUSED_UNACCEPTABLE_PROTOCOL_VERSION redefined at /usr/local/share/perl/5.28.1/Net/MQTT/Constants.pm line 44.

2021.09.05 11:55:05.278 1: PERL WARNING: Constant subroutine MQTT::MQTT_CONNACK redefined at /usr/local/share/perl/5.28.1/Net/MQTT/Constants.pm line 44.

2021.09.05 11:55:05.278 1: PERL WARNING: Constant subroutine MQTT::MQTT_CONNECT redefined at /usr/local/share/perl/5.28.1/Net/MQTT/Constants.pm line 44.

2021.09.05 11:55:05.278 1: PERL WARNING: Constant subroutine MQTT::MQTT_PUBCOMP redefined at /usr/local/share/perl/5.28.1/Net/MQTT/Constants.pm line 44.

2021.09.05 11:55:05.279 1: PERL WARNING: Constant subroutine MQTT::MQTT_PINGRESP redefined at /usr/local/share/perl/5.28.1/Net/MQTT/Constants.pm line 44.

2021.09.05 11:55:05.279 1: PERL WARNING: Constant subroutine MQTT::MQTT_PUBLISH redefined at /usr/local/share/perl/5.28.1/Net/MQTT/Constants.pm line 44.

2021.09.05 11:55:05.279 1: PERL WARNING: Constant subroutine MQTT::MQTT_CONNECT_ACCEPTED redefined at /usr/local/share/perl/5.28.1/Net/MQTT/Constants.pm line 44.

2021.09.05 11:55:05.279 1: PERL WARNING: Constant subroutine MQTT::MQTT_PUBREL redefined at /usr/local/share/perl/5.28.1/Net/MQTT/Constants.pm line 44.

2021.09.05 11:55:05.279 1: PERL WARNING: Subroutine Define redefined at ./FHEM/00_MQTT.pm line 105.

2021.09.05 11:55:05.279 1: PERL WARNING: Subroutine Undef redefined at ./FHEM/00_MQTT.pm line 131.

2021.09.05 11:55:05.279 1: PERL WARNING: Subroutine Delete redefined at ./FHEM/00_MQTT.pm line 137.

2021.09.05 11:55:05.279 1: PERL WARNING: Subroutine Shutdown redefined at ./FHEM/00_MQTT.pm line 144.

2021.09.05 11:55:05.279 1: PERL WARNING: Subroutine onConnect redefined at ./FHEM/00_MQTT.pm line 152.

2021.09.05 11:55:05.280 1: PERL WARNING: Subroutine onDisconnect redefined at ./FHEM/00_MQTT.pm line 159.

2021.09.05 11:55:05.280 1: PERL WARNING: Subroutine onTimeout redefined at ./FHEM/00_MQTT.pm line 166.

2021.09.05 11:55:05.280 1: PERL WARNING: Subroutine isConnected redefined at ./FHEM/00_MQTT.pm line 175.

2021.09.05 11:55:05.280 1: PERL WARNING: Subroutine process_event redefined at ./FHEM/00_MQTT.pm line 182.

2021.09.05 11:55:05.280 1: PERL WARNING: Subroutine Set redefined at ./FHEM/00_MQTT.pm line 203.

2021.09.05 11:55:05.280 1: PERL WARNING: Subroutine parseParams redefined at ./FHEM/00_MQTT.pm line 250.

2021.09.05 11:55:05.281 1: PERL WARNING: Subroutine parsePublishCmdStr redefined at ./FHEM/00_MQTT.pm line 337.

2021.09.05 11:55:05.281 1: PERL WARNING: Subroutine parsePublishCmd redefined at ./FHEM/00_MQTT.pm line 346.

2021.09.05 11:55:05.281 1: PERL WARNING: Subroutine Notify redefined at ./FHEM/00_MQTT.pm line 388.

2021.09.05 11:55:05.281 1: PERL WARNING: Subroutine Attr redefined at ./FHEM/00_MQTT.pm line 396.

2021.09.05 11:55:05.281 1: PERL WARNING: Subroutine Start redefined at ./FHEM/00_MQTT.pm line 429.

2021.09.05 11:55:05.281 1: PERL WARNING: Subroutine Stop redefined at ./FHEM/00_MQTT.pm line 447.

2021.09.05 11:55:05.281 1: PERL WARNING: Prototype mismatch: sub MQTT::Ready ($) vs none at ./FHEM/00_MQTT.pm line 467.

2021.09.05 11:55:05.281 1: PERL WARNING: Subroutine Ready redefined at ./FHEM/00_MQTT.pm line 464.

2021.09.05 11:55:05.282 1: PERL WARNING: Subroutine Rename redefined at ./FHEM/00_MQTT.pm line 469.

2021.09.05 11:55:05.282 1: PERL WARNING: Subroutine Init redefined at ./FHEM/00_MQTT.pm line 479.

2021.09.05 11:55:05.282 1: PERL WARNING: Subroutine Timer redefined at ./FHEM/00_MQTT.pm line 489.

2021.09.05 11:55:05.282 1: PERL WARNING: Subroutine Read redefined at ./FHEM/00_MQTT.pm line 512.

2021.09.05 11:55:05.283 1: PERL WARNING: Subroutine send_connect redefined at ./FHEM/00_MQTT.pm line 658.

2021.09.05 11:55:05.283 1: PERL WARNING: Subroutine send_publish redefined at ./FHEM/00_MQTT.pm line 671.

2021.09.05 11:55:05.283 1: PERL WARNING: Subroutine send_subscribe redefined at ./FHEM/00_MQTT.pm line 683.

2021.09.05 11:55:05.283 1: PERL WARNING: Subroutine send_unsubscribe redefined at ./FHEM/00_MQTT.pm line 690.

2021.09.05 11:55:05.283 1: PERL WARNING: Subroutine send_ping redefined at ./FHEM/00_MQTT.pm line 697.

2021.09.05 11:55:05.283 1: PERL WARNING: Subroutine send_disconnect redefined at ./FHEM/00_MQTT.pm line 701.

2021.09.05 11:55:05.283 1: PERL WARNING: Subroutine send_message redefined at ./FHEM/00_MQTT.pm line 708.

2021.09.05 11:55:05.283 1: PERL WARNING: Subroutine topic_to_regexp redefined at ./FHEM/00_MQTT.pm line 723.

2021.09.05 11:55:05.284 1: PERL WARNING: Subroutine client_subscribe_topic redefined at ./FHEM/00_MQTT.pm line 734.

2021.09.05 11:55:05.284 1: PERL WARNING: Subroutine client_unsubscribe_topic redefined at ./FHEM/00_MQTT.pm line 753.

2021.09.05 11:55:05.284 1: PERL WARNING: Subroutine Client_Define redefined at ./FHEM/00_MQTT.pm line 770.

2021.09.05 11:55:05.284 1: PERL WARNING: Subroutine Client_Undefine redefined at ./FHEM/00_MQTT.pm line 789.

2021.09.05 11:55:05.284 1: PERL WARNING: Subroutine client_attr redefined at ./FHEM/00_MQTT.pm line 794.

2021.09.05 11:55:05.284 1: PERL WARNING: Subroutine notify_client_connected redefined at ./FHEM/00_MQTT.pm line 908.

2021.09.05 11:55:05.285 1: PERL WARNING: Subroutine notify_client_disconnected redefined at ./FHEM/00_MQTT.pm line 913.

2021.09.05 11:55:05.285 1: PERL WARNING: Subroutine notify_client_connection_timeout redefined at ./FHEM/00_MQTT.pm line 918.

2021.09.05 11:55:05.285 1: PERL WARNING: Subroutine client_start redefined at ./FHEM/00_MQTT.pm line 923.

2021.09.05 11:55:05.285 1: PERL WARNING: Subroutine client_stop redefined at ./FHEM/00_MQTT.pm line 955.

/entry.sh: line 621: kill: (4889) - No such process

Undefined subroutine &main::Set called at fhem.pl line 3894.


Abrupt daemon termination, starting 10s countdown .../entry.sh: line 625: kill: (4889) - No such process

10/entry.sh: line 625: kill: (4889) - No such process

9/entry.sh: line 625: kill: (4889) - No such process

8/entry.sh: line 625: kill: (4889) - No such process

7/entry.sh: line 625: kill: (4889) - No such process

6/entry.sh: line 625: kill: (4889) - No such process

5/entry.sh: line 625: kill: (4889) - No such process

4/entry.sh: line 625: kill: (4889) - No such process

3/entry.sh: line 625: kill: (4889) - No such process

2/entry.sh: line 625: kill: (4889) - No such process

1/entry.sh: line 625: kill: (4889) - No such process

/entry.sh: line 632: kill: (4889) - No such process

0
Automatic restart ...

/entry.sh: line 645: kill: (4889) - No such process




Preparing configuration ... done

Starting FHEM ...
2021.09.05 11:55:18.518 1: Including fhem.cfg
2021.09.05 11:55:18.551 2: eventTypes: loaded 3423 lines from ./log/eventTypes.txt
Undefined subroutine &main::Define called at fhem.pl line 3894, <$fh> line 1262.


Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15809
Antw:00_MQTT.pm - Connection timed-out obwohl Server erreichbar
« Antwort #20 am: 05 September 2021, 12:42:37 »
reload klappt wegen der Prototypen-Geschichte nicht, aber da scheint eh noch was anderes verbogen zu sein. Mit der alten pm und den richtigen Zugangsdaten müsste es aber erst mal klappen.

Nachtrag: Habe die "Initialize" wieder auf den alten Stand gezogen - damit müßte (!) das mit dem "Set" wieder auf die richtige Routine verweisen.
(Ist aber weiter ungetestet!)

Hier eine wenigstens angetestete Fassung, in der von gestern war u.A. noch eine Funktion aus GPUtils noch nicht mit importiert...
(Die macht mir jetzt aber einen Haufen Logeinträge, von denen ich annehme, dass sie aus einem unvollständigen Systemumfeld kommen, bitte nochmal gegenchecken).

EDIT: Hier jetzt nur die Themen Passwort-reset via DEF sowie commandref geändert... Das eigentliche Problem scheint aus den zugrundeliegenden Perl-libs zu kommen, siehe auch "Client FHEM disconnected due to malformed packet" 
« Letzte Änderung: 07 September 2021, 09:16:04 von Beta-User »
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline kennymc.c

  • Full Member
  • ***
  • Beiträge: 183
Antw:00_MQTT.pm - Connection timed-out obwohl Server erreichbar
« Antwort #21 am: 07 September 2021, 20:00:31 »
Mit der Version von heute kommen die Verbindungsabbrüche nur noch alle 60 Sekunden. Log Einträge dazu gibt es allerdings nicht. So wie ich das aus dem anderen Thread lese, liegt das Hauptproblem ja an veralteten in Fhem integrierten MQTT Libs.
Ich bin aber mittlerweile sowieso auch auf MQTT2_Client und MQTT2_Device umgestiegen. Damit kann ich dann auch mal SSL aktivieren was mit dem alten Modul nicht geht. Großer Nachteil ist aber, dass ich meine Devicenamen nicht behalten kann, da MQTT2_basetopic_ als Prefix hardcodiert ist.
« Letzte Änderung: 07 September 2021, 20:37:17 von kennymc.c »

Offline Master_Nick

  • Sr. Member
  • ****
  • Beiträge: 908
Antw:00_MQTT.pm - Connection timed-out obwohl Server erreichbar
« Antwort #22 am: 07 September 2021, 21:04:02 »
 ;) Schande über mich, dass ich den hier nicht gefunden hatte. Sorry - echt.

Ja ich überlege echt was nun der sinnvolle Weg ist.

Ich hab noch 0% Ahnung von dem MQTT2 und daher auch leider noch keine was du mit den hardcodierten basetopics meinst. :-D
Rancher K8s Cluster mit nanoCUL (a-culfw) | IObroker | IT(V1&V3), IT-PIR, THGR122NX |Co² | alexa-fhem | WOL | NFC | Harmony UltimateHub | Anwesenheitserkennnung | Roomba | 10" Touch mit Node-Red | SonOff S20 | SonOff Touch | SonOff Dual | Rolladen | Und ganz viel anderes tolles Gerödel.... ;-)

Offline kennymc.c

  • Full Member
  • ***
  • Beiträge: 183
Antw:00_MQTT.pm - Connection timed-out obwohl Server erreichbar
« Antwort #23 am: 07 September 2021, 22:10:48 »
Mit basetopic meine ich den entsprechenden ZigBee2MQTT Konfig-Eintrag. Neue Devices werden mit MQTT2_Device immer so benannt: MQTT2_zigbee2mqtt_FriendlyName/ID.
Das zwar theoretisch auch Sinn, mit dem alten Xiaomi Modul wurden die Devices aber automatisch immer nach ihrer ZigBee ID bzw. dem FriendlyName benannt. Das ist durch die Umstellung gerade fürs Logging nicht so schön, da man sie nicht so ohne weiteres umbenennen kann ohne, dass sie danach erneut mit dem alten Namen erscheinen. Siehe: https://forum.fhem.de/index.php/topic,108761.0.html

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15809
Antw:00_MQTT.pm - Connection timed-out obwohl Server erreichbar
« Antwort #24 am: 08 September 2021, 05:57:02 »
Wenn nach dem Umbenennen neue Devices angelegt werden, ist was faul.

Sehe keinen Grund, warum das nicht klappen sollte.

Meine Vermutung: Es wird mit MQTT2_CLIENT gearbeitet, ohne dass ein "allgemeines Bridge-Device" angelegt ist, und/oder das "Zentral-MQTT2-Device" für zigbee2mqtt ist nicht angelegt.

Diese ganzen aktuellen Posts rund um MQTT(2) grade kommen mir ziemlich "rumgestochert" vor. Es macht wenig Sinn, alles auf einmal zu diskutieren und dann keine vollständigen (raw-) lists zu liefern. Das betrifft z.B. auch die Frage nach dem homeBridgeMapping - da fehlt  die "vorher - nachher"-Info (zudem kann ich dazu wenig sagen, eigentlich gehört das eher in den Sprachssteuerungs-Bereich, das ist bei MQTT2 nur eine "Zugabe", die ich gerne korrigiere, wenn ich was besseres zugerufen bekomme...).

(Ich kann allerdings nachvollziehen, dass ihr schnell "irgendeine Lösung" des Problems braucht, aber dann würde ich erst mal
a) die Perl-MQTT-libs updaten und
b) wenn (!) das nichts hilft, den mosquitto vorübergehend downgraden.)

Und dann langsam und strukturiert mal die wenigen im Wiki verlinkten "Umzugsthreads" durchstöbern, wenn ihr dann noch auf MQTT2.*-Module umsteigen wollt.
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline kennymc.c

  • Full Member
  • ***
  • Beiträge: 183
Antw:00_MQTT.pm - Connection timed-out obwohl Server erreichbar
« Antwort #25 am: 08 September 2021, 11:24:24 »
Es ist ein ZigBee2MQTT Bridge Device angelegt, dass die Bridge Nachrichten abfängt und auch Funktionen der Software steuern kann. Kann natürlich sein, dass das ZigBee2MQTT Bridge Template die Rename Probleme verursacht. Es ist aber ja schon logisch, dass die Devices immer wieder neu angelegt werden, da diese nach dem Umbenennen nicht mehr dem autocreate Namens-Muster von Modul entsprechen und neue Nachrichten unter dem alten Namen wieder einem neuen Device zugeordnet werden. Durch den verlinkten Thread bin ich auch davon ausgegangen das das Verhalten so gewollt ist.
Falls man nicht nur auf ZigBee2MQTT setzt, macht das auch Sinn, um die unterschiedlichen Nachrichten zu unterscheiden. Autocreate ganz ausstellen dürfte auch zu Problemen führen, da dann die einzelnen Devices keine Updates mehr bekommen.
Das HomeBridge Problem kann ich auch nochmal in den entsprechenden Thread posten. Ich bin aber davon ausgegangen, dass das bisherige Template irgendetwas in der HomeBridge Logik verändert. Eventuell auch bei anderen Schaltern. Wenn es da eine Lösung über HomeBridgeMapping gibt, könnte man das mit in die Templates integrieren.
« Letzte Änderung: 08 September 2021, 11:27:40 von kennymc.c »

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15809
Antw:00_MQTT.pm - Connection timed-out obwohl Server erreichbar
« Antwort #26 am: 08 September 2021, 11:41:33 »
Sorry, aber du darfst mir glauben, dass das _Umbenennen_ NICHT problematisch ist.

Bei eingehenden Nachrichten schaut MQTT2_DEVICE immer (!), ob es irgendwo einen passenden readingList-Eintrag gibt.
Danach kommt bridgeRegexp zum Tragen, die ggf. eine "fake"-ClientID erzeugt, anhand derer dann das Zieldevice ermittelt wird.Erst danach wird dann die "originäre" ClientID ausgewertet (die bei MQTT2_CLIENT immer gleich ist) und zur Ermittlung des "Zieldevices" ausgewertet (die ClientID wird mit der DEF aller M2D-Instanzen verglichen, nicht mit dem Namen).

Probleme können eigentlich nur entstehen, wenn man bridgeRegexp mischt, weil dann in der Tat "zufällige" Ergebnisse rauskommen, wenn (!) es mehrere Matches geben kann - das hat dann aber wieder NICHTS mit dem NAMEN des Devices zu tun, der ist nur ggf. eine FOLGE aus dem Vorherigen.

Bis "show me" da ist, kann ich nichts dazu sagen, und ich bin auch nicht willens, jedesmal auf RTL bei Adam anzufangen...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline kennymc.c

  • Full Member
  • ***
  • Beiträge: 183
Antw:00_MQTT.pm - Connection timed-out obwohl Server erreichbar
« Antwort #27 am: 08 September 2021, 20:08:17 »
Ich habe es jetzt doch hinbekommen. Ich vermute es lag daran, dass ich die Bridge zuerst manuell definiert habe aber trotzdem noch ein automatisch generiertes Bridge Device erstellt wurde was der echten ZigBeeBridge entsprach. Die zwei gleichzeitig vorhandenen Bridges könnte für das Wiederauftauchen gesorgt haben.

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15809
Antw:00_MQTT.pm - Connection timed-out obwohl Server erreichbar
« Antwort #28 am: 08 September 2021, 20:48:44 »
...wenn du beide Devices hier gezeigt hättest, bräuchten wir nicht mehr "vermuten"...

Generell: Entweder FHEM automatisch arbeiten lassen - angefangen vom "generellen bridge-Device" für MQTT2_CLIENT - oder manuell arbeiten! Wenn, dann muss man sich aber auch alles selbst machen...
Die einzigen Punkte, um die man sich bei MQTT2 manuell kümmern sollte, sind
- subscriptions (für MQTT2_CLIENT, v.a. in großen Installationen) und
- ignoreRegexp (für beide IO-Typen), um Kommandos rauszufiltern und keinen Mischmasch mit  Statusmeldungen zu riskieren (cmnd-Zweige bei Tasmota, z.B.).

So jedenfalls meine spontane Zusammenfassung aus dem Kopf...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}