Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE

Begonnen von edy_80, 25 Oktober 2020, 19:06:36

Vorheriges Thema - Nächstes Thema

Spartacus

Moin,

also das ist das was ich sehe (Screenshot) und der Link führt mich m.E nur zu einer allgemeinen Beschreibung zu Templates und nicht zu dem konkreten Code.
Wenn das das "Shutter-Template" ist, dann sind meine Kenntnisse einfach zu dünn um dies zu verstehen, sorry!

Vielleicht kann man meine Einstellungen noch etwas vereinfachen, aber eigentlich bin ich auch ganz zufrieden, mit dem, was da in HA ankommt. Ganz sauber ist es sicherlich nicht, aber es erfüllt seinen Zweck (siehe Screenshot, Rollo) Offenbar liegt das mit dem "stopp"-Zustand an der MQTT Implementierung in HA.

Was mich allerdings etwas stört, ist, dass nach einem Reboot von HA die Zustände der Rollladen als "unknown"  auftauchen. Mit retain: true kriegt man das zwar gefixt, aber das könnte, wie Du schon angemerkt hast, auch zu unschönen Effekten führen. Das gefällt mir einfach noch nicht.

Gruß,
Spartacus
Fhem-System: 1 x raspberry PI Typ B, 1 x enOcean PI Typ B | Enocean: PTM210, FMS61NP, FAM14, 2 x FSR14-4x, FTS14-EM | LaCrosse: 2 x TX29D über Jeelink V3 | 1-Wire: 2 x DS18B20 über DS9490R

Spartacus

Moin zusammen,

ich muss noch einmal die Experten befragen, da ich das Problem selber nicht lösen kann.

Ich betreibe im HA inzwischen auch einen Zigbee2Mqtt. Der Server läuft in einem Docker auf meiner Qnap. Der Mosquitto läuft ebenfalls auf der Qnap in einer separaten VM.

fhem stellt über die MGB ein paar 1wire duofern und enocean Geräte bereit; Zigbee2Mqtt alle meine Zigbee Aktoren und Sensoren über einen externen IP Coordinator

Im HA ist es jetzt aber so, dass nach einem Reboot alle States, die über die fhem Schiene kommen, verloren gehen. Bei den Zigbee2Mqtt-Devices ist das nicht der Fall. Nach ein paar Sekunden, sind die Zustände da. Das funktioniert sehr zuverlässig, ohne Nebeneffekte, wie z.B. ungewollte Schaltaktionen.

Ich hatte das retain Flag bei den fhem Devices mal gesetzt, aber dann habe ich das Problem, dass es zu den sog. Ghost-Schaltaktionen kommt.

Bei den 1w-Sensoren sind die fehlenden Zustände nicht so kritisch, da diese nach ein paar Minuten wieder ok sind, da die Devices  ihre Werte senden. Nervig ist das bei den Rolladenaktoren und den Schaltaktoren.

Hat jemand eine Idee, was man da machen kann?
Fhem-System: 1 x raspberry PI Typ B, 1 x enOcean PI Typ B | Enocean: PTM210, FMS61NP, FAM14, 2 x FSR14-4x, FTS14-EM | LaCrosse: 2 x TX29D über Jeelink V3 | 1-Wire: 2 x DS18B20 über DS9490R

jove01

Hallo Gadget
Mein Kompliment. Ohne die vielen Seiten gelesen zu haben, habe ich den Testswitch so umsetzen zu können. Mal schauen, ob ich das auch mit echten Devices so hinbekomme. :)
Aktuelles FHEM auf Raspi 3 und dbLog
CUL 433
HMLan Rolladensteuerung

rubinho

Servus,

ich bin momentan dabei mit HA etwas rumzuspielen und wollte zumindest sämtliche MQTT Devices die momentan direkt mit dem Fhem Broker kommunizieren, in Richtung HA weiterleiten. (Man kann ja in der Regel in den IOT Devices nie mehr als ein einen Broker angeben)

