[Gelöst] MQTT2_CLIENT schaltet bei Disconnect/Repear Flurlicht aus

Mark · 01 August 2023, 15:14:46

Hallo zusammen,

ein Disconnect/Repear von meinem MQTT2_CLIENT "mosquitto_hassio" führt dazu, dass mein Flurlicht ausgeschaltet wird.
Für mein Verständnis müsste doch der Status vom Flurlicht auch nach dem reconnect vom MQTT Server korrekt geholt werden (retain)
und das Flurlicht, wenn überhaupt, erneut eingeschaltet werden.

Hat jemand ein Idee? Unten ein Auszug aus den Logs. Einmal ist das Flurlicht an und wird ausgeschaltet, beim zweiten reconnect wird nochmal ein off gesendet.

Danke

Gruß Mark

fhem.pl 27750 2023-07-11 18:30:38Z rudolfkoenig

Code Auswählen

Flurlicht LOG:
2023-07-31_21:02:32 Flurlicht on
2023-07-31_22:59:37 Flurlicht off
2023-07-31_23:59:41 Flurlicht off

Code Auswählen

mosquitto_hassio LOG:
023.07.31 22:59:32 1: 192.168.11.11:1883 disconnected, waiting to reappear (mosquitto_hassio)
2023.07.31 22:59:33 1: 192.168.11.11:1883 reappeared (mosquitto_hassio)
2023.07.31 23:59:36 1: 192.168.11.11:1883 disconnected, waiting to reappear (mosquitto_hassio)
2023.07.31 23:59:36 1: 192.168.11.11:1883 reappeared (mosquitto_hassio)

Code Auswählen

define mosquitto_hassio MQTT2_CLIENT 192.168.11.11:1883
attr mosquitto_hassio icon mqtt
attr mosquitto_hassio msgAfterConnect -r fhem/connection/status connected
attr mosquitto_hassio msgBeforeDisconnect -r fhem/connection/status disconnected
attr mosquitto_hassio room 00_devices,01_system,02_MQTT2_Devices
attr mosquitto_hassio username mqtt-server
#   BUF        
#   Clients    :MQTT2_DEVICE:MQTT_GENERIC_BRIDGE:
#   ClientsKeepOrder 1
#   DEF        192.168.11.11:1883
#   DeviceName 192.168.11.11:1883
#   FD         255
#   FUUID      63f7b199-f33f-a0b3-ee44-985e6cc082f53f1c
#   NAME       mosquitto_hassio
#   NR         1135
#   PARTIAL    
#   STATE      opened
#   TYPE       MQTT2_CLIENT
#   WBCallback 
#   clientId   mosquitto_hassio
#   eventCount 100
#   lastMsgTime 1690895232.517
#   nextOpenDelay 10
#   nrConnects 66
#   MatchList:
#     1:MQTT2_DEVICE ^.
#     2:MQTT_GENERIC_BRIDGE ^.
#   READINGS:
#     2023-03-16 15:04:05   lastPublish     zigbee2mqtt/nous_03/set:off
#     2023-08-01 14:59:49   state           opened
#
setstate mosquitto_hassio opened
setstate mosquitto_hassio 2023-03-16 15:04:05 lastPublish zigbee2mqtt/nous_03/set:off
setstate mosquitto_hassio 2023-08-01 14:59:49 state opened

Code Auswählen

