@watou do you have a tutorial to do that integration?
I would like to try to install multiple openhab instances since on large buildings, you need multiple controllers, expecially if you are using z-wave devices.
For example, I would like to add an openhab controller for each floor with a z-wave controller installed on each, then have a main openhab controller that will allow to manage everything. If I can’t do that, openhab would not have any application outside our homes.
At the moment, some z-wave controllers support multiple instances: Fibaro with master and slave controllers, Zipato with cluster, Vera should also provide that.
Are you sure you need that? The maximum distance that a zwave device can be from a controller is 200 meters (4 hops). 200 meters (400 ft) is roughly a 25 story building (assuming 15 feet per story) which of course ignores interference but an average multi-story office building should easily be managed by a single controller assuming there are enough devices to form the mesh.
I’m not arguing against the usefulness of having multiple OH instances integrated together so much as asking whether you are trying to solve a problem you don’t really have.
If you want a reliable installation, you must have more than one controller.
In my house, I have an external garage building. With 4 hops I can’t reach it.
I have three floors, four hops to the basement (controller is on the top floor) and it is very reliable. I guess it depends on a lot of other variables.
The master instance of openHAB would also run MQTT item binding (no need to set up the event bus binding in the master), pointing to the same broker, and the master instance machine would also run the mosquitto MQTT broker that all instances point to. You would selectively add MQTT binding configs to items on the master like:
This way, the master instance’s Slave1Lamp item would send commands to the slave1 Lamp item, and receive state updates from the slave1’s Lamp item. However you configure the item inside the slave1 instance (Z-Wave, Insteon, Hue, whatever) is completely isolated from the master. I have this configuration spanning thousands of miles and it works reliably. My only difference from above is that my slaves communicate over SSL to the central mosquitto broker with a username and password (but this is a mosquitto configuration subject, and only needed if you don’t trust the networks between slaves and master).
Thanks @watou for the overview.
I have one more question: suppose I would like to install 2 or more openhab controller with z-wave installed on each.
Would your solution work?
If I have light1 on controller1 and light2 on controller2: do I have to do this configuration?
I’m not sure I understand your question (do I have to do this configuration). I don’t think the Z-Wave binding works with multiple Z-Wave controllers on a single openHAB instance, so if you had two distinct Z-Wave networks and two distinct openHAB instances, your single master instance could send commands and receive updates to each. Whether or not you have to do it this way could be better answered by the local Z-Wave experts.
I meant that controller1 and controller2 would host 2 different z-wave network and mqtt could be used to integrate those 2 networks. In my example, I have to set mqtt eventbus on both and a user experienced a loop problem.
My problem right now is that I configured 2 openhab controller: 1 publish state and command to mqtt broker and the second subscribe to that. The problem is that all device status don’t change. I expected that every change on the first controller would refresh changes on the second.
Your setup is not the same as I offered, and it will have a loop problem as you saw. Please try a configuration similar to mine and let us know if it works.
I realize this is a few months old but it was really helpful. I got all my slave instances working together but the master instance was giving me a hard time. I like the idea of selectively configuring which items are synced. This change in thinking solved my problem.
Just my 2 cents regarding zwave and other devices that require a physical connection, you can create an instance just for those devices. I essentially made a network bridge for my zwave and Caddx NX8e (one instance for each). The Zwave instance is configured to publish updates and subscribe to commands. The NX8e instance publish command and subscribes to updates. The zwave instance for example, obviously would have all zwave items on it bound to the zwave binding and the slaves only has the zwave items that are in that room bound to nothing. On the Zwave instance there is only the zwave binding, mqtt binding, and 2 item files (one for all switches and outlets and one for all thermostats). It’s been working great and the time to send a command to an item appear to be just as fast as if the zwave controller was local.
I wanted my slaves to be as independent as possible. The only thing they need the master for is the weather and the house mode. Since I wasn’t able to get the master working right the slaves have automated work arounds for when the master is unavailable.
I’m searching and reading posts about how to have dual openhabs, one for my house and one for my cabin up in the mountains.
I think the best so far even if I don’t really understand how to do it yet is your solution here @watou.
I understand some time has gone by since you guys last discussed this. And I was wondering if this is now considered the best practice for using obenhab in two geographical locations.
Today I have openhab2 set up in my home and its running great.
Now I want to set up openhab at my cabin as well.
And I see an issue with my.openhab not allowing me to bind to two openhab setups?
Also the habdroid obenhab android app only takes one URL and not two as it would need to do to be able to point to each of the openhab instances.
But I understand that your solution works in such a way that a salve openhab instance forwards all its info via this mqtt protocol to the main openhab and this main one is the one that is then connected to all the front ends like habdroid?
That is correct. Only one instance of OH is allowed per account.
That is also correct.
Correct.
ALL updates and commands issued to all your Items get published to an MQTT Bus. The slave has a bunch of Items that represent sensors and control its local location but the slave does not host a sitemap (or at least not the main sitemap) nor does it necessarily have any rules (that part is up to you as to how smart to make the slave OH).
The Master OH has an Item that represents all the Items in the slave. These Items get updates from and sends commands through the MQTT Event Bus. Put another way, you have Items that act as a proxy for the Items in the slave. Once you have the Items then everything else works the same: e.g. create a sitemap with the proxy items to represent your remote location.
You will have some challenges getting the two networks to see each other though. There are several approaches you can take including:
set up SSL/TLS on your MQTT broker with certificates and ACLs and set up a port forward in your firewall to allow the remote OH to communicate directly with your broker over the internet
set up an SSH tunnel between your remote server and your local network, again using ssh certs, and set up a port forward in your firewall for ssh to allow the remote OH to communicate with your broker over the internet through this tunnel
set up a VPN solution such as OpenVPN that will let your remote openHAB appear to be on your local network throuhg an encrypted VPN tunnel
use a cloud based MQTT broker that both instances of OH can see (has some cost, may not be as secure if they don’t allow encryption and ACL configuration)
Thanks Rich for those very good explanations! I think I understand the MQTT Bus more now, and it seems like a good logical solution to use for the obenhab set up. When I first encountered the name MQTT Bus all I saw in my imagination was a Bus (the vehicle).
In addition it hadn’t occurred to me that I’d have a challenge in communicating between the two instances over the internet, thanks for pointing that out.
There are a lot of new technologies here that I am unfamiliar with so I will have to do some reading to learn about them before deciding on which method to use. I’m probably going to use the most simple method. Whether that be with more or less of security level we shall see.
Security will not be a huge issues in my case as I’m mostly interested in keeping tabs on the health of my cabin. Like temperature in winter time, knowing about if any water leak occurs when I’m not there or if any fire alarm goes off. Those kind of things. I’m not going to set up any door locks or stuff like that. But then again, the best security is always something to go for unless it’s a lot of extra work of makes it really complicated or has other drawbacks in terms of performance or otherwise.
But this is great, its a really good start for me as I didn’t even know the names of those things before, now I can start to research them. Hopefully they aren’t to over complicated. But I guess if I managed to get a linux machine with openhab up and running with all the new knowledge that involved to learn, then these new things should not be a problem.
The security I’m talking about is opening up your networks to hackers. Any time you punch a hole through your firewall (i.e. expose a port to the internet) you have opened up a place for attack.
These attackers may not care to open your door, but they may want to get on your network so they can steal enough information to steal your identity, set up a platform from which to attack others, encrypt your hard drives and hold them for ransom, etc.
Given your professed level of skill, I highly recommend setting up a VPN. One potential solution that isn’t too hard to set up is Hamachi. I think it is still free and it might be easier to set up than OpenVPN, assuming your router doesn’t support OpenVPN out of the box.
Ok, I understand. I didn’t think about it that way, thanks for pointing that out. That type of security holes is definitely something that I want to make sure not to expose my home network to. So I will follow your advice.
When I got everything set up I’ll update here again with all details. And it will be in layman’s terms so it might serve as useful information for someone else later on that would like to do the same.
Hi @markus7017 ,
Unfortunately I was burned badly while a heavy contributor to this project last spring, and as a result it evaporated my interest in contributing. Hopefully there is a good person who can offer you assistance. Regards, John
Can anyone offer some assistance, im playing around with this but will ultimately use it to fix my Zwave network which right now relies on socat/ser2net and its just not reliable.
I’ve setup two Openhab 2.4.0 stable systems.
Garage: (192.168.0.3) Main instance - This already had a MQTT Broker running and has the MQTT 1.x binding
House: (192.168.0.33) Slave instance, I’ve installed the MQTT 1.x binding and configured mqtt.cfg in /etc/openhab2/services/mqtt.cfg as follows:
It appears I’ve got my slave configured incorrectly in the MQTT.cfg file as I see this:
07:29:20.022 [INFO ] [rt.mqtt.internal.MqttBrokerConnection] - Starting connection helper to periodically try restoring connection to broker 'mosquitto'
07:29:30.027 [INFO ] [rt.mqtt.internal.MqttBrokerConnection] - Starting MQTT broker connection 'mosquitto'
07:29:30.044 [WARN ] [rt.mqtt.internal.MqttBrokerConnection] - MQTT connection to 'broker' was lost: Connection lost : ReasonCode 32109 : Cause : null
07:29:30.046 [INFO ] [rt.mqtt.internal.MqttBrokerConnection] - Starting connection helper to periodically try restoring connection to broker 'broker'
The ‘Garage’ where the broker runs (master) sees this in /var/log/mosquitto.log
1575664270: New client connected from 192.168.0.33 as House (c1, k60).
1575664280: New connection from 192.168.0.33 on port 1883.
1575664280: Client House already connected, closing old connection.
1575664280: Client House disconnected.
1575664280: New client connected from 192.168.0.33 as House (c1, k60, u'mosquitto').
1575664290: New connection from 192.168.0.33 on port 1883.
Can someone explain what I’m doing wrong please? or offer some guidance.
Are you using unique cleintIds for both openHAB instances? Only one clientId can be connected to the same broker at the same time. If a new client connects with the same ID, the broker will kick off the old client.
The master has configuration as below with clientId MASTER in mqtt.cfg. Master has always worked fine with MQTT for a long time, I’ve got over 20 sonoffs on it without issue
Hopefully they aren’t to over complicated. But I guess if I managed to get a linux machine with openhab up and running with all the new knowledge that involved to learn, then these new things should not be a problem.