Da ich bzgl. MQTT eine echte Schnarchnase bin, wollte ich mal fragen wie ich das am Besten anfange.
Wie schon geschrieben, stand jetzt, benötige ich nur eine Bridge zwischen den zwei Brokern, so dass alle MQTT Devices die über Fhem angebunden sind, auch in HA auftauchen.

Viele Grüße
Rubinho
Fhem 5.9@Zotac Zbox Ci327 | HMCCU | Z-Wave@ZMEEUZB1 | HUE Bridge Gen2 | knxd over IP

rubinho

Ich habe versucht aus den diversen Beispielen in diesem Thread eine Bridge zu bauen.
Leider habe ich dadurch Fhem auf die Bretter geschickt.
Fhem legte gefühlt von jedem Device das mit Fhem interagiert ein zusätzliches Device an und irgendwann war dann Feierabend.
Ich musste Fhem hart beenden und die Konfig auf der Konsole bereinigen.

Im Prinzip benötige ich nur eine Bridge beider MQTT Broker.

VG
Rubinho

Fhem 5.9@Zotac Zbox Ci327 | HMCCU | Z-Wave@ZMEEUZB1 | HUE Bridge Gen2 | knxd over IP

Beta-User

Wieso benötigst du überhaupt zwei Broker? Verwende einen und alles dürfte gut sein...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rubinho

Das ist in der Tat mein Endszenario.
Ich hatte ursprünglich der Einfachheit halber den internen Fhem Broker in Betrieb genommen. Dieser ist natrülich fest mit Fhem verdrahtet.

Da man, wie du schon geschrieben hast nur einen Broker benötigt, möchte ich auf einen Externen zu setzen um flexibler zu sein.

Ich werde mich mal durchkämpfen.

Trotzdem danke für die Info.
Fhem 5.9@Zotac Zbox Ci327 | HMCCU | Z-Wave@ZMEEUZB1 | HUE Bridge Gen2 | knxd over IP

Beta-User

Das "Umswitchen" ist m.E. kein Hexenwerk. Du zeigst einfach mit einem MQTT2_CLIENT auf den externen Broker, setzt ignoreRegexp so, dass commandos und das homeassistant-autodiscovery-Zeug nicht in FHEM anlanden und läßt das "native MQTT-Gedöns" dann mit dem externen Broker sprechen und änderst an den vom MQTT2_SERVER angelegten Devices dann nur das IODev. Fertig die Laube ;) .

Hat übrigens auch nüscht mit MQTT_GENERIC_BRIDGE zu tun.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rubinho

Zitat von: Beta-User am 02 März 2023, 16:19:18
Hat übrigens auch nüscht mit MQTT_GENERIC_BRIDGE zu tun.

Nö hat es nicht :)
Der ursprüngliche Gedanke war ja beide Broker miteinander zu bridgen. Ich dachte das wäre der einfache Weg.
Was es wohl nicht ist.

Allerdings macht das gebastel am MQTT mein Fhem sehr instabil.
Keine Ahnung was ich kaputt gemacht habe.
Sobald ich den externen Broker in Betrieb nehme. Wird alles Zäh und ich bekomme im Log nur noch Timeouts von irgendwelchen Verbindungen (z.B. Influx)

Vielleicht boote ich mal alles durch. Sowas soll manchmal helfen :D



Fhem 5.9@Zotac Zbox Ci327 | HMCCU | Z-Wave@ZMEEUZB1 | HUE Bridge Gen2 | knxd over IP

Beta-User

Das klingt nach einer unbeabsichtigt verursachten Schleife.

Zum Auffinden könnte es helfen, den MQTT-Traffic am IO (M2C) zu beobachten. Weitere Fragen dazu dann aber bitte in einem gesonderten Thread...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rubinho

Zitat von: Beta-User am 02 März 2023, 19:52:08
Das klingt nach einer unbeabsichtigt verursachten Schleife.

