So in short, you don’t like openHAB so you want to use the community.openhab.org forum, a forum intended to help users of openHAB, to help you create something completely new that will compete with openHAB.
You don’t want to use openHAB’s communication bus. You don’t want to use openHAB’s rules engine, and you don’t want to use openHAB’s bindings. There isn’t much else left.
You will probably have better luck getting advice from some other forum. Something more generic. I do not think you will find much advice in this forum.
But I also see some misunderstandings about openHAB.
-
I’m not sure moving the bindings to a separate service or script that publishes to MQTT buys you much. There will still be errors and crashing if not configured correctly whether or not it is running in openHAB. Also, in my pretty extensive experience, I can say that when an openHAB binding crashes, only that binding crashes. The rest of the addons work just fine.
-
That isn’t how openHAB versioning works. The addons have the same versions as the core of openHAB. For example, if you are running 1.7.1, the latest stable version of openHAB, all of the addons should also be version 1.7.1. A new version is only released after the core and all of the addons have been tested to ensure they work together. So you would never have a situation where you would be using a 2.1 z-wave binding with openHAB 1.8. Also it is important to realize that openHAB 2 is a complete rewrite of openHAB’s core and bindings so any binding that is a 2.x version will not work with 1.x anyway.
-
In my experience publishing everything over MQTT is only going to make the real-time performance even worse. And I’ve yet to see or hear about a home automation use case where a third of a second actually makes any sort of real difference when using cron. When using triggers from other items on openHAB’s event bus, on my machines, I’m seeing delays in the 50-100 msec as the longest delays, around 20 msec on average. But my MQTT messages can take 200-500 msec from publishing by the publisher until the subscribers receive it.
There is a graphical rule designer as part of HABmin. It uses Scratch its basis.
If you don’t like programming in Xtend then you can use the JSR223 Engine and write your rules in Python or Javascript. You don’t need a separate engine from communication or from oepnHAB to write in a different and more standard programming language.
I agree, debugging is a challenge and it is one of the major focuses of OH 2.
- Running the different parts on the system doesn’t give you redundancy. That gives you load balancing. If you want redundancy you need to run more than one instance of each part of your system which really isn’t feasible for all types of technologies (e.g. there is no way to have a secondary z-wave controller that you can fall back to if the primary one fails).