Real world solution / Openhab at two locations

Hello community,

I would really like to have our two cents on how to setup openhab on two locations.

Currently i have a house were openhab is already running, but i will soon also have a small apartment. Of course I will be using openhab there as well. The big question is, how? I see two options.

  1. Running another openhab session in my appartment
  2. Tunneling with a Site-to-Site-VPN from my appartment to my house and use the existing openhab.

In terms of hardware, i will be having a small itx based system anyways (for my offsite backup), so running openhab in a VM would not be a problem. Still my gut feeling tells me that I should go with the VPN solution. I think it will be easier to maintain 1 system instead of 2.

Please, if you have experience with either of the two options I would really appreciate your input.

Thanks
Olaf

  • Platform information:
    • Hardware: Ryzen 3 2200 g 1-core /1.5 G Ram / 30 G Storage (in Virtual Box)
    • OS: Sparky linux
    • Java Runtime Environment: Zulu 8.40.0.25
    • openHAB version: 2.4.0

Well it’s for sure easier to have one instance only than to coordinate two, also less HW you need (also think of spare HW!).

Do you need any local transport layer such as a ZWave or Zigbee stick ? If so, go for 2 servers.

If no, think which functionality would go missing in your 2ndary site if connectivity breaks in either site, but count functions only that would continue to be available if you had another local server there (i.e. don’t count stuff to rely on data off the other site or cloud services as those would be affected, too).
Do your own math, then.

Thanks for your input.

At my main site i have zwave, but i actually do not want to implement this. From all my bindings i found it extremly hard to get it running properly and the first actor already “quit service” after only 2.5 years.

All my other bindings will be wlan/lan based (for example homematic and hue bridges). These bridges i of course need to exist on both ends.

In my current place the internet is rather stable. I sometimes have rather low speeds but only once i had an internet outage with was even announced before due to maintenance.

My preference would be two separate instances of openhab. If one of the internet connections stop to work, you can’t control your apartment. Latency may be an issue as well. I do not use cloud services for mission-critical (light, switches, rollershutters) tasks. But as @mstormi already said: do your own math.

rpi is cheap, oh runs fine on rpi it’s almost nobrainer, separate localised instances are always better idea than one somehow shared instalation.

just my 2 cents, i would go for two separated

Dig around, Rich did a write up on how to connect two OpenHAB instances together using mqtt. You probably want both locations to continue functioning should dirconnection between the two is lost. No direct experience doing so but if I were to try, and I can see a second location already (shop) it is the route I would choose.

This sound quite neat. I will have a look into it.

Another question I should have put up: do you have functions in your new site that rely on data or access to devices in the old site ?
If there’s no dependencies, it indeed is (well, almost) a nobrainer to run 2 separate instances.

I’m currently running a remotely deployed OH at my dad’s house to keep an eye on him and have experience with both approaches.

You do not provide enough information about how you want to use this remote version. Is it completely stand alone or does the apartment need to work with the other OH instance? If it’s stand alone I’d go for a separate instance at both locations.

If want to either federate your OH instances (see MQTT 2.5 Event Bus and I’m currently working on a reusable library implementation) it’s not hard to set up but it does add a bit of complexity in overall design and mental load required to think about your system. For example, all the Items you want to share between the two instances need to be defined in both OH instances and kept up with each other.

And even if your devices are all network based, keep in mind that usually a VPN tunnel ends up on a different subnet which will prevent some automatic discovery features of some bindings from working if you use one central OH instance for both locations.

2 Likes

Good monring

The 2nd site is standalone. I would just duplicate some items/rules/things from my main site like the presence detection. So no site is relaying on the other site.

But here is my first worry because i have not tried this. I don’t know what will happen if my presence detection (using the GPSTracker binding with Owntracks) will nicely work with two sites. In theory i think that it should not create any trouble if I can add my second site to the myopenhab cloud site. Any experience with this?

As for the VPN, i have this at my current site as well that the IOT devices are in a seperate VLANs. I am currently only working with text based things, because i found it harder to set up, but much easier to work with. So far, the only problems i have are with my libreelec boxes that do not want to be on a seperate subnet.

So, from what i read in all of your recommendations, the simpler solution would be the to run a seperate openhab.

Even though Kriznik suggested a Raspberrypi, i just want to share my experience. The main two benefits for me for the rpi was the low power cunsumption (had a powerbank as my UPS) and the price. But somehow i killed 3 sdcards (LExar, transcent and Sandisk) over the period of 2 years. I believe the nicer solution is a VM. Just my opinion.

Again, thanks for all your input

BR
Olaf

Not out of the box because owntracks can report to just one server i.e. your main site.
You can mirror the relevant presence detection items via MQTT eventbus. But it’s no reason to back away from 2 sites. Your presence detection wouldn’t work anyway if Internet connection was down.

You can’t do that. So you will probably need to forward the OwnTracks Items to the other OH instance, which should be simple enough to do using the MQTT Eventbus implementation I described. I personally would not use this as an excuse to merge the two into one instance.

I still believe this to be the case.

SD cards are known to wear out and there are lots of ways you can prevent or delay that, many of which are built into openHABian such as putting all the heavy writes into zram and only writing them to the card on shutdown. Many/most users end up using an SSD or HDD and again, openHABian has the ability to migrate an existing SD card installation to that external drive.

I ran openhab at two separate sites for a couple of years. I came to the conclusion that the way to go was with two separate instances, simply because if anything went wrong at either location the problem would be isolated… (usually caused by me tinkering!)

The only nag I really came across with this approach was Openhab Cloud and Google Home integration; I had to use two separate OH Cloud accounts (one for each house), which then resulted in it being impractical to set up Google home at each location. Although you could just use alexa in one place and GH in the other, if that’s something you’re thinking of.
If you do end up doing that, keep a tab on which oh cloud account is being used where… :joy::joy:

Tl;Dr, a single linked system is easier for account management, but potentially easier to cause problems you wouldn’t notice until you get a disenchanted phone call