Ja war es. Ich habs hinbekommen.
Danke für die Info

So, das war auch mein letzter Post in diesem Thread. Habe ihn lange genug gehijackt.

Sorry nochmal.

VG
Rubinho
Fhem 5.9@Zotac Zbox Ci327 | HMCCU | Z-Wave@ZMEEUZB1 | HUE Bridge Gen2 | knxd over IP

fire3k

Zitat von: rubinho am 04 März 2023, 08:48:59
Zitat von: Beta-User am 02 März 2023, 19:52:08Das klingt nach einer unbeabsichtigt verursachten Schleife.

Ja war es. Ich habs hinbekommen.
Danke für die Info

So, das war auch mein letzter Post in diesem Thread. Habe ihn lange genug gehijackt.

Sorry nochmal.

VG
Rubinho

So, ich versuche auch schon seit Tagen FHEM -> HA MQTT zu "Bridgen" ....

bisher allerdings recht erfolglos, eventuell hat da noch jemand einen tip zu, versucht habe ich die Anleitung die hier gepostet wurde, danach hatte ich aber mehrmals dasselbe Problem
wie rubinho, vllt kann er ja was dazu schreiben ob es nun geht den einfach zu bridgen.

HA hatte ich dann das Mosquitto Addon installiert, allerdings funktionierte die zusätzliche Konfiguration des DemoSwitches schon nicht (in HA) da HA den nicht bereitstellen wollte wegen eines zukünftigen updates.

Ich habe in FHEM meine ganzen Steckdosen (Tasmota) integriert, natürlich auch diverse Automationen laufen (Trockner, Waschmaschine usw) und würde gerne die Energie auswertungen
in HA machen, sprich die Steckdosen halt auch in HA verfügbar machen.

FHEM läuft auf einem PI4, HA auf einem 2ten PI4, also technisch recht easy gestrickt, trotzdem bekomm ich das nicht ans laufen irgendwie

LG, Sven

fire3k

#192
EDIT: Nach x-mal löschen der configs unmd neu einrichten läuft es jetzt ....

Dummy ist über FHEM und HA schaltbar, status ändert sich ebenfalls in beiden systemen :)

HA ist ja grausam :)

aber egal, danke allen hier, läuft :)

LG - Sven

coolice

Hallo, bei mir ist es so, das der MQTT2_Client immer wieder in disconnected wechselt. Ist das normal ? Liegt das an dem keepaliveTimeout ?
Wenn der Client connected ist wird der state nicht von ha -> fhem oder von fhem -> ha aktualisiert.

List MQTT Server
CONNECTS   2
   Clients    :MQTT2_DEVICE:MQTT_GENERIC_BRIDGE:
   ClientsKeepOrder 1
   DEF        1883 global
   FD         16
   FUUID      62650a0a-f33f-6642-587c-9884ee46095d1d93
   NAME       mqtt2s
   NR         470
   PORT       1883
   STATE      Initialized
   TYPE       MQTT2_SERVER
   eventCount 2
   MatchList:
     1:MQTT2_DEVICE ^.
     2:MQTT_GENERIC_BRIDGE ^.
   READINGS:
     2023-06-22 18:05:55   nrclients       2
     2023-06-22 18:05:39   state           Initialized
   clients:
     mqtt2s_127.0.0.1_58056 1
     mqtt2s_192.168.143.242_44977 1
   retain:
Attributes:
   autocreate simple
   respectRetain 0
   room       System->Gateways