define Flurlicht IT A5
attr Flurlicht userattr mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long
attr Flurlicht IODev CUL433
attr Flurlicht alexaName Flurlicht
attr Flurlicht devStateIcon off:light_light_dim_100 on:light_light_dim_100@yellow
attr Flurlicht fp_Licht 290,530,0,
attr Flurlicht fp_Susanne 35,371,1,
attr Flurlicht mqttSubscribe state:stopic=fhem/Flurlicht/set
attr Flurlicht room Flur
#   DEF        A5
#   FUUID      5c46f962-f33f-a0b3-79cc-eed8d15514fa30f8
#   IODev      CUL433
#   LASTInputDev mosquitto_hassio
#   MSGCNT     39
#   NAME       Flurlicht
#   NR         549
#   STATE      off
#   TYPE       IT
#   XMIT       000000f00f
#   XMITdimdown 00
#   XMITdimup  0f
#   XMIToff    f0
#   XMITon     ff
#   eventCount 55
#   mosquitto_hassio_MSGCNT 39
#   mosquitto_hassio_TIME 2023-08-01 14:59:53
#   CODE:
#     1          000000f00f
#   READINGS:
#     2023-07-28 22:57:47   IODev           CUL433
#     2015-04-03 09:16:13   protocol        V1
#     2023-07-25 21:46:53   set             off
#     2023-08-01 14:59:53   state           off
#
setstate Flurlicht off
setstate Flurlicht 2023-07-28 22:57:47 IODev CUL433
setstate Flurlicht 2015-04-03 09:16:13 protocol V1
setstate Flurlicht 2023-07-25 21:46:53 set off
setstate Flurlicht 2023-08-01 14:59:53 state off

Beta-User · 01 August 2023, 16:35:51

Die spannende Frage dürfte sein, warum der MQTT-Server weg war.
Kann es sein, dass der neu gestartet worden ist? (Oder HASS?)

Mosquitto speichert z.B. die retain-Infos nicht (jedenfalls nicht im default; es gibt zudem eine Obergrenze).

Vermutlich ist es "sicherer", sowas ohne das feature zu konfigurieren.

Mark · 01 August 2023, 17:23:16

Danke für Dein Input. Aktiv habe ich nichts neu gestartet. Laut Protokoll lief der Mosquitto broker durch. Der Watchdog ist aktiv, den schalte ich einmal aus um zu schauen ob er sich vielleicht tatsächlich zerlegt.

JensS · 01 August 2023, 18:41:44

Zitat von: Mark am 01 August 2023, 15:14:46
Code Auswählen Erweitern
# READINGS: # 2023-07-28 22:57:47 IODev CUL433 # 2015-04-03 09:16:13 protocol V1 # 2023-07-25 21:46:53 set off # 2023-08-01 14:59:53 state off # setstate Flurlicht off setstate Flurlicht 2023-07-28 22:57:47 IODev CUL433 setstate Flurlicht 2015-04-03 09:16:13 protocol V1 setstate Flurlicht 2023-07-25 21:46:53 set off setstate Flurlicht 2023-08-01 14:59:53 state off

Code Auswählen

Flurlicht LOG:
2023-07-31_21:02:32 Flurlicht on
2023-07-31_22:59:37 Flurlicht off
2023-07-31_23:59:41 Flurlicht off

Da passt doch zeitzlich was nicht zusammen. InterTechno V1 kann praktisch von überall geschaltet werden - das muss nicht FHEM gewesen sein.

Gruß Jens

Beta-User · 01 August 2023, 18:55:04

Hmm, die paar Sekunden vom reconnect bis set hatte ich unter "FHEM ist sehr beschäftigt" verbucht - was aber auch nicht toll ist....

JensS · 01 August 2023, 19:14:29

Kann es sein, dass beim Restart vom HASS das Flurlicht vom HASS selbst ausgeschaltet wird? Gibt's da eventuell einen CUL oder eine Verbindung zum FHEM-CUL?

Mark · 02 August 2023, 09:23:44

> Da passt doch zeitzlich was nicht zusammen. InterTechno V1 kann praktisch von überall geschaltet werden - das muss nicht FHEM gewesen sein.
@JensS, nach jetzigem Stand schaltet der Broker das Licht aus, nicht FHEM. Ja, der InterTechno V1 kann per CUL geschaltet werden. Der zeitliche
Zusammenhang ist für mich eindeutigt. Unten noch einmal ein Auszug vom InterTechno V1 direkt nach dem reconnect.

