Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE

[Beta-User]

Kannst du kurz zusammenfassen, was sich geändert hat; nicht, dass wir versehentlich was kaputt gemacht haben...

Weiter würde mich interessieren, warum du denselben Topic für Senden und Empfangen nutzt (oder ist das eine Fehlinterpretation meinerseits?)?

Zu guter Letzt: Du schreibst, dass du den Umweg über readingsProxy gehen müßtest, um MQTT2_DEVICE-Type Geräte an FHEM anzubinden. Ich bin nicht ganz sicher, glaube aber, dass das ohne weitere gehen sollte (v.a., wenn man für die 2. Anbindung dann wieder jeweils unterschiedliche topics in Sende- und Empfangsrichtung verwendet; zwischenzeitlich sollte es sogar klappen, so ein Device über mehrere MQTT_GENERIC_BRIDGEs (mit unterschiedlichen Prefixes, versteht sich) auch in verschiedene Richtungen publishen zu lassen, also z.B. auch - neben der HomeAssistant-Anbindung) direkt ein ESP-Display damit zu beschicken; (mit dem aktuellen Mechanismus sollte das sogar praktisch kaum mehr Systemlast erzeugen). Das aber nur am Rande).

[gadget]

Ich hab attr mqttGeneric mttqForward all ergänzt und stateFormat / event-aggregator rausgenommen (aufgrund der nachfolgenden Posts) damit das Beispiel hoffentlich wieder schlüssig ist.

Senden und Empfangen laufen auf unterschiedlichen Topics: fhem/demoswitch/state bzw. fhem/demoswitch/set (siehe auch configuration.yaml).

Wegen readings_proxy: Als ich die Anbindung Mitte 2020 umgesetzt habe, ging das noch nicht. Ich habe in meiner fhem Installation ja zwei unterschiedliche MQTT-Server, einmal den fhem-eigenen    
MQTT2_SERVER m2s (zur Anbindung von tasmota- und Zigbee2MQTT-Devices) und dann remote den Mosquitto von HA. Wenn ich z.B. den Schaltzustand eines tasmota-Devices, das am m2s  angebunden ist, an den Mosquitto von HA senden wollte, hat das nicht funktioniert. Die haben als IODev m2s drin stehen und wurden dann offenbar  von der Bridge ignoriert. Drum habe ich denn halt jeweils einen Readingsproxy zwischengeschaltet, der ist dann ja eben kein MQTT-Device und konnte dann über die Bridge zum HA Broker funken.
Ich werde das bei Gelegenheit nochmal ausprobieren falls es da jetzt Änderungen gab, die das ohne Umweg ermöglichen.

Grüße,

gadget.

[hexenmeister]

Ist das wirklich nötig, zwei MQTT-Server zu verwenden? Es gibt dafür Anwendungesföllen, sind aber schon eher speziell. Ansonten wird  Mosquitto auch alleine wunderbar alles bedienen können. Oder eben der MQTT2_SERVER. Ich würde eher die HA umbiegen und den 'entfernten' Mosquitto abschaffen.

Ansonsten werden MQTT-Server i.d.R. miteinander mit eigenen Mitteln verbunden (bridging). In Mosquitto kann man konfigurieren, welche Topics der an andere Server weiterleiten soll. Ob das MQTT2_SERVER auch unterstützt, weiß ich nicht, sollte aber klappen, der Mosquitto auf der Gegenseite wird sich um senden und abonieren kümmern.

[Beta-User]

Würde auch dazu neigen, die Gesamtkonstruktion möglichst einfach zu halten, wobei sich die Wahl des Servers wohl danach ausrichten sollte, wie viel "externer Verkehr" stattfindet, den "das Haupt-FHEM" nicht mitzubekommen braucht. Ist das wenig, eher M2_SERVER, ist das viel oder sind lahme Clients mit großen Datenmengen, dabei, dürfte mosquitto (o.a.) die bessere Wahl sein.
(die Daten müssen halt irgendwie in FHEM).

Server-bridgeing beherrscht M2_SERVER afaik nicht.

Hier hatte gadget ja erläutert, dass die Zugriffsrechte für manche (menschliche) User auf den mosquitto andere sind als auf M2_SERVER/FHEM, von daher hat es hier vermutlich seine Berechtigung. (Ob mosquitto es ermöglicht, unterschiedliche "Berechtigungen" zu verwalten, wäre ggf. noch eine Frage, aber das ist dann ggf. auch nicht "einfacher" im Sinne obiger Grund-Tendenz).


