Not exactly. I think/believe that using OpenHAB as a platform (eg. first choice). In my world it makes things simpler to use the same platform everywhere. I still have to decide what is my main instance (for all the reasons you mention), but I wouldn’t have top look for five different scripts on different Rasperries, I allways know that on this machine everything I integrate to is represented by a Binding. Each instance is then bound together using MQTT.
I am not sure I fully agree on that point, but to some distinct yes. It depends on how you ask them to talk together. My point is exactly that if I use the eventbus strategy it will add overhead, because a lot of data has to be transferred without any need.
I have actually both a OH1 and OH2 instance running, that is because I don’t want to migrate fully to OH2 yet. Some of my sitemaps was causing issues, the persistence seems to cause issues. But I really needed Z-Wave improvements from OH2, so I have actually created this bridge manually. It runs perfectly on the same Raspberry. But I need the bridge.
I don’t have anything near laod issues, but I have hear/ read others that have split their OH for that reason.
That is what I really want to avoid as mentioned above. I agree I could tend to be a sort of religion. But I believe that making things equal also makes it more obvious to see what is going on. It is hard to guess what python script delievers what information after a year when things break down.
Well sending MQTT messages isn’t eactly rocket science.
But I guess we have quite different views on how our architecture should be. I would like to use OH as a generic integrationplatform for all my devices, thus having a number of OpenHAB instances each contributing with some data to the main instance (with rules and so on). I have already obtained that by mapping each and every item to a in and/or out MQTT queue. I just wanted to see if some binding could be defiend to help here.
You think my solution is cluttered, where I think your script approach will clutter things. Each one has its own pros and cons. In my case I belive the OpenHAB as first choice approach is best, where you belive the light approach is best.
Agreed. Didn’t want to start an argument on that, it’s just that I feel those few people capable of programming that type of inter-OH binding you’re looking for haven’t done it for some of the same reasons as those I gave, i.e. their view on architecture is similar to mine. Anyway, just guessing, and good luck, maybe you still find someone to build it.
One stick, but one of the reasons I did think of redundancy was the master / slave possibility with the stick.
Basically I just want to avoid a lot of individual mapping, e.g. a graphical approach to the eventbus.
and it works to have two different java processes both do concurrently lock and use the same USB device ?
On ZWave redundancy, that’s a complicated one, see also this thread. Not much point in having two OH servers but a single ZWave controller/network only.
Oh, sorry I have misunderstood you. Nope that wouldn’t work.
In my case I have Z-Wave in my OH2 and sitemaps, rules etc. in OH1
I have a file called zwave.items in both OH1 and OH2
I like the idea. I do think though that there is some work going on towards this direction in the 2.0 MQTT binding. I remember reading something like this. It is worth the look.
I’d second this and point you to another python script which supports more than just GPIO (I’m partial since I largely wrote it). Options are good.
There are use cases where it makes a lot of sense to have multiple. The one that comes to mind is watou’s setup where he has remote instances to monitor his aging parent that feed to his central OH server. It is admittedly an edge use case but for me a fascinating one that really is a great use of home automation.
Why is this any different than running some program on another raspberry (i.e. openHAB)? I personally find debugging and finding problems in these simple python scripts WAY easier than debugging any sort of problem in OH. And when you combine multiple OH instances… that is cluttering thing up.
In this scenario wouldn’t you want to send everything? The “master” has to know everything and be able to talk to everything. Though clearly the slave OH instances only need to receive those messages they care about/control so I see the use in that direction.
One case I can think of is where you have two wireless devices which interfere with each other’s signals. In that case, one solution could be to put that device on a separate computer, though in that case I’d probably go with socat instead of a separate OH.
With my script, I have four instances of the same script each configured differently on three different Pis and computers. And even with this configuration it is WAY easier to update, debug, and implement new capabilities than it would be to deal with the MQTT Event Bus. It’s just one anecdote but I don’t think it is an uncommon one.
And just for the record, this script:
executes shell commands (I run OH in Docker so Exec binding isn’t terribly useful)
reports state on GPIO pins
activates GPIO pins based on MQTT command from OH
reports presence or absence of nearby BT devices
reports Amazon Dash button presses
acts as a bridge to/from my RFM69 wireless network
queries the network for and reports the addresses of my Rokus
And despite these scripts doing all of that in different combinations across four machines updating and maintaining these scripts is dead simple, usually just editing a .ini file and checking that in to my git server.
Debuging problems are localized, network traffic is light, and because I’m using MQTT I even have a built in health and status feature that tells me when a node goes down.
At least in my case a simple cat chimera.ini tells me exactly what information my script is delivering and how on the machine I named chimera, assuming I’d forget which hasn’t happened yet.
No but dealing with circular messages and infinite feedback loops can become quite challenging even with carefully selecting what gets published.
I think what you may be missing is that both @mstormi and I have actually tried to do this. And I’ve tried to help lots of others deal with this. We are not talking theoretics. We have direct experience and battle scars. We KNOW it is a more complicated. OH simply was not architected like Node Red was to run like this. This is why I wrote my script in the first place.
I know it feels like it would be better and easier to have everything be the same, but when everything is OH, based on our experience, it is most definitely not easier.
But note, both of us have said we like the idea of this binding and see lots of applicable uses for it.
Yes and no, If I have lets say three raspberries, where A is my master and B and C is some secondary instances. Then I don’t want B and C to receive ANY MQTT messages. I am not looking for redundancy, I just mentioned that as a possibility. But I want B to report states to A and C to report states to A. I agree that could be done just using the the mqtt eventbus, but I would also like to be able to filter what i publish. For my Z-wave things, some of them is used in my home grown “alarm system” where others isn’t. For this reason I have a program running that acts like a Alarm monitor (basically do alert if a sensor is triggered and nobody is at home). I want Those items to be published on a Alarm topic in MQTT other things goes on another MQTT Topic.
As far as the scripts I would dare to say that they have grown in the OH1 world, because that was the possibility there. But I believe OH2 tends to turn a little more to a GUI, thus making it more user friendly to more people. I would ever never tend to claim that the scripts doesn’t work, but I believe the other approach has some strengths, where scripts also has some strengths.
I don’t want this to be a religious discussion, about the two approaches, but I would like to know if anybody is interested in such a binding, and / or if there is some work going on in OH Core that would ewventually suppport my requirement.
Like I said, I believe there is some work in this direction in the MQTT 2.0 native binding. And both mstormi and I expressed interest in the binding.
It does but it isn’t quite good enough yet to be the exclusive approach to configuring OH in all respects (it is getting better day-by-day) but the problems we are foreseeing and have experienced are independent of the UIs. They are technical and logical problems that arise when trying to set up a master/slave distributed system using a program that was built and architected as a centralized controller. Something like NodeRed was architected and built from the start to support this sort of architecture.
And while there is a lot that could be done to make this sort of thing easier to do in OH, it will always be a bolted on capability and will always work less well than something built from the start with this as a requirement.
That sounds absolutely great, since I believe that some of my ideas might not fit into the binding concept.
Great, and by the way, thanks for pinpointing pro’s and cons. It is always great to have such kinds of discussions, since it helps making things more useable. I will try to think the usage, and eventually describe a possible binding in more details. I guess it won’t be a all in one swiss army knife binding
Seems quite interesting work going on here.
I saw some discussion about Auto detect from some sort of templete / config file. That seems to be exactly what i need
I think for now I can live with the manual mapping so I will wait and see …
I am running three instances of Openhab 2. Two are Raspberry Pis (with the aim of having one as a redundant standby) and the the third is a laptop. I use MQTT. Essentially all three run MQTT but the MQTT server is referenced by ip address, so all data is going to/from 192.168.1.10. In addition to the real world I/O the other two OHs also reference the IP address and so their data is always up to date.
My aim is to make the OH2 servers change IP address in the event of a problem, i.e. 192.168.1.10 goes to 192.168.1.30 (and stops handling MQTT) and 192.168.1.50 goes to 192.168.1.10 (and starts handling MQTT). When everything is going well, this is simple to do, the issue how to achieve it when a server fails (or detect failure early enough to allow either shutdown or IP address change)
I have existing rules which determine whether the OH instance is “in control”. Only one OH handles watchdogs for data and RTC updating/synching
I got stuck indeed, specifically due to the fact that OH2 the channels need a specific type.
The binding is/was working, but not in a very intuitive way. I’ll take another stab at it over xmas holiday
