Accepted proof of QOS2 working, would be to still get a message, for an event that took place while the node (remote openhab in my case) was offline, once it went back online. Simply getting a message proves MQTT publishing & subscribing works, but can it still work with a flaky network.
Test 1: Here’s how Ive been proving QOS0 works: System “setup” (keeping it vague), event triggered on remote openhab instance, event received on my main openhab instance. Piece of cake.
Test 2: QOS2 with crappy/unreliable network: First test the system works via QOS0. Then change all “nodes” along the way to QOS2 (publisher, subscriber, openhab…). Then unplug the remote openhabs network cable. Then trigger an event on the remote openhab. Wait 10 minutes. Then plug it back in. If QOS2 is successfully setup, you will recieve the event on the main openhab instance. If its only setup for QOS0, then youll never get it because it did its job: fire and forget. So, I did get this to work great with “MQTT Persistent Service”, but since youre telling me thats going away I need a new solution. I’m going to try your solution (event bus), and also test that I can get QOS2, and I will report back.
I’m going to be perfectly clear: most people wont give a crap or have the need to do what I’m trying to do So for that reason I won’t take it personally if you dont respond! ha
My use case and why I REQUIRE QOS2: I’m guaranteed the delivery of the message. Think the security context. Again, I have temperature sensors that report every 5 minutes that I dont care about. I can miss every other message and I wont care. But my door sensor I need to know exactly when it was opened, and what time it closed.
You are probably 100% correct that openhab is event based and MOST people will never have a need for what I’m trying to do. End-goal: I’d like some kind of dashboard (either openhab or grafana pointing to my influx data on openhab), with all the “regular” use cases (most of this is working great now), but ALSO, a way to drill into my remote openhab instances and look at all the door activity: maybe a grafana table that shows all the “activity”; the times the door opened and closed. I hope that use-case makes sense so I don’t sound like Im nuts
Regarding the whole state thing, and if you get a flood of MQTT messages all at once, out of order, once the network connection resumes - youre 100% correct… that’s why I was wondering about trying to add the “event time”, along with the event. (Typically, or in all cases, openhab says, oh, event happened? Cool. Ill add that to my “log”, along with the current time. It happens auto-magically. So I get it, again, my use-case, and idea aren’t something people commonly do.) The end result would be a dashboard (like normal people), and the ability to drill in and get the reporting for the door: Im positive Ill run into some more issues, specifically like the ones you mentioned - but I also hope Ill figure them all out.
Ie, if I have “normal” openhab events along with its auto-populated event times, that go into my influx db, I’m good. The reporting (say grafana) runs a query, generates the graph or whatever, all is great. In addition to that, I use MQTT to pass along remote openhab events, along with MY manually/programatically generated timestamps, they end up in the influx db as well. Then grafana runs a query (doesnt care where the event timestamp came from: auto vs manual), draws a chart, all is good. It also generates the activity reports.
Regarding the retention feature of MQTT: that won’t make my “door activity” reporting 100% accurate, and I already know I have an unreliable connection between the publisher and the broker, so yea, sucks for me And obviously retention is perfect for last know state…but not all the previous opens and closes that happened when it was offline.
I used to use Wink. I have one at each house (remote location), theyd all tie into my Wink account/cloud. Wink works, mostly. It has ZERO customization. Then I found out about this. Besides the lack of customization, a major issue with the Wink hubs/bridges in these crappy network areas are I’d miss many events when a door would open, and the network had a blip - so I’m trying this system to fix that issue. (I use Tmobile hotspots for the Wink to connect to the “Internet”, and into the Wink cloud from there so I’m just asking for trouble - as opposed to a hard wired internet connection. But I pay $5/month for these hotspots. These remote locations move often to different houses so I can’t setup a permanent connection - its construction and I’m temporarily monitoring that the heat is still working in the winter so pipes dont freeze and no one breaks in, or when workers come and go, which is why I MUST get the door alerts.)
Anyways, hope that answers some questions. I certainly have some homework to do.
- How does one know if a binding or add-on is a ver1 binding, and will soon be deprecated? Is that the orange “v1” tag, like here: https://www.openhab.org/addons/persistence/mqtt/ ?
- Given my “odd” use-case, without wasting your time with an answer, do you (or anyone else) know if it will even be possible to pass a timestamp with my event? (So even if I get a flood of events, likely out of order, I’ll apply the timestamp to “true-up” the data & events)
- Am I going down the wrong path?! If my use-case makes sense, should I be using something else? (I’m still using openhab in my house for “regular” things, and it works perfect and is awesome. Its just the remote instances I’m trying to get “just-right”) (Any of this relevant? https://www.openhab.org/addons/bindings/mqtt.homeassistant/ or https://www.openhab.org/addons/bindings/mqtt.homie/ )
- With your Event Bus method: Do you happen to know for sure, with a 10min network outage, will the event still get sent once the network connection resumes? (If not, no biggie, Ill test & let the group know)