MQTT DoIf trigger bei fhem Neustart

Begonnen von hackepeter, 17 März 2025, 20:55:14

Vorheriges Thema - Nächstes Thema

hackepeter

Hallo, ich habe jetzt schon einige Zeit im Forum gesucht und keine Lösung gefunden:
Wenn ich FHEM neustarte, löst eines meiner doif´s aus und öffnet (ausgerechnet) die Haustür.

Der Auslöser ist ein MQTT Topic "HaustuerOeffnen".

Hat jemand eine Idee?

Internals:
   DEF        ([MQTT2_ha_MQTT2:HaustuerOeffnen] eq "1")
(set Haustuer on)
(setreading MQTT2_ha_MQTT2 HaustuerOeffnen 0)
##(set ha_MQTT2 publish -r fromFHEM/Haustuer/Value "4")
##(set ha_MQTT2 publish -r fromFHEM/Haustuer/Value "5")
##(set ha_MQTT2 publish -r fromFHEM/Haustuer/Value "6")
##(set ha_MQTT2 publish -r fromFHEM/Haustuer/Value "7")

(set ha_MQTT2 publish -r fromFHEM/Haustuer/Value UNLOCKING)
(set ha_MQTT2 publish -r fromFHEM/Haustuer/Value UNLOCKED)
(set ha_MQTT2 publish -r fromFHEM/Haustuer/Value LOCKING)
(set ha_MQTT2 publish -r fromFHEM/Haustuer/Value LOCKED)

   FUUID      66f1add6-f33f-cd6f-fd55-3377767c9aeed61b
   MODEL      FHEM
   NAME       di_FromHA_HaustuerOeffnen
   NOTIFYDEV  MQTT2_ha_MQTT2,global
   NR         521
   NTFY_ORDER 50-di_FromHA_HaustuerOeffnen
   STATE      cmd_1
   TYPE       DOIF
   VERSION    29460 2024-12-29 20:25:48
   eventCount 14
   READINGS:
     2025-03-17 19:55:02   Device          MQTT2_ha_MQTT2
     2025-03-17 19:55:06   cmd             1.6
     2025-03-17 19:55:06   cmd_event       MQTT2_ha_MQTT2
     2025-03-17 19:55:06   cmd_nr          1
     2025-03-17 19:55:06   cmd_seqnr       6
     2025-03-17 19:55:02   e_MQTT2_ha_MQTT2_HaustuerOeffnen 1
     2025-03-17 19:55:06   state           cmd_1
     2025-03-17 19:55:06   wait_timer      no timer
   Regex:
     accu:
     bar:
     barAvg:
     collect:
     cond:
       MQTT2_ha_MQTT2:
         0:
           HaustuerOeffnen ^MQTT2_ha_MQTT2$:^HaustuerOeffnen:
   attr:
     cmdState:
     wait:
       0:
         0
         0
         1
         1
         1
         1
     waitdel:
   condition:
     0          ::ReadingValDoIf($hash,'MQTT2_ha_MQTT2','HaustuerOeffnen') eq "1"
   do:
     0:
       0          set Haustuer on
       1          setreading MQTT2_ha_MQTT2 HaustuerOeffnen 0
       2          set ha_MQTT2 publish -r fromFHEM/Haustuer/Value UNLOCKING
       3          set ha_MQTT2 publish -r fromFHEM/Haustuer/Value UNLOCKED
       4          set ha_MQTT2 publish -r fromFHEM/Haustuer/Value LOCKING
       5          set ha_MQTT2 publish -r fromFHEM/Haustuer/Value LOCKED
     1:
   helper:
     NOTIFYDEV  MQTT2_ha_MQTT2,global
     event      HaustuerOeffnen: 1
     globalinit 1
     last_timer 0
     sleepdevice MQTT2_ha_MQTT2
     sleepsubtimer -1
     sleeptimer -1
     timerdev   MQTT2_ha_MQTT2
     timerevent HaustuerOeffnen: 1
     triggerDev MQTT2_ha_MQTT2
     DOIF_eventa:
       cmd_nr: 1
       cmd_seqnr: 6
       cmd_event: MQTT2_ha_MQTT2
       cmd_1
     DOIF_eventas:
       cmd_nr: 1
       cmd_seqnr: 6
       cmd_event: MQTT2_ha_MQTT2
       state: cmd_1
     timerevents:
       HaustuerOeffnen: 1
       HaustuerOeffnen: 0
     timereventsState:
       HaustuerOeffnen: 1
       HaustuerOeffnen: 0
     triggerEvents:
       HaustuerOeffnen: 1
       HaustuerOeffnen: 0
     triggerEventsState:
       HaustuerOeffnen: 1
       HaustuerOeffnen: 0
   internals:
   perlblock:
   readings:
     all         MQTT2_ha_MQTT2:HaustuerOeffnen
   trigger:
   uiState:
