(gelöst) Tasmota MQTT_BRIDGE führt zu PUBLISH-Endlosschleife

Begonnen von AlexBV, 24 Juni 2018, 22:48:37

Vorheriges Thema - Nächstes Thema

AlexBV

Hallo zusammen!

Ich habe einen Dummy per MQTT_BRIDGE mit einer Obi-WLAN Steckdose verbunden, die ich zuvor auf Tasmota geflasht habe.  Die Definition sieht wie folgt aus:


define SmartplugTas1 dummy
attr SmartplugTas1 eventMap on:ON off:OFF
attr SmartplugTas1 genericDeviceType switch
attr SmartplugTas1 room Alexa,Büro
attr SmartplugTas1 setList on off
attr SmartplugTas1 webCmd on:off

define mqttSmartplugTas1 MQTT_BRIDGE SmartplugTas1
attr mqttSmartplugTas1 IODev myBroker
attr mqttSmartplugTas1 publishState cmnd/MqttPlug1/POWER
attr mqttSmartplugTas1 room Büro
attr mqttSmartplugTas1 subscribeSet stat/MqttPlug1/POWER


Wenn ich nun einen Schaltbefehl sende, egal ob von der Steckdose zu FHEM oder von FHEM zur Steckdose per MQTT, startet eine Endlosschleife. Denn Tasmota bestätigt jeden publishState mit einer Statusmeldung, die wiederum das subscribeSet empfängt, den Dummy wieder schaltet, was wieder zu einem publishState zur Steckdose führt. Nach ein paar hundert publishStates innerhalb weniger Minuten verabschiedet sich die Steckdose bzw. Tasmota endgültig.

Hier ein Auszug aus dem MQTT-Log:


Client mosqsub/rpi01 received PUBLISH (d0, q0, r0, m0, 'cmnd/MqttPlug1/POWER', ... (2 bytes))
cmnd/MqttPlug1/POWER ON
Client mosqsub/rpi01 received PUBLISH (d0, q0, r0, m0, 'stat/MqttPlug1/RESULT', ... (14 bytes))
stat/MqttPlug1/RESULT {"POWER":"ON"}
Client mosqsub/rpi01 received PUBLISH (d0, q0, r0, m0, 'stat/MqttPlug1/POWER', ... (2 bytes))
stat/MqttPlug1/POWER ON
Client mosqsub/rpi01 received PUBLISH (d0, q0, r0, m0, 'cmnd/MqttPlug1/POWER', ... (2 bytes))
cmnd/MqttPlug1/POWER ON
Client mosqsub/rpi01 received PUBLISH (d0, q0, r0, m0, 'stat/MqttPlug1/RESULT', ... (14 bytes))
stat/MqttPlug1/RESULT {"POWER":"ON"}
Client mosqsub/rpi01 received PUBLISH (d0, q0, r0, m0, 'stat/MqttPlug1/POWER', ... (2 bytes))
stat/MqttPlug1/POWER ON
Client mosqsub/rpi01 received PUBLISH (d0, q0, r0, m0, 'cmnd/MqttPlug1/POWER', ... (2 bytes))
cmnd/MqttPlug1/POWER ON
Client mosqsub/rpi01 received PUBLISH (d0, q0, r0, m0, 'stat/MqttPlug1/RESULT', ... (14 bytes))
stat/MqttPlug1/RESULT {"POWER":"ON"}
Client mosqsub/rpi01 received PUBLISH (d0, q0, r0, m0, 'stat/MqttPlug1/POWER', ... (2 bytes))
stat/MqttPlug1/POWER ON



Hat jemand eine Idee, wie ich die Sache lösen kann?


hexenmeister

Wenn zum Senden und Empfangen dieselbe Reading nimmt, entsteht natürlich ein Kreis.
Entweder trennen, oder umkehren (publishSet und subscribe state). Einen Dummy brauchst Du übrigenms nicht.
Meine Beispiellösung:

defmod MQ_DG_WZ_Licht_Top MQTT_DEVICE
attr MQ_DG_WZ_Licht_Top IODev mqtt
attr MQ_DG_WZ_Licht_Top devStateIcon off:light_light_dim_00@gray on:light_light_dim_100@yellow .*:hourglass
attr MQ_DG_WZ_Licht_Top eventMap on:on off:off
attr MQ_DG_WZ_Licht_Top group DG_Wohnzimmer
attr MQ_DG_WZ_Licht_Top publishSet on off /ha/dg/wz/licht/top/set
attr MQ_DG_WZ_Licht_Top room MQTT_TEST
attr MQ_DG_WZ_Licht_Top stateFormat state
attr MQ_DG_WZ_Licht_Top subscribeReading_state /ha/dg/wz/licht/top/state
attr MQ_DG_WZ_Licht_Top webCmd on:off
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

