openhabforum.de

Ok Udo kein Thema. Danke
Aber sag mal hast Du eine Idee warum ich die Werte aus meinem DHT22 der an der MCU hängt in OH erst aktualisiert bekomme, wenn ich den erzeugten Switch betätige?
Die MCU läuft über MQTT ich habe kein zusätzlichen things in der PaperUI angelegt, (ich bekomme das nicht auf die Kette mit dem anlegen der Things über die PaperUI, finde nie die Daten/Infos die ich dort alle eingeben muss) die entsprechenden Werte erhalte ich somit über:
Die Werte werden alle 300 Sek. neu vom MCU an den MQTT übergeben.
PS. was auch noch sonderbar ist, wenn ich ein LED an den MCU anschließe, reagiert die Geschichte mit der Power verdreht Power Switch ON ist LED aus, Power Switch OFF ist LED an.

Also erstmal konfigurierst Du hier ja mqtt1, nicht mqtt2. Bei mqtt ist es tatsächlich so, dass Du beide Bindings parallel betreiben kannst. Mittelfristig solltest Du aber unbedingt auf mqtt2 umsteigen. Das ist aber auch nicht komplizierter als mqtt1. Du kannst das über Text konfigurieren oder über Paper UI. Wichtig ist halt, dass Du den Broker anlegst, so wie er für mqtt1 auch in der mqtt.cfg eingerichtet werden musste.
Dann legst Du mindestens ein Thing an, besser je Gerät ein Thing, und für jeden Schaltkanal bzw. für jeden Fühler (DHT22) einen Channel. Wenn Du zusätzliche Daten haben willst, wie z.B. RSSI (Feldstärke des WLAN Signals am Device - daran kann man eventuelle Verbindungsprobleme abscbätzen) musst Du dafür ebenfalls eigene Channel anlegen.

Das stat Topic (z.B. stat/MCU1/POWER) wird nur aktualisiert, wenn das passende cmnd Topic (also cmnd/MCU1/POWER) einen Befehl oder eine Anfrage empfängt (also als Payload ON/OFF/TOGGLE oder nix). openHAB sendet von sich aus kein null-Payload gegen das cmnd Topic. Du kannst das aber über eine System started rule erreichen, Du musst dazu aber die mqtt action verwenden, da ein sendCommand kein null-Payload senden kann.

Bei mqtt1 musst Du die Action getrennt installieren, bei mqtt2 ist die Action mit dabei, wird aber anders aufgerufen.

Was die LED betrifft, der Ausgang ist meines Wissens bei ON logisch Hi, also 3.3 Volt. Die LED muss gegen Masse geschaltet sein, damit sie bei ON leuchtet.

Hi Udo,
vielen Dank für die Hilfe.... wenn ich auch nicht alles zu 100% verstanden habe bzw. nicht genau weiß was Du mit allem meinst bzw. wie ich es umsetzen soll.
Den Abschnitt mit der Geschichte Daten in OH aktualisieren würde ich gerne mal angehen. Leider ist mit die Info Payload ON/OFF/TOGGLE nicht bekannt. Das soll wohl bedeuten, dass ich einen Schalter benötige, der automatisch alle x-Minuten zwischen on und off wechselt. Das könnte ich wohl mit einer Regel losen. Aber was ist das mit dem TOGGLE? Kannst Du mir vielleicht anhand meiner Daten oben ein Beispiel der Geschichte erstellen die Du mir hier beschrieben hast? Das war mega und würde mir in der Sache weiterhelfen.
Vielen Dank
Joe

Die Payload ist der Inhalt des Befehls oder auch des Status, der zurück kommt. Jede Payload wird in ein Topic gesendet. Das Topic cmnd/MCU1/POWER unterstützt dabei die von mir beschriebenen Payloads. ON schaltet das Relais ein, OFF schaltet das Relais aus, TOGGLE wechselt den Zustand des Relais, ein null-Payload führt zu keinem Wechsel. Jedes Mal (auch beim null-Payload) wird aber vom Tasmota Modul auf das Topic stat/MCU1/POWER entweder ON oder OFF gesendet.
Es kann allerdings auch sein, dass das Modul mit POWER1 antwortet, dann sollte man auch das command Topic entsprechend ändern (weil's halt ordentlicher ist).
Mit z.B. mqtt spy oder mqtt.fx kannst Du live verfolgen, welche Topics gesendet werden. Dabei kannst Du das Topic # abonnieren, damit bekommst Du jedes vom Broker empfangene Topic zugestellt. Gerade beim Testen in neuen Installationen kann das sehr hilfreich sein.