Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE

[sunrise]

Und noch ein Beispiel für eine Lovelace Karte in HA, welche Fehler aus dem THZ-Modul anzeigt, also Fehler einer Stiebel Eltron/Tecalor LWZ/THZ Luft-Wärmepumpen-Heizung. Diese kann max. 10 Fehler speichern (Nr. 0-9). Über "conditional" im Lovelace YAML Code auf HA werden nur Fehler-Felder gezeigt, die nicht "unknown" oder "n.a." sind, die also echte Fehler-Codes enthalten.

Code Auswählen Erweitern

type: vertical-stack
cards:
  - type: conditional
    conditions:
      - condition: state
        entity: sensor.mythz_fault0code
        state_not: unknown
      - condition: state
        entity: sensor.mythz_fault0code
        state_not: n.a.
    card:
      type: entities
      entities:
        - entity: sensor.mythz_fault0code
          icon: mdi:alert-outline
          name: Fehler
        - entity: sensor.mythz_fault0date
          icon: mdi:calendar-alert-outline
          name: Datum
        - entity: sensor.mythz_fault0time
          icon: mdi:clock-alert-outline
          name: Uhrzeit
      state_color: true
  - type: conditional
    conditions:
      - condition: state
        entity: sensor.mythz_fault1code
        state_not: unknown
      - condition: state
        entity: sensor.mythz_fault1code
        state_not: n.a.
    card:
      type: entities
      entities:
        - entity: sensor.mythz_fault1code
          icon: mdi:alert-outline
          name: Fehler
        - entity: sensor.mythz_fault1date
          icon: mdi:calendar-alert-outline
          name: Datum
        - entity: sensor.mythz_fault1time
          icon: mdi:clock-alert-outline
          name: Uhrzeit
      state_color: true
  - type: conditional
    conditions:
      - condition: state
        entity: sensor.mythz_fault2code
        state_not: unknown
      - condition: state
        entity: sensor.mythz_fault2code
        state_not: n.a.
    card:
      type: entities
      entities:
        - entity: sensor.mythz_fault2code
          icon: mdi:alert-outline
          name: Fehler
        - entity: sensor.mythz_fault2date
          icon: mdi:calendar-alert-outline
          name: Datum
        - entity: sensor.mythz_fault2time
          icon: mdi:clock-alert-outline
          name: Uhrzeit
      state_color: true
  - type: conditional
    conditions:
      - condition: state
        entity: sensor.mythz_fault3code
        state_not: unknown
      - condition: state
        entity: sensor.mythz_fault3code
        state_not: n.a.
    card:
      type: entities
      entities:
        - entity: sensor.mythz_fault3code
          icon: mdi:alert-outline
          name: Fehler
        - entity: sensor.mythz_fault3date
          icon: mdi:calendar-alert-outline
          name: Datum
        - entity: sensor.mythz_fault3time
          icon: mdi:clock-alert-outline
          name: Uhrzeit
      state_color: true
  - type: conditional
    conditions:
      - condition: state
        entity: sensor.mythz_fault4code
        state_not: unknown
      - condition: state
        entity: sensor.mythz_fault4code
        state_not: n.a.
    card:
      type: entities
      entities:
        - entity: sensor.mythz_fault4code
          icon: mdi:alert-outline
          name: Fehler
        - entity: sensor.mythz_fault4date
          icon: mdi:calendar-alert-outline
          name: Datum
        - entity: sensor.mythz_fault4time
          icon: mdi:clock-alert-outline
          name: Uhrzeit
      state_color: true
  - type: conditional
    conditions:
      - condition: state
        entity: sensor.mythz_fault5code
        state_not: unknown
      - condition: state
        entity: sensor.mythz_fault5code
        state_not: n.a.
    card:
      type: entities
      entities:
        - entity: sensor.mythz_fault5code
          icon: mdi:alert-outline
          name: Fehler
        - entity: sensor.mythz_fault5date
          icon: mdi:calendar-alert-outline
          name: Datum
        - entity: sensor.mythz_fault5time
          icon: mdi:clock-alert-outline
          name: Uhrzeit
      state_color: true
  - type: conditional
    conditions:
      - condition: state
        entity: sensor.mythz_fault6code
        state_not: unknown
      - condition: state
        entity: sensor.mythz_fault6code
        state_not: n.a.
    card:
      type: entities
      entities:
        - entity: sensor.mythz_fault6code
          icon: mdi:alert-outline
          name: Fehler
        - entity: sensor.mythz_fault6date
          icon: mdi:calendar-alert-outline
          name: Datum
        - entity: sensor.mythz_fault6time
          icon: mdi:clock-alert-outline
          name: Uhrzeit
      state_color: true
  - type: conditional
    conditions:
      - condition: state
        entity: sensor.mythz_fault7code
        state_not: unknown
      - condition: state
        entity: sensor.mythz_fault7code
        state_not: n.a.
    card:
      type: entities
      entities:
        - entity: sensor.mythz_fault7code
          icon: mdi:alert-outline
          name: Fehler
        - entity: sensor.mythz_fault7date
          icon: mdi:calendar-alert-outline
          name: Datum
        - entity: sensor.mythz_fault7time
          icon: mdi:clock-alert-outline
          name: Uhrzeit
      state_color: true
  - type: conditional
    conditions:
      - condition: state
        entity: sensor.mythz_fault8code
        state_not: unknown
      - condition: state
        entity: sensor.mythz_fault8code
        state_not: n.a.
    card:
      type: entities
      entities:
        - entity: sensor.mythz_fault8code
          icon: mdi:alert-outline
          name: Fehler
        - entity: sensor.mythz_fault8date
          icon: mdi:calendar-alert-outline
          name: Datum
        - entity: sensor.mythz_fault8time
          icon: mdi:clock-alert-outline
          name: Uhrzeit
      state_color: true
  - type: conditional
    conditions:
      - condition: state
        entity: sensor.mythz_fault9code
        state_not: unknown
      - condition: state
        entity: sensor.mythz_fault9code
        state_not: n.a.
    card:
      type: entities
      entities:
        - entity: sensor.mythz_fault9code
          icon: mdi:alert-outline
          name: Fehler
        - entity: sensor.mythz_fault9date
          icon: mdi:calendar-alert-outline
          name: Datum
        - entity: sensor.mythz_fault9time
          icon: mdi:clock-alert-outline
          name: Uhrzeit
      state_color: true