AlexBV

Danke für die Info.

Der Kreis entsteht ja nicht durch das selbe Reading, sondern dadurch dass Tasmota jedes publish cmd mit einer Statusmeldung bestätigt, die wiederum den Dummy (auf den selben Status) schaltet, was dann wieder ein publish cmd auslöst usw. Das würde auch passieren, wenn die readings völlig unterschiedlich wären.

Was meinst du hier mit trennen oder umkehren? Darunter kann ich mir nichts vorstellen.

Die Lösung mit MQTT_DEVICE funktioniert übrigens gut.  Allerdings musste ich sie verwerfen,  da sich das MQTT_DEVICE offensichtlich nicht in den Aexa Standard Homeskill integrieren lässt. Mit dem Dummy geht das problemlos.

hexenmeister

Aber selbstverständlich entsteht der Kreis dadurch, dass sowohl Tasmota, als auch FHEM auf jeden Befehl mit einer Staqtusänderung reagieren. Bei dem Tasmota muss das so sein (als Bestätigung, dass es geschaltet wurde), bei FHEM ist das ein Fehler. Dadurch schliesst sich der Kreis.
Verwende verschiedene Topict fürs Schalten und Status und nehme nicht die selbe Reading in FHEM, dann hast Du kein Problem ;)

Also entweder verschiedenen Topics (und auch nicht dieselbe Reading) nehmen, oder wie ich es vorgeschlagen habe (meine Mapping-Variante ist quasi zu Deiner 'umgekehrt'). Da MQTT_DEVICE und MQTT_BRIDGE ähnlich konfiguriert werden, ist mein Vorschlag auch auf einen Dummy übertragbar.

Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

AlexBV

Ok, danke erstmal.

Aber so ganz komme ich noch nicht dahinter, wie ich vorgehen soll.

Wie kann ich denn verschiedene Topics nehmen? Die Topics "cmnd/MqttPlug1/POWER" und "state/MqttPlug1/POWER" sind doch von Tasmota vorgegeben.
Mit verschiedene Readings meinst du wahrscheinlich, für den Dummy auf/zu oder ähnliches anstatt ON/OFF, richtig? Aber so ganz erschließt mich der Sinn nicht.
Denn die States werden doch trotzdem abwechselnd gesetzt und lösen gegenseitig Statusänderungen aus.

Könntest Du mir ein konkretes Beispiel zeigen, wie du vorgehen würdest?

hexenmeister

Zu Tasmota kann ich wenig sagen, kenne ich nicht. Aber so wie Du schreibst, sind die Topics bereits verschieden cmnd... zum Steuern und state... für den Zustand.
Was FHEM betriefft, werwechselst Du Readings mit den darin enthaltenen Werten. State ist ein Reading, ON, OFF, an, aus sind Werte.
Lege z.B. ein Readings namens 'set' und setze entsprechend publish darauf, dann wird beim Setzen eines Wertes darin diser auch per MQTT gesendet.
Für den Empfang des Zustandes muss dann aber zwingend eine andere Reading zuständig sein. z.B. 'state'. Dann wird seine Zustandsänderung keine neue Sendung veranlassen (denn 'set' hat sich ja nicht geändert).
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

AlexBV

Ich habe trotz Forumsuche keine Ahnung, wie ich dem Dummy ein Reading namens "set" beibringen kann. Wahrscheinlich mit setreading über ein notify oder über eine readingList. Das scheint mir aber recht umständlich.

In der CommandRef steht unter publishState "configures a topic such that a message is sent to topic whenever the device state changes"
Das scheint offensichtlich nicht zu funktionieren (Bug?). Denn von "state on" auf "state on" ist schließlich kein Change.
Es hat mich allerdings zur Lösung gebracht. Mit einem "event-on-change-reading .*" funktioniert es jetzt perfekt.

Trotzdem nochmal vielen Dank für den Input.

hexenmeister

Das ist eher ein Workaround, denn eine stabile Lösung.
Ich würde Dir anraten, die FHEM-Grundlagen (Einsteigerhandbuch) durchzlesen, dann wird die grundsätzliche Funktionsweise und zusammenspiel von Modulen, Readings, Events etc. klar.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy