Just throwing additional info out there for other viewers (not rich - I say that because you said “I know what QOS is” above, but I wasnt directing that to you, apologies). BTW MQTT retained messages wont work for my case - my use-case is knowing exactly when a door opens and closes, NOT what state its in (which one might find useful for a light on, or off or whatever).
This differentiates MQTT Retained Messages (last known good state) vs Persistent Session: https://www.hivemq.com/blog/mqtt-essentials-part-8-retained-messages/
This is about an MQTT Persistent session: https://www.hivemq.com/blog/mqtt-essentials-part-7-persistent-session-queuing-messages/, which I’m crystal clear about, but cannot find a setting to enable it using the MQTT Broker & MQTT Thing “method”.
I’ll have to re-read this whole thread tho because I was writing to this while on a plane
I do get what you mean about “if a network is unplugged” there is no technology in the world that will allow the communication to continue, that’s obviously true. But QOS2 should allow it to resume and not lose messages, if setup correctly…I’m not sure if my example and testing was clear but I’ll try again… I have a remote & a “main” openhab instance. The remote instance has an erratic connection. QOS2 with a persistent connection is required for that feature to work https://www.hivemq.com/blog/mqtt-essentials-part-6-mqtt-quality-of-service-levels/ , but this reveals the setting I’m looking for may actually be called something else https://www.hivemq.com/blog/mqtt-essentials-part-7-persistent-session-queuing-messages/ clean-session-flag=false, to enable a persistent connection. (For those that don’t know, a persistent connection is required for QOS1/2 because if its NOT a persistent connection then you start “clean” with every reconnect - so there’s no way to check what messages you received and didn’t, if you started clean!)
So here’s what my tested revealed: a crappy network connection will safely deliver all messages with QOS2 and a persistent connection upon the network reconnecting! This is great news because it’s exactly what I require - imagine, then network disconnects, someone enters the house and triggers the door sensor, then the network reconnects - well, I’ll never get the door alert with a typical MQTT setup, but with QOS2 Im guaranteed to get the alert once the network resumes connection (this assumes everything is setup correctly and all publishers and subscribers have QOS2 enabled). – When I deliberately then set this up with QOS0 & tested, during the network outage I’d miss all alerts! (As expected, but definitely not the setup I’m seeking.) Hope that makes sense on why I’m focused on this very specific feature. It is awesome though btw.
So anyways, I’m going to reread this a few more times, and probably test out Richs implementation/method, and see if I can get it to work with QOS2 (across the line obviously-all nodes in the path) because I need this to work with a crappy network, as I mentioned. I’m also interested because Rich indicates Event bus is the way to go, and probably the only thing supported going forward. So yea, Id be foolish to continue down my existing path. (Thanks for the heads up ) I clearly missed that when I tested the other bindings (guess its not obvious to me what’s a 1.x binding, and what’s going to be deprecated).
Quick question: in a very simple 1 liner or example, how do you input an event time, instead of the system doing it for you?