Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE

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

Vorheriges Thema - Nächstes Thema

hckoe

So, habe jetzt die Kommunikation zwischen HA/MosquittoMQTT und FHEM/MQTT2_CLIENT/MGB soweit am Laufen. Stecke aber jetzt noch in einem Verständnis-Problem mit "retain".
Ich versuch's mal zu beschreiben:

FHEM und HA haben bei einem Demoswitch jeweils folgende Topics (mit retain=0) abonniert:
mqttPublish     -> MGB/demoswitch      -> state_topic
mqttSubscribe <- MGB/set/demoswitch <- command_topic

Wenn ich jetzt bei eingeschaltenem Switch am MQTT2_CLIENT disconnect/connect ausführe (oder FHEM neu starte) schaltet sich der Switch aus. Mosquitto_sub liefert:

MGB/connection disconnected
MGB/connection connected
MGB/demoswitch off

Vermutlich ist bei MQTT der Default "off" bei retain=0.

Das gleiche Verhalten habe ich, wenn ich in FHEM retain=1 eingebe.
Erst wenn ich in HA retain=true setze, bleibt der Status des Switches über Neustarts von FHEM bzw. disconnect/connect-Aufrufe des MQTT2_CLIENTS erhalten. Das FHEM Retain-Flag ist hier egal.

MGB/connection disconnected
MGB/connection connected
MGB/demoswitch on


Warum hat "retain" hier in FHEM keine Auswirkung, sondern nur in HA?
Kann hier jemand Licht in mein Dunkel bringen?


# CT mit Debian Buster / FHEM aktuell / EnOcean TCM310 / Eltako FSA12, FUD12NPN, FSB12, FRW, FSRP-230V
# Permundo PCS234, Nodon NO-SIN-2-2-00, GTAGS

rudolfkoenig

ZitatVermutlich ist bei MQTT der Default "off" bei retain=0.
Es gibt kein Default bei retain=0.

Retain bedeutet, dass diese Nachricht gespeichert wird, und wenn jemand nach diesem Topic fragt, die Nachricht erhaelt.
Um die Nachricht zu entfernen, muss man das gleiche Topic mit einem leeren Message schicken.

Vor kurzem wurden Fehler bei der Kombination MGB/MQTT2_CLIENT/retain gemeldet, weiss aber nicht den aktuellen Status dazu.
Auf dem ersten Blick schaut der MGB Code richtig aus.

Beta-User

Könnte auch was mit "resendOnConnect" zu tun haben.

Hast du da irgendeine Einstellung in diese Richtung vorgenommen?
(Im Code gibt es dazu einen auskommentierten Zweig in isConnected(), der für M2C "always online" signalisiert, was aber dieses Phänomen eigentlich auch nicht erklären würde...)
Ansonsten: kannst du sicherheitshalber mal in global "showInternalValues" auf 1 setzen und dann mal schauen, ob an der MGB irgendwas in richtung .helper -> .pub_queue zu erkennen ist?
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

hckoe

Nein, resendOnConnect verwende ich nicht. Werde das mit "showInternalValues" heute abend mal testen.
# CT mit Debian Buster / FHEM aktuell / EnOcean TCM310 / Eltako FSA12, FUD12NPN, FSB12, FRW, FSRP-230V
# Permundo PCS234, Nodon NO-SIN-2-2-00, GTAGS

gadget