List MQTT_Client
BUF       
   Clients    :MQTT_GENERIC_BRIDGE:MQTT2_DEVICE:
   ClientsKeepOrder 1
   DEF        192.168.143.242:1883
   DeviceName 192.168.143.242:1883
   FUUID      64908efc-f33f-6642-415f-1b2e6a1dd3c015d8
   NAME       ha_MQTT2
   NEXT_OPEN  1687451278.21973
   NR         508
   PARTIAL   
   STATE      disconnected
   TYPE       MQTT2_CLIENT
   clientId   fhem
   connecting 1
   nextOpenDelay 10
   nrConnects 129
   nrFailedConnects 129
   qosCnt     0
   qosMaxQueueLength 100
   MatchList:
     1:MQTT_GENERIC_BRIDGE ^.
     2:MQTT2_DEVICE ^.
   READINGS:
     2023-06-22 18:27:48   state           disconnected
   qosQueue:
Attributes:
   clientId   fhem
   clientOrder MQTT_GENERIC_BRIDGE MQTT2_DEVICE
   keepaliveTimeout 60
   msgAfterConnect -r fhem/connection/status connected
   msgBeforeDisconnect -r fhem/connection/status disconnected
   qosMaxQueueLength 100
   room       test
   subscriptions setByTheProgram
   username   hamqtt

List Bridge
DEF        mqtt room=HASS
   FUUID      6490937a-f33f-6642-8872-87fa06624c9c6a9b
   IODev      ha_MQTT2
   NAME       mqttGeneric
   NR         511
   NTFY_ORDER 70-mqttGeneric
   STATE      in: 0 out: 0 devices: 1
   TYPE       MQTT_GENERIC_BRIDGE
   devspec    room=HASS
   eventCount 4
   prefix     mqtt
   READINGS:
     2023-06-22 18:05:51   IODev           ha_MQTT2
     2023-06-19 21:05:16   attrTemplateVersion 20211208_MGB_M2D
     2023-06-22 18:05:51   device-count    1
     2023-06-22 18:05:40   incoming-count  0
     2023-06-22 18:05:40   outgoing-count  0
     2023-06-22 18:05:51   transmission-state IO device initialized (mqtt2)
     2023-06-22 18:05:40   updated-reading-count 0
     2023-06-22 18:05:40   updated-set-count 0
   devices:
     :global:
       :defaults:
         pub:base   mqttGeneric
         sub:base   mqttGeneric/set
       :publish:
         *:
           mode       R
           topic      {"fhem/$device/$reading"}
     demoswitch:
       :subscribe:
         HASH(0x84d3548)
   globalDeviceExcludes:
   globalReadingExcludes:
   globalTypeExcludes:
     pub:
       FHEMWEB    *
       Global     *
       MQTT       transmission-state
       MQTT_BRIDGE transmission-state
       MQTT_DEVICE transmission-state
       MQTT_GENERIC_BRIDGE *
       telnet     *
     sub:
       FHEMWEB    *
       Global     *
       MQTT       transmission-state
       MQTT_BRIDGE transmission-state
       MQTT_DEVICE transmission-state
       MQTT_GENERIC_BRIDGE *
       telnet     *
   subscribe:
Attributes:
   IODev      ha_MQTT2
   globalDefaults sub:base=mqttGeneric/set pub:base=mqttGeneric
   globalPublish *:topic={"fhem/$device/$reading"}
   icon       mqtt_bridge_2
   room       test
   stateFormat in: incoming-count out: outgoing-count devices: device-count
   verbose    0

rudolfkoenig

ZitatHallo, bei mir ist es so, das der MQTT2_Client immer wieder in disconnected wechselt. Ist das normal ?
Nein.

ZitatLiegt das an dem keepaliveTimeout ?
"keepaliveTimeout 60" bedeutet, dass FHEM alle 60 Sekunden ein PING schickt, und auf ein PONG wartet.
Laut RFC ist der Server verplichtet die Verbindung zu kappen, wenn das PING nach 90 Sekunden nicht empfangen wurde (1.5* keepaliveTimeout).
FHEM kappt auch die Verbindung, falls beim naechsten PING noch keine Antwort auf das Vorherige gekomment ist. Das wird mit loglevel 2 protokolliert.

Gibt es passende Meldungen im FHEM-Log?