Man kann das in HA sicherlich noch schöner gestalten, aber für den Anfang reicht es mir aus.
Ich hoffe, das ist hier nicht zu sehr off-topic. 😉

[sunrise]

@CaptainSlow und alle

Das Lesen in HA von Werten inkl. UserReadings aus FHEM funktioniert. Jedoch ist mir noch unklar, wie ich einen FHEM-Wert (Ventilator-Stufe) von HA aus ändern kann bzw. das dafür Nötige einrichten muss.

Konkretes Beispiel: Meine Heizung hat Lüfter-Stufen 0, 1, 2, 3. Der Wert steht in Mythz/07FanStageDay, und ich sehe ihn auch im MQTT-Explorer:

Du darfst diesen Dateianhang nicht ansehen.

Die Konfiguration in HA sollte über MQTT Fan funktionieren, aber ab hier steige ich leider aus, d.h. ich verstehe schon nicht, wie ich meine FHEM-Seite korrekt auf der HA-Seite definieren muss, damit es klappt. Sorry, ich stehe etwas auf dem Schlauch. 🤔

Hat jemand bitte einen helfenden Hinweis für mich? Danke! 🙏

[Beta-User]

Konkretes Beispiel: Meine Heizung hat Lüfter-Stufen 0, 1, 2, 3. Der Wert steht in Mythz/07FanStageDay, und ich sehe ihn auch im MQTT-Explorer:

Zum Setzen via MQTT mit MQTT_GENERIC_BRIDGE muss (u.a. von HA aus) ein _anderer_ topic verwendet werden (Schleifengefahr!), und der muss dann eben auf der FHEM-Seite auch entsprechend konfiguriert werden (subscribe-Attribut, dort stopic). Genau davon handelt doch dieser Thread...

Abstraktes Beispiel:

Code Auswählen Erweitern

set/Mythz/07FanStageDay

[sunrise]

