Erneutes Publishen von MQTT-Werten nach einem HomeAssistant-Disconnect

Begonnen von ronzo, 07 März 2025, 14:57:41

Vorheriges Thema - Nächstes Thema

ronzo

Ich würde gerne anstatt überall bei den mqttPublish attrs ein Retain:1 anzuhängen einen anderen weg verfolgen um publizierte Werte nach einem Disconnect von HomeAssistant nochmal von FHEM schicken zu lassen. Wie könnte ich das lösen?

Die KI schlägt folgendes vor:
define mqttStatusNotify dummy
attr mqttStatusNotify mqttSubscribe homeassistant/status
attr mqttStatusNotify eventMap online:call { my @devices = devspec2array(".*"); foreach my $dev (@devices) { my $mqttTopic = AttrVal($dev, "mqttPublish", ""); if ($mqttTopic) { my $state = ReadingsVal($dev, "state", "unknown"); fhem("publish $mqttTopic $state retain:1"); } } }

Bei Schritt 3 dachte ich mir allerdings, dass es eine gute Idee wäre hier nochmal im Forum die echte Intelligenz zu fragen. Mein FHEM-Container ist mir nämlich bei Schritt 3 gleich mal abgeschmiert...

Beta-User

Zitat von: Beta-User am 19 März 2025, 15:10:24Nachdem das ein "Dauerbrenner" ist mit der Frage, wie man den Zustand _sinnvoll_ via MQTT "persistent" machen kann ([...]):

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: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors