Why
My garage is far enough not to be in Z-wave range, but I have Ethernet connection there.
Alongside my main OH system (with Z-wave controller) I had another one running in the garage, with another Z-wave controller (razberry) with 2 devices there.
I was happy to find detailed documentation on MQTT 1.x and used it to post (publish) bus-events, so I could subscribe two items on main controller and know their state and send commands.
That worked as a charm.
What happened
Now, I’ve updated to 2.4 and - obviously - it stopped working.
You guys wrote about it in 2018 already and the general conclusion was there is a possibility to create some “publishAction” and so on, so it should be easy to recreate even 50 devices with one rule. Fine.
The problem is not everyone is a programmer and - honestly - I didn’t understand those explanations there at all.
What to do?
Would someone be so nice and point me to some good examples of the configuration how to implement the replacement of the bus events in OH2.4? I know there are users out there with similar configuration, but I can’t share this optimism.
If such a replacement (or “publish Action” explanation) is too much, even just simple example of working configuration for 1 item in sync with another item on remote OpenHab instance would do.
Please notice that I would not be able to implement “publish Action” on my own. (As a matter of fact, I’m not even sure if I understand what it is.)
Caveats This documentation is worthless for non-programmer like me. I’ve read it and still don’t even know where to begin.
I even found some (quasi-)tutorial, but it was using the PaperUI, which I don’t want to use, because every time I did, it messed up with my configuration (mostly with z-wave), so I had to spend even more time debugging and re-configuring.
You don’t have to use the MQTT 2 binding. If this was working before, just uninstall it, make sure you have “Show Legacy 1.x bindings” enabled in PaperUI’s configs. Then reinstall the MQTT1 binding.
Perhaps explain what wasn’t clear about those explanations. At this point, those explanations are it. They are all that exist.
MQTT is a pretty low level binding. Whether you think it’s fair or not, but you are going to have to work on working through documentation like this even as a non-programmer. Because it is so low level, it is never going to be as easy or simple to use MQTT as, for example, zwave. This goes double so for a user who insists on not using the UIs to manage Things.
In general, the developer of the MQTT2 binding is only really interested in supporting management of Things in PaperUI. So if you don’t want to use PaperUI you will not have as much support. But there are tons of examples for how to define the Things in PaperUI. I myself don’t use .things files but only PaperUI (and have never experienced any problems with Zwave, you should open a new thread on that problem).
You don’t need an event bus for just two Items. It would be much easier to just configure MQTT Generic Things on both instances to publish/subscribe to the same topics so updates and commands in one get published and update or commands the Items in the other.
There have been many generic tutorials posted to the forum on how to set up MQTT 2.4 including:
It’s worth noting that the 2.4 version of the binding has some bugs with .things files that will require a reboot of OH every time you make a change. You should upgrade to OH 2.5 V1 if you plan to use .things files.
To reproduce the event bus behavior there is some documentation here.
For instance, the supported things are listed with channels, but there is no example of the thing as it should be in the .things file. I’ve tried to transform my existing file, but it didn’t work (unsurprisingly). Had I only not had the bad experience with PaperUI !
Well, I didn’t think about it. I thought newer is better you know future proof
I’m not the type of person, that asks without having tried to solve the problem myself. At that time I just found a working way with .things files. I don’t even remember how and what exactly got messed up. I think there was some inconsistency with things and all the active channels…
Also - backing up and restoring the config files is so much easier than re-clicking all the stuff in PaperUI (or any GUI for that matter) on migration (which I have planned and did recently).
That’s what I thought after reading your explanation in the old thread. Thank you so much for the links and that bug info (I wasn’t aware of). I just checked and it seems I started already the good way. Before asking this question, I created the bridge and device .thing files, but stuck on the .items.
Now, I will should be able to understand it better, so I can polish them a bit
Thanks once more, I will have a deeper look into this during days/nights to come.
You clearly haven’t tried my Paper UI replacement design study yet ^^.
It depends on how well the UI is written and Paper UI is crap (and deprecated).
I’m sorry for not having the examples in the main mqtt doc file. In my opinion they do not belong there as they only cover the old .thing and .item file syntax which I do not support.
The web team is very unresponsive at the moment and not really going to help me with adding additional example files to the web-page documentation.
Indeed, I haven’t. Would you really care about my opinion though?
I actually would like to give it a try, but not only:
( - I don’t care because I don’t like PaperUI ) but it seems to be only available in dev branch (if I’m not mis-interpreting your words). Unfortunately for me changing branches represents a lot of work and a lot of risk of things not working. I understand the need of updating and following the development (that’s why I upgraded and faced broken backward compatibility of mqtt), but having one broken connection is more than I need and I am willing to accept.
I’m glad we agree on that one and I hope your GUI will be complete, flexible and consistent (unlike PaperUI).
Fingers crossed.
I appreciate your input and understand the concept. Like I said - as long as the GUI is complete and consistent and as long as there is a basic backward compatibility (i.e. a way to migrate from old to new at least ) I wouldn’t mine using it.
- I don’t care because I don’t like PaperUI