Ja, aber wie definiere ich einen echten FHEM-Wert als Schalter?

Folgendes ist doch nur ein Dummy:

Code Auswählen Erweitern

attr demoswitch mqttSubscribe state:stopic={"$base/set"}Ich habe hier ein Mythz/07FanStageDay, und mir ist nach der mehrfachen Lektüre dieses ganzen Threads immer noch unklar, was ich tun muss, um das als eine Art Schalter zu definieren.

Bei den Readings (also FHEM => HA, read-only) reichte es aus, in FHEM das Mythz Device in the "HASS" Raum zu stellen und dann auf HA-Seite die Konfiguration für einen Sensor vorzunehmen.

Aber für einen Lüfter-Wert, der zudem auch noch von HA aus gesteuert werden soll? Sorry, ich weiß überhaupt nicht, wo ich da einsteigen muss.

[Beta-User]

Aber für einen Lüfter-Wert, der zudem auch noch von HA aus gesteuert werden soll? Sorry, ich weiß überhaupt nicht, wo ich da einsteigen muss.

Es gibt doch hier (und im howto-Thread von Hexenmeister) viele Beispiele für "schaltbares" Zeug via MGB. Leider gibt es nicht sowas wie einen "allgemeingültigen" Standard. Die Schritte sind aber immer dieselben:
1. Finde in "der Außenwelt" (also bei dir: HA) ein "Element" (Gerät, ...), das in Stufen von 0-3 geschaltet werden kann. Das kann z.B. auch ein dimmbares "Licht" sein. FHEM ist es jedenfalls egal, wie es in HA aussieht.
2. Wenn du in HA schaltest, sorge dafür, dass der Wert dann an den Topic gesendet wird, auf dem
3. FHEM das subscribe macht, also mal angenommen, dein "$base" steht für "Mythz/07FanStageDay", eben an "Mythz/07FanStageDay/set" (mit stopic, wobei der Reading-Name passen sollte. Ist das wirklich "state"? Oder das Reading "07FanStageDay" am Device Mythz?!?

Sorry, aber auch hier gilt wieder: nur mit Schnippseln ist es schwierig, und ich (wie die meisten anderen Helfer) haben vermutlich kein THZ-Device und kennen weder dessen Verhalten noch dessen Readings...

[sunrise]

1. Finde in "der Außenwelt" (also bei dir: HA) ein "Element" (Gerät, ...), das in Stufen von 0-3 geschaltet werden kann. Das kann z.B. auch ein dimmbares "Licht" sein. FHEM ist es jedenfalls egal, wie es in HA aussieht.

Das verstehe ich nicht. Ich kann doch nicht etwas in HA finden, das noch gar nicht dort definiert ist.

Es ist doch anders herum: Meine THZ Heizung ist in FHEM eingebunden, und ich kann deren Readings komplett in HA lesen, weil ich alles aus dem THZ-Modul über MQTT rauspuste (globalPublish*) und in HA für jeden mich interessierenden Reading-Wert einen Sensor konfiguriert habe.

(*Ich weiß, das ist schlecht, aber zum Anfangen war's für mich erst einmal ok.)

Nun gibt es in FHEM einen THZ Parameter p07FanStageDay, der Werte von 0, 1, 2 oder 3 annehmen kann, d.h. ich kann diesen Wert setzen, und dann wird er von FHEM auch so angezeigt. Mir fällt es sehr schwer zu verstehen, wie ich so einen Parameter in FHEM "umbauen" (erweitern?) muss, damit der via MQTT an HA geht und umgekehrt auch von dort gesetzt werden kann.

Die Code-Beispiele kenne ich, aber da sind es z.B. Dimmer oder Schalter, nichts, was ich mit einem 4-stufigen (0, 1, 2, 3) Ventilator einer Heizung vergleichen kann - zumindest verstehe ich es nicht.

Gerne poste ich hier mehr Details (statt nur Schnipsel), aber mir ist nicht klar, was genau von mir benötigt wird. Ich bitte um Verzeihung, dass ich mich blöd anstelle. Ich bin wirklich lernwillig, aber trotz meines Bemühens hat es noch nicht "Klick" gemacht.

Hier die RAW Definition (ohne setstates - bis auf das eine relevante) meines THZ Devices. Es sind auch viele userReadings enthalten, aber das für mich zunächst interessante p07FanStageDay ist kein userReading, sondern kommt direkt über's Device.

Code Auswählen Erweitern

defmod Mythz THZ /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller-if00-port0@14400
attr Mythz userattr mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long
attr Mythz devStateIcon opened:10px-kreis-gruen disconnected:10px-kreis-rot
attr Mythz event-min-interval .*:120
attr Mythz event-on-change-reading .*
attr Mythz firmware 2.06
attr Mythz icon sani_heating
attr Mythz interval_sDisplay 15
attr Mythz interval_sFan 60
attr Mythz interval_sGlobal 300
attr Mythz interval_sHC1 300
attr Mythz interval_sHistory 3600
attr Mythz interval_sLast10errors 3600
attr Mythz nonblocking 0
attr Mythz room Heizung,HomeAssistant
attr Mythz showtime 1
attr Mythz simpleReadTimeout 6
attr Mythz userReadings outsideTemp:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[1]}, \
flowTemp:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[3]}, \
returnTemp:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[5]}, \
hotGasTemp:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[7]}, \
dhwTemp:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[9]}, \
flowTempHC2:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[11]}, \
evaporatorTemp:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[13]}, \
condenserTemp:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[15]}, \
mixerOpen:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[17]}, \
mixerClosed:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[19]}, \
heatPipeValve:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[21]}, \
diverterValve:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[23]}, \
dhwPump:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[25]}, \
heatingCircuitPump:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[27]}, \
solarPump:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[29]}, \
compressor:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[31]}, \
boosterStage3:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[33]}, \
boosterStage2:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[35]}, \
boosterStage1:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[37]}, \
highPressureSensor:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[39]}, \
lowPressureSensor:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[41]}, \
evaporatorIceMonitor:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[43]}, \
signalAnode:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[45]}, \
evuRelease:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[47]}, \
ovenFireplace:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[49]}, \
STB:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[51]}, \
outputVentilatorPower:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[53]}, \
inputVentilatorPower:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[55]},\
mainVentilatorPower:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[57]},\
outputVentilatorSpeed:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[59]}, \
inputVentilatorSpeed:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[61]}, \
mainVentilatorSpeed:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[63]}, \
outsideTempFiltered:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[65]}, \
relHumidity:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[67]}, \
dewPoint:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[69]}, \
P_Nd:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[71]}, \
P_Hd:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[73]}, \
actualPower_Qc:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[75]}, \
actualPower_Pel:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[77]}, \
collectorTemp:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[79]}, \
insideTemp:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[81]}, \
number_of_faults:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[1]}, \
fault0CODE:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[3]}, \
fault0TIME:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[5]}, \
fault0DATE:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[7]}, \
fault1CODE:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[9]}, \
fault1TIME:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[11]}, \
fault1DATE:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[13]}, \
fault2CODE:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[15]}, \
fault2TIME:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[17]}, \
fault2DATE:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[19]}, \
fault3CODE:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[21]}, \
fault3TIME:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[23]}, \
fault3DATE:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[25]}, \
fault4CODE:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[27]}, \
fault4TIME:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[29]}, \
fault4DATE:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[31]}, \
fault5CODE:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[33]}, \
fault5TIME:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[35]}, \
fault5DATE:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[37]}, \
fault6CODE:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[39]}, \
fault6TIME:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[41]}, \
fault6DATE:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[43]}, \
fault7CODE:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[45]}, \
fault7TIME:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[47]}, \
fault7DATE:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[49]}, \
fault8CODE:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[51]}, \
fault8TIME:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[53]}, \
fault8DATE:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[55]}, \
fault9CODE:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[57]}, \
fault9TIME:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[59]}, \
fault9DATE:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[61]}, \
dhwBoosterStage:sDHW.* {(split ' ',ReadingsVal("Mythz","sDHW",0))[13]}, \
dhwOpMode:sDHW.* {(split ' ',ReadingsVal("Mythz","sDHW",0))[17]}, \
integralHeat:sHC1.*  {(split ' ',ReadingsVal("Mythz","sHC1",0))[7]}, \
heatSetTemp:sHC1.*  {(split ' ',ReadingsVal("Mythz","sHC1",0))[11]}, \
heatTemp:sHC1.*  {(split ' ',ReadingsVal("Mythz","sHC1",0))[13]}, \
seasonMode:sHC1.*  {(split ' ',ReadingsVal("Mythz","sHC1",0))[15]}, \
integralSwitch:sHC1.*  {(split ' ',ReadingsVal("Mythz","sHC1",0))[17]}, \
hcOpMode:sHC1.* {(split ' ',ReadingsVal("Mythz","sHC1",0))[19]}, \
roomSetTemp:sHC1.* {(split ' ',ReadingsVal("Mythz","sHC1",0))[21]}, \
onHysteresisNo:sHC1.* {(split ' ',ReadingsVal("Mythz","sHC1",0))[33]}, \
offHysteresisNo:sHC1.* {(split ' ',ReadingsVal("Mythz","sHC1",0))[35]}, \
hcBoosterStage:sHC1.* {(split ' ',ReadingsVal("Mythz","sHC1",0))[37]}, \
dhw_heating:sGlobal.* {(split ' ', ReadingsVal ("Mythz","sHistory",0))[5]}, \
dhw_hours:sGlobal.* {(split ' ', ReadingsVal ("Mythz","sHistory",0))[7]}