> Hmm, die paar Sekunden vom reconnect bis set hatte ich unter "FHEM ist sehr beschäftigt" verbucht - was aber auch nicht toll ist....
@Beta-User, interessanter Ansatz. Mein FHEM hat hin und wieder 100% CPU Auslastung, mir ist aber nicht klar, wie ich das eingrenzen/loggen kann.

Code Auswählen

top -u fhem # ???
> Kann es sein, dass beim Restart vom HASS das Flurlicht vom HASS selbst ausgeschaltet wird? Gibt's da eventuell einen CUL oder eine Verbindung zum FHEM-CUL?
@JensS, Hass wird nicht neu gestartet und das Flurlicht wird auch nicht von Hass geschaltet (keine Automationen). Es gibt einen CUL aber nur in FHEM.

Das Verhalten kann ich wie folgt reproduzieren.

1. In FHEM Flurlicht einschalten

Code Auswählen

Flurlicht LOG:
2023-08-02_08:58:37 Flurlicht on

2. In FHEM mosquitto_hassio (MQTT2_CLIENT) disconnect/connect geschaltet

Code Auswählen

MQTT2_CLIENT LOG
2023.08.02 08:58:50 1: 192.168.11.11:1883 reappeared (mosquitto_hassio)

3. Nach dem reconnect wird das Flurlicht ausgeschaltet

Code Auswählen

Flurlicht LOG:
2023-08-02_08:58:55 Flurlicht off

Code Auswählen

define Flurlicht IT A5
attr Flurlicht userattr mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long
attr Flurlicht IODev CUL433
attr Flurlicht alexaName Flurlicht
attr Flurlicht devStateIcon off:light_light_dim_100 on:light_light_dim_100@yellow
attr Flurlicht fp_Licht 290,530,0,
attr Flurlicht fp_Susanne 35,371,1,
attr Flurlicht mqttSubscribe state:stopic=fhem/Flurlicht/set
attr Flurlicht room Flur
#   DEF        A5
#   FUUID      5c46f962-f33f-a0b3-79cc-eed8d15514fa30f8
#   IODev      CUL433
#   LASTInputDev mosquitto_hassio
#   MSGCNT     9
#   NAME       Flurlicht
#   NR         548
#   STATE      off
#   TYPE       IT
#   XMIT       000000f00f
#   XMITdimdown 00
#   XMITdimup  0f
#   XMIToff    f0
#   XMITon     ff
#   eventCount 16
#   mosquitto_hassio_MSGCNT 9
#   mosquitto_hassio_TIME 2023-08-02 08:58:55
#   CODE:
#     1          000000f00f
#   READINGS:
#     2023-08-01 17:37:57   IODev           CUL433
#     2015-04-03 09:16:13   protocol        V1
#     2023-07-25 21:46:53   set             off
#     2023-08-02 08:58:54   state           off
#
setstate Flurlicht off
setstate Flurlicht 2023-08-01 17:37:57 IODev CUL433
setstate Flurlicht 2015-04-03 09:16:13 protocol V1
setstate Flurlicht 2023-07-25 21:46:53 set off
setstate Flurlicht 2023-08-02 08:58:54 state off

4. Im Hassio Protokoll wird der Ablauf genauso wiedergegeben. Siehe Screenshot.

Beta-User · 02 August 2023, 10:45:35

