While the 2nd generation Unifi Cloudkey hit the market last year, a lot of Gen1 version have become available on the 2nd hand market.
Such a small device got me thinking, is this a viable replacement for my old Raspberry Pi B+ that runs my Homebridge setup? I found out that I’m not the only one thinking of this idea, and found inspiration in this blogpost. And so I bought one!
The handy thing of the Cloudkey is the fact that you get PoE support out of the box. Of course, the latest Raspberry Pi’s have this as well, but getting your hands on a 2nd hand version Cloudkey saves you the investment of a case for the Pi.
So, what’s next?
Once installed you’ll be able to access the Cloudkey via ssh. You’ll end up on a Debian Jessie based OS. And thus we can just add our own stuff!
Unfortunately the implementation comes with a version 6 of NodeJS, which is way too old for a proper functioning Homebridge setup. And that’s where the challenge was in this case. You don’t want to remove the NodeJS 6 version, because some of the Bluetooth Proxy tooling of Unifi relies on it.
So we’ll have to run multiple versions of NodeJS. Node Version Manager to the rescue!
Install NVM first and activate it.
Download the latest NodeJS 10 version via: nvm install lts/dubniun
If this works properly, ‘node -v’ will show the version active in NVM instead of the NodeJS version 6 which is the system default.
Install homebridge: npm install -g homebridge –unsafe-perm
Create the /etc/default/homebridge file with the following content:
# Defaults / Configuration options for homebridge # The following settings tells homebridge where to find the config.json file and where to persist the data (i.e. pairing and others) HOMEBRIDGE_OPTS=-U /data/homebridge # If you uncomment the following line, homebridge will log more # You can display this via systemd's journalctl: journalctl -f -u homebridge #DEBUG=*
And the /etc/systemd/system/homebridge.service file with the following contents:
[Unit] Description=Node.js HomeKit Server After=syslog.target network-online.target [Service] Type=simple User=root EnvironmentFile=/etc/default/homebridge ExecStart=/root/.nvm/versions/node/v10.22.1/bin/node /root/.nvm/versions/node/v10.22.1/bin/homebridge $HOMEBRIDGE_OPTS Restart=on-failure RestartSec=10 KillMode=process [Install] WantedBy=multi-user.target
The trick here is to prefix the execution by the NodeJS version that you want to use. If we wouldn’t be doing this, automatically the older system default version would be used.
If you have created your first config.json file in /data/homebridge you should be able to activate it:
systemctl daemon-reload systemctl enable homebridge systemctl start homebridge
You might have noticed the folder that I chose to point to for the config.json and data. The /data folder is mounted from the SD-card (if you have one), to prevent firmware updates from wiping your settings. If you don’t do this, a firmware upgrade will wipe everything! (It turns out that if you do a firmware upgrade from the controller interface, you’re safe!)
Upgrading your NodeJS version is as easy as: ‘nvm install lts/dubnium –reinstall-packages-from=node’. This will reinstall all packages, just don’t forget to update homebridge.service file to reflect the correct version.
If you’d like to install homebridge-config-ui-x to have web interface to control the homebridge installation, you also have to put some additional commands to be able to successfully install the plugin.
/root/.nvm/versions/node/v10.22.1/bin/node /root/.nvm/versions/node/v10.22.1/bin/npm install -g --unsafe-perm homebridge-config-ui-x
If you don’t do this, installation of the plugin will fail due to the fact that the installation process forks itself and will start using the OS installed version of Node, which is still version 6.x.