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

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 24485
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: 15641
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: 15641
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: 15641
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: 15641
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: 15641
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: 15641
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}

 

decade-submarginal