Vorab: Für Quotes gibt es ein passendes tag (Schriftrollen-Symbol).
Der Ablauf ist für mich klarer jetzt: Wenn du in FHEM das Licht umschaltest, bekommt HASS das zwar mir, aber es wird deswegen ja noch lange nicht der letzte VON DORT gesendete Befehl geändert - der war hier halt nach wie vor OFF...
Kurz: Ich bleibe dabei, dass "retain" allgemein und speziell für deinen Anwendungsfall das falsche Mittel ist!
Ansonsten:
1. MQTT ist an sich leichtgewichtig, aber wenn man es falsch nutzt, entstehen leicht Schleifen. Da HASS deinen Schaltvorgang mitbekommt, würde ich darauf tippen, dass deine MQTT_GENERIC_BRIDGE irgendeine globale Einstellung hat, die mindestens den neuen Status beim Schalten von FHEM aus übermittelt - aber wenn ich richtig rate eben nicht nur das, sondern sehr viel mehr!
Würde empfehlen, das zu überdenken und dann (nur) am jeweiligen Ziel-Gerät festzulegen, was gesendet werden soll.
2. Zu Performance-Problemen gibt es bereits einige Threads.
https://forum.fhem.de/index.php?topic=117007.0
https://forum.fhem.de/index.php?topic=84372.0 (sehr lang!)
Vermutlich ein sehr guter Startpunkt ist auch https://forum.fhem.de/index.php?topic=125831.0.

Mark · 02 August 2023, 15:38:37

Danke für die Hinweise und den Links zu den Performance-Problemen.

Tatsächlich achte ich bei MQTT Geräten darauf nur so viel(e) als nötig einzustellen.

Mit dem MQTT-Explorer habe ich die beschriebene Prozedur wiederholt und mir den Traffic angesehen.
Es gab keine Auffälligkeiten (Hassio Querschläger) mit dem Topic Flurlicht.

Was aufgefallen ist, ist der grosse "RETAINED" Button im MQTT-Explorer. Mouseover teilt mir mit: "Delete retained topic".

Diesen habe ich gedrückt, der beschrieben Effekt ist seitdem weg

.

Warum das so ist kann ich nicht erklären. Die Vermutung liegt nahe, dass der Retain Speicher "Flurlicht" des Mosquitto Broker falsch/kaputt war
und bei jedem reconnect "off" gesendet hat.

Beta-User · 02 August 2023, 16:05:13

Zitat von: Mark am 02 August 2023, 15:38:37Diesen habe ich gedrückt, der beschrieben Effekt ist seitdem weg .

Warum das so ist kann ich nicht erklären. Die Vermutung liegt nahe, dass der Retain Speicher "Flurlicht" des Mosquitto Broker falsch/kaputt war
und bei jedem reconnect "off" gesendet hat.

Works as designed!

Und nach dem nächsten Schalten aus HASS heraus wirst du genau dasselbe Problem wieder haben! Weil dann nämlich der nächste Soll-Wert da abzufragen ist und FHEM bei einem reconnect genau macht, was es (lt. der Konfiguration, nicht nach dem, was du erwartest) soll!

Also zum Dritten: "retained" sollte man sich sparen, wenn man nicht sicher weiß, dass man es braucht!

Mark · 02 August 2023, 18:20:04

Zitat von: Beta-User am 02 August 2023, 16:05:13Und nach dem nächsten Schalten aus HASS heraus wirst du genau dasselbe Problem wieder haben!

Und genau das habe ich nicht gemacht. Und die Wahrscheinlichkeit, dass genau in der Sekunde des reconnects im HASS geschaltet wird ist sehr unwahrscheinlich.

Code Auswählen

2023.08.01 14:59:48 1: 192.168.11.11:1883 disconnected, waiting to reappear (mosquitto_hassio)
2023.08.01 14:59:49 1: 192.168.11.11:1883 reappeared (mosquitto_hassio)

Das Topic ist bei fhem und HASS identisch und wird zentral auf dem Mosquitto Broker gespeichert.
Bei einem reconnect von FHEM oder dem Neustart von HASS erwarte ich immer den letzten Wert vom Mosquitto Broker. So verstehe ich retain.

Bis der "Delete retained topic" Button gedrückt wurde kam immer ein OFF, was schlichtweg falsch war.

Ich habe die Ursache gefunden und kann wie folgt erklären:

FHEM ändert beim "Schalten" nur das Topic "fhem/Flurlicht/state", subscribe steht auf set "mqttSubscribe state:stopic=fhem/Flurlicht/set"

