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
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
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)
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
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
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.
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.
Zitat von: Mark am 01 August 2023, 15:14:46# 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
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 offDa passt doch zeitzlich was nicht zusammen. InterTechno V1 kann praktisch von überall geschaltet werden - das muss nicht FHEM gewesen sein.
Gruß Jens
Hmm, die paar Sekunden vom reconnect bis set hatte ich unter "FHEM ist sehr beschäftigt" verbucht - was aber auch nicht toll ist....
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?
> 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.
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
Flurlicht LOG:
2023-08-02_08:58:37 Flurlicht on
2. In FHEM mosquitto_hassio (MQTT2_CLIENT) disconnect/connect geschaltet
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
Flurlicht LOG:
2023-08-02_08:58:55 Flurlicht off
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.
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.
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 :o .
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.
Zitat von: Mark am 02 August 2023, 15:38:37Diesen habe ich gedrückt, der beschrieben Effekt ist seitdem weg :o .
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!
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.
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.
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
Oh, ein Popcorn-Thread.
Genau das richtige nach meinem heutigen anstrengenden Tag ;D
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: retain.png
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 ;D
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...)
Welches Problem wird mit dem retain Flag eigentlich geloest?
Kurz:
Problem: Unerwartetes Retain Flag im Mosquitto-Broker / HASS oder Mosquitto-Broker macht nicht was es soll.
Lösung: Lösche alle Nachrichten auf dem Mosquitto-Broker (zum Beispiel mit dem MQTT-Explorer).
Lang:
Problem war, dass der set Befehl von HASS mit einem Retain 1 beim Mosquitto-Broker gespeichert wurde und sich FHEM beim reconnect unter Umständen einen nicht gewünschten Zustand holt.
(Umstand: Schalte im HASS das Flurlicht aus (set&state off). FHEM schaltet per at das Flurlicht an(state on, set bleibt off).
Folgt dann ein zufälliger reconnect, wird das Flurlicht ausgeschaltet da sich FHEM, so wie es soll, den set Befehl holt (mqttSubscribe state:stopic=fhem/Flurlicht/set).
HASS sendet laut Doku default ohne Retain. Die Ursache, warum im meinem Szenario trotzdem mit retain gesendet wurde kann ich nicht erklären.
Nachdem ich alle Nachrichten auf dem Mosquitto-Broker per MQTT-Explorer gelöscht habe, kommt der HASS set Befehl korrekt ohne Retain an.
Was natürlich gemein ist, da nun mein beschriebenes Problem nicht mehr vorhanden ist.
Nachstellen konnte ich den "Fehler" indem ich im HASS dem Flurlicht per yaml "retain: true" aktiviert habe.
Für mich ist das Problem verstanden und gelöst auch wenn die Ursache (HASS oder Mosquitto-Broker) unklar bleibt.
Danke nochmal für die Unterstützung.
Womoeglich hat sich die Voreinstellung fuer retain in HASS nach einem update geaendert.