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.
1 Like
Disagree, I think 1.x binding with MQTT is significantly simpler than 2.5 with its rules etc.
1 Like
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.
2 Likes
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).
What is that suppose to mean?
I agree RF issues should be solved elsewhere. But the suggestion and the idea is still valid.
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.
rolls eyes Whatever Markus
Here we go:
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.
1 Like
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.
2 Likes
Just about everyone in the ser2net thread (Share Z-wave dongle over IP (USB over IP using ser2net / socat ) guide) would have a use case for it as well.
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.
1 Like
Ok but so what? They’re not newbies if they “need” that.
They can use ser2net, a Z/IP gateway or another tunneling technique.
They can be expected to be able to create a solution based on the MQTT event bus, too.
And if they’re not it’s a matter of education and docs. That can and should be handled on the forum.
So still no need to bug devs with master/slave there either.
I wouldnt say its pointless. Ofcouse at some point someone need to involve another one who can actually get the job done. But debate can be usefull to things like, getting ideas, discovering needs/nice features/different/whatever… ways of doing things…
Atm it doesn´t go anywhere, because dastrix80 is not allowed to make his suggestion.
If I knew MQTT and rules better, I would probably like it. I have looked at it a few times, and I stil believe its a hard work to get it up running. I dont know if I ever mange to get it to work. But even if I do, I would still highly appreciate if there could be an easier way.
When I read dastrix80´s suggetion, I read he suggest an easier solution which suits all and not just those with highl MQTT and rule knowledge… I see no reason to try stop such a suggestion, just because there already is a “harder” way doing it, or if I´d fancy the MQTT solution.
A small example of what it maybe could have become:
I have a few Velbus devices. The Velbus data bus is connected to my openhab system on my Odroid C2 through the Velbus USB interface. On the Odroid there is a Velbus server running, its a small script which behave as a server and gateway between the USB data bus and the server. All I need to do in the Velbus openhab binding, is to add the IP adresse of the Velbus server, and then it will find my devices through a USB data bus.
On my other openhab systems, all I had to do was to install the Velbus binding, point it to the IP of my Odroid running the Velbus server, and the psysically same Vebus devices are now added to two openhab systems at the same time…
The Windows software to program the Velbus devices, (Velbus Link) is using the Velbus server as well to connect to the Velbus devices. Again, all I had to to was to tell Velbus Link which IP of my Velbus server. Now I have 3 systems communicating with the very same Velbus devices, through the Velbus server running on my Odroid. (I´m sure you get the picture).
I´m not saying the same thing is easily done with openhab. But if something simular could be done, it would be much easier to comprehend and setting up for most, (even for the knowledgde users) rather than the suggested MQTT solution, which in my opinion, is for highly advanced users.
But we never get there, because we´re (as usual) discussing personal needs, and the fact that there already is an option, though, probably most, including me, find it highly difficult to setup.
Thats what killing suggestions like dastrix80´s.
3 Likes
“I’m using a bad product. I have found a complicated circumvention using a dissimilar 2nd product. I want someone to make that 2nd product easier for me to use in order to avoid the 1st product.”
The obvious response is - why not pressure the 1st product for improvements? Or is that happening as well?
If ser2net is crap, can it be handled better? It doesn’t really matter if it does hiccup occasionally, if it is recoverable promptly. Is there something to improve in zwave binding? Or more likely, in openHAB serial handling?
Oddly enough I was reading (but not understanding) github activity about serial for OH3 last night. Should you be poking that to highlight ser2net problems?
1 Like
No, what kills suggestions like dastrix80’s is that he’s started a thread on the forum asking for X. All sorts of users have come out of the woodwork to discuss X. Where is the developer who’s going to implement X? I don’t see one here. Whose going to build it? No one on this thread is going to. So even if we all thought the suggestion was the greatest thing since sliced bread, no arguments, nothing would come of it.
There is absolutely positively nothing stopping someone from implementing this feature if they think they can do better. If its something that anyone really wants, go find a developer or become a developer and make it happen. Who cares what the rest of those on this thread think. Code speaks louder than forum posts.
1 Like
Gorgeous day here in Sydney, time for a nice coffee. Thanks all!
3 Likes
Not entirely true 
What is true though - I’m not speaking on behalf of all developers here, just expressing a personal opinion - while getting the pulse of the community is important to know we’re headed in the right direction, at the end of the day, everyone here invests their time for a reason: it could be the intellectual satisfaction of having built something cool, solving one’s own problem, sometimes it’s another ulterior motive (however financial bounties or flattering one’s ego are rather marginal here I think), or yes, at times, it can be pure altruism - I have poured hours into implementing features I don’t even use just because I thought they were important to have (and the pleasure of seeing others using them and building things with them, so okay, there’s a “ego” factor).
However, relying on altruism alone to get things done for you is only going to get you so far; while everyone can make a feature request - or rather “suggestion”, a “request” implies an expectation, openHAB being a volunteer-run project rather than a product, there are no expectations to be had -, even if it’s the best idea in the world, it translates to someone having to do the grunt work. Sure, if you haven’t been convincing enough, it means that sometimes it will be denied or lost in the cesspool of good ideas never implemented, but it would be quite dishonest to then blame developers like “I, your user, am disappointed, and it’s on your conscience now” - and it won’t keep them from sleeping at night, to be honest.
There are maybe a dozen of active developers and maintainers regularly working on the code, at most, and you can trust on the professionalism of all of them not to leave you with something unusable… and we are users too, we’re not in our ivory tower. In general we choose to focus our energy to getting the work done, rather than participating in debates like this, and it’s natural that we have the final say on what we’d like to devote our spare time to.
10 Likes
Right on Yannick!!!
Pitch in folks!!! don’t just complain!
What part of
do you not understand?