HASS ändert beim "Schalten" sowohl das topic "fhem/Flurlicht/state" als auch set "fhem/Flurlicht/set"

Wird das Flurlicht am HASS einmal ausgeschaltet steht das Topic "fhem/Flurlicht/set" auf off. Das bleibt auch so, wenn man in FHEM
das Flurlicht einschaltet. Erfolgt nun ein reconnect holt sich FHEM (so wie es soll) das set Topic und das Licht geht aus.

Dadurch, dass ich den "Delete retained topic" Button am Mosquitto-Broker gedrückt habe, war das set topic weg und der Effekt weg (bis man im HASS wieder einmal ausschaltet).

Jetzt stellt sich nur die Frage wie ich den Fehler beheben kann.
Ändere ich das Subscribe in fhem von set auf state baue ich einen Loop.
Ein Versuch im HASS yaml die state_on und state_off Zeile zu löschen macht keinen Unterschied. HASS sendet weiter sowohl set als auch state.

Code Auswählen

HASS Flurlicht yaml
switch:
  - name: Flurlicht
    state_topic: "fhem/Flurlicht/state"
    command_topic: "fhem/Flurlicht/set"
    payload_on: "on"
    payload_off: "off"
    state_on: "on"
    state_off: "off"
    unique_id: Flurlicht

betateilchen · 02 August 2023, 18:30:50

Oh, ein Popcorn-Thread.
Genau das richtige nach meinem heutigen anstrengenden Tag

JensS · 02 August 2023, 18:40:09

Zitat von: betateilchen am 02 August 2023, 18:30:50-----------------------
Mach es möglichst simpel und mach es richtig,
dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

... gefällt mir und manchmal hilft es auch, auf jemanden zu hören, der sich damit auskennt.

Ich hab's mal mit einem roten Pfeil gekennzeichnet: Du darfst diesen Dateianhang nicht ansehen.

Beta-User · 02 August 2023, 19:00:27

Zitat von: Mark am 02 August 2023, 18:20:04Jetzt stellt sich nur die Frage wie ich den Fehler beheben kann.
Ändere ich das Subscribe in fhem von set auf state baue ich einen Loop.
Ein Versuch im HASS yaml die state_on und state_off Zeile zu löschen macht keinen Unterschied. HASS sendet weiter sowohl set als auch state.

a) (4x!) Es ist KEIN FEHLER, sondern ein fehlerhaftes Verständnis deinerseits!

b) Wenn überhaupt, muss FHEM (!) nach dem Schalten das "state"-Topic (wenn es unbedingt sein muss mit "r"-flag) setzen und HASS das abbonieren, es darf aber AUF KEINEN FALL das set-Topic überhaupt gespeichert werden. Wenn weg, dann weg, egal ob ausgeführt oder nicht!

c) "rund" ist das m.E. nur, wenn man sauber zwischen Anweisung und Rückmeldung trennt, und das machst du auch (!) nicht (auf der HASS-Seite). "optimistic" ist Käse, warte auf die Rückmeldung...

d) mit der yaml verstehe ich (endlich!) auch, warum du der Ansicht bist, nur die "notwendigen" Infos zu publishen - es ist nämlich gar kein Stand aus FHEM heraus, der da zu sehen war...

Zitat von: betateilchen am 02 August 2023, 18:30:50Oh, ein Popcorn-Thread.
Genau das richtige nach meinem heutigen anstrengenden Tag

Da hast du recht, und ich bin hier jetzt auch raus, denn ich habe keine Ahnung, wie man in HASS einstellt, was mit retain-flag gesendet werden soll und was nicht. (OK, es scheint einen screenshot zu geben, der dahingehend aufschlussreich ist...)

rudolfkoenig · 02 August 2023, 20:16:02

Welches Problem wird mit dem retain Flag eigentlich geloest?