Unifi controller and openHAB on one machine?

Hi, I’m running openHAB 2.5.0M1 on an Ubuntu 16.04 machine. Now I’m buying some Ubiquiti gear and want to install the controller on the same machine, as it is running continuously anyways…

Any experiences from other users running the same? I understand that Unifi needs to install the following packages, which might interfere with Java 8(?) from openHAB?

The following additional packages will be installed:
  ca-certificates-java jsvc libboost-filesystem1.58.0 libboost-program-options1.58.0 libcommons-daemon-java libgoogle-perftools4 liblcms2-2
  libpcrecpp0v5 libsnappy1v5 libtcmalloc-minimal4 libunwind8 libv8-3.14.5 libyaml-cpp0.5v5 mongodb-clients mongodb-server openjdk-9-jre-headless
Suggested packages:
  java-virtual-machine liblcms2-utils libnss-mdns fonts-dejavu-extra fonts-ipafont-gothic fonts-ipafont-mincho ttf-wqy-microhei | ttf-wqy-zenhei
The following NEW packages will be installed:
  ca-certificates-java jsvc libboost-filesystem1.58.0 libboost-program-options1.58.0 libcommons-daemon-java libgoogle-perftools4 liblcms2-2
  libpcrecpp0v5 libsnappy1v5 libtcmalloc-minimal4 libunwind8 libv8-3.14.5 libyaml-cpp0.5v5 mongodb-clients mongodb-server openjdk-9-jre-headless unifi
0 upgraded, 17 newly installed, 0 to remove and 0 not upgraded.


I’d do it with docker. Much less chance of one affecting the other.

As long as the machine has enough ran to run 2 fairly large java apps.

1 Like

Hi Maurits,

I did the same some time ago, and remember having had some issues because of the openjdk-9-jre-headless dependency in the Unifi package.

What I ended up doing was to manually remove this dependency from the Unifi .deb file (so basically extract the contents of the deb file, find the line that contains the dependencies, remove openjdk-9-jre-headless and put a new .deb file back together).

This way, you can at least install the package without interfering with your existing openHAB Java installation.

The next step was to convince Unifi that Java was actually installed… systemctl start unifi did at first not work for me because the startup script did not find my Java installation. You can have a look in /etc/init.d/unifi to see where it looks for Java and change the paths according to your installation.

