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
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...
d.H. die Nachrichten müssen mit :r versendet werden, und dann sollte es gehen?
KEIN retain (jedenfalls nicht für diesen Datenpunkt aus Hass heraus)...
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"
Weiß dein MQTT-Server das auch schon....?
Das muss man aktiv widerrufen bzw. überschreiben.
Das ist eine gute Frage. Der MQTT-Server läuft auch auf dem HA. Wie kann ich das prüfen auf FHEM-Seite?
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.
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');
}
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.
Zitat von: Jamo am 18 März 2025, 22:29:54ZitatHat 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.
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...
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.
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.
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.