OH3 schaltet MQTT nur sporadisch

[KiWi22]

Hallo Leute,
ich möchte über MQTT einige Relais ansteuern, was mit MQTT.fx auch einwandfrei funktioniert. Über OH funktioniert es aber leider nur sporadisch und es kommt in MQTT.fx (und an den Relais) manchmal nichts an.
OH3 und MQTT-Broker Mosquitto laufen auf RP4. Zum Schalten über UI habe ich für jeden Schalter ein Item angelegt, für jeden "MQTT-Ausgang" ebenfalls ein eigenes Item. Die Steuerung erfolgt über jeweils eine Rule "AN":

Code: Alles auswählen

triggers:
  - id: "1"
    configuration:
      itemName: SchalterV2
      state: ON
      previousState: OFF
    type: core.ItemStateChangeTrigger
  - id: "3"
    configuration:
      time: 18:26
    type: timer.TimeOfDayTrigger
conditions: []
actions:
  - inputs: {}
    id: "2"
    configuration:
      itemName: MQTT_Bew_Ventil_2
      command: ON
    type: core.ItemCommandAction

und über eine Rule "AUS":

Code: Alles auswählen

triggers:
  - id: "1"
    configuration:
      itemName: SchalterV2
      state: OFF
      previousState: ON
    type: core.ItemStateChangeTrigger
  - id: "3"
    configuration:
      time: 18:31
    type: timer.TimeOfDayTrigger
conditions: []
actions:
  - inputs: {}
    id: "2"
    configuration:
      itemName: MQTT_Bew_Ventil_2
      command: OFF
    type: core.ItemCommandAction

Hat jemand eine Idee, woran es liegen könnte, dass der Befehl manchmal nicht gesendet wird?
Ich bin über jeden Tipp dankbar!

[udo1toni]

Wozu hast Du denn den zweiten (also eigentlich den ersten) Trigger mit in der Rule?

[KiWi22]

Wozu hast Du denn den zweiten (also eigentlich den ersten) Trigger mit in der Rule?

Ich möchte (derzeit) über festgelegte Zeiten aber auch über virtuelle Schalter auf UI schalten.

Nachdem ich die Empfänger (ESP8266 + Relais) mit MQTT.fx fertig getestet hatte, habe ich in OH3 MQTT-Channels angelegt und diese direkt mit den virtuellen Schaltern verlinkt. Die Test damit verliefen auch schon sporadisch. Da die Steuerung über die Schalter hinaus erweiterbar sein soll (feste Zeiten, wetterabhängig, usw.), habe ich die Verlinkung wieder entfernt und dafür die Rules eingefügt.
Die Schaltvorgänge habe ich am Empfänger/Relais und parallel mit MQTT.fx geprüft und manchmal kommt eine Schalterumstellung nicht an. Am Schalter wird entsprechend ein anderer Zustand angezeigt, als am Relais und MQTT.fx. Auch zur eingestellten Zeit wird nicht verlässlich geschaltet.
Mit den Profilen "Standard" und "Folgen" habe ich auch getestet, aber kein nennenswerter Unterschied.
Was könnte ich noch probieren?

[peter-pan]

Also ich habe mal versucht, deine Rule "nachzubauen". Das sieht dann als Yaml so aus:

Code: Alles auswählen

triggers:
  - id: "1"
    configuration:
      itemName: Dummy_4
      state: ON
    type: core.ItemStateChangeTrigger
conditions: []
actions:
  - inputs: {}
    id: "2"
    configuration:
      itemName: esp_32_01_relay1
      command: ON
    type: core.ItemCommandAction

Der einzige Unterschied ist, dass ich den vorherigen Status (previousState: OFF) nicht abfrage. Bei mir funktioniert das auf Anhieb. Meine Vermutung ist daher, dass der Status des "virituellen Items" nicht immer OFF ist, z.B. nach einem Neustart (wenn es nicht persistiert war).