setstate Mythz 2023-12-08 15:32:45 p07FanStageDay 3

Code Auswählen Erweitern

defmod HA_MQTT2 MQTT2_CLIENT homeassistant.fritz.box:1883
attr HA_MQTT2 clientId fhem
attr HA_MQTT2 clientOrder MQTT_GENERIC_BRIDGE
attr HA_MQTT2 keepaliveTimeout 60
attr HA_MQTT2 msgAfterConnect -r fhem/connection/status connected
attr HA_MQTT2 msgBeforeDisconnect -r fhem/connection/status disconnected
attr HA_MQTT2 qosMaxQueueLength 100
attr HA_MQTT2 room MQTT
attr HA_MQTT2 username mqttuser

setstate HA_MQTT2 opened
setstate HA_MQTT2 2023-12-08 11:57:55 state opened


Code Auswählen Erweitern

defmod mqttGeneric MQTT_GENERIC_BRIDGE mqtt room=HomeAssistant
attr mqttGeneric IODev HA_MQTT2
attr mqttGeneric globalDefaults sub:qos=2 pub:qos=0 retain=1 base={"fhem/$device"}
attr mqttGeneric globalPublish *:topic={"fhem/$device/$reading"}
attr mqttGeneric icon mqtt_bridge_2
attr mqttGeneric room MQTT
attr mqttGeneric verbose 0