Was aber (zumindest in meinem Test eben) geht (hat aber mit Server-bridgeing nichts zu tun):

MQTT2_SERVER+2 MGB+Weiterleiten von Readings aus einem MQTT2_DEVICE.

Würde daher annehmen, dass es prinzipiell kein Problem darstellt, die Daten von einem (wirklich hinsichtlich des TYPE (fast) beliebigen) Device auf diesem Weg auch an verschiedene Server zu verteilen. Das sollte auch unabhängig vom IO-TYPE gehen.
Zur Klarstellung noch: es ist mAn. effizienter, für _dasselbe IO_ nur eine MGB zu verwenden und eher den !other_subscriber-Weg zu gehen, wenn man Daten aus einem Device "vervielfältigen" will.

[hckoe]

Hallo,

nachdem das mit dem Demoswitch alles geklappt hat, habe ich dann auch problemlos einen EnOcean Lichtschalter (Eltako FSB12) eingebunden. Kommunikation HA und FHEM funktioniert in beide Richtungen. Dagegen habe ich jetzt mit einem EnOcean Dimmer (Eltako FUD12) schon Probleme bei der Richtung FHEM -> HA. Wenn ich den Dimmer in FHEM ein-/auschalte sehe ich den passenden Zustand in HA. Wenn ich den Slider verwende, funktioniert das nur, wenn ich vorher den Dimmer einschalte.

Hier die Definition des Dimmers:

Code Auswählen Erweitern


defmod demodimmer EnOcean FFCC6822
attr demodimmer userattr DIMMER DIMMER_map mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long structexclude
attr demodimmer IODev TCM310_0
attr demodimmer devStateIcon 0:FS20.off 100:FS20.on
attr demodimmer gwCmd dimming
attr demodimmer icon light_control
attr demodimmer manufID 00D
attr demodimmer mqttPublish state:topic={"$base/state"} dim:topic={"$base/dim"}
attr demodimmer mqttSubscribe state:stopic={"$base/set"}
attr demodimmer room HASS
attr demodimmer stateFormat dim
attr demodimmer subType gateway
attr demodimmer webCmd on:off:dim

setstate demodimmer 0
setstate demodimmer 2021-01-26 21:13:00 block unlock
setstate demodimmer 2021-01-26 21:13:00 dim 0
setstate demodimmer 2021-01-26 21:12:45 dimValueStored 50
setstate demodimmer 2021-01-26 21:13:00 state off


Hier noch die Ausgaben vom mosquitt_sub auf fhem/demodimmer/set .../state .../dim
Dimmer aus, dann Slider auf 50% -> HA: Dimmer aus, Slider 0%

fhem/demodimmer/state off
fhem/demodimmer/dim 50
fhem/demodimmer/state dim

Dimmer an, dann Slider auf 50% -> HA: Slider auf 50%

fhem/demodimmer/state on
fhem/demodimmer/dim 50
fhem/demodimmer/state dim

Hier noch die Konfig aus HA:

Code Auswählen Erweitern


light:
  - platform: mqtt
    unique_id: "demodimmer"
    name: "Demo Dimmer"
    optimistic: false
    retain: true
    brightness_scale: 100
    on_command_type: brightness
    command_topic: "fhem/demodimmer/set"
    brightness_command_topic: "fhem/demodimmer/dim"
    brightness_state_topic: "fhem/demodimmer/dim"
    state_topic: "fhem/demodimmer/state"
    payload_on: "on"
    payload_off: "off"


Hat jemand eine Idee, warum das nur im Zustand "on" funktioniert. In FHEM schaltet auch ein "set dim 50" die Lampe ein und dimmt sie auf 50%.

Gruß
Helmut

[gadget]

Hallo Helmut,

Ich habe einen Eltako FUD71 Dimmaktor mit folgender Konfig problemlos laufen:

Home Assistant configuration.yaml:

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"


fhem:

Code Auswählen Erweitern