Attributes:
   do         resetwait
   wait       0,0,1,1,1,1


Internals:
   CID        ha_MQTT2
   DEF        ha_MQTT2
   FUUID      66c24f3b-f33f-cd6f-f198-a187e16b06b58586
   IODev      ha_MQTT2
   LASTInputDev ha_MQTT2
   MSGCNT     1
   NAME       MQTT2_ha_MQTT2
   NR         490
   STATE      ???
   TYPE       MQTT2_DEVICE
   eventCount 1
   ha_MQTT2_MSGCNT 1
   ha_MQTT2_TIME 2025-03-17 19:55:02
   READINGS:
     2025-03-04 16:47:12   HaustuerKlingel 1
     2025-03-17 19:55:02   HaustuerOeffnen 0
     2025-03-17 19:55:00   IODev           ha_MQTT2
Attributes:
   alias      fromHA
   readingList ha_MQTT2:toFHEM/HaustuerKlingel/Value:.* HaustuerKlingel
ha_MQTT2:toFHEM/LichtGarageAussenAus/Value:.* LichtGarageAussenAus
ha_MQTT2:toFHEM/LichtGarageAussenEin/Value:.* LichtGarageAussenEin
ha_MQTT2:toFHEM/LichtGarageInnenAus/Value:.* LichtGarageInnenAus
ha_MQTT2:toFHEM/LichtGarageInnenEin/Value:.* LichtGarageInnenEin
ha_MQTT2:toFHEM/LichtHinzAus/Value:.* LichtHinzAus
ha_MQTT2:toFHEM/LichtHinzEin/Value:.* LichtHinzEin
ha_MQTT2:toFHEM/LichtHofAus/Value:.* LichtHofAus
ha_MQTT2:toFHEM/LichtHofEin/Value:.* LichtHofEin
ha_MQTT2:toFHEM/LichtStefanAus/Value:.* LichtStefanAus
ha_MQTT2:toFHEM/LichtStefanEin/Value:.* LichtStefanEin
ha_MQTT2:toFHEM/LichtTerrasseAus/Value:.* LichtTerrasseAus
ha_MQTT2:toFHEM/LichtTerrasseEin/Value:.* LichtTerrasseEin
ha_MQTT2:toFHEM/SteckdoseGartentorAus/Value:.* SteckdoseGartentorAus
ha_MQTT2:toFHEM/SteckdoseGartentorEin/Value:.* SteckdoseGartentorEin
ha_MQTT2:toFHEM/SteckdoseVordachAus/Value:.* SteckdoseVordachAus
ha_MQTT2:toFHEM/SteckdoseVordachEin/Value:.* SteckdoseVordachEin
ha_MQTT2:toFHEM/TorObenAus/Value:.* TorObenAus
ha_MQTT2:toFHEM/TorObenEin/Value:.* TorObenEin
ha_MQTT2:toFHEM/TorUntenAus/Value:.* TorUntenAus
ha_MQTT2:toFHEM/TorUntenEin/Value:.* TorUntenEin
ha_MQTT2:toFHEM/HaustuerOeffnen/Value:.* HaustuerOeffnen
   room       _from_HA

Internals:
   BUF       
   Clients    :MQTT2_DEVICE:MQTT_GENERIC_BRIDGE:
   ClientsKeepOrder 1
   DEF        192.168.178.177:1883
   DeviceName 192.168.178.177:1883
   FD         33
   FUUID      66c22033-f33f-cd6f-a552-abed5aeac7d44478
   NAME       ha_MQTT2
   NR         488
   PARTIAL   
   STATE      opened
   TYPE       MQTT2_CLIENT
   WBCallback
   clientId   ha_MQTT2
   eventCount 56
   lastMsgTime 1742241182.83625
   nextOpenDelay 10
   nrConnects 1
   qosCnt     57
   qosMaxQueueLength 100
   MatchList:
     1:MQTT2_DEVICE ^.
     2:MQTT_GENERIC_BRIDGE ^.
   READINGS:
     2025-03-17 20:51:53   lastPublish     fhem/states/HPSU/T_Warmwasser/Value:46.4
     2025-03-17 19:55:02   state           opened
   qosQueue:
Attributes:
   autocreate simple
   keepaliveTimeout 60
   msgAfterConnect -r fhem/connection/status connected
   msgBeforeDisconnect -r fhem/connection/status disconnected
   qosMaxQueueLength 100
   room       Admin,MQTT2_DEVICE,_from_HA
   subscriptions toFHEM/HaustuerKlingel/Value toFHEM/HaustuerOeffnen/Value toFHEM/LichtGarageAussenAus/Value toFHEM/LichtGarageAussenEin/Value toFHEM/LichtGarageInnenAus/Value toFHEM/LichtGarageInnenEin/Value toFHEM/LichtHinzAus/Value toFHEM/LichtHinzEin/Value toFHEM/LichtHofAus/Value toFHEM/LichtHofEin/Value toFHEM/LichtStefanAus/Value toFHEM/LichtStefanEin/Value toFHEM/LichtTerrasseAus/Value toFHEM/LichtTerrasseEin/Value toFHEM/SteckdoseGartentorAus/Value toFHEM/SteckdoseGartentorEin/Value toFHEM/SteckdoseVordachAus/Value toFHEM/SteckdoseVordachEin/Value toFHEM/TorObenAus/Value toFHEM/TorObenEin/Value toFHEM/TorUntenAus/Value toFHEM/TorUntenEin/Value toFHEM/Garagentor/Value
   username   MQTTUser

Beta-User

Zitat von: hackepeter am 17 März 2025, 20:55:14Hat jemand eine Idee?
Schon mal über "retain" intensiv nachgedacht?

Kein Zufall, dass jedenfalls ich das grundsätzlich nicht empfehle...
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

hackepeter

d.H. die Nachrichten müssen mit :r versendet werden, und dann sollte es gehen?

Beta-User

KEIN retain (jedenfalls nicht für diesen Datenpunkt aus Hass heraus)...
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

hackepeter

#4
das hatte ich bereits so - ohne Erfolg.

  - lock:
      unique_id: btn_to_fhem_Haustuer_Oeffnen
      name: "to_fehem Haustür öffnen"
      command_topic: "toFHEM/HaustuerOeffnen/Value"
      state_topic: "fromFHEM/Haustuer/Value"
      payload_unlock: "1"
      payload_lock: "LOCK"
      state_locked: "LOCKED"
      state_unlocked: "UNLOCKED"
      state_locking: "LOCKING"
      state_unlocking: "UNLOCKING"
      qos: 0
      retain: false
      optimistic: false
      availability_topic: "fhem/connection/status"
      payload_available: "connected"
      payload_not_available: "disconnected"
      device:
        identifiers: "HaustuerFromFhem"
        name: "Haustür"

Beta-User

Weiß dein MQTT-Server das auch schon....?

Das muss man aktiv widerrufen bzw. überschreiben.
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

hackepeter

Das ist eine gute Frage. Der MQTT-Server läuft auch auf dem HA. Wie kann ich das prüfen auf FHEM-Seite?

Beta-User

Zitat von: hackepeter am 18 März 2025, 10:55:39Das ist eine gute Frage. Der MQTT-Server läuft auch auf dem HA. Wie kann ich das prüfen auf FHEM-Seite?
Indem du deine Haustür durch einen fhem -restart öffnest....

Im Ernst: verwende ein externes Tool wie mosquitto_sub.

Und beschäftige dich intensiver mit dem Thema, es gibt bei retain noch ein paar Fallstricke, die man kennen sollte.
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

Jamo

ZitatHat jemand eine Idee?

Bis das mit dem retained geloest ist, koenntest Du auch zum Neustart von FHEM das DOIF 'disablen', und dann z.B. 60 Sekunden nach dem Neustart wieder enablen.

define INITIALIZED_n notify global:INITIALIZED { myInitialize() }

sub myInitialize {
  fhem('attr -silent di_FromHA_HaustuerOeffnen disable 1;sleep 60 sleep_myDOIF;attr -silent di_FromHA_HaustuerOeffnen disable 0');
}
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/Conbee III, FB7690, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack, Sonos, ESPresence

Beta-User

