I was referring to the MQTT solution. You don’t need developer skills for that. Those skills you need in turn for MQTT you are expected to learn, just like any user is expected to.
In your eyes only, that is. But probably any dev and advanced user like myself disagrees.
Please accept that and that noone will take on it - once and for all.
And I wouldn’t think I need to repeat that this is an Open Source project and any core dev and contributor is free to choose for himself what he thinks is right and most important to work on.
You must not urge and annoy anyone to build a thing they consider to be a bad idea. Let them do their job.
As I said, that’s just waste of time on everybody’s part so please stop raising this again and again.
To provide the technical framework it takes I think yes.
But that’s just a minor part. It takes much more to build and maintain a database of user-contributed code: spare time, willingness to review other’s contributions and dedication - else that ‘project’ will quickly run dry. And it’s more likely to happen with Python rather than Rules DSL.
This is what will NGRE do. I think this will greatly improve the usages of rules (and complexity) used by newbie users.
These might be great, but I also think this will be used by a minority of the users.
I consider myself a more of an advanced user and still I just use one instance / house.
However adding more instances to one account in myopenhab and be able to access them in one place might be a better first suggestion. And also might not be that hard to implement.
Also there are still other minor things in openHAB which could be a better suggestion and not that hard to implement.
Like existing Things should automatically show new channels in case an update added new channels to the binding rather than having to delete and recreate that Thing.
Or for example the startup of openHAB could be improved so that these unexpected errors would go away. This is a more trial thing as you can see this here on the forum. Almost every day someone has some problem which can be related to startup sequence…
It’s not a waste of everyones time, its just waste of your time so feel free to take your negative comments elsewhere. No one is forcing you to reply. The forum is littered with comments about users having zwave issues and looking for solutions. This is certainly one of them. Zwave has limitations, this can help solve them. Clearly if there was alot of debate about this, then alot of people see its usefulness. If no one wants to develop it fine, thats cool. its after all a suggestion.
FYI im using MQTT and Openhab linked just fine, it works well. But for a first timer, or someone who doesnt have years of experience with OH its complex and time consuming.
Multiple openHAB for this purpose is a circumvention, not a solution. A solution would lie within zwave itself e.g. repeaters, bridges.
Consider that a more generally useful “solution” could be the ability of a single openHAB instance to reliably use multiple remote zwave controllers.
The usage of MQTT linkage that seems to me to be most prevalent is linking two genuinely remote instances e.g. home/workplace , home/holiday home. If you need a use-case, build it around demand.
Definitely so. Or ser2net or any Z/IP gateway. @dastrix80 why do you call your post “Suggestions for openHAB” when actually you mean to ask for a potential solution to your or somebody elses zwave problem ? You’re making us victims to the XY problem here. That’s where you wasted all reader’s time, not just mine.
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.
Markus, I don’t have a zwave problem, the suggestion was in response to recent threads by OTHERS who have problems. Both in response to repeaters and ser2net where many OTHER users have had issues. Read that again Markus. Its not a circumvention at all. Construction these days sometimes renders Zwave less than reliable, maybe your forced to put your controller in a basement yet your home is above? there are so many use cases its not funny. Otherwise ser2net wouldnt even exist!
@Rich, sounds great - looking forward to making it simpler. I havent looked at MQTT 2.5 Event bus because 1.x works for me
Not to get too frustrated, but you asked for a simpler implementation of the MQTT event bus without actually looking at the latest version of the event bus implementation which, in my opinion, is already significantly simpler than the MQTT 1.x event bus and gives you more control as well. In general it’s very frustrating when users ask for things to be implemented which are already being implemented or have been implemented for a long time or even worse, complain about these things. That’s another reason why issues on github are better than threads on the forum. The developers know better than we do what is being worked.
Yes great suggestion, and a place to first develop the idea among others with the same need before creating a bounty. Sadly this forum can not be a new idea friendly place so turning a wish into a solid working proposal can be hard.
Disagree, lets not tie up a dev explaining to a noob why the idea is not practical, better to do that here on the forum. A bug report on GitHub for sure, a well thought out proposal for new feature on GitHub yes, but developing a loose idea into a proposal by someone that does not understand the changes needed to the code is IMHO better done here on the forum.
Very good point. Hopefully after V3 comes out the V1 binding then get moved across as the need then goes up.
I also disagree, MQTT 2.5 is much more robust than MQTT 1.x
It is really different from MQTT 1.x so without looking into it more, it looks complicated compared to the 1.x, but it is not. And it is much more stable and maintained.
Maybe you should just read his post as a suggestion to a debat on the matter. This is a commity place, where debates about new features or even suggestion is totally on topic.
I see no reason why the community can not debate on a new idea, before is goes to request.
Exactly!!!
Just to add my opinion…
I´m with dastrix80.
Some of you are speaking about there is no need and doubt who will ever use it.
First of all - If the option is not there, noone is ever gona use it. You need to see it the other way around. If the option is there, users may start to see a reason for using it.
If/when there is a possibilty, like using MQTT, those with high experience in MQTT and rules, may be using it. The rest will not even try as it would not be worth the effort.
Second, I see at least one very obvious reason in a situation where you have wired USB/serial devices in different places of you house you wish to add to the system. This is where a master/slave connection really come in hand.
Its a valid suggestion from OP, for at least discussing, if this is something to become (requested) or to abandon.
Well given my own activity on the forum I fail to see there’s a relevant number of people to have zwave problems to be related to this that could not be resolved the right way ‘inside’ ZWave such as with repeaters. Granted I don’t read every post but I haven’t seen a single case recently.
I think it is less to the benefit of others but rather because you have been pregnant with that idea ever since and would like to have this feature (see @rossko57’s “summary” of your contributions on that topic).
Everyone his pet, I don’t mind. But keep yours in your house, please.
And jumping from (rare) individuals’ zwave problems on to request a openHAB master/slave architecture just to solve these however is a HUGE and unneeded step to cost I’d guess hundreds if not thousands of dev work hours and puts the whole system at risk hence that’s where I oppose.
But even if I was to ignore the impact on the dev side, it’s the wrong solution approach. RF issues must be solved on the transport layer, there are existing solutions (repeaters, ser2net) and workarounds (MQTT).
That the openHAB master/slave idea is @dastrix80’s pet and that he is free to consider that to be a good idea.
But that he is to please stop spreading the word as it has now become more than obvious that anyone he addresses disagrees.
I’m sure there are many many many more. All use cases for linking multiple zwave networks together or extending range or overcoming range issues etc etc etc.
I do not agree on this.
Some dont see the advantage of this, but others do. There are even people in here who is using the MQTT bus already. So there is infact a need, though it may be limited…
As I previously wrote… When the option isn´t there, no one will use it, and maybe even not notice any need or advantage of a option like this. Thats not the same as saying, there is no need.
Its a bit ackward to state it like you do. I understand and partly agree where you´re getting at when looking at dastrix80´s individual situation (solve wireless issue). But I believe you seem to much focused on his specific situation. At least try to see it from a general aspect and purpose.
I´d mention another situation where it may come in hand.
If it´s worth the effort, I dont know. I have no idea how hard it would be to develope.
One of the biggest issues with ser2net, which the Event bus situation solves is the lack of signalling between ser2net and the Zwave binding (or any other system). What can occur and occured frequently for me and others, is that if ser2net looses connection and it does, the ZWave binding does not know about it.
That causes all sorts of ZWave issues and the Zwave network then breaks. You must restart it all , manually, or automatically if you’re extremely advanced and can script it.
The advantage of the event bus is very simple. Two discrete networks, operating independently, no bindings to restart. Should one of the master/slaves fail, they restart themselves and come back up, leaving the rest of the network to function (ie the other node that hasn’t failed).
But we don’t know what is being worked on. Many/most of the developers don’t spend much time at all here on the forum to tell us. Threads like these become huge arguments made largely out of ignorance about with is actually actively being worked. And since no developers are involved, even if there was a consensus nothing would come of it. The developers won’t see it, won’t act on it, and already apparently don’t see the need for it.
Looking at it from the other side, what good does the argument serve? If one person proposes something and 99 people say “that’s a bad idea” there is nothing stopping that one person from proposing it as an issue or actually working on it and submitting a PR. So what good is the argument here on the forum?
Then please suggest changes to make it simpler. “It sucks” doesn’t help. “If you added X or changed how Y works” is something actionable that I can do something with. Please post suggestions on the MQTT 2.5 Eventbus thread.
But don’t confuse familiarity with easy. The 1.x event bus configuration is simpler for you because you’ve already set it up and know how it works. I spent a couple weeks trying to figure it out so I could duplicate the features in 2.5.
As far as I can tell, the only part about the 2.5 version is that I provided thorough documentation explaining how it works which was missing from the 1.x version. And since the 1.x binding will not work on OH 3, it’s important to get this feature working with 2.5.
To use the 2.5 binding:
copy the rules to both OH instances
add the Items you want to publish to the Publish Group on both instances
configure the subscription channel
create the proxy Items to represent the remote Items
Done.
Debates are fine but without the involvement of a developer who is actually going to work on it it’s pointless. Everyone gets all worked up and it never goes anywhere. It just becomes one group of people saying “I can’t believe OH doesn’t do X” and another group of people who say “OH shouldn’t do X” and 100 posts later there’s a bunch of angry people with no resolution and X is no closer to being implemented than it was before the thread was created.
But the option is there. Kris just doesn’t like it. Perhaps you don’t like it. But unless and until a developer steps up to do something about it you are stuck with it. Threads like this do not get us any closer to finding such a developer.
