This is already available for Scripted Automation and I expect what we have now or something better will be available in OH 3. There likely will never be such a library or system for Rules DSL. The language simply does not support it now and it’s unlikely to be modified to support it in the future.
I welcome any improvements to Marketplace MQTT Event Bus. When using scripted automation, all that is required is importing the library and adding your Items to the right Groups. I’ve plans to convert this to a Rule Template but am waiting for OH 3’s new UI first before I spend time on that.
The problem is it’s not so simple to set up because the only way to avoid infinite loops requires details about the system that only the user knows ahead of time. Therefore some assumptions simply cannot be built into the bus and must be left to the user to configure. I’m not saying that the 30 or so lines of Rules DSL code above makes it as simple as it could be, but based on my experience building those Rules and the Python library equivalent, it’s never going to be as simple as providing a url for the “slave” OH instance and it’s done.
Obviously, someone can convert the Rule I wrote into a binding, or as an addition to the MQTT binding, but at the end of the day, the user will still have to identify which Items to share and how to share them and be careful not to create infinite loops. That’s where the complexity lies and that’s the part that can’t be avoided.
@dastrix80 actually has a valid use case. But I do take your point, it’s probably not something a “newbe” should be worrying about. I’d have it as an advanced topic.
I see two problems with this.
-
It forces users to be reliant on a cloud service for this feature, even when both instances are on the same network. That would not be a satisfactory approach for many users.
-
The whole reason that IFTTT integration was shut down is because too many users were sharing all their Items with the Cloud Service. I’m very hesitant to introduce something that would exacerbate the problem.
It does have the advantage of making it easier to integrate two instances that are on different networks without setting up a VPN or the like though. Maybe there would be a way to do it more efficiently than it’s currently done.
But we are still left with the problem that user is going to have to be knowledgeable and careful in how they expose what Items to avoid infinite loops. And that’s the root of the complexity.
One flaw with this argument though is that one of the justifications for the removal of support for 1.x bindings in OH 3 is the ability to federate an OH 1.x or OH 2.x instance with OH 3 and have the users run their OH 1.x bindings on those older instances of OH. So there is coming down the line a use case for even newbie users to be able to as simple as possible federate two instances of OH. The strength of that need will depend on how many 1.x bindings don’t get ported to 2.x before OH 3 comes out. I’m happy to see the list of such bindings dwindling but there will still be some I’m sure. So the need will be there at some point. My main problem is that I don’t see how what I’ve done in the rules linked to above can be made any simpler for users.
It’s actually already in there. But to create a template you have to basically write the JSON yourself and to import the template you need to use the REST API. Once the template is imported though, you can easily create a Rule from the Template. I think there was some work to publish Rule Templates on the IoT Marketplace but I think the marketplace is going away in OH 3 since it’s an Eclipse service. I’m not sure how they will be managed in OH 3.
As for stuff like Python libraries, I’ve seen mention that the community library contributions to the Helper Libraries might become bundled up as a separately installable binding.
For better and for worse, it doesn’t matter what is in your eyes or in my eyes. Our opinions about what is basic functionality doesn’t matter. All that matters is what someone who is a developer is willing to work on. And the developers will volunteer to work on only those features they see as basic functionality. If we disagree, we can ask for it, which is probably best done as a feature request issue on the correct GitHub repo, or find or become a developer and work on it ourselves.
That would solve one type of use case. But based on past posts from OP and on my own setups, there is a very real need sometimes to run multiple OH instances that providing support in myopenhab.org won’t address. In OP’s case, his main OH instance is physically located in a bad place to put the zwave controller and socat/ser2net was too unreliable. In my case I have an OH instance that is 100 miles away that is largely autonomous but which has some sensors that feed into my main OH instance to drive automations here.
At the end of the day, posts like this on the forum are not very productive. If you want a feature added to OH, you need to file an issue and cross your fingers someone decides to work on it. If you really want a feature added to OH, you need to find or become a developer and submit a PR that implements it.