Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE

[Beta-User]

IODev hast du angepasst?

[Deanw1975]

Hallo zusammen,

in Fhem und Homeassistent habe ich den Dummyswitch angelegt.
Kann diesen von beiden Seiten auch schalten.
In Homeassistent wird mir aber der Schalter immer als Status "unbekannt" angezeigt.
Wenn ich den availability_topic, payload_available und payload_not_available in Homeassistent aktiviere, geht der ganze Dummy offline.

Code Auswählen Erweitern

mqtt:
  - switch:
      unique_id: demoswitch
      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"
Hier der Eintrag aus FHEM:
Bridge:

Code Auswählen Erweitern

nternals:
   BUF       
   Clients    :MQTT2_DEVICE:MQTT_GENERIC_BRIDGE:
   ClientsKeepOrder 1
   DEF        192.168.178.100:1883
   DeviceName 192.168.178.100:1883
   FD         230
   FUUID      677a7828-f33f-61e0-9c2c-64af1a295dc3aaf8
   NAME       ha_MQTT2
   NR         842
   PARTIAL   
   STATE      opened
   TYPE       MQTT2_CLIENT
   WBCallback
   clientId   fhem
   eventCount 11
   lastMsgTime 1736148829.2737
   nextOpenDelay 10
   nrConnects 4
   qosCnt     67
   qosMaxQueueLength 100
   .attraggr:
   .attrminint:
   .clientArray:
     MQTT2_DEVICE
     MQTT_GENERIC_BRIDGE
   MatchList:
     1:MQTT2_DEVICE ^.
     2:MQTT_GENERIC_BRIDGE ^.
   READINGS:
     2025-01-06 08:15:58   state           opened
   qosQueue:
Attributes:
   clientId   fhem
   keepaliveTimeout 60
   msgAfterConnect -r fhem/connection/status connected
   msgBeforeDisconnect -r fhem/connection/status disconnected
   qosMaxQueueLength 100
   room       MQTT
   username   xxxxxxxxxx

Code Auswählen Erweitern

Im MQTT Explorer sehen ich den Topic zum Status auch in Homeassietent

Was soll ich ändern?

VG
Dean

[Beta-User]

Zum einen TYPE vom "Dummyswitch" ist ?!?

Zum anderen: Clientorder anschauen!

[Deanw1975]

Zum einen TYPE vom "Dummyswitch" ist ?!?

Ist ein dummy:

Code Auswählen Erweitern

Internals:
   FUUID      677a79d8-f33f-61e0-ead4-e2c243464501d492
   LASTInputDev ha_MQTT2
   MSGCNT     7
   NAME       demoswitch
   NR         844
   STATE      off
   TYPE       dummy
   eventCount 10
   ha_MQTT2_MSGCNT 7
   ha_MQTT2_TIME 2025-01-06 08:04:37
   .attraggr:
   .attrminint:
   READINGS:
     2025-01-06 08:04:37   state           off
Attributes:
   mqttForward all
   mqttSubscribe state:stopic={"$base/set"}
   room       HASS,Test
   userattr   mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long
   webCmd     on:off

Was meinst du damit:

Zum anderen: Clientorder anschauen!

[Deanw1975]

Guten Morgen,
leider habe ich noch keine weitere Reaktion auf meinen beiden Einträge vom 06.1.2025

Kann es sein, dass meine Probleme daran liegen das kein set übertragen wird.
Also dieser Befehl fehlt:

Code Auswählen Erweitern

fhem/demoswitch/set
Der Eintrag ist aber hinterlegt:

Code Auswählen Erweitern

attr demoswitch mqttSubscribe state:stopic={"$base/set"}"
Der "state" wird übertragen.

Danke
Dean

[Beta-User]

Guten Morgen,
leider habe ich noch keine weitere Reaktion auf meinen beiden Einträge vom

Hast du denn das Stichwort in deinem Beitrag gesucht und in der commandref nachgeschaut?

[Deanw1975]

Hi "Beta-User"

Bin ich Blind?
in meinem Beitrag steht nichts zu "Clientorder"
Diese soll laut commandref auch nicht relevant sein, wenn autocreate nicht aktiv ist (was der Fall ist)
Oder auch nicht, wenn die wenn die Bridge schon eine ausreichende Order inne hat.
Was ich aus dem zweiten Beitrag hier 1zu1 übernommen hatte.

