Wieso ist die Verwendung z.B. eines Tasmota Device oder EVCC Modul Geräten
in Verbindung mit einer MQTT Clientverbindung (weil externer Broker) neuerdings
“inkompatibel” ??
Hat bisher problemlos funktioniert.
Wie soll das in Zukunft funktionieren / verwendet werden ?
Das funktioniert auch weiterhin.
Das ist eine reine optische Anzeige in der Konsole.
Ich vermute aber das die Module irgendwas nicht ganz korrekt machen. Weil bei Z2M kommt diese Meldung nicht. Egal ob MQTT Client oder Server.
Mein Tipp: Im jeweiligen Modul Thema adressieren.
Ich schaue mir das bei Tasmota mal an.
Grüße,
Kai
@KaiS Bei den Shelly Instanzen gleiches Problem:
Das Gen2+ Modul sollte schon gefixt sein.
Grüße,
Kai
Spezielle Version ?
Bei mir zeigts im Konfigurator drin noch Fehler:
Erschwerend kommt hinzu, dass er bei Button Gateway ändern
direkt in die Neuanlage einer MQTT Server Instanz springt. Ich könnte hier offenbar
das GW gar nicht ändern..
–>
Ich glaube mit der Neuerung für die MQTT GW Geschichte haben sich die Jungs nichts Gutes getan. Da kam reichlich Unordnung in den Bestand.
Das ist nicht das neue Modul was @KaiS meint.
Beim 2+ gleiche Problematik:
Hab den gerade frisch angelegt. Beim Anlegen kann ich übrigens nur eine Instanz
des Konfigurators anlegen, wenn ich zugleich über den WeiterWeiter Dialog auch eine
MQTT Server Instanz anlege. Danach kann ich dann im Konfigurator drin das GW (mit Expertenfunktion) auf den MQTT Client ändern. Zum Schluss dann wieder den MQTT Server löschen.. Naja…
Beta vom Modul installiert?
Aber nochmals übergeordnet in die Runde nachgefragt:
Wenn das nur eine “ reine optische Anzeige” ist, die prinzipiell dann auch falsch ist, weil funktioniert ja trotzdem.
Wieso wurde das dann so neu eingebaut, inkl. der nun hier entstehenden Begleitprobleme ?
Gibts da zukünftig zu erwartende Inkompatibilitäten ? Irgendein Zweck wurde da doch verfolgt, oder ?
Guck ich gleich nach.
Changelog nicht gelesen?
Zweiter Absatz: „Optimierte Instanzerstellung“
Die Anzeige kommt halt, weil einige PHP-Module es zu genau („ich will aber einen MQTT Server“) nehmen 
Changelog hatte ich schon gelesen und die Optimierung an der Stelle ist auch sehr gut,
ich meinte eher den Sinn hinter der Anzeige der “Inkompatibilität”.
Nochmals zu den Basics, dass ich das auch korrekt anwende / verstanden hab.
Entweder ich verwende in Symcon eine MQTT Server Instanz, dann ist das “MQTT SERVER”
oder ich hab einen externen Broker im Einsatz, dann wird die Verbindung von Devices zu diesem
über MQTT Client etabliert, oder ?
Schrieb ist ja:
Das Modul will halt einen MQTT Server. Darum die Anzeige.
Jein… Das „Entweder“ stimmt so nicht. Du kannst beliebig viele externe als auch in Symcon angelegte Broker nutzen.
In Symcon redet aber nur der MQTT Client mit einem externen Broker.
Beta ist die Lösung.. Beim älteren Shelly Modul war ich auf Beta.
Bei der 2+ auf normal..
@KaiS 2+ Beta Konfigurator läuft.
Stimmt, ich habs aus Sicht des “Enddevice” versucht zu beschreiben. Da gibts ja nur eine Anbindung, so gesehen “entweder”.
Aber klar, es können mehrere MQTT Server oder auch MQTT Client Instanzen verwendet werden.
Das ist ja das coole in Symcon. Man kann über mehrere Instanzen etwas Ordnung ins MQTT Universum bringen. 
@KaiS Macht es Sinn / kann / soll ich eigentlich die alten Shelly Devices auf das neue Modul (2+) umbauen ?
PS: Warum ich solche und manch andere vllt. doofe Fragen stelle:
Ab einer gewissen Anzahl und auch Größe von Symcon Systemen wird man etwas vorsichtiger was
Updates und Zukunftstauglichkeit mancher Installationen oder auch UI Elementen angeht.
Daher bin ich bei solchen Updates / Meldungen grundsätzlich vorsichtig und am eroieren,
wie der Impact auf anderen Systemen aussehen könnte, die ggf. nicht immer im direkten Zugriff sind und / oder
wo z.B. ältere Menschen mit im Spiel sind. (Die reagieren z.B. auf plötzliche UI Neuerungen immer sehr empfindlich 
)
Die Gen1 solltest du auf dem alten Modul lassen, das neue Shelly Modul ist halt ab Gen2.