defmod Eltako_Aktor_FUD71_19888CA EnOcean 019888CA
attr Eltako_Aktor_FUD71_19888CA userattr  mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long
attr Eltako_Aktor_FUD71_19888CA IODev TCM_ESP3_0
attr Eltako_Aktor_FUD71_19888CA alias Deckenleuchte WZ
attr Eltako_Aktor_FUD71_19888CA comMode confirm
attr Eltako_Aktor_FUD71_19888CA eep A5-38-08
attr Eltako_Aktor_FUD71_19888CA group Licht
attr Eltako_Aktor_FUD71_19888CA gwCmd dimming
attr Eltako_Aktor_FUD71_19888CA icon light_ceiling
attr Eltako_Aktor_FUD71_19888CA manufID 00D
attr Eltako_Aktor_FUD71_19888CA mqttSubscribe state:stopic={"$base/set"} dim:stopic={"$base/setdim"}
attr Eltako_Aktor_FUD71_19888CA room EnOcean,HASS,Wohnzimmer
attr Eltako_Aktor_FUD71_19888CA subDef FFBD8A34
attr Eltako_Aktor_FUD71_19888CA subType gateway
attr Eltako_Aktor_FUD71_19888CA webCmd dim
attr Eltako_Aktor_FUD71_19888CA widgetOverride dim:knob,min:40,max:100,step:1,linecap:round,angleOffset:-125,angleArc:250



In Lovelace verwende ich die Custom Card https://github.com/thomasloven/lovelace-slider-entity-row (via  HACS installiert), damit kann ich normale Ein/Aus Lichter und dimmbare Lichter kompakt in einer Card zusammenfassen.

Code Auswählen Erweitern


entities:
  - entity: light.wz_decke
    hide_when_off: true
    min: 25
    toggle: true
    type: 'custom:slider-entity-row'



Grüße, gadget

[Beta-User]

@hckoe:
Na ja, du hast auch auf dim kein subscribe...

attr demodimmer mqttSubscribe state:stopic={"$base/set"}