Im Beispiel (Post#2)  ist auch aufgezeigt, wie man in HA das  availability_topic verwendet. Wenn fhem (oder die Verbindung zum MQTT Server) down ist bekomme ich in HA bei den abhängigen Geräten schlicht ein "unavailable" angezeigt und kann dann bei denen auch nix schalten.
Bei Schaltern würde ich auch kein retain verwenden. Das kann unschön werden, wenn nach einer längeren Störung dann auf einmal alte Schaltzustände "nachgeschickt" werden, die aktuell wahrscheinlich eher unerwünscht sind.

hckoe

Das availability_topic habe ich schon eingestellt. Die connected/disconnected-Meldungen kommen auch davon. Und da beim Switch retain=false eingestellt ist, kann ich den auch nicht mehr von HA aus schalten, wenn fhem down ist. Ich stelle jetzt noch einmal alles auf retain=false und lösche alle alten Stati in MQTT und dann teste ich noch einmal, um sicher zu gehen.
# CT mit Debian Buster / FHEM aktuell / EnOcean TCM310 / Eltako FSA12, FUD12NPN, FSB12, FRW, FSRP-230V
# Permundo PCS234, Nodon NO-SIN-2-2-00, GTAGS

hckoe

So, da haben doch noch irgendwelche alten retained-Stati beim Mosquitto reingefunkt. Habe mal alle gespeicherten retained Topics gelöscht. Und siehe da, es klappt - auch mit disconnect/connect.
Habe alles wieder auf retained=false gestellt.

Sorry für die Verwirrung, die ich gestiftet habe.
# CT mit Debian Buster / FHEM aktuell / EnOcean TCM310 / Eltako FSA12, FUD12NPN, FSB12, FRW, FSRP-230V
# Permundo PCS234, Nodon NO-SIN-2-2-00, GTAGS

jensorium

Hey

ich hab Jahrlang zufrieden pilight genutzt, das lief dann nicht mehr und ich bekam es auch einfach nicht mehr ans laufen, dann auf Fhem gewechselt, aber irgendwie warm geworden bin ich damit nie ;/. Jetzt meine Idee HomeAssistant zu nutzen, optisch erstmal besser aber keine Verbindung zu meinem Nanocul möglich. Ok Plan B Fhem mit MQTT auf dem alten Raspi, HA auf dem neuen.
Erstmal so gar nichts geklappt und dann diese super Anleitung gefunden. Danke erstmal!
attr mqttGeneric mttqForward all lies sich nicht einrichten. "mqttGeneric: unknown attribute mttqForward. Type 'attr mqttGeneric ?' for a detailed list."

Mit dem Demoschalter schien auch alles zu laufen.
Dann habe ich einen wirklichen Schalter aus Fhem eingefügt. Dies ging auch nach anfänglichen Problemen in HA (weiß immer noch nicht wo nun mein Typo war), lässt sich aus HA auch schalten, aber der Status springt dann immer wieder auf den vorherigen Status den HA hatte :( Also der Schrank ist an, ich schalte ihn aus über HA aber der Schalter springt wieder zurück auf an.

Hat hier wer eine Idee? Es scheint für mich an HA zu liegen, daher hier der Code:

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"
  - platform: mqtt
    name: "schrank"
    command_topic: "fhem/schrank/set"
    state_topic: "fhem/schrank/state"
    payload_on: "on"
    payload_off: "off"
    state_on: "on"
    state_off: "off"


Wenn ich sonst was an Code senden soll sagt bescheid
Danke und Gruß
Jens

Beta-User

Dann mal willkommen im Forum hier!

Das Attribut gehört mAn. zum jeweiligen "wirklichen Schalter" und kann je nach prefix-Einstellung in der MGB auch anders heißen; ein list von der MGB und dem "wirklichen Schalter" wären ggf. aufschlussreich...
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

jensorium

Hey

Danke fürs Willkommen und die Gedanken

der wirkliche schalter ist auch ein Dummy. Der schaltet dann über RPi_utils per notify.

mgttGeneric devinfo:
demoswitch
  publish:
  subscribe:
    state            <= fhem/demoswitch/set (mode: S)

schrank
  publish:
  subscribe:
    state            <= fhem/schrank/set (mode: S)


ist es das was du meintest?


HA schaltet ja auch in Fhem, aber er geht dann zurück auf den alten Zustand.

Gruß

gadget

Mach mal ein list schrank und poste das Ergebnis hier. Wenn die MQTT-Kommunikation z.B. mit mosquitto_sub  abhörst: Was passiert auf dem topic  fhem/schrank/state   wenn Du von fhem oder von HA aus schaltest ?

(mosquitto_sub - Beispiele sind im Post #2 dieses Threads, es gibt mit https://mqtt-explorer.com/ auch ein sehr gutes grafisches Tool)

Wenn der Schalter hin HA wieder zurück springt, liegt das i.d.R. daran, dass du auf dem .../state keine Rückmeldung über den Schaltvorgang bekommst, der über .../set ausgelöst wurde.
Das kann je nachdem was du da tatsächlich an Hardware schaltest auch normal sein, z.B. bei einfachen Funksteckdosen mit einem oder mehreren Handsendern. Da bekommen die Handsender keine Rückmeldung ob der Schaltbefehl ausgeführt wurde und wie der momentane Schaltzustand gerade ist. Dann kann man nur hoffen dass der Schaltbefehl ausgeführt wurde. Für diesen Fall gibt es in HA den optimistic mode. in der configuration.yaml ergänzt Du dann entweder ein
optimistic: true
oder Du lässt state_topic, state_on, state_off ganz weg, dann ist der Schalter sowieso im optimistic mode. Evtl. solltest du aus dem Schalter dann aber einen Taster machen ("Umschalten").



jensorium

Hey

Danke für die Antwort

list schrank:

Internals:
   FUUID      5cb511dd-f33f-6e90-c8b3-12a1d7e089e26541
   LASTInputDev ha_MQTT2
   MSGCNT     7
   NAME       schrank
   NR         50
   STATE      on
   TYPE       dummy
   ha_MQTT2_MSGCNT 7
   ha_MQTT2_TIME 2021-02-21 14:27:25
   READINGS:
     2021-02-21 14:27:25   state           on
Attributes:
   alias      schrank
   mqttSubscribe state:stopic={"$base/set"}
   room       HASS,licht,wz
   setList    on off
   userattr   lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0 mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long room_map structexclude


Der Schaltet ja einen Dummy und dieser dummy ist ja auch an oder aus, sollte der dann nicht seinen status zurück geben? Und es sind 433er Steckdosen ohne Rückkanal, aber der Schaltzustand sollte doch in HA und Fhem gleich angezeigt werden?

Wenn ich in fhem schalte sagt der Explorer mir state on und off,
wenn ich in HA schalte sagt er mir set on und off und der Status bleibt, schaltet aber
Dies bleibt auch wen ich den optimistic rein gemacht habe oder alles gelöscht.

Ich glaub ich besorg mir besser par zigbee Dosen und gut, dann hab ich die Fehlerquelle MQTT hin und her weniger :(

gadget

Ich glaube das liegt am fehlenden mqttforward all bei deinem schrank-dummy.

Aus der Doku:

mqttForward
Dieses Attribut definiert was passiert, wenn eine und dasselbe Reading sowohl aboniert als auch gepublisht wird. Mögliche Werte: 'all' und 'none'.
Bei 'none' werden per MQTT angekommene Nachrichten nicht aus dem selben Gerät per MQTT weiter gesendet.
Die Einstellung 'all' bewirkt das Gegenteil, also damit wird das Weiterleiten ermöglicht.
Fehlt dieser Attribut, dann wird standardmäßig für alle Gerätetypen außer 'Dummy' die Einstellung 'all' angenommen (damit können Aktoren Befehle empfangen und ihre Änderungen im gleichem Zug weiter senden) und für Dummies wird 'none' verwendet. Das wurde so gewählt, da dummy von vielen Usern als eine Art GUI-Schalterelement verwendet werden. 'none' verhindert hier unter Umständen das Entstehen einer Endlosschleife der Nachrichten.


Wenn du das  Attribut nicht setzen kannst musst Du evtl. mal dein fhem updaten.

Grüße, gadget


jensorium

Hey

Über update sagt der mir es sei nichts zu tun...

Gruß

jensorium

Hey. Unter userattribute on Schrank ist er auch drin. Wie auch bei anderen Usern so gesehen grade.


attr mqttGeneric mttqForward all

Hier steht mttq und nicht mqtt aber so oder so nimmt er das nicht.
Gruß