MQTT parallel MQTT2_Device: autocreate Problem

Begonnen von tyrolean, 10 November 2019, 17:35:55

Vorheriges Thema - Nächstes Thema

tyrolean

Hallo,

auf meinem RPi läuft folgende Konfiguration:
Ein mosquitto server auf Port. 1883
damit verbunden Zigbee2mqtt eingebunden in FHEM über MQTT

Damit ich meine Shellies bzw. Sonoffs benutzen kann noch ein MQTT2_Client (Port 1883)
Zumindest mit den Shellies und eingebundenen Zigbee Devices läuft das Ganze Problemlos.

Jetzt aber zu meinem Problem:
Sobald ich Versuche ein weiteres Gerät (Z.Bsp. Sonoff Tasmota) neu einzubinden (Hierfür ist das "globale" Autocreate auf enable und ich stelle temporär MQTT2 autocreate auf simple oder complex (den Unterschied habe ich ehrlich gesagt nicht verstanden) werden keine neuen Geräte hinzugefügt jedoch werden in sämtlichen bereits vorhandenen Geräten in die ReadingLists einfach alle Einträge von allen Geräten gespeichert.
Das dauert natürlich ewig bis das wieder korrigiert ist und meine neuen Geräte habe ich immer noch nicht eingebunden.

Mache ich da grundsätzlich etwas falsch oder liegt es am prallelen Betrieb von MQTT und MQTT2_Devices?

Gruß und Dank aus Tirol

rudolfkoenig

MQTT und MQTT2_CLIENT sollten sich gegenseitig nicht stoeren.

MQTT2_CLIENT kann nur ein bisschen autocreate, da es nicht weiss, welche Topics zu einem Geraet gehoeren.
Man kann damit immerhin ein MQTT2_DEVICE anlegen, und dessen readingList automatisch erweitern. Einzelne Geraete anzulegen, und readingList auseinanderfieseln darf man manuell.
ES SEI DENN man setzt in diesem einzigen MQTT2_DEVICE bridgeRegexp, mit dem man dem Modul beibringt, wem die Topics zuzuordnen sind.

MQTT2_SERVER hat es einfacher, weil jedes (gesittete) MQTT-Client einen eindeutigen clientId schickt, und anhand dieser Id kann man die Topics zuordnen.

autocreate=simple verwendet die kurze Form von json2nameValue, complex die Aufwendige, fuer den Fall dass die JSON Variablennamen nicht eindeutig sind.
Sollte im commandref beschrieben sein.

Beta-User

Du solltest in jedem Fall die Definitionen (fast) aller MQTT2_DEVICE-Instanzen durchsehen. Das Problem der "überall erweiterten" readingList-Einträge dürfte daher kommen, dass die alle dieselbe CID haben (nämlich die des CLIENT). Da gilt: besser keine oder eine Phantasie-Angabe als die "Standard-CID"...

Tendenziell sollte das attrTemplate "MQTT2_CLIENT_general_bridge" (etwas) weiterhelfen; das "errät" (häufig), welche Infos zusammengehörend und ordnet die dann (hoffentlich) dem "richtigen" Gerät zu. Evtl. mußt du die dortige bridgeRegexp auf deine Topic-Struktur anpassen, dann wird der "Yield" besser...

Wenn du dann verstanden hast, wie diese bridgeRegexp wirkt, kannst du dann ja auch die CID deiner vorhandenen Geräte auf den passenden Stand bringen.
Server: HP-elitedesk@Debian 12, 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: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files