Autor Thema: [gelöst] MQTT2-Server legt Device per autocreate an obwohl es bereits existiert  (Gelesen 531 mal)

Offline Mihca

  • Full Member
  • ***
  • Beiträge: 131
  • Fhem seit 2014
Ich betreibe einen Sonoff 4CH Pro Switch mit TASMOTA 6.4.1. Er hat eine statische IP (192.168.0.99). In den Einstellungen des Switches ist im Reiter MQQT als "Client" der Name "4CH_Switch_E_Keller" eingetragen. Der Switch wurde von "autocreate" erkannt und mit dem Namen "MQTT2_4CH_Switch_E_Keller" angelegt. Er funktioniert nach setzen des entsprechenden Templates auch einwandfrei.

Da mir der Name zu lang ist, habe ich den Switch in "4CH_Switch_E_Keller" umbenannt, also das "MQTT2_" vorne weggelassen.

Obwohl ich am MQTT2-Server das "autocreate=0" gesetzt habe, wird u.a. bei einem restart von FHEM, oder wenn mal kurz die Verbindung zum Device "4CH_Switch_E_Keller" getrennt wurde, ein neues Device mit dem Namen "MQTT2_4CH_Switch_E_Keller" sowie entsprechender LOG angelegt. Dieses "MQTT2_4CH_Switch_E_Keller" Device hat keine IP-Adresse und schaltet entsprechend auch den Switch nicht. Löschen des Device hilft nicht; irgendwann ist es wieder da.

Muss der Name eines MQTT2-Devices immer mit MQTT2_ beginnen, oder gibt es eine andere Lösung?

Vielen Dank vorab
Achim
« Letzte Änderung: 06 März 2019, 18:50:35 von Mihca »
Kein Fehler ist so dumm, dass man ihn nicht machen könnte.

Intel NUC Ubuntu, Rollo-, Sonnen-, Licht-, Heizungs-, Poolsteuerung, Energiebilanzen. 40xHomeMatic, 15xFS20, 1xWMBUS, 3xSonoff/Tasmota, 4xWeMos/ESPEasy, 2xCUL868v3 USB, 3xMAX! Cube LAN mit CUL-Firmware davon 2 HomeMatic und 1 WMBUS

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 21682
Normalerweise (d.h. wenn die Aenderungen gespeichert sind) sollte sowas nicht passieren.
Wenn ich das naeher untersuchen soll, dann brauche ein ein "attr global verbose 5" Log-Ausschnitt des Vorgangs.

Offline Mihca

  • Full Member
  • ***
  • Beiträge: 131
  • Fhem seit 2014
Alle Änderungen waren gespeichert. Hier als Anlage die beiden Device Listings und ein Auszug des Logfiles, das den  "autocreate" zeigt, mit "verbose 5".

Vielen Dank vorab
Achim
« Letzte Änderung: 06 März 2019, 12:40:27 von Mihca »
Kein Fehler ist so dumm, dass man ihn nicht machen könnte.

Intel NUC Ubuntu, Rollo-, Sonnen-, Licht-, Heizungs-, Poolsteuerung, Energiebilanzen. 40xHomeMatic, 15xFS20, 1xWMBUS, 3xSonoff/Tasmota, 4xWeMos/ESPEasy, 2xCUL868v3 USB, 3xMAX! Cube LAN mit CUL-Firmware davon 2 HomeMatic und 1 WMBUS

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 21682
Leider war fuer MQTT2Server das verbose Attribut explizit auf 3 oder niedriger gesetzt, was "attr global verbose 5" fuer die interessanten Daten ueberschreibt. Ich habs versucht aus den restlichen Log das Problem nachzustellen, ohne Erfolg.

Ich bitte also um noch einen Mitschnitt, aber vorher bitte Folgendes durchfuehren:deleteattr .* verbose
attr global verbose 5
Screenshots als PDF sind zwar nett anzuschauen, ich bevorzuge aber die Ausgabe von "Raw definition" (unten im FHEMWEB Detailfenster), was hier in Code-Tags (oder als Anhang) eingefuegt wird. Damit kann ich das betroffene Geraet in einer Testinstallation einfach definieren, ohne alles abzutippen.

Offline Mihca

  • Full Member
  • ***
  • Beiträge: 131
  • Fhem seit 2014
So, nächster Versuch. Anligend die entsprechenden Logs/DeviceListings.

Inzwischen habe ich festgestellt, dass meinem MQTT2Server kein attribut autocreate zugewiesen war. Wenn kein Attribut autocreate zugewiesen ist, legt Fhem das neue Device "MQTT2_4CH_Switch_E_Keller" an. (Das Device "autocreate" ist allerdings "active".) Wenn dem MQTT2Server das Attribut "autocreate=0" zugewiesen wird, legt  Fhem kein neues Device "MQTT2_4CH_Switch_E_Keller" bei einem reconnect an.

Das ist der Stand nach dem heutigen Fhem-update.

Vielen Dank vorab!
Achim
« Letzte Änderung: 07 März 2019, 08:20:27 von Mihca »
Kein Fehler ist so dumm, dass man ihn nicht machen könnte.

Intel NUC Ubuntu, Rollo-, Sonnen-, Licht-, Heizungs-, Poolsteuerung, Energiebilanzen. 40xHomeMatic, 15xFS20, 1xWMBUS, 3xSonoff/Tasmota, 4xWeMos/ESPEasy, 2xCUL868v3 USB, 3xMAX! Cube LAN mit CUL-Firmware davon 2 HomeMatic und 1 WMBUS

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 21682
Danke fuer die vorbildlichen Logs :)

Das Problem ist, dass die alte Instanz noch mit "DVES_4782CF" als ClientId angelegt wurde, das neue Geraet aber sich mit 4CH_Switch_E_Keller als clientId anmeldet (vmtl. wurde clientId in Tasmota umbenannt), und deswegen wurde sie von FHEM falsch identifiziert.

Die Loesung ist eindefmod 4CH_Switch_E_Keller MQTT2_DEVICE 4CH_Switch_E_Keller

Offline Mihca

  • Full Member
  • ***
  • Beiträge: 131
  • Fhem seit 2014
Ja, das stimmt, dass ich das in Tasmota umbenannt habe. Danke für die Lösung. So funktioniert das jetzt!   :)
Kein Fehler ist so dumm, dass man ihn nicht machen könnte.

Intel NUC Ubuntu, Rollo-, Sonnen-, Licht-, Heizungs-, Poolsteuerung, Energiebilanzen. 40xHomeMatic, 15xFS20, 1xWMBUS, 3xSonoff/Tasmota, 4xWeMos/ESPEasy, 2xCUL868v3 USB, 3xMAX! Cube LAN mit CUL-Firmware davon 2 HomeMatic und 1 WMBUS