Ich arbeite nach wie vor an meinem Zisternen-Messsystem. Es arbeitet bestens und zuverlässig. Inzwischen fiel mir aber etwas auf.
Hin und wieder wird mal eine MQTT Nachricht nicht gesendet oder vom MQTT Broker nicht verarbeitet. Solange das die zu sendenden Messwerte betrifft, ist das kein Problem. Dann wird halt mal ein Messwert-Datensatz nicht gespeichert. Es gibt trotzdem genügend Datensätze, die alle 2 Minuten erfasst und gespeichert werden.
Die Ursache liegt offensichtlich in der von Tasmota verwendeten MQTT Bibliothek "pubsub client". Darin ist die Quality of Service (QoS) nicht implementiert. Somit steht ausschließlich QoS 0 = fire and forget zur Verfügung. Eine diesbezüglich "bessere" Bibliothek könnte zukünftig zumindest in Tasmota32 verwendet/vorgesehen werden, da der ESP32 über relativ viel Speicher verfügt.
Ich suche nun aber nach einem Workaround zu einer Art Nachbildung der QoS 2, die eine sichere und einmalige Übertragung einer Nachricht gewährleisten soll. Dazu erscheint mir meine Rahmenbedingung durchaus geeignet:
Mein Messsystem erfasst die Unterschreitung eines benutzerdefiniertem Mindest-Wasservorrats. Daraufhin sendet es eine benutzerdefinierte MQTT Nachricht, die einen Wasserzulauf starten soll. Der Wasserzulauf wird von einem Shelly 1 mit Tasmota per Rules gesteuert. Das hier vermutlich nützliche und imho entscheidende Prinzip liegt darin, dass es genau einen zuständigen Empfänger, hier der Shelly 1, gibt. Entsprechendes ist zur Überschreitung eines Maximums implementiert.
Meine Idee zur Nachbildung einer QoS 2:
Der Sender, hier mein Messsystem, sendet eine retained Steuerungsnachricht. Der Empfänger, hier der Shelly 1, empfängt irgendwann diese Nachricht, wobei es sich bei irgendwann typischerweise um maximal wenige Sekunden später handelt. Da letztlich die Übertragung der Nachricht vom einzigen Adressaten empfangen wird, solange er funktioniert, kann dieser diesen Empfang durch eine Nachricht quittieren, dir zur Löschung der empfangenen Nachricht sorgt. Zu kompliziert? Ok, etwas einfacher:
Sender sendet Steuerungsnachricht retained -> MQTT Broker -> einziger Abonnent empfängt Nachricht -> Abonnent sendet Nachricht zum löschen der retained Nachricht
Nachdenk ... wie kann der Empfänger das Löschen der retained Nachricht erzwingen? Hm, per retained? Das habe ich noch nie nicht getestet.
Frage:
Hat jemand hier einschlägige Erfahrung mit einem solchen oder ähnlich gelagerten Workaround für QoS 2?
Anmerkung:
Für Steuerungen, die je Nachricht einmalig erfolgen sollen, sind retained Nachrichten zu unterlassen, da sich ansonsten ungewollte Phantom-Schaltvorgänge ereignen können.
Gegen dieses Prinzip verstößt meine obige Workround-Idee. Ich vermute aber, dass sie trotzdem wie gewünscht funktionieren kann, da die retained Nachricht nach deren Empfang gelöscht werden soll.
Irgendwie bleibt in mir der Verdacht haften, dass dieses Problem eine höhere Relevanz verdient.