Wie MQTT-Client richtig anlegen

[kaloschke]

Hallo,
ich habe diesen Drehknopf
Er liefert mir u.a. das MQTT-Topic

zigbee2qutt/z_knob1/action

.
Dieses kann die Werte
- single
- double
- rotate_right
- rotate_left
annehmen.
Wie definiere ich ein entsprechendes Item und wie reagiere ich in einer Rule auf die verschiedenen Werte des Topics?
Das MQTT-Binding ist natürlich definiert.

Viele Grüße

Edit: Vergaß zu erwähnen, dass die Definition des Things in einer things-Datei erfolgen soll.

[udo1toni]

sollte so gehen:

Code: Alles auswählen

// übergeordnet die Bridge mqtt:broker:broker
Thing topic tuya_ers_1 "TuYa ERS-10TZBVK-AA" [
 ] {
    Channels:
    Type trigger : knob [ stateTopic="zigbee2qutt/z_knob1/action" ] 
 }

Der Trick ist, den Channel als Trigger anzulegen.

Bist du beim Topic sicher? ich hätte eher zigbee2mqtt/... erwartet.

In einer DSL Rule reagierst Du dann so:

Code: Alles auswählen

rule "TuYa ERS-10TZBVK-AA 1 triggert"
when
    Channel 'mqtt:topic:broker:tuya_ers_1:knob' triggered
then
    switch(receivedEvent.toString.toLowerCase) { // evtl. geht's auch ohne .toString.toLowerCase
        case "single"       : {
            // mach was
        }
        case "double"       : {
            // mach was anderes
        }
        case "rotate_right" : {
            // mach was verdrehtes
        }
        case "rotate_left"  : {
            // schwindelig?
        }
        default             : {
            logWarn("tuyaKnob","Da ist was schiefgelaufen! unbekannter Trigger ({})",receivedEvent)
        }
    }
end

Die Doku ist an dieser Stelle übrigens verkehrt, keine Ahnung, ob das früher mal anders zu konfigurieren war (laut Doku als Channel mit dem Parameter trigger=true), jedenfalls habe ich es bei mir getestet und es funktioniert wie beschrieben...
receivedEvent ist eine implizite Variable, die in jeder Rule, welche auf Channel ... triggered auslöst, das triggernde Event enthält. Um die Schreibweise sicher zu haben, bietet es sich an, den String in Kleinbuchstaben zu wandeln (wahlweise ginge natürlich auch .toUpperCase oder man verzichtet darauf und passt auf, die Trigger ganz sicher wirklich exakt so anzugeben wie sie im System rein kommen ).
Der default Zweig wird ausgeführt, wenn keiner der vorherigen Cases zutrifft, das ist also immer eine tolle Möglichkeit, eine Warnmeldung abzusetzen.

[kaloschke]

Hervorragend!!!
Klappt 1A, auch wenn nicht sofort und ich anfangs etwas frustriert war. Habe aber dann den kleinen Tippfehler bei

zigbee2->qutt<-/z_knob1/action

gefunden

Vielen vielen Dank.
Eine Frage noch: wozu dienen die eckigen Klammern in

Code: Alles auswählen

Thing topic tuya_ers_1 "TuYa ERS-10TZBVK-AA" [ ] { ...

?

[udo1toni]

Du kannst für mqtt Things verschiedene konfigurieren, beispielsweise das LWT.
Ein Beispiel Device (eine Gosund SP110 "WLAN Steckdose"):

Code: Alles auswählen

     Thing topic gosund_2 "Gosund 2" @ "mqtt" [
         availabilityTopic="gosund_2/tele/LWT",
         payloadNotAvailable="Offline",
         payloadAvailable= "Online"
      ]{
          Type switch : ch1 "Schalter"     [ stateTopic="gosund_2/stat/POWER", commandTopic="gosund_2/cmnd/POWER" ]
          Type number : power "Leistung"   [ stateTopic="gosund_2/tele/SENSOR", transformationPattern="JSONPATH:$.ENERGY.Power"  , unit="W" ]
          Type number : voltage "Spannung" [ stateTopic="gosund_2/tele/SENSOR", transformationPattern="JSONPATH:$.ENERGY.Voltage", unit="V" ]
          Type number : current "Strom"    [ stateTopic="gosund_2/tele/SENSOR", transformationPattern="JSONPATH:$.ENERGY.Current", unit="A" ]
      }

Mein FullTopic ist übrigens %topic%/%prefix%/, nur um Verwirrung zu vermeiden...

[kaloschke]

Ah cool.
Aber wir nutzt man die Angaben z.B. payloadAvailable bzw. warum diese Angabe an dieser Stelle?

[udo1toni]

Ah cool.
Aber wir nutzt man die Angaben z.B. payloadAvailable bzw. warum diese Angabe an dieser Stelle?

Das LWT ist als Funktion definiert, nicht jedoch, wie das Topic lautet, wo es zu finden ist und welchen Inhalt es hat.
Ein Client kann sich mit ONLINE/OFFLINE oder On/Off oder auch an/aus melden, das bleibt dem Entwickler überlassen. Enstprechend muss man im Client auch definieren, welche Payload die jeweilige Bedeutung hat.

[kaloschke]

Dank Dir

[peter-pan]

Das LWT ist als Funktion definiert, nicht jedoch, wie das Topic lautet, wo es zu finden ist und welchen Inhalt es hat.
Ein Client kann sich mit ONLINE/OFFLINE oder On/Off oder auch an/aus melden, das bleibt dem Entwickler überlassen. Enstprechend muss man im Client auch definieren, welche Payload die jeweilige Bedeutung hat.

..hab's leider immer noch nicht verstanden.!?
Hier ein Beispiel-Thing aus meinem SetUp mit ergänztem "Payload":

Code: Alles auswählen

Thing mqtt:topic:claudi:nous01 "Nous A1T"  (mqtt:broker:claudi )     @ "MQTT2" [
         availabilityTopic="tele/nous_01/LWT",
         payloadNotAvailable="Offline",
         payloadAvailable= "Online"
      ]{
    Channels:
        Type switch : power     "Power "                 [ stateTopic="stat/nous_01/POWER", commandTopic="cmnd/nous_01/POWER" ]
        Type number : rssi      "WiFi Signal Strength"   [ stateTopic="tele/nous_01/STATE", transformationPattern="JSONPATH:$.Wifi.RSSI"]
        Type string : version   "Firmware Version    "   [ stateTopic="stat/nous_01/STATUS2", transformationPattern="JSONPATH:$.StatusFWR.Version"]
        Type string : reachable "Reachable"              [ stateTopic="tele/nous_01/LWT" ]
        Type string : hardware  "Chip Set            "   [ stateTopic="stat/nous_01/STATUS2", transformationPattern="JSONPATH:$.StatusFWR.Hardware"]
        Type string : ipaddress "IP Address          "   [ stateTopic="stat/nous_01/STATUS5", transformationPattern="JSONPATH:$.StatusNET.IPAddress"]
        Type number : powerload "Power load"             [ stateTopic="tele/nous_01/SENSOR", transformationPattern="JSONPATH:$.ENERGY.Power"]
        Type number : voltage   "Line voltage"           [ stateTopic="tele/nous_01/SENSOR", transformationPattern="JSONPATH:$.ENERGY.Voltage"]
        Type number : current   "Line current"           [ stateTopic="tele/nous_01/SENSOR", transformationPattern="JSONPATH:$.ENERGY.Current"]
        Type number : total     "Total energy "          [ stateTopic="tele/nous_01/SENSOR", transformationPattern="JSONPATH:$.ENERGY.Total"]
        Type number : totalday  "Total energy today"     [ stateTopic="tele/nous_01/SENSOR", transformationPattern="JSONPATH:$.ENERGY.Today"]
        Type number : totalyest "Total energy yesterday" [ stateTopic="tele/nous_01/SENSOR", transformationPattern="JSONPATH:$.ENERGY.Yesterday"]
        Type string : ssid      "WiFi"                   [ stateTopic="tele/nous_01/STATE", transformationPattern="JSONPATH:$.Wifi.SSId"]
        Type datetime : time    "Time"                   [ stateTopic="tele/nous_01/STATE", transformationPattern="JSONPATH:$.Time"]
        Type string : grouptop  "Group Topic"            [ stateTopic="stat/nous_01/STATUS1", transformationPattern="JSONPATH:$.StatusPRM.GroupTopic"]
    }

Einen Channel ("reachable") mit verlinktem Item, habe ich auch.

Code: Alles auswählen

Switch nous_01_Unreach      "Nous 01 Dyson  Erreichbarkeit [%s]"  <siren1> (gNous_01,gLWT)  ["Point"]   { channel="mqtt:topic:claudi:nous01:reachable" }     

Die Infos unter https://tasmota.github.io/docs/MQTT/#lw ... -testament sagen mir auch nichts direkt. Ich muss auch dazu sagen, dass ich das bisher nie so richtig beachtet habe.

Wenn ich in der Shell-Konsole den Befehl eingebe, bekomme ich folgendes als Ergebnis:

Code: Alles auswählen

hab3@oh3ssd:~ $ mosquitto_sub -t "tele/nous_01/LWT"
Online
hab3@oh3ssd:~ $

Was ich bisher gefunden habe, ist mir bis jetzt etwas zu "abstrakt". Gibt's dafür ein praktisches Beispiel, wie ich erkennen kann bzw. wie ich die Info erhalte, dass das Gerät offline ist ?

Also irgendwie steh' ich da "auf dem Schlauch."

[udo1toni]

Wenn Du es in einem Item sehen möchtest, müsstest Du den Channel aber auch korrekt konfigurieren, in diesem Fall also entweder als String (und das Item ebenfalls als String -> dann solltest Du Online oder Offline als Status ausgegeben bekommen) oder als switch (passend zum Switch Item), dann aber so:

Code: Alles auswählen

Type switch : reachable "Reachable"              [ stateTopic="tele/nous_01/LWT", on="Online", off="Offline" ]

dann sollte das Switch Item automatisch von On nach Off umspringen, sobald das Nous nicht mehr erreichbar ist. Als Test ziehst Du das Nous einfach mal kurz aus der Steckdose, Mosquitto bekommt das gewöhnlich sofort mit (eher Sekundenbruchteile als ganze Sekunden).

Aber da die Information auch als Thing-Eigenschaft zur Verfügung steht, kannst Du eine passende Rule auch direkt auf

Code: Alles auswählen

Thing 'mqtt:topic:claudi:nous_01' changed

triggern lassen - siehe https://www.openhab.org/docs/configurat ... d-triggers und https://www.openhab.org/docs/configurat ... tion-block - mit newThingStatus und previousThingStatus stehen zwei lokale String Konstanten zur Verfügung, welche man auswerten kann.

[peter-pan]

@udo1toni
Super, Danke. Hat sofort geklappt.
Ich hab gar nicht gemerkt, das Item und Channel unterschiedliche Typen waren. Und Danke auch für die Links. Damit werde ich mich mal in den nächsten Tagen auseinander setzen, um zu sehen, was man mit den Thing-Triggern alles machen kann.
Ich hab mir erst mal eine kleine Regel gebastelt, mit der ich alle LWT's überwachen kann.

Code: Alles auswählen

import org.openhab.core.model.script.ScriptServiceUtil

rule "gLWT_Logging"

when Member of gLWT changed
then
   if(Tasmota_LWT_Logging.state == ON) {
      var GenericItem tempItemName = ScriptServiceUtil.getItemRegistry.getItem(triggeringItem.name.replace("_Unreach","_IPAddress")) as  GenericItem
      logInfo ("Last will test", "Gerät-Bezeichnung: {} - Status: {} - Item-Name {} - Generic-Name {} - Generic-Status {}",triggeringItem.label, triggeringItem.state.toString, triggeringItem.name, tempItemName.name,tempItemName.state.toString)     
    }
end
//===============================================================================================

Das/die LogInfo ist zwar (vorerst noch) etwas lang, dient aber nur meiner Neugier, und zum Testen,ob alles richtig läuft. Was mich aber etwas wundert, ist die Tatsache, dass öfters ein "ON" getriggert wird, ohne vor ein "OFF" gewesen zu sein!?

Code: Alles auswählen

2024-02-12 23:07:03.354 [INFO ] [hab.core.model.script.Last will test] - Gerät-Bezeichnung: Gosund 01 Echo 8 Switch Erreichbarkeit - Status: OFF - Item-Name SP111_01_Unreach - Generic-Name 192.168.178.36 - Generic-Status {}
2024-02-12 23:07:38.041 [INFO ] [hab.core.model.script.Last will test] - Gerät-Bezeichnung: Gosund 01 Echo 8 Switch Erreichbarkeit - Status: ON - Item-Name SP111_01_Unreach - Generic-Name 192.168.178.36 - Generic-Status {}
2024-02-12 23:29:41.064 [INFO ] [hab.core.model.script.Last will test] - Gerät-Bezeichnung: Gosund 01 Echo 8 Switch Erreichbarkeit - Status: ON - Item-Name SP111_01_Unreach - Generic-Name SP111_01_IPAddress - Generic-Status 192.168.178.36
2024-02-12 23:29:41.069 [INFO ] [hab.core.model.script.Last will test] - Gerät-Bezeichnung: Gosund 01 Echo 8 Switch Erreichbarkeit - Status: ON - Item-Name SP111_01_Unreach - Generic-Name SP111_01_IPAddress - Generic-Status 192.168.178.36