Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE

[davedeluxe]

Guten Morgen,
danke für die tolle Anleitung @gadget!
Kann mir jemand ein Codebeispiel für einen Homematic Fenstersensor geben?
Ich habe aktuell folgendes:

Code Auswählen Erweitern

  - binary_sensor:
      name: "Optisch_Dachfenster"
      unique_id: "optisch_dachfenster"
      state_topic: "fhem/Optisch_Dachfenster/state"
      payload_on: "open"
      payload_off: "closed"
      availability_topic: "fhem/connection/status"
      payload_available: "connected"
      payload_not_available: "disconnected"
Ich verstehe leider nicht wie ich z.B. den Batteriestatus hinzufügen kann.
Hat jemand solch einen Sensor (HM-SEC-SCO) per MQTT in HASS eingebunden?

Grüße, Dave

[Burt_Gummer]

Moin!
Klinke mich hier mal ein:

Habe FHEM und Mosquitto seit Ewigkeiten bei mir auf einem Ubuntu Server installiert. (natürlich immer wieder upgedated)
Tasmota Devices sind via MQTT (nicht 2) angebunden.

Kann es sein, dass aufgrund der Installation von Home Assistant (u. a. mit der Tasmota Integration und MQTT) FHEM bzw. FTUI "stört" ?

Seit einiger Zeit friert meine Übersichtsseite in der Tablet UI regelmäßig ein. FullyKiosk startet die dann zwar immer wieder neu, aber das passiert so ca. alle paar Minuten und nervt.

Hatte da bisher Home Assistant nicht für verantwortlich gemacht, weil ich eigentlich der Meinung bin, dass doch HA sowie FHEM nur Clients sind und dem Mosquitto Server nur zuhören.

Können die sich gegenseitig stören und die Tablet UI sogar zum einfrieren bringen? (aktualisieren der Seite geht sofort und liefert aktuelle Daten der MQTT Devices)

War der Meinung, dass dieses Phänomen nach einem FHEM Update eingetreten ist.
Fehler im Protokoll von FHEM sieht man diesbezüglich auch nicht wirklich...

 

[jazzor]

Republishen eines Attributes:
Hi zusammen, ich muss hier nochmal nach all den Jahren, die mein System doch halbwegs passabel läuft, mal eine Frage stellen:

Kann ich erzwingen, dass ein Attribut, neu gepublished wird, wenn ich es von außerhalb per mqtt setze?

Folgende Situation: Ich muss aus... Gründen... zwischen Homeassistant und Fhem eine Zahl in einem Fhem Dummy aktuell halten.
Der Fhem-Dummy heißt RolloDummy und hat ein Reading "AktuellerKanal".
Auf der Homeassistant-Seite ist die Entity folgendermaßen definiert:

Code Auswählen Erweitern

    - name: "Rollo-Kanal"
      unique_id: "rollokanal"
      state_topic: "fhem/RolloDummy/AktuellerKanal"
      command_topic: "fhem/set/RolloDummy/AktuellerKanal"
      min: 1
      max: 15
auf der Fhem-Seite ist der Dummy folgendermaßen definiert:

Code Auswählen Erweitern

defmod RolloDummy dummy
attr RolloDummy userattr mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long
attr RolloDummy alexaName Rollokanal
attr RolloDummy genericDeviceType thermostat
attr RolloDummy group Hilfsgeräte
attr RolloDummy homebridgeMapping TargetTemperature=AktuellerKanal::AktuellerKanal,minValue=1.0,maxValue=15.0,minStep=1.0\
CurrentTemperature=RolloDummy:AktuellerKanal, nocache=1
attr RolloDummy mqttPublish AktuellerKanal:topic={"$base/$name"}
attr RolloDummy mqttSubscribe AktuellerKanal:stopic={"$base/AktuellerKanal"}
attr RolloDummy readingList AktuellerKanal
attr RolloDummy room Interfaces->homekit,MQTT_HA,fhem,fhem->Alexa
attr RolloDummy setList AktuellerKanal:1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
attr RolloDummy siriName Rollo Kanal
attr RolloDummy stateFormat {ReadingsVal("RolloDummy","AktuellerKanal",0)}
attr RolloDummy webCmd AktuellerKanal