Wie sieht denn dein Thing aus ?

Edit: Was meinst du mit "Verlinkung entfernen" ? Der Link zwischen deinem Item "MQTT_Bew_Ventil_2" und dem dazugehörigen Channel muss natürlich immer bestehen bleiben.

[KiWi22]

Der einzige Unterschied ist, dass ich den vorherigen Status (previousState: OFF) nicht abfrage. Bei mir funktioniert das auf Anhieb. Meine Vermutung ist daher, dass der Status des "virituellen Items" nicht immer OFF ist, z.B. nach einem Neustart (wenn es nicht persistiert war).

Ja, das klingt logisch, hab ich auch sofort umgesetzt und getestet. Das Einschalten hat auf allen Kanälen sofort funktioniert, das Ausschalten dann wieder nur sporadisch und dann auch wieder das Einschalten nur sporadisch Bin ich eventuell zu schnell mit dem Hin und Her Schalten das sich OH verschluckt Glaube nicht, hab auch bei langsamen Wechsel den gleichen Effekt
Das ist aber schon ein kleiner Teil, glaube ich jedenfalls und lasse diese Zeile auf jeden Fall aus den Rules raus

Wie sieht denn dein Thing aus ?

Von der Rule betrachtet ausgangsseitig: MQTT - Channels -
MQTT Command Topic: /Bewaesserung/Ventil_3
Custom On/Open Value: 1
Custom Off/Closed Value: 0
Item - Type: Switch

eingangsseitig (virtuelle Schalter): kein Thing, jeweils ein Item - Type: Switch

Was meinst du mit "Verlinkung entfernen" ?

Ich hatte für die ersten Tests den virtuellen Schalter direkt mit dem MQTT-Channel verlinkt. Dann hab ich zwischen Schalter und Channel die Rule gebastelt. Vielleicht habe ich den Begriff "Verlinkung" unpassend gewählt, sorry

Dank für die Hilfe, vielleicht hast Du noch weitere Ideen

[peter-pan]

So richtig verstanden habe ich das nicht, was du da meinst.

Ich gehe mal davon aus, dass du einen Broker (mosquitto) laufen hast und auch das MQTT-Binding installiert hast. Die Kommunikation zwischen deinem Device (ESP8266+Relais) läuft über Things. Dazu brauchst du auch noch einspezielles Thing (die Bridge), welches die grundsätzliche Kommunikation zwischen OH und Broker herstellt.

Dazu brauchst du als erstes ein sogenanntes Bridge/Thing. Das sieht bei mir als Yaml so aus:

Code: Alles auswählen

UID: mqtt:broker:vera
label: Mosquitto
thingTypeUID: mqtt:broker
configuration:
  lwtQos: 0
  publickeypin: true
  clientID: OH3_vera
  keepAlive: 60
  qos: 0
  reconnectTime: 60000
  port: 1883
  host: 192.168.178.xx
  secure: false
  certificatepin: true
  lwtRetain: true
  enableDiscovery: true

Und dann brauchst du pro Device ein Thing mit den entsprechenden Channels. Z.B. für meinen ESP32 mit 5 Relais, 1 Smoke-Sensor, 1Thermostat:

Code: Alles auswählen

