Hi zusammen,
Ich habe leider seit ca. 2 Monaten massive Probleme mit MQTT2_DEVICE in FHEM: Meine Devices sind korrekt an IODev=MQTT2_FHEM_Server gebunden wie immer seit jahren, aber das Internal MQTT2_FHEM_Server_CONN zeigt phasenweise auf ein falsches temporäres MQTT2_FHEM_Server_<IP>_<Port>-Objekt. Internals sind in FHEM modulinterne Zustandsinformationen, deshalb vermute ich hier eine fehlerhafte interne Zuordnung.
Beispiel:
betroffenes Device: Shelly auf 192.168.x.59
IODev zeigt korrekt auf MQTT2_FHEM_Server
MQTT2_FHEM_Server_CONN zeigt aber z. B. auf MQTT2_FHEM_Server_192.168.x.9_24199
dieses temporäre Verbindungsobjekt gehört laut dessen Internals zu einem ganz anderen Client (cid eines anderen Shelly)
Symptom:
das betroffene MQTT2-Device ist dann ,,tot"
nach FHEM-Neustart oder MQTT reconnect ändert sich MQTT2_FHEM_Server_CONN, bleibt aber weiterhin randomly falsch bzw. springt auf andere fremde Sessions
IODev bleibt dabei korrekt
Meine Frage:
Wodurch wird MQTT2_FHEM_Server_CONN gesetzt?
Kann man diese Zuordnung refreshen oder korrigieren, ohne das Device zu löschen? Kann man hier eine korrekte Zuordnung definieren?
Ist das ein Bug? Jeder Hinweis wäre hilfreich.
Danke euch und beste Grüße
Debu
Ergänzung:
ein MQTT2_DEVICE bekommt seit neustem gar kein MQTT2_FHEM_Server_CONN mehr zugeordnet.
Würde auf irgendwelche Übereinstimmungen in der CID oder readingList tippen.
Ohne Infos ist die Glaskugel aber sehr trübe...
keine Übereinstimmungen in CID oder readingList.
Welche Details wären interessant?
Zitat von: debu am 13 Juni 2026, 13:05:00keine Übereinstimmungen in CID oder readingList.
Show us!
ZitatWodurch wird MQTT2_FHEM_Server_CONN gesetzt?
Das setzt MQTT2_SERVER (indirekt per Dispatch) nach Empfang einer Nachricht bei allen Geraeten, die diese Nachricht akzeptieren.
Wird zusammen mit ..._MSGCNT und ..._TIME gesetzt.
..._CONN wird ausser den AttrTemplates nicht ausgewertet, deswegen kann es kein Grund(!) fuer ein Problem sein.
Natuerlich kann es ein Symptom sein.
Womoeglich ist readingsList mehrdeutig, und wird _CONN deswegen bei mehreren Geraeten gesetzt.
Zitatdas betroffene MQTT2-Device ist dann ,,tot"
Was genau bedeutet das?
ZitatWelche Details wären interessant?
"Copy for forum.fhem.de" unten in der Detailseite von relevanten Geraeten.
Apple-User muessen die Kopie von "Raw definition (With internals)" durchfuehren.
Relevant: das angeblich falsch Zugeordnete, und das Geraet was diese IP hat.
Nachtrag: ein bridgeRegexp Attribut kann die Nachrichten auch falsch zuordnen.
Zitat von: debu am 13 Juni 2026, 12:35:56Kann man diese Zuordnung refreshen oder korrigieren, ohne das Device zu löschen? Kann man hier eine korrekte Zuordnung definieren?
Jein, du kannst dir aber dein ,,RAW" vom existierenden device rauskopieren. In z.B. ne textdatei zwischen speichern. Das existierende device löschen und neu anlegen lassen.
Die Attribute aus der textdatei mit suchen und ersetzen editieren mit der neuen id (falls vorhanden?)und so die Einstellungen zurück setzen.
Zitat von: rudolfkoenig am 13 Juni 2026, 13:53:09..._CONN wird ausser den AttrTemplates nicht ausgewertet
Das ist eine wichtige Info. Danke!
Wenn diese falschen _CONN für die Verbindung verwendet würden wäre das verhalten bei mir erklärbar gewesen.
"tot" heisst mqtt nachrichten dieser devices kommen in fhem nicht an obwohl die devices definitiv online sind und auch per http erreichbar.
Ich vermute aber mittlerweile dass das eigentliche Problem ein Netzwerkproblem bzw. ein bug in FritzOS 8.22 bei internen ARP/Routing-Zuweisungen ist.
Danke euch!