Also, make sure to check that the listening TCP ports of Unifi do not interfere with openHAB (e.g. 8080 and re-configure them if necessary.

After these changes, I got the Unifi controller running next to openHAB :slight_smile:


I run the latest UniFi Controller along with a some-day-old snapshot version of openHAB 2.5 on Debian 9. No problem with that, just make sure you have Java8 installed (zulu java 8 in my case).

@hoalex is right, you have to change either OH or Unifis Webservice port.

Sidenote: the accesspoints are great, I would stay away from the switches and the gateway.

Thanks @psyciknz, good idea. I tried it and installed docker on the fairly old laptop, but indeed it takes up a lot of resources and might not be the road to take…

Thanks, I’m going to try this next, sounds pretty complicated but I should be able to manage. Where can I change the Unifi port for the webhosting?

Just to make sure I understand, you did the same as described above by hoalex, or did you have another trick to not install the java 9 that comes with Unifi?

I just ordered the USG and the APs, I see a lot of positive reviews on the USG… I guess I’ll have to experience it

Does anybody has this working on a RPi3

Hi Marijn, yes I have it working on a RPI3, but just the controller, I have openHAB on another machine.

Anybody both OH and the Unifi controller?
Before I start trying to try it would be nice to know if it’s performing before I mess up my system :slight_smile:

I agree with the comments about docker. The unifi controller has historically had a lot of problems between versions and it easy do get into dependency problems with mongodb and its dependencies. You will do yourself a favor running it in a docker container. That being said, you don’t have to run openhab in a docker container, unless it makes sense for you to do so.

Regards, S

I’m picking up this little project of mine again. Could you run OH (openhabian0
) next to a docker container with the unifi controller on the rpi3?

Yes, shouldn’t be a problem.

I got it running on a rpi4 machine. For unifi I have the standard openjdk-8 running and openhab2 uses the recommended zulu java.
What I did and found out:

  • openhab2 gets its java via the /etc/default/openhab2 -> JAVA_HOME=/opt/…
  • unifi gets its openjdk-8 over the standard install procedure (apt jdk8 …)
  • Change the openhab ports 8080 & 8433 to something else (it is easier than fiddling with all the unifi devices around.
  • jsvc required by unifi doesn’t like the zulu java installation: it alway reports no jvm found
  • don’t use the 64bit kernel of raspbian buster, because MongoDB crashes. I couldn’t find a suitable MongoDB, unifi & linux version. I even tried Ubuntu 64bit for the rpi4, but no luck.

If I find some time I will try to get the zulu java in place of the openjdk and test it further. YMMV

A small update:
Unifi runs on the Zulu 8 jdk, but few modifications are needed. The jsvc, which unifi requires, has few restrictions on the used jdk. It can not deal with aarch32 folders within the jdk. It checks only for arm. First symlink any aarch32 folder in the jdk to arm. Second rename and move the jdk to /usr/lib/jvm/java-8-openjdk-armhf location. I do now some further long time tests.
Lets see, it looks promising.

1 Like

A small update Unifi runs fine now since more than 2 month with zulu jdk of openhab on raspbian. Just don’t forget the 2 symlinks (aarch32->arm after every jdk re-install). I created a request for inclusion in the install script (openhabian-config).

I run unify + openhab for the house since 3 years now.
Have lived over 10 updates of the Unifi Controler and they are always a russian roulette.
Either it will crash a DB or not this time.
Therefore I would never run it on same machine with OH
My setup is a large 6 bay - QNAP running separate VM’s for OH and Unifi Controller so I can restore a machine backup if it dies. I did that 3 times so far over 3 years of using UniFi. When you get your OH to manage critical infrastructure you need to make it very reliable and co-hosting it with Unifi is not a way.

I also used to run Unifi NVR on a separate VM machine, but that was a half baked product that crashes weekly and it was so hopeless they introduced the UniFi protect now that requires their dedicated hardware. since I had invested in 12 of theirs cameras I forced myself to buy it recently and it is surprisingly neat.

1 Like

Dear Maurits,

I’ve started using OH long time ago on a Raspberry Pi. For known reasons, like SD card hassles and performance, I’ve moved the OH installation onto a howbrew Ubuntu machine.

The machine was designed as a silent NAS station with a single disk as the root partition and three large disks configured with as a software raid and managed by LVM- This gave me the freedom to add and change partitions as needed.

When starting to integrate OH and Ubiquiti on the same machine, like others here described, you will run into hassles concerning software version requirements of these systems. So the best approach is to give them separate environments. I’ve done that with virtual machines first, because they are easy to setup and manage but they come with a large overhead in terms of processing power as well as memory and disk allocation.

In my professional career I came across docker and soon realized that this would be perfect to also run on my howbrew machine for setting up and manage lightweight containers for isolated software environments.

For that reason I now use OH and the Ubiquiti controller on docker and gave them their isolated environments with suting Java and database versions.

The last step I did in this journey was to use the macvlan bridges/interfaces for both products. A macvlan gives the docker containers the illusion to have a dedicated network interface to the home lan. Both OH and Ubiquiti greatly benefit from this approach, because the auto discovery features (based on broadcasts) work perfectly well with it.

In contrast to the the host bridge of docker, macvlan interfaces have their own IP addresses and appear like dedicated machines/interfaces on the network. So the clients and the router see them like independent hardwares with own connectivity.

It also gave me the possibility to map OH to the standard port 80 and 443 so no more :8080 extensions in the URL when accessing OH.

I’m running this setup, If I remember right, for more than two years now and I’m perfectly satisfied with it.

1 Like