Wenn ich nun von Homeassistant die Nummer ändere, kann ich sehen, dass fhem/set/RolloDummy mit der Nummer gesendet wird und Fhem diese Nummer auch ünernimmt.
Fhem sendet dann aber kein Update der Nummer raus, weshalb bspw der Slider der Nummer in Homeassistant auf der neuen Nummer steht, das Entity aber kein Update bekommt, weil es auf FHem wartet.
Hat jemand eine Idee, was ich da bei FHem noch einstellen muss?
Vielen Dank!

[jazzor]

Republishen eines Attributes:
Hi zusammen, ich muss hier nochmal nach all den Jahren, die mein System doch halbwegs passabel läuft, mal eine Frage stellen:...

Da ich nun meinen Fehler gefunden habe, möchte ich zukünftige Generationen vor dem gleichen Schicksal wie mich bewahren:
Das Standardverhalten von mqttForward ist für Dummy-Geräte nicht "all" sondern "none". Im Gegensatz zu allen anderen Geräten. Damit wird bei Dummy-Geräten nixhts weitergeleitet!
Wer lesen kann ist klar im Vorteil
P.S.: Ich will gar nicht anfangen, was ich alles versucht habe, weil ich mir sicher war, dass mqqForward immer gilt...

[obelix221]

Hallo in die Runde,

ich stehe vor folgender Fragestellung:
Ich habe einen Homematicdimmer (HM-LC-DIM1L-PL-3) und möchte diesen über HA ansteuern.
Dazu habe ich in HA in der einer mqqt.yaml folgendes angelegt:

Code Auswählen Erweitern

- light:
      - name: "Deckenfluter2"
        unique_id: light.Wohnzimmer.Deckenfluter.2
        state_topic: "fhem/HM_41E8A6_Dim/state"
        brightness_command_topic: "fhem/HM_41E8A6_Dim/brightness"
        brightness_scale: "100"
        brightness_state_topic: "fhem/HM_41E8A6_Dim/level"
        command_topic: "fhem/HM_41E8A6_Dim/set"
        payload_on: "on"
        payload_off: "off"
        qos: 1
        optimistic: false
und in fhem:

Code Auswählen Erweitern

internals:
   DEF        41E8A601
   FUUID      5c521477-f33f-f80f-2e74-69eda06aa42fa1e0
   LASTInputDev ha_MQTT2
   MSGCNT     5
   NAME       HM_41E8A6_Dim
   ...
   ...
   ...
Attributes:
   alexaName  Deckenfluter
   alias      Deckenfluter
   genericDeviceType light
   homebridgeMapping Brightness=dim::dim,minValue=0,maxValue=100, cmd=dim, minStep=1
   model      HM-LC-DIM1L-PL-3
   mqttSubscribe state:stopic={"$base/set"} pct:stopic={"$base/brightness"}
   peerIDs    00000000
   room       AlexaControl,HASS,Homekit,Wohnzimmer
   siriName   Deckenfluter
   userattr   lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0 mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long
   webCmd     statusRequest:toggle:on:off:up:down
Nun stelle ich folgendes Verhalten fest:
1) Wenn ich in fhem den Dimmer bediene werden die Werte auch nach HA übermittelt --> OK
2) Wenn ich in HA den Dimmer bediene kann ich den Dimmer ein-/ausschalten, aber nicht dimmen --> NOK
3) Tausche ich hingegen die Reihenfolge der Parameter im Attribut mqqtSubscribe von

Code Auswählen Erweitern

mqttSubscribe state:stopic={"$base/set"} pct:stopic={"$base/brightness"}
auf

Code Auswählen Erweitern

mqttSubscribe pct:stopic={"$base/brightness"} state:stopic={"$base/set"} kann ich dimmen, aber nicht mehr ein-/ausschalten über HA --> NOK.