Wie du dem "List" entnehmen kannst, kann ich die also meinem eigenen Beitrag gar nicht den Begriff "Clientorder" entnehmen:-(

Also was soll ich als "Clientorder" wo eintragen?

[Beta-User]

Hmm, trotzdem ändern.

Nur, falls es ein M2D geben sollte, das den topic abgreift..

Und mqttForward im MGB commandref nachsehen (dummy-TYPE). Dann aber Schleife prüfen!

[Deanw1975]

Clientorder kann man nur bei MQTT2_CLIENT hinterlegen.

Laut Doku habe ich nun das am client hinterlegt

clientOrder demoswitch mqttGeneric


Das hat aber ein Effekt.
Vor allem, verstehe ich den Sinn nicht.

Aber sicher bekomme ich nur wieder ne Antwort die mich nicht weiter bringt.

[rudolfkoenig]

Clientorder kann man nur bei MQTT2_CLIENT hinterlegen.

Das geht auch bei MQTT2_SERVER, das ist aber vmtl. in diesem Fall irrelevant.

clientOrder demoswitch mqttGeneric

So wird das nicht funktionieren: clientOrder benoetigt Modulnamen, wie in der Doku: https://fhem.de/commandref_modular.html#MQTT2_CLIENT-attr-clientOrder
d.h.

Code Auswählen Erweitern

attr ha_MQTT2 clientOrder MQTT_GENERIC_BRIDGE MQTT2_DEVICE


Vor allem, verstehe ich den Sinn nicht.

Diese Liste bestimmt die Reihenfolge der Module, die unbekannte Nachrichten verarbeiten.
Per Voreinstellung bekommt MQTT2_DEVICE sie als erstes, und legt eine MQTT2_DEVICE Instanz an.
MQTT_GENERIC_BRIDGE hat dann das Nachsehen.

Aber sicher bekomme ich nur wieder ne Antwort die mich nicht weiter bringt.

Nicht immer haben die (freiwilligen) Helfer Zeit oder Geduld, das nochmal detailliert hinzuschreiben, was sie schon oft gemacht haben, manchmal erwarten sie sogar, dass Hilfesuchende erst die Doku lesen.
Das kann fuer Hilfesuchende frustrierend sein, aber man kann sich damit troesten, dass man hier die Chance hat, den Entwickler direkt zu treffen, was bei bezahlten Produkten nicht der Fall ist.

[Beta-User]

Vor allem, verstehe ich den Sinn nicht.

Rudi hat das ja dankenswerterweise erklärt.

Vielleicht nochmal der "Datenweg":
"irgendwas" (hier: HomeAssistant) publisht eine Message. Der MQTT-Server (hier extern) schubst es weiter an alle, die den betreffenden Topic abonniert haben. Das sollte hier FHEM mit einer MQTT2_CLIENT-Instanz sein.

In dieser sind keine "subscriptions" per Attribut gesetzt, es kommt also "alles" an. Das kann man prüfen, indem man "show MQTT traffic" in der entsprechenden Instanz anschaltet. Dann wirst du vermutlich sehen, ob/was da ankommt (mein Tipp: viel zu viel...).
Danach wird jede message per "dispatch" weitergereicht. Ist clientOrder nicht gesetzt, bekommt zuerst MQTT2_DEVICE diese message. Falls autocreate NIE gesetzt war, macht es "nichts" und reicht die message an das nächste Modul weiter. Falls aber - aus IRGENDEINEM Grund eine passende readingList da ist (bei weiter deaktiviertem autocreate), kommt nichts bei MGB an. Daher sollte man IMMER die clientOrder setzen, es sei denn, man weiß GENAU, was man tut und wie man Fehler findet.

Dann kommt ggf. die message wirklich bei MGB an. Mit etwas Glück paßt dann die Konfiguration und das entsprechende FHEM-Device (hier: der dummy) wird aktualisiert/geschaltet/whatever.
Falls das passiert ist, kann man sich um den Rückweg kümmern. Zu mqttForward gab es keine Rückmeldung...

Also anders gesagt: Bis wohin funktioniert jetzt die Kette, wenn du von HomeAssistant aus versuchst, den dummy zu "schubsen"?
Weil das ganze kompliziert ist und man sinnvollerweise eine bestimmte Auswahl von Attributen an den diversen Elementen setzt, gibt es "attrTemplate" - auch für MQTT_GENERIC_BRIDGE - mit denen wir vermeiden wollen, dass man jedes Mal von Adam und Eva anzufangen muss...

[Deanw1975]

Danke für eure Erläuterungen

ich habe nun das Device angepasst
Also: clientOrder mqttGeneric demoswitch

Hier mal das List

Code Auswählen Erweitern

Internals:
   BUF       
   Clients    :mqttGeneric:demoswitch:
   ClientsKeepOrder 1
   DEF        192.168.178.100:1883
   DeviceName 192.168.178.100:1883
   FD         173
   FUUID      677a7828-f33f-61e0-9c2c-64af1a295dc3aaf8
   NAME       ha_MQTT2
   NR         840
   PARTIAL   
   STATE      opened
   TYPE       MQTT2_CLIENT
   WBCallback
   clientId   fhem
   eventCount 1
   lastMsgTime 1736759768.42387
   nextOpenDelay 10
   nrConnects 1
   qosCnt     93
   qosMaxQueueLength 100
   .clientArray:
   MatchList:
     1:mqttGeneric ^.
     2:demoswitch ^.
   READINGS:
     2025-01-13 03:30:15   state           opened
   qosQueue:
Attributes:
   autocreate no
   clientId   fhem
   clientOrder mqttGeneric demoswitch
   keepaliveTimeout 60
   msgAfterConnect -r fhem/connection/status connected
   msgBeforeDisconnect -r fhem/connection/status disconnected
   qosMaxQueueLength 100
   room       MQTT
   username   mqtt

Im MQTT Explorer sehe ich immer noch den den Demoswitch der an Homeassistent ankommt.
Aber der Demoswich bleibt immer noch im Status UNBEKANNT.

Ohne Clientordner kann ich auf beiden Seiten schalten, mit Clientorder kann ich  Homeassistent nicht mehr schalten, obwohl auch in FHEM der Befehl (laut MQTT Explorer am Fhem Broker) ankommt.
Wenn ich den Clientorner wieder weg nehme, kann ich von beiden Seiten schalten.

[Beta-User]

Also: clientOrder mqttGeneric demoswitch

Nope! So wie Rudi das geschrieben hatte...

d.h.
Code Auswählen Erweitern

Code Auswählen Erweitern

attr ha_MQTT2 clientOrder MQTT_GENERIC_BRIDGE MQTT2_DEVICE

Und wenn du dann (wieder) den dummy via MQTT schalten kannst, und es "einfach nur" darum geht, dass die Schaltung nicht von FHEM wieder rückwärts gesendet wird, befasse dich mit mqttForward! (oder einer "optimistic"-Einstellung auf der HomeAssistant-Seite).