UID: mqtt:topic:vera:esp3201
label: ESP32 01
thingTypeUID: mqtt:topic
configuration: {}
bridgeUID: mqtt:broker:vera
location: MQTT2
channels:
  - id: relay1
    channelTypeUID: mqtt:switch
    label: Relay 1
    description: null
    configuration:
      commandTopic: cmnd/esp32_01/POWER1
      retained: false
      postCommand: false
      formatBeforePublish: "%s"
      stateTopic: stat/esp32_01/POWER1
  - id: relay2
    channelTypeUID: mqtt:switch
    label: Relay 2
    description: null
    configuration:
      commandTopic: cmnd/esp32_01/POWER2
      retained: false
      postCommand: false
      formatBeforePublish: "%s"
      stateTopic: stat/esp32_01/POWER2
  - id: relay3
    channelTypeUID: mqtt:switch
    label: Relay 3
    description: null
    configuration:
      commandTopic: cmnd/esp32_01/POWER3
      retained: false
      postCommand: false
      formatBeforePublish: "%s"
      stateTopic: stat/esp32_01/POWER3
  - id: relay4
    channelTypeUID: mqtt:switch
    label: Relay 4
    description: null
    configuration:
      commandTopic: cmnd/esp32_01/POWER4
      retained: false
      postCommand: false
      formatBeforePublish: "%s"
      stateTopic: stat/esp32_01/POWER4
  - id: relay5
    channelTypeUID: mqtt:switch
    label: Relay 5
    description: null
    configuration:
      commandTopic: cmnd/esp32_01/POWER5
      retained: false
      postCommand: false
      formatBeforePublish: "%s"
      stateTopic: stat/esp32_01/POWER5
  - id: rssi
    channelTypeUID: mqtt:number
    label: WiFi Signal Strength
    description: null
    configuration:
      retained: false
      postCommand: false
      step: 1
      formatBeforePublish: "%s"
      stateTopic: tele/esp32_01/STATE
      transformationPattern: JSONPATH:$.Wifi.RSSI
  - id: version
    channelTypeUID: mqtt:string
    label: "Firmware Version    "
    description: null
    configuration:
      retained: false
      postCommand: false
      formatBeforePublish: "%s"
      stateTopic: stat/esp32_01/STATUS2
      transformationPattern: JSONPATH:$.StatusFWR.Version
  - id: reachable
    channelTypeUID: mqtt:switch
    label: Reachable
    description: null
    configuration:
      retained: false
      postCommand: false
      formatBeforePublish: "%s"
      stateTopic: tele/esp32_01/LWT
      transformationPattern: MAP:reachable.map
  - id: hardware
    channelTypeUID: mqtt:string
    label: "Chip Set            "
    description: null
    configuration:
      retained: false
      postCommand: false
      formatBeforePublish: "%s"
      stateTopic: stat/esp32_01/STATUS2
      transformationPattern: JSONPATH:$.StatusFWR.Hardware
  - id: ipaddress
    channelTypeUID: mqtt:string
    label: "IP Address          "
    description: null
    configuration:
      retained: false
      postCommand: false
      formatBeforePublish: "%s"
      stateTopic: stat/esp32_01/STATUS5
      transformationPattern: JSONPATH:$.StatusNET.IPAddress
  - id: ssid
    channelTypeUID: mqtt:string
    label: WiFi
    description: null
    configuration:
      retained: false
      postCommand: false
      formatBeforePublish: "%s"
      stateTopic: tele/esp32_01/STATE
      transformationPattern: JSONPATH:$.Wifi.SSId
  - id: temp
    channelTypeUID: mqtt:number
    label: Temp. DHT11 ESP32 01
    description: null
    configuration:
      retained: false
      postCommand: false
      step: 1
      formatBeforePublish: "%s"
      stateTopic: tele/esp32_01/SENSOR
      transformationPattern: JSONPATH:$.DHT11.Temperature
  - id: hum
    channelTypeUID: mqtt:number
    label: Hum.  DHT11 ESP32 01
    description: null
    configuration:
      retained: false
      postCommand: false
      step: 1
      formatBeforePublish: "%s"
      stateTopic: tele/esp32_01/SENSOR
      transformationPattern: JSONPATH:$.DHT11.Humidity
  - id: dew
    channelTypeUID: mqtt:number
    label: Tau.  DHT11 ESP32 01
    description: null
    configuration:
      retained: false
      postCommand: false
      step: 1
      formatBeforePublish: "%s"
      stateTopic: tele/esp32_01/SENSOR
      transformationPattern: JSONPATH:$.DHT11.DewPoint
  - id: smoke1
    channelTypeUID: mqtt:number
    label: Gas Sensor  ESP32 01
    description: null
    configuration:
      retained: false
      postCommand: false
      step: 1
      formatBeforePublish: "%s"
      stateTopic: tele/esp32_01/SENSOR
      transformationPattern: JSONPATH:$.ANALOG.A1