setstate mqttGeneric in: 0 out: 11 devices: 1
setstate mqttGeneric 2023-12-08 11:57:55 IODev HA_MQTT2
setstate mqttGeneric 2023-11-29 09:17:04 attrTemplateVersion 20211208_MQTT
setstate mqttGeneric 2023-12-08 11:57:55 device-count 0
setstate mqttGeneric 2023-12-08 11:57:55 incoming-count 0
setstate mqttGeneric 2023-12-08 18:23:35 outgoing-count 4544
setstate mqttGeneric 2023-12-08 18:23:35 transmission-state outgoing publish sent
setstate mqttGeneric 2023-12-08 11:57:55 updated-reading-count 0
setstate mqttGeneric 2023-12-08 11:57:55 updated-set-count 0


[Beta-User]

Das verstehe ich nicht. Ich kann doch nicht etwas in HA finden, das noch gar nicht dort definiert ist.

Eben. Du musst es dort definieren. Im Prinzip genau so wie du eine MQTT-Leuchte anlegen würdest (ein Tasmota-geflashtes Leuchtmittel, z.B.). (Ich weiß, dass HA sowas in der Regel per "discovery" automatisch machen kann, aber das geht hier nicht und es gibt auch einen manuellen Weg).

Alles, was du in HA schalten willst, muss dort m.E. auch schaltbar angelegt sein. Würde mich überraschen, wenn jemand mit HA-Erfahrung was anderes wüßte... Also statt "sensor" mal ein "light" anlegen (da gibt es bestimmt Optionen, die Grenzen für's dimmen entsprechend zu setzen).

[sunrise]

Danke, jetzt habe ich ich richtig verstanden.

Frage an Diejenigen hier, die bereits erfolgreich FHEM-Schalter mit mehreren Stufen in HA angelegt haben:

Habt Ihr dafür in HA Lichter, Schalter oder gar MQTT Fan angelegt?

[sunrise]

Ich verstehe es schlicht nicht. 🙄 Ein Topic lautet z.B.: fhem/Mythz/p07FanStageDay
Es kann Werte von 0, 1, 2 oder 3 annehmen. Es gibt kein state_topic o.ä., sondern nur dies.

In Beispielen zu Lichtern finde ich u.a. für einen EnOcean Dimmer das:

Code Auswählen Erweitern

light:
  - platform: mqtt
      name: "WZ Decke"
      optimistic: false
      retain: false
      brightness_scale: 100
      on_command_type: first
      command_topic: "fhem/Eltako_Aktor_FUD71_19888CA/set"
      brightness_command_topic: "fhem/Eltako_Aktor_FUD71_19888CA/setdim"
      brightness_state_topic: "fhem/Eltako_Aktor_FUD71_19888CA/dim"
      state_topic: "fhem/Eltako_Aktor_FUD71_19888CA/state"
      payload_on: "on"
      payload_off: "off"
      availability_topic: "fhem/connection/status"
      payload_available: "connected"
      payload_not_available: "disconnected"
Leider ist das aber überhaupt nicht auf meinen Fall anwendbar.

Erstens, weiß ich nicht, wie ich ein command_topic umbauen müsste
von: "fhem/Eltako_Aktor_FUD71_19888CA/set"
nach: "fhem/Mythz/p07FanStageDay ... ?"

Und zweitens gibt es bei mir keine "brightness" und somit auch keine entsprechenden command_topics oder state_topics dafür.

Sorry, ich stehe immer noch auf dem Schlauch. Gibt's hier niemand, der einen ähnlichen Fall wie ich hat? Es muss ja keine Heizung sein, aber ein Reading, das 3-4 Werte annehmen kann wäre für mich Anfänger als Einstieg und Beispiel wirklich sehr hilfreich. Dankeschön, wenn sich hierzu noch jemand konkreter äußern könnte. 😉

Und auch danke an Beta-User und andere User, die sich hier schon gemeldet haben! 😊

[Beta-User]

Ich verstehe es schlicht nicht. 🙄 Ein Topic lautet z.B.: fhem/Mythz/p07FanStageDay
Es kann Werte von 0, 1, 2 oder 3 annehmen. Es gibt kein state_topic o.ä., sondern nur dies.

Noch ein Versuch:
1. Welche Topics es gibt, kannst du auch mit entscheiden. Wichtig für eine "set"-Anweisung ist nur, dass beide Seiten (Anweisendes HA und "empfangendes FHEM") diesen Topic kennen. Ob der "fhem/Mythz/p07FanStageDay/set" oder "Timbuktu/Hinflug/Lufthansa" lautet, ist komplett egal...

2. Für "aktive" Komponenten braucht man zwingend* einen "Kreis", keine einfache "Linie". Das Topic, auf dem eine Anweisung abzusetzen ist, ist immer ein ANDERES wie das, auf dem die Antwort ("erledigt") kommen sollte. Genau, wie es bei dem "brightness"-Ding der Fall ist. Zwei (!) Topics.

3. Für dein "Ding" hast du jetzt "nur" das Problem, dass es halt kein Licht ist, und der "on/off"-Zustand nicht separat geschaltet werden kann. Von daher würde ich für "state-on" halt einfach nochmal denselben Datenpunkt (fhem/Mythz/p07FanStageDay) nehmen und erst mal den "off"-Wert mit "0" belegen.

4. Wenn es bis dahin immer noch nicht klar ist: Konzentriere dich erst mal nur darauf, den Kreis für "brightness" (1-3) zu schließen. Wenn du mit der HA-Einrichtung nicht weiter kommst, nimm irgendein anderes MQTT-Tool (z.B. mosquitto_pub) und sende den Soll-Wert auf das "set"-Topic. Wie gesagt: Du kannst es frei wählen, es sollte aber anders sein wie das, was du bisher als "sensor" eingetragen hattest (das bleibt für den Rückflug). Und du musst es in FHEM passend konfigurieren (ich empfehle erst mal "Klartext" ohne Variablen für das subscribe-Attribut).

Hoffe, das wird jetzt langsam klarer?

*Ja, man kann es in bestimmten Fällen anders machen, aber das ist m.E. schlechtes Design!

[rheini231]

Ich habe die Anbindung von MAX-Geräten aus FHEM in Home Assistant via MQTT automatisiert:
https://github.com/danielrheinbay/fhemMAX2HASS/
Durch die Nutzung des MQTT Discovery Protokolls entfällt die aufwändige und fehleranfällige Konfiguration von zig MQTT-Sensoren in Home Assistant.
Freue mich über Feedback und Verbesserungen, gern in Form von Pull Requests.

[rallye]

Hallo zusammen!
Ich verwende FHEM als "hidden" Automationszentrale zu welcher nur ich Zugriff habe, für den WAF habe ich Home Assistant als Interface. Die Anwesenheit meiner Frau und von mir wird über Owntracks geprüft, unser Sohn verweigert Owntracks und Home Assistant, weshalb ich seine Anwesenheit so recht und schlecht über Home Assistant tracke. Und zwar über den device_tracker seines iPhones. Hier erhalte ich zuverlässig den Status "home" bzw. "not_home" bei An- bzw. Abwesenheit. Den Status möchte ich an FHEM weiterreichen. Nun hat HA die Eigenschaft, dass nur dann ein Event ausgegeben wird, wenn die Zone des iPhones von einer Zone zu einer anderen Zone wechselt (z.B: work->home) Aber nicht, wenn von not_home auf home. Daher kann ich keine Automation in HA triggern und den neuen Status an FHEM übergeben. Aus diesem Grund muss ich über die MQTT-Bridge den aktuellen Zustand weiterreichen.
Bei Switches funktioniert das bei mir einwandfrei:
FHEM:

Code Auswählen Erweitern

defmod Presence_Nici dummy
attr Presence_Nici userattr mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long
attr Presence_Nici mqttForward all
attr Presence_Nici mqttSubscribe state:stopic={"$base/set"}
attr Presence_Nici room HASS,Development
attr Presence_Nici webCmd on:off
HA:

Code Auswählen Erweitern

    - name: Presence_Nici
      command_topic: "fhem/Presence_Nici/set"
      state_topic: "fhem/Presence_Nici/state"
      payload_on: "on"
      payload_off: "off"
      state_on: "on"
      state_off: "off"
      availability_topic: "fhem/connection/status"
      payload_available: "connected"
      payload_not_available: "disconnected"
Egal wo ich schalte, das Ergebnis wird an das andere System korrekt "durchgereicht". Nun kann ich aber HA-seitig "home" und "not_home" nicht auf "on" und "off" übersetzen und muss mit den Springs arbeiten. Daher handelt es sich nicht mehr um einen Switch, sondern um einen Sensor (in HA-Nomenklatur). Ich habe das nun so definiert:
FHEM:

Code Auswählen Erweitern

defmod Presence_Test dummy
attr Presence_Test userattr mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long
attr Presence_Test mqttForward all
attr Presence_Test mqttSubscribe state:stopic={"$base/set"}
attr Presence_Test room HASS,Development
attr Presence_Test webCmd home:not_home
HA:

Code Auswählen Erweitern

    - name: Presence_Test
      state_topic: "fhem/Presence_Test/state"
      availability_topic: "fhem/connection/status"
      payload_available: "connected"
      payload_not_available: "disconnected"
Wenn ich FHEM-seitig zwischen "home" und "not_home" hin- und her schalte, dann wird das HA-seitig (wie bei allen anderen Sensoren - z.B. Luftfeuchte) richtig angezeigt/verändert. Umgekehrt wird der veränderte Status jedoch nicht durchgereicht. Zumindest

Code Auswählen Erweitern

command_topic:
bei einem Switch ist nicht zulässig. Was muss ich machen, damit eine Statusänderung auch von HA nach FHEM geht?

[sunrise]

Sorry, dass ich auf Deinen doch schon älteren - aber immer noch aktuellen - Hinweis eine Frage habe:

Bitte aber KEIN globales publish angeben, (auch) das sollte mAn. immer am Device (=> "schrank") konfiguriert werden...

Im Wiki steht:

Code Auswählen Erweitern

attr mySensor mqttPublish temperature|humidity|battery:topic={"$base/$device/$name"}
Ich habe hier einen Sensor (Stromzähler Device MyObis1), für den ich über Wildcards bei event-on-change-reading einige Parameter berücksichtige:

Code Auswählen Erweitern

.*consumption.*,power.*
Kann ich entsprechend solche Wildcards dann so für die MGB umsetzen?

Code Auswählen Erweitern

attr MyObis1 mqttPublish .*consumption.*|power.*:topic={"fhem/$device/$reading"}

Das Topic {...} sieht im Wiki anders aus als in meinem (noch) globalPublish, das ich nun endlich rauswerfen will, aber möglichst ohne mir dabei etwas zu zerschießen - daher meine Frage, ob/wie ich das richtig umsetze im attr zum Device. Danke für Deine Hilfe!

[Beta-User]

Kann ich entsprechend solche Wildcards dann so für die MGB umsetzen?

Hmm, also:
- ob das mit den wildcards so klappt, müßte man austesten, es wird jedenfalls erst mal so akzeptiert...
- die "globalen" settings werden - soweit ich mich entsinne - durch die Settings am einzelnen Device überschrieben (soweit sie passen), und das Gesamt-Ergebnis ist dann an der MGB in "get deviceinfo" sichtbar. Du kannst also durchaus erst mal den Test am Einzeldevice machen, ohne dir groß was zu zerschießen.

Würde mich auch interessieren, ob das so mit ".*" klappt...
Vor dem Testen ggf. dann mal ein "save" aufrufen, damit die letzten Reading-Stände weggeschrieben werden.

[m8ichael]

Moin,

irgendwie stehe ich hier gewaltig auf dem Schlauch, das Demogerät aus dem ersten Thread in HA zur Anzeige zu bringen.

in der configuration.yaml:

Code Auswählen Erweitern

Code Auswählen Erweitern

switch:
  - platform: mqtt
    name: demoswitch
    command_topic: "fhem/demoswitch/set"
    state_topic: "fhem/demoswitch/state"
    payload_on: "on"
    payload_off: "off"
    state_on: "on"
    state_off: "off"
    #availability_topic: "fhem/connection/status"
    #payload_available: "connected"
    #payload_not_available: "disconnected"

Ich habe in HA den Samba-Share installiert und editiere die config mit Visual Studio Code. Damit erkennt man Einrückungsfehler in yaml -Files recht schnell.

Dann Einstellungen -> Serversteuerung -> Config prüfen und Einstellungen -> Serversteuerung -> Server neu starten.

(Man kann in der aktuellen Version auch nur die MQTT Devices neu laden, bei mir fliegen dann aber immer die Autodiscovery-Devices raus)

Unter Entwicklerwerkzeuge -> Zustände sollte sich nun bei den Entitäten ein switch.demoswitch befinden.

Ich bin hier genau so vorgegangen, allerdings wird nichts in HA angezeigt. Meine configuration.yaml sieht insgesamt so aus:

Code Auswählen Erweitern

# Loads default set of integrations. Do not remove.
default_config:

# Load frontend themes from the themes folder
frontend:
  themes: !include_dir_merge_named themes

automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.yaml

switch:
  - platform: mqtt
    name: demoswitch
    command_topic: "fhem/demoswitch/set"
    state_topic: "fhem/demoswitch/state"
    payload_on: "on"
    payload_off: "off"
    state_on: "on"
    state_off: "off"
    #availability_topic: "fhem/connection/status"
    #payload_available: "connected"
    #payload_not_available: "disconnected"
Was mache ich hier falsch? Über nen kleinen Tipp wäre ich sehr dankbar!

Gruß
Michael