[SOLVED] Multiple instances of Openhab

Setup, Configuration and Use Installation
1

Hi
I am new with openhab. I want to implement an architecture for automation of a building consisting of some rooms. In each room there is a rapsberry pi with LCD touchscreen running an instance of openhab on it. All of these rasperry pis are connected to a central server running another instance of openhab. The server should check the status of each room periodically and there are some other feature for this architecture, for example the server can stream video to each raspberry pi, so there should be some kind of connection protocol between these instances. Is it possible to do this with openhab? Is there any tutorial to do a similar job with openhab?

1 Like
2

You may find an idea here:

Continuing the discussion from Connecting distributed openhab instances:

1 Like
3

I have separate instances of openHAB communicating via an MQTT broker. “Satellite” instances use the MQTT event bus binding to publish state changes and subscribe to commands. The “master” instance uses the MQTT item binding to selectively subscribe to items of interest from the satellites, and selectively publish commands to the topics that the satellites have subscribed to to receive commands. I’ve found it very reliable.

3 Likes
4

Interested to hear what your use-case is for this architecture @watou?

5

I have multiple properties, but I prefer to connect (UI, rules) to the master openHAB instance and control the others from there. For example, it’s cool to turn on a device thousands of miles away by sending a command to an item in the local master instance, which publishes it to the MQTT broker, which the satellite instance subscribes to, and the distant Z-Wave network responds immediately. As long as the satellites can connect to the common broker, it has been solid.

1 Like
6

Very nice indeed.

7

This can be done but I recommend you centralize the rules and persistence similar to how @watou describes. Another alternative is to just put a client on each of your satellite raspberry pis, particularly if the main goal of the satellites is for display and UI and not to control something wired directly to them. You can have multiple sitemaps should you choose to use the built in UIs, a different one for each room. And even if you do have something wired directly to your satellite pis it might be simpler to write your own script or use someone else’s (here is mine) that openHAB communicates to cause things to happen.

The last one is the architecture I used. I have two satellite raspberry pis which send sensor readings and respond to commands from the central openHAB server over MQTT.

If you follow @watou’s approach the server will be notified of any changes that take place in the rooms as they occur. There is no need to poll the rooms.

OH doesn’t really do streaming video like that. You can probably set each of the satellite raspberry pis as a DLCP receiver and push video to them from the OH server through an Exec command which kicks off a command line script. That is probably how I would approach it.

1 Like
8

@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.

9

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.

10

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.

11

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.

12

Not really, but here is a rough overview:

Each slave instance of openHAB would be setup as normal, but with the MQTT binding configuration like this:

mqtt:mosquitto.url=tcp://master:1883
mqtt:mosquitto.clientId=slave1
mqtt:mosquitto.retain=true
mqtt-eventbus:broker=mosquitto
mqtt-eventbus:statePublishTopic=/slave1/out/${item}/state
mqtt-eventbus:commandSubscribeTopic=/slave1/in/${item}/command

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:

Switch Slave1Lamp "Slave1 Lamp [%s]" <switch> { mqtt="<[mosquitto:/slave1/out/Lamp/state:state:default], >[mosquitto:/slave1/in/Lamp/command:command:*:default]" }

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).

7 Likes
13

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?

Controller1:
light1: zwave device
light2: mqtt device

Controller2:
light1: mqtt device
light2: zwave device

14

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.

15

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.

My config lines are these:

Controller1:
`mqtt-eventbus:commandPublishTopic=openHAB/out/${item}/command
mqtt-eventbus:statePublishTopic=openHAB/in/${item}/state

Controller2:
mqtt-eventbus:commandSubscribeTopic=openHAB/out/${item}/command
mqtt-eventbus:stateSubscribeTopic=openHAB/in/${item}/state
`

16

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.

17

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.

19

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?

Regards, Erik

20

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)

21

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. :slight_smile: 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.