Der Mikroprozessor ist mit der Firmware von Tasmota (Version 9.5.0) geflasht.

Wie du siehst, hat jedes Relais einen eigenen Channel mit dem ein Kommando übergeben werden kann bzw. ein Status zurückgeliefert (angefragt) werden kann.

Und dann brauchst du noch für jeden deiner Channels ein verknüpftes Item.

Grundsätzliches dazu findest unter anderem hier.

Wenn du das alles hast, sollte das in OH3/Einstellungen/Things etwa so aussehen:

mqtt.jpg

Welche Firmware hat denn dein ESP8266 ?

[KiWi22]

Vielen Dank peter-pan für die ausführliche Beschreibung.
Bei mir ist es auch (fast) so, nicht so gut sortiert nach unterschiedlichen Devices, bei mir ist alles in einem Thing, in Channels.
Ein weiterer Unterschied ist, dass ich den Status nicht zurück geliefert bekomme/abfrage.
Auszug von Dir:

Code: Alles auswählen

  - id: relay1
    channelTypeUID: mqtt:switch
    label: Relay 1
    description: null
    configuration:
      commandTopic: cmnd/esp32_01/POWER1
      retained: false
      postCommand: false
      formatBeforePublish: "%s"
      stateTopic: stat/esp32_01/POWER1

Auszug von mir:

Code: Alles auswählen

- id: Bew_Ventil_1
    channelTypeUID: mqtt:switch
    label: Bew_Ventil_1
    description: ""
    configuration:
      commandTopic: /Bewaesserung/Ventil_1

Müsste der Rückgabewert in der Rule abgefragt werden oder für was ist der notwendig?

Der Mikroprozessor (D1 mini) ist mit der Arduino IDE 1.8.15 programmiert. Dort könnte ich noch den Status publishen. Das habe ich bisher nicht gemacht, weil ich es nicht für notwendig gehalten habe und es über MQTT.fx fehlerfrei funktioniert. Wenn es für OH besser/notwendig ist, kann ich das gern mal testen aber an welcher Stelle in OH kommt der dann zum Einsatz (in der Rule)?

[udo1toni]

Grundsätzlich sollte der Schaltzustand immer aktiv vom aGerät gemeldet werden. Wenn openHAB den Schaltzustand anzeigt, weil es den entsprechenden Befehl gesendet hat, kannst Du auch komplett auf die Anzeige verzichten.

Man kann in den Metadaten des Items mit beim Parameter autoupdate=false verhindern, dass openHAB den Status anhand des letzten Befehls setzt.

[KiWi22]

Grundsätzlich sollte der Schaltzustand immer aktiv vom aGerät gemeldet werden. Wenn openHAB den Schaltzustand anzeigt, weil es den entsprechenden Befehl gesendet hat, kannst Du auch komplett auf die Anzeige verzichten.

Man kann in den Metadaten des Items mit beim Parameter autoupdate=false verhindern, dass openHAB den Status anhand des letzten Befehls setzt.

Sorry aber das habe ich jetzt nicht verstanden
Könntest Du das bitte nochmal anders erklären, damit ich verstehe was ich probieren kann.

[udo1toni]

Du solltest wenn möglich in einem Channel mit commandTopic immer auch ein stateTopic setzen, welches den Schaltzustand meldet.
Wenn Du einen solchen Channel mit einem Item verknüpfst, sollte dieses Item mit autoupdate=false konfiguriert werden.

Das betrifft natürlich nur solche Channel, in denen es ein sinnvolles stateTopic gibt.