Fazit: Es scheint so zu sein, als ob fhem den zweiten stopic-Parameter nicht parsen kann.
Habt Ihr Tipps für mich?


Grüße
obelix

[mkraus81]

Hi,

ich stelle vermutlich eine saudoofe Frage.
Ich habe auch eine größere Fhem Umgebung laufen
und baue gerade nebenbei auch Homeassitent auf...
Da ich noch viele FHT80 Thermostate und Antriebe besitze und es für HASS da nichts gibt.
Möchte ich eigentlich meine ganze FHEM Umgebung weiter betreiben und alles über MQTT Generic Bridge laufen lassen.
Die Thermostate laufen nun schon über die Bridge und funktioniert auch in HASS

Nun habe ich gesehen, dass es für HASS eine Tasmota Integration gibt, welche mit Hilfe der Tasmota Discocery Nachricht die  Geräte anlegt.
Ich frage mich gerade was ich tun muss um die "tasmota/discovery" Nachrichten über die Bridge weiterzuleiten?
Geht das? oder ist mein Gedanke falsch?

[beckerheinz]

Hallo,
erstmal vielen Dank für die tolle Anleitung in Post #2. Dank der konnte ich meine Lacrosse Temperatur- und Luftfeuchtigkeitssensoren, meine max! Fensterkontakte und meine PCA301 in beide Richtungen sowohl FHEM als auch HA betrieben.
Die max! Heizkörperthermostate habe ich nur in eine Richtung hinbekommen - ich kann die Readings in HA auslesen.

Ich kann sogar die gewünschte Temperatur mit HA hier platzieren:

mosquitto_sub -h ip -u hamqtt -P passwd -t 'fhem/heizungXY/desiredTemperature'
6.0
6.0
10.0
9.0

Aber im Gegensatz zu den Schaltern will max! in FHEM den Wert von HA nicht im Gerät setzen / annehmen?

Was fehlt mir auf der FHEM Seite, dass hier ein set desiredTemperature 9.0 passiert?

Habe diese drei Kombinationen bereits erfolglos probiert:
attr heizungXY mqttSubscribe state:stopic={"$base/set"}
attr heizungXY mqttSubscribe desiredTemperature:stopic={"$base/desiredTemperature"}
attr heizungXY mqttSubscribe state:stopic={"$base/desiredTemperature"}

[beckerheinz]

Hallo,
erstmal vielen Dank für die tolle Anleitung in Post #2. Dank der konnte ich meine Lacrosse Temperatur- und Luftfeuchtigkeitssensoren, meine max! Fensterkontakte und meine PCA301 in beide Richtungen sowohl FHEM als auch HA betrieben.
Die max! Heizkörperthermostate habe ich nur in eine Richtung hinbekommen - ich kann die Readings in HA auslesen.

Ich kann sogar die gewünschte Temperatur mit HA hier platzieren:

mosquitto_sub -h ip -u hamqtt -P passwd -t 'fhem/heizungXY/desiredTemperature'
6.0
6.0
10.0
9.0

Aber im Gegensatz zu den Schaltern will max! in FHEM den Wert von HA nicht im Gerät setzen / annehmen?

Was fehlt mir auf der FHEM Seite, dass hier ein set desiredTemperature 9.0 passiert?

Habe diese drei Kombinationen bereits erfolglos probiert:
attr heizungXY mqttSubscribe state:stopic={"$base/set"}
attr heizungXY mqttSubscribe desiredTemperature:stopic={"$base/desiredTemperature"}
attr heizungXY mqttSubscribe state:stopic={"$base/desiredTemperature"}

Ich habe es selbst gelöst.
attr heizungXY mqttSubscribe state:stopic={"$base/set"}
ist richtig - man muss allerdings bei HA mittels Template beim set ein desiredTemperature davorsetzen (da der Befehl in fhem bei max set desiredTemperature 20.5 und nicht nur set 20.5 lautet)