You mean like Marketplace MQTT Event Bus
See How to get started (there is no step-by-step tutorial)
I can’t answer why you spent hours to get Zwave working. The binding doc states:
The binding uses a standard Z-Wave serial stick to communicate with the Z-Wave devices. There are many sticks available, and they all support the same interface so the binding does not distinguish between them.
If the Controller bears the Zwave logo it will work. If you have suggestions to make that more clear please suggest some edits. There is a link at the bottom of the file that will take you straight to the GitHub page where you can suggest edits to make it more clear.
Because it isn’t. It should run on anything from an RPi 2 B though an RPi 4. Only a minority of OH users running on RPis are using RPi 4s.
See the links above.
This is indeed a very nitch configuration. Depending on the desired use case there may be several alternative approaches that would work better.
Errors? There might be a bug that needs to be fixed. Without out more details we can’t diagnose let alone fix it. It is supposed to work and it has worked in the very recent past.
But from what you’ve described you are going to have to expose something to the internet. You may not care about security but I guarantee the hack bots and script kiddies will love the fact that you don’t have any.
Except it’s not. What you describe is actually pretty complex. And even with all the details you’ve provided you’ve no where near provided enough information to actually “provide a guide.” That’s the problem here. There are a gazillion options, many of which do very similar or the same things but in ways that are more or less suitable to a given set of requirements.
Let’s take your “track this historically” with charts. Are you concerned about the size of the database? What sort of Item is the sensor represented as? What kind of chart? How much ability do you want to customize the appearance of the chart? The answer to any one of these questions will result in a completely different end-to-end guide. And that’s just for generating a chart.
Home automation is hard. It is a development exercise. And every one’s system is bespoke. I would write an end to end complete guide for how to set up my home automation system, and there is an audience of one person in the world who can/should follow it set by step. My requirements are different and therefore my system is different.
So what we have are what you call partial guides. Guides that tell you have to do one thing, and are very detailed about that one thing. But it’s up to you to piece together the guides to reach your end goal.
If you were to write end-to-end guides for all the possible combinations of openHAB configurations just counting addons, you would have 350! (350 factorial) guides. I’m guessing that would be more guides than there are written documentes currently in existence.
As for your specific desires, a good deal of it is outside the scope of openHAB as well. For example, what MQTT broker you use and how you secure the communication between the MQTT broker and your openHAB instances is largely outside the scope of openHAB. You have lots of options though:
- OpenVPN between all your instances, self hosted MQTT broker (see OpenVPN for details)
- Use a cloud based MQTT broker such as CloudMQTT (here’s a tutorial for that, though I don’t know what if anything different needs to be done for MQTT 2.5)
- Expose a self hosted MQTT broker to the Internet (see your Broker’s vendor’s web site for details)
I do not recommend the last option.
Once you have the communication set up, than you can follow any one of the many postings to set up MQTT. Then you can use the link at the top of this post to set up the Event Bus.
NOTE: openHABian is just a bunch of scripts. It will autoupdate itself to the latest the first time you run openhabian-config.
Cloud Connector will not do anything for you for MQTT. It only proxies the openHAB REST API. All three instances of your OH need to be able to see and connect to the same MQTT broker.
It requires some sort of persistence. Which one you want to use depends on your requirements. Want to ensure the DB nevers grows beyond a certain size? rrd4j is a good choice, though it decimates the data as it ages. If you want lots of control over the charts MySql/MariaDB/InfluxDB with Grafana are popular choices. See InfluxDB+Grafana persistence and graphing.
Lots of options here too. myopenhab.org with the Cloud Connector addon can do this. Telegram, PushBullet, and several others are also supported.