Nachdem das ein "Dauerbrenner" ist mit der Frage, wie man den Zustand _sinnvoll_ via MQTT "persistent" machen kann (siehe auch https://forum.fhem.de/index.php?topic=141013.0):

MQTT ist imo prinzipiell als _Benachrichtungungssystem_ für _Änderungen_ (bzw. die Übermittlung gerade ermittelter Umgebungsbedingungen) konzipiert.
Ein MQTT-Server ist daher nur sehr bedingt als "Datenspeicher" geeignet, und "retain" bedingt uU. andere Reaktionen, als man auf den ersten Blick annehmen würde - angefangen bei der Zahl der Datenpunkte, die z.B. mosquitto überhaupt nur retained akzeptiert über die Frage, was mosquitto damit beim eigenen Neustart macht...

Ergo: Die jeweilige Lösung MUSS m.E. anders aussehen: Jedes Teilsystem soll seine relevanten Daten selbst verwalten und eben ggf. für Persistenz (bzw. Zustandsvalidierung) bei "Verbindungsabbrüchen" sorgen.

FHEM macht das (beim ordnungsgemäßen Beenden) sowieso, hier ist eher die Frage, ob die gespeicherten Daten noch aktuell sind (=>readingsWatcher und andere).

Für homeassistant muss man das - zumindest ergab das eine schnelle Suche, die nicht korrekt sein muss - aktiv "anschalten", siehe z.B. https://www.home-assistant.io/integrations/template/#trigger-based-sensor-and-binary-sensor-storing-webhook-information oder https://community.home-assistant.io/t/binary-sensor-last-known-state-when-unavailable/59967/11.

Ergo: Die Frage ist falsch gestellt und daher (zumindest nach meiner Auffassung) die Lösung auch nicht (originär) im FHEM-Forum zu finden.
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

hackepeter

Zitat von: Jamo am 18 März 2025, 22:29:54
ZitatHat jemand eine Idee?

Bis das mit dem retained geloest ist, koenntest Du auch zum Neustart von FHEM das DOIF 'disablen', und dann z.B. 60 Sekunden nach dem Neustart wieder enablen.

define INITIALIZED_n notify global:INITIALIZED { myInitialize() }

sub myInitialize {
  fhem('attr -silent di_FromHA_HaustuerOeffnen disable 1;sleep 60 sleep_myDOIF;attr -silent di_FromHA_HaustuerOeffnen disable 0');
}

Vielen Dank, das funktioniert.
Die Lösungen von Bet-User sind mir zu komplex.

Beta-User

Zitat von: hackepeter am 19 März 2025, 20:05:49Die Lösungen von Bet-User sind mir zu komplex.
Was ist daran komplex, einfach "irgendwas" einmalig auf den Topic zu publishen, damit der content mit retain-flag weg ist?!?

Ansonsten: Denke nochmal intensiv über die retain-Nutzung nach. Komplex oder nicht: Das wird früher oder später wieder seltsame Effekte haben...
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

betateilchen

Zitat von: Beta-User am 19 März 2025, 20:21:05Was ist daran komplex, einfach "irgendwas" einmalig auf den Topic zu publishen, damit der content mit retain-flag weg ist?!?

Nur mal nebenbei angemerkt: Das publish eines topic mit "irgendwas" ohne retain Flag führt nicht zwangsläufig automatisch dazu, dass ein retained-publish des gleichen topic auf dem Server gelöscht wird.

# publish testtopic mit retain
mosquitto_pub -r -t /testtopic -m with_retain

# Abfrage der auf dem mqtt server gespeicherten retained messages zum testtopic
mosquitto_sub -t /testtopic -v --retained-only
/testtopic with_retain

# publish identisches testtopic ohne retain
mosquitto_pub -t /testtopic -m without_retain

# Abfrage der auf dem mqtt server gespeicherten retained messages zum testtopic
mosquitto_sub -t /testtopic -v --retained-only
/testtopic with_retain

-> Die Nachricht ist immer noch vorhanden!

Erst das explizite Löschen hilft wirklich weiter.

# Löschen der retained message durch ein "nichts" in der message - wieder mit retain flag!
mosquitto_pub -r -t /testtopic -m ""

# Abfrage der auf dem mqtt server gespeicherten retained messages zum testtopic
mosquitto_sub -t /testtopic -v --retained-only

-> Keine Nachricht mehr vorhanden!



Zitat von: Beta-User am 19 März 2025, 20:21:05Ansonsten: Denke nochmal intensiv über die retain-Nutzung nach.

Guter Rat, der aber wahrscheinlich nichts bringt, solange ein Anwender die grundlegenden Zusammenhänge noch nicht verstanden hat und offenbar auch nicht bereit ist, sich diese einfachen aber notwendigen Grundlagen anzueignen.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Beta-User

Zitat von: betateilchen am 19 März 2025, 21:27:26Erst das explizite Löschen hilft wirklich weiter.
Danke für die Klarstellung!

Mir war es ehrlich gesagt zu blöd, das im Detail nochmal zu recherchieren, nachdem der TE sich entsprechend geäußert hatte...

Weitere Klarstellung: Genausowenig habe ich nachgesehen, ob mosquitto in V2 jetzt bzgl. dieses Themas ein anderes Verhalten beim Neustart zeigt wie bei V1.5 oder ob sich die default-max-Anzahl für retained messages zwischenzeitlich geändert hat. Ist mir egal, für mich hat retain in unserem Umfeld schlicht (abgesehen von der Verwirrung mancher User) keinen Mehrwert, fertig die Laube.
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

betateilchen

Zitat von: Beta-User am 19 März 2025, 21:38:54oder ob sich die default-max-Anzahl für retained messages zwischenzeitlich geändert hat.

Vor V2 war der default Wert für max_queued_messages bei 100
Ab V2 ist der default Wert für max_queued_messages bei 1000

Aber auch in den älteren Versionen ist der Wert in der mosquitto.conf konfigurierbar.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!