Well, as I trust I’ve shown here, you can’t get there from here. openHAB can not and without massive changes to the core and overall architecture will never be able to handle this use case.
Your best approach is to record everything locally and when connectivity is restored sync the databases or configure your Grafana instance to query the remote instance database. You can report the time that the door entered it’s current state in a separate Item and you can publish that Item to your event bus too and show it on your sitemap. That gets your display. But even if you have a persistent connection you will never be able to tell OH that “this event actually occurred 10 minutes ago.” Only the remote OH will know that.
And that’s the part you can’t have. It can’t be done with OH as it exists.
What you can have an InfluxDB local to each OH instance and record everything locally when they occur. Then you can sync the databases or point your Grafana at both databases. But you cannot maintain the date time with the events across the two instances. You have to manage that outside of OH.
I still think this is an XY Problem. You are trying to solve the problem in a way that doesn’t actually solve your problem and is suboptimal. You need to look outside of OH to solve this.
But that isn’t to say that OH could not support that clear-session flag. But you need to file an issue to get that supported.
Lots of ways. That’s probably the easiest. Also, if you look at the URL the name of the add-on will often end in a 1. You can run a bundle:list in the Karaf console and the version will be 1.xx.
But keep in mind, that URL is to a Persistence add-on, not a Binding. There are six types of add-ons and the best way to tell depends on which type you are looking at.
No, not in a way that would be meaningful to OH. Your best bet is to record everything locally, publish the most recent event and the time using the event bus with the retained flag, and configure your Grafana to use both instances of InfluxDB or synchronizing the two instances of InfluxDB when connectivity is restored.
I think yes. MQTT is not going to solve this for you, at least not given how OH works.
Those two links are not relevant. They are cases of two MQTT topic standards (i.e. a standard in a way to use MQTT) that allows OH to automatically discover devices and create Things for you. They will do nothing for your use case.
I’ve never tested an outage for that long. Outages for a few dozen seconds work. And I can see the connection retries.
If it doesn’t work, I can add code that when the connection to the broker is restored it blasts out the current state of all the Items. That would be easy to implement.
But OH doesn’t.
It can do anything you code it to do. It’s all right there. You can add the date time to the one message which would just be adding now.toString to the publishMQTT calls. Or you can do it without changing code by using a separate DateTime Item. When the door opens on the remote instance, use a timestamp-update profile or a Rule to populate the corresponding DateTime Item. Then the Event Bus will publish it like any other configured Item.
But… the local instance of OH will still treat the events as if they occurred when the message was received. So your InfluxDB will never be correct. You will need to handle that outside of OH.
The MQTT does, or can be made to accurately cause the two OH instances to accurately reflect the current state of all the synced Items. It cannot be used to accurately reflect the past states of the two instances.
PaperUI is only intended for use as an administration tool. It is also being wholly replaced. For actual monitoring and use of your home automation you need to create a Sitemap or HAPPanel or play around with HABot. You have full customization control over these UIs.
That’s not unusual. Items are where you model your home automation. This is where you give zwave:saldkfjslkdf:node12:switch meaning (e.g. FrontroomLamp).
Since you have a SW background, I strongly recommend not getting started with Rules DSL. Use Scripted Automation instead and code Rules in Python. This gives you other options as well. For example, you can store and access data on Items using Item Metadata. This can eliminate a bunch of Items whose sole purpose is configuration information (e.g. During the day set this light to 50%, but at night set it to 75% which can be encoded as Item metadata on that Item or represented as two additional Items).
See [beta testers wanted!] Jython addon w/ helper libraries (requires OH 2.5.x) to get started.
Also, if you do use Scripted Automation, you can just clone the branch of the helper library where my PR is (see OP), copy the eventbus stull over to your $OH_CONF/automation folder and add two variables to configuration.py and you have the event bus. And Scott is working furiously to make that sequence of steps much simpler in the future.
And I look forward to the results of your test re QOS2 and a 10 minute loss of connectivity to the broker. If it doesn’t work, I’ll add the code to blast out the current state of everything when the broker connection is restored. But I’ll probably only add it to the Python code.