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.
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.
“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?
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.
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.
I totally agree AND would like to add don’t assume or take a suggestion or wish to discuss something as a complaint or an attack. I am saying to all and not aiming it at you or anyone else.
A) don’t attack the devs or anyone willing to help out.
B) don’t attack a passionate user that loves openhab for trying to understand and suggest ideas.
I would like both to happen and sorry I won’t get drawn into arguments, I have better things to do.
Yes, as I said, at some point he (someone) would need to involve those who are going to do the job (file an request).
But its still a suggestion here on the forum, where we can debate for/against/changes of the suggestion itself. There is simply no need to attack him for doing this.
If you dont like his suggestion, you´re free to not participate in the debate, or argue for whatever reason you may have for beeing against.
But by telling him there already is an option, which you know he dont like, cause he is suggesting something he believe is better. (He´d actually mention the MQTT option). That´s not really doing any good.
Right now, I see a few people who rather wants to avoid (sabotage) the debate, twisting its contents to suit something I really cant get my head on to, why, except their personal needs.
If you dont like the suggestion, thats totally fine. But if you do, maybe you should back up the suggestion, maybe even help gettting the real request filed as clear as possible to be better accepted by the developers. Insted of these pointless discussions about, how OP present his suggestion, your personal needs, and whats already possible. That doesnt change anything, except killing the debate. And the idea will probably never reach the developers, cause its killed with the attitude he´s meeting from some people here on the forum.
Thats very sad when the idea is a great idea! (which it is in my opinion wether or not I´m ever going to use it. Which is why I´m taking part, backing up dastrix80).
But debating a idea/suggestion could be usefull for OP and the rest of us, before actually making the final request.
Again, try not to focus on how he present it and your personal needs, but insted focus on the idea itself from an over-all point of view.
It seems to me, you rather prefere each and every individual user filing requests all by themselves not involving any part of the community on their ideas?
Sometimes people just want to debate the idea first, before going through to the actual request, even though they may present the idea as a suggestion.
I´m pretty sure, if we all stood together in a specific matter, a suggestion would probably be reached more positive, (more seriuos) by the developers when filing the final request, rather than one individual personal requests. Thats where the commnuity (forum) come in hand, and can become very powerfull and benefit openhab! You should not try ruin or ignore that part.
All this is not only pointed at you Rich… Its an request to those who´s acting up each an every time someone mention an idea/suggestion.
What you tend to read as complaints, I read as suggestions, ideas, whishes to make things become better/easier for all, based on an experience from an individual person. Dont pick on him, because you dont wish the same, have a need of what he´s suggesting, or even have the same experience.
And please, as Matt just wrote…
When you do, you kill the idea as well as kill the passionate user, which in time will kill openhab, leaving you with absolute nothing.
Maybe thats what you want, but I´m sure, the rest of the community, developers, maintainers as well as the foundation do NOT share your idea!
Its unfortunate that both the idea and my enthusiasm for openhab after this is very much tarnished. What some people think is a selfish request for ME was actually a suggestion to benefit all by the number of posts I see in similar issues. Any way I’m over it. Carry on.
We are now 45 posts into this thread. Are we any closer to any sort of resolution? Is anyone going to work on this?
I’m willing to do what I can to make the 2.5 MQTT Event Bus simpler if I’m given actionable suggestions. I’ve asked for suggestions more than once on this thread. I’ve also defended the need for this feature. But so far all I’ve got is “that’s to complicated, it uses yuck icky MQTT 2, Rules are too hard”. No actionable suggestions for what I could make simpler. No recommendations for what could be improved. Just “it sucks and needs to be redone.”
You all have rejected the considerable amount work I’ve done to address this problem in its entirety without even the decency to suggest what I could do to make it meet your needs better. I think it’s a rather elegant solution frankly and it works fantastically well and I’ve explained why I can’t figure out how to make it simpler. So again I ask, who do you have lined up to replace what I’ve done? I did the best I can and you all reject it out of hand. My best isn’t good enough for you to even make suggestions for improvements so I sure as hell am not going to work on replacing it. That won’t be good enough for you either.
As for the people arguing against the requirement, they have a point too. Federating multiple OH instances should be a little hard. You have to understand how OH works, how updates and commands are processed, and be careful how to configure the pub/sub for individual Items or else you end up in infinite loops very easily. Once you do have this understanding, setting up the Event Bus isn’t all that hard. But I can’t give you a short cut. You have to understand these things. But since I’m clearly wrong, who is going to work out the technical details?
Regarding Kris´s suggestion, no. Regarding the attacks on him, hopefully this has come to an end!
I can only supply with ideas, since I´m not a developer.
I know you are, Rich!
Working/optimizing the MQTT event bus is a very good idea. But I do not feel certain enough about MQTT and rules to help you in how to make things more clear and easier. And I just dont see this as your job teaching me MQTT and rules through the event bus, but insted me who needs to step up and learn MQTT and the rules alot better.
Question is - Is an event bus/linked systems suppose to have this kind of requirement?
You do have a point in the user would need to know some basic stuff when dealing with a server/client system, like the Velbus way I mentioned. A simple thing as having each systems updated to be using the same basic setup (binding in this situation). But thats really isnt rocket science, at least not regarding Velbus. Stuart have done a great job with a very little script for keeping the systems up to date in an very easy way…
But the Velbus example is just a small brick in the pussle of openhab. It´s probably alot easier when only dealing with that brick only.
I would never reject any of the work you have done. It has never been my intention to even indicating such a thing. I´m very sorry if thats the impression I gave you.
I know you worked very hard for this and in general here on the community. You do this for the right reasons. And I know you´re highly appreciated among several users in here, including me, because of your help all the time.
Then question is - which requirements do you feel the MQTT Event bus should have? Which users are you targeting? Which users do you want to target?
Would you be able to do the same, targeting new users, or users who dont know MQTT and rules? Would it make sense? Or would that require totally different way of doing an event bus?
Thats probably the best way I can answer your main question, while not having enough experience on MQTT and rules, yet. I know there are lot of question in my answering, but I can only see this with a very limited experience in whats really matters. I wish my situation were different.
It’s not a requirement but given the technologies OH supports, MQTT is the most appropriate technology to use for this.
The user of such a system must fully understand what happens when an Item receives and update verses when it receives a command (this is the complex part).
The user must understand Items and how to add Items to Groups.
The user must be able to install bindings.
The user must be able to configure the MQTT binding or at least be able to follow the step-by-step instructions (complete with screenshots) using PaperUI (if you want .things files you are largely on your own) that covers all those steps.
The user must be able to copy and paste Rules code or if using Scripted Automation Community Contributions to the Helper Library (maybe someday which will be install able as an add-on). The Rules work as written, there is no customization required.
Except for specifics about MQTT, and requiring a deeper understanding of updates and commands, there is nothing in that list isn’t required of all users of OH. And for the deeper understanding of commands and updates and specifics for MQTT I tried to cover through extensive documentation.
Intermediate to advanced users who know enough to justify the decision to run more than one instance of openHAB. openHAB is hard enough to learn for new users to greatly complicate things by trying to run more than one federated together.
I agree with several on this thread, new users should not be doing this. If a user can’t copy and paste some Rules, they don’t yet know enough to assess the implications nor deal with the complexities involved with running multiple federated OH instances. It’s far too easy to end up with an infinite loop. the additional complexity adds greatly to their already steep learning curve.
I don’t think it does make sense. Because ultimately you need to know when to duplicate an event on one OH instance on the remote instance and when to duplicate a command on one instance on the remote instance. And knowing when to do which requires a nuance of understanding that many experienced OH users even now struggle with. There isn’t a blanket “always publish commands on one instance and always publish updates on the other” configuration. The user needs to pick and choose and choose correctly.
One of the great limitations of the 1.x MQTT Event Bus is that it only provides a blanket configuration. All updates to all Items get published here. All commands to all Items get published there. All subscriptions for all events is here. All subscriptions for all events are there. Such blanket configurations do not work for all use cases. And any Event Bus configuration must work for all event bus use cases. It supports just a couple of relatively simple use cases (e.g. reporting all the sensor readings from a remote OH instance, only supporting commands that match the Item’s state (e.g. you can’t reliably sendCommand(INCREASE) to a Dimmer)).
No matter what technology is used to actually send the messages, this is where the challenge lies. It’s the fact that not all commands can be processed as an update.
If instead of using MQTT this were a binding that used the REST API and websocket this complexity would not go away (not to mention that only commands and changes get published to the websocket I think so you couldn’t really reliably set up an event bus without changes to how that works anyway). Configuration over all could be slightly simpler but only moderately so.
Having worked on this and spent a huge amount of time thinking through all the angles, it is my assertion that what I’ve done with the MQTT 2.5 event bus is as simple as is possible to achieve in OH 2.5 that handles all the event bus use cases. I have high hopes that installation and configuration may become a little easier in OH 3 but won’t know that until OH 3 matures a bit more. Perhaps once OH 3 comes out and more people have a need for the event bus to support 1.x bindings we can make the installation and configuration of the Rules and connection to the openHABian MQTT Broker automatic (Marcus probably wouldn’t like that) but that doesn’t really address the root of the complexity. It’s like turning off the lights to save energy when 90% of your energy usage comes from the heater. And setting up MQTT to do this is really pretty simple. The steps are pretty easy to follow.
Maybe you could go through the steps on the link and provide feedback on what I can make more clear or perhaps automate some more. All I have from this thread is:
The first point is hopefully what you (we) want to archive
The second point is useless…
The third point is the troubblemaker, in my opinion.
Before I go and mess up the thread of the MQTT Event Bus tutorial, I´ll do a comment here, which will explain why I find the MQTT Event Bus is a problem.
MQTT is a hell, in my opinion. Its far from clear exactly how to install it. It has been a total mess for long, with lots of issues and hickups as vel as confusions. Noone seems to know exactly what broker to install, and how. Mosquitto (from openhabian-config) is no longer maintained (as far as I read somewhere not long ago). The embedded broker fails for many. And even when you try to get started with MQTT, you end up with a list of MQTT addons, which requires you to already know, to be able to distinguish them from eachother.
This is what happens when entering the addons directory and searching for MQTT:
Given you have no idea of how to install MQTT. All you want is to have a bus running between two OH systems. Is this what should be presented to you?..
To me this is a problem, because…
There are more than one MQTT binding, two of them even look the same and are named the exact same!!!
There is a MQTT actions and MQTT persistence. (Whats that? All I wanted was MQTT) There is a MQTT broker, and last there is a blue ikon of something just called binding. I have no idea what it is.
Reading the text below just makes things worse… Nice to know that the mentioned things are covered by the MQTT binding. But which binding is covering that? What the he*** do I need to install.
So before I even get started, I´ll need to figure out which one to install…
I turned to the docs insted. The only place I found something regarding MQTT is under Persistence Services…Well, at least now I know what MQTT Persistence binding is…
And thats it… No more about MQTT in the docs, (except when searching I end up in the bindings again).
Lets try the forum then…
The forum is filled with tons of posts with issues regarding MQTT and it didnt make things better when MQTT went from old setup to new setup. Now, I need to find those without issues.
I tried a search for “How to install MQTT”, only to find tons of tutorials of how to install from a specific device or people having issues, and even more posts regarding installation of V1.
This is where things gets highly complicated, to me!
I know, this has nothing to do with your MQTT Event Bus. It´s not your fault, and not you to blame.
But in order to use your event bus, you (we) have to face the fact, that the requirement is an issue. That mean, any problems regarding MQTT will becomes a problem for your event bus, just as well.
I promised you some help and suggestion… I´m not sure if it really belong in the tutorial thread… We can move it afterwards if you really want to…
You need to read my suggestion in the best manner. I dont want to sound like I blame you, cause I really dont. My idea is to start from the very beginning of the tutorial…
“How to get started with the MQTT Event Bus”.
You have mentioned a few times its piece of cake installing MQTT. What will happen if you did cover installation of MQTT, or a link from your tutorial to a working tutorial of “How to get started with MQTT”, (if it exsist).
A link to a broker and a binding could become handy as well.
Since there are more than one broker, maybe an recommendation in the tutorial, of which broker to use, with focus on the Event bus only ofcouse. As far as I understand, not all brokers are alike.
Maybe also covering the situation of a user who already do have MQTT installed on his “main” system… Whats required on the “remote” system… I read you´re tutorial a coupple of times, but this part is quite unclear to me. Maybe its due to I´m struggling understanding MQTT as well.
These are just my suggestions of what could make it easier to get started with the Event bus, taken from my experience.
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).