Vielleicht noch eine Anmerkung:
Wenn du das jetzt angehst, können wir das auch zusammen versuchen, allerdings sollten dann machen "Standards" beachtet werden (bzw. das, was dazu werden könnte:

- $base (aus den globalen Vorgaben) sollte jetzt doch ohne den $device-Anteil auskommen
- alle Setter gehen nach subscribe-$base ("xyz"/set) (festgelegt über ein globales Attribut an der MGB, wobei "xyz" das ist, was in publish-Richtung $base heißt)
- alles, was state betrifft, geht dann über $base/$device direkt, alles andere über $base/$device/$name

- dann sollte man für alles, was irgendwie "Standard" ist, auch standardisierte Benennungen verwenden. Vorschlag:
-- pct für (fast) alles, was 0-100 ist (bzw. bei ZWave: 0-99) (das würde hier bedeuten, einen mqttAlias zu verwenden "dim=pct")
    (Ausnahme: actuator/valve (?) bei Thermostaten etc., slatLevel (?) für Lamellendrehung)
-- brightness für alles, was in 0-255 einzustellen ist

-- desired-temp für die Soll-Temperatur,
-- temperature für gemessene Temperatur.

Falls da Interesse besteht, bitte ich um Rückmeldung, dann kann ich nämlich gleich versuchen, das in attrTemplate-Form zu gießen.

Falls jemand sich die Frage stelle, was das ggf. bringt: So kann man
- im Bedarfsfall einfach das Gerät (gegen ein völlig anderes) tauschen, paßt die (standardisierten!) Attribute an (ggf. über attrTemplate), und alles funktioniert von MQTT aus weiter wie bisher;
- in der yaml für alle Device-Typen denselben "Grundtypus" verwenden, man muss nur den Namen anpassen, und man kann sich auch hier zwischen den Usern einfacher austauschen...

(Ist nur ein Vorschlag...)

EDIT: Rückmeldungen zu Benennungsfragen bitte im Hauptthread ab hier: https://forum.fhem.de/index.php/topic,117987.msg1126418.html#msg1126418

[gadget]

Ich glaube, der Zug für die Standardisierung ist bei fhem bereits abgefahren. Das wäre fast überall ein breaking change. Beispiel:

Fritz Dect Heizungsaktor (FBDECT):

desired-temp  17.0  C

fhem PWMR Modul:

desired-temp 21.5

Max Heizkörper Stellaktor:

desiredTemperature 17.0

Da kommt man um Handarbeit nicht rum, um das HomeAssistant-konform aufzubereiten.

[Beta-User]

Ich glaube, der Zug für die Standardisierung ist bei fhem bereits abgefahren. Das wäre fast überall ein breaking change. Beispiel:

Jein, Missverständnis, und herzlichen Dank für genau diese Frage !

Es geht _nicht_ darum, das IN FHEM zu standardisieren (jedenfalls nicht, für den Ist-Zustand), sondern für die MQTT-Schnittstelle; siehe dazu auch DevelopmentGuidelinesReadings - weitere Vorschläge für künftige Module. Optimalerweise wird sowas dann auch beachtet bei der Entwicklung künftiger Module, aber soweit sind wir noch lange nicht...

Für MAX gibt es bereits ein attrTemplate, das die Namen ummappt, und für den DECT könnte man im Prinzip den ZWave-Code des ebenfalls bereits vorliegenden attrTemplate ausschlachten: Da ist für temperature ein "mach das Celsius weg"-code drin. Die Frage ist da nur, ob der einen rein nummerischen Wert als Anweisung versteht...

Hoffe, jetzt wird auch etwas klarer, wohin meine Überlegungen/Vorschläge gehen ?

[hckoe]

Hallo Beta-User,

ich bin da offen für alles. Ich werde mal schauen, daß ich es auf die "Standards" anpasse. Kann ich aber erst am WE in Ruhe machen.
Den Subscribe auf dim hatte ich schon drin, aber dann hat irgendwie das Publish dim und Subscribe dim einen Loop gebildet.

Melde mich demnächst.

Viele Grüße
Helmut

[hckoe]

Hallo Beta-User,

ich habe jetzt die MGB und den Dimmer noch einmal "sauber" nach Deinen Vorschlägen und mit attrTemplate aufgesetzt, d.h. Subscribe- und Publish-base sind jetzt gesplittet, pct ist jetzt ein mqttAlias für dim. Es funktioniert jetzt auch von HA nach FHEM alles, von FHEM nach HA gibt es aber noch immer das Problem, daß HA die Position des dim-Sliders nur aktualisert, wenn der Dimmer im on-Zustand ist. Das Problem ist vermutlich, daß der Dimmer die 3 Stati on,off und dim kennt und  HA nur on,off. FHEM published nämlich immer folgende Topics, egal ob aus dem on- oder off-Zustand:

MGB/demodimmer/pct 50
MGB/demodimmer dim

Wenn ich jetzt manuell mit mosquitto_pub folgende Topics schicke funktioniert es:

MGB/demodimmer/pct 50
MGB/demodimmer on

D.h. ich muss schauen, ob ich den dim-Status in HA irgendwie auf on gemappt bekomme.
Hat jemand so etwas schon einmal gemacht? Oder sieht jemand eine andere Möglichkeit?

Viele Grüße
Helmut

[Beta-User]

Sorry, dass es etwas gedauert hat mit der Rückmeldung...

Vorab mal: Schön, dass du vorankommst!

Bin etwas aus der Spur geraten, weil ich das Wiki bzw. die cref überarbeitete habe und da noch auf die (wohl wirklich überholte) Info gestoßen bin, Alias ginge nicht bei subscribe...

Was das Verhalten bei "gedimmtem on" angeht, würde ich vermuten, dass man das mit einer expression in den Griff bekommen könnte: "einfach" "dim" durch "on" ersetzen. Ungetestet:

Code Auswählen Erweitern

state:expression={$value=~m,dim,?"on":$value}

Wenn das so klappt, wäre das m.E. die zu bevorzugende Variante, weil man dann wieder in der externen Anwendung nichts ändern muss, sondern einen mAn. konsistenten Datensatz bekommt. Und das war ja der eigentliche Gedanke hinter der attrTemplate-Idee...

[hckoe]

Danke für die Info. Werde ich heute abend gleich ausprobieren.

[hckoe]

Also mit dem Hinweis auf state:expression funktioniert es jetzt.
Danke! Jetzt kommen noch Rollos und Jalousien dran.

@gadget: Kann der von Dir erwähnte Slider aus dem HACS Werte von 0–100 oder nur wie der Standard 1–100?

[gadget]

Hab ich nicht ausprobiert
Mein eltako Dimmer schaltet unter 15% eh ab.