Category Archives: freebsd

Hooking up Harmony Hub and generic ZigBee Lights to HomeKit

Hooking up Harmony Hub and generic ZigBee Lights to HomeKit

Home automation seems to be the rage this christmas, with gadgets to control lights, heating and entertainment systems wirelessly, maybe even with only your voice.

I’ve been using Logitech’s Harmony Hub for many years now, and are very happy being able to switch on all devices needed and set them to the right channels: the TV, the surround receiver, the TV and an Apple TV, Fire TV or Bluray player, with single button press on a single remote.

Harmony Hub isn’t supported by Apple’s HomeKit, but so far, that wasn’t really a concern, since I wasn’t using anything else that would be able to be controlled by HomeKit. But in December, I broke down and got a bunch of Philips Hue lights. Naturally, tying Hue and Harmony together became a challenge.

I also have a number of light fixtures that Philips has no bulbs for; I decided to get an Osram Lightify Smart Plug to be able to at least turn the light off and on through the system. While it’s simple to connect the Smart Plug to the Hue controller, Philips somehow fails to offer up 3rd-party devices to either HomeKit or Hub. (Ikea Tradfri components seem to suffer the same fate.)

So I started looking around, to find a way to control everything through a single interface. It seems that HomeKit together with homebridge manages to do exactly what I want: offer all devices connected to the Hue hub to HomeKit (through homebridge-hue), and allow me to control the Harmony Hub (through homebridge-harmonyhub).

Here’s how I got this all working in FreeBSD.

Installing homebridge on FreeBSD

Creating a user

homebridge is a daemon process that mediates between HomeKit, Hue and Harmony. As such, it needs to run permanently. For security reasons, we do not want to run homebridge as root, but as a less privileged user homebridge. To create the user, I used vipw and consulted /usr/ports/GIDs to look for an id in the range below 1000 that is not yet used by any port. Instead of vipw, you can use adduser(1). I gave the user /usr/sbin/nologin as a shell since we’re never going to log in directly as a user.

Installing packages

There is no FreeBSD port for homebridge, but the installation is relatively straightforward. The installation instructions for homebridge insist that the NPM must be installed globally; I briefly tried to install locally, but couldn’t get it work.

Let’s start with the prerequisites, and a hack:

# pkg install npm-node8 avahi-libdns
# ln -s /usr/local/include/avahi-compat-libdns_sd/dns_sd.h /usr/local/include

The FreeBSD port for avahi-libdns puts the include file into its own subdirectory (so it won’t conflict with mDNSResponder), but the NPM packages expect it to be in /usr/local/include. The easiest way to fix this is to create the symlink. Since I’m running avahi, I have not investigated how to run homebridge with mDNSResponder.

After this, we can starting installing the NPM packages:

# npm install -g mdns
# npm install -g --unsafe-perm homebridge
# npm install -g homebridge-hue homebridge-harmonyhub

As of homebridge-harmonyhub 0.2.1, you’ll need to hack the broadcast address that it uses to find the Harmony Hub. Edit /usr/local/lib/node_modules/homebridge-harmonyhub/node_modules/harmonyhubjs-discover/lib/ping.js and change the address in line 9 to the appropriate broadcast address for the network that your Hub is connected to. For example:

this.address = '192.168.1.255';

Configuring Homebridge

Create a config file in the homebridge users’ home directory, as .homebridge/config.json. I created the initial file like this:

{
    "bridge": {
        "name": "Homebridge",
        "username": "CC:22:3D:E3:CE:30",
        "port": 51826,
        "pin": "031-45-154"
    },
    
    "description": "My Homebridge",

    "accessories": [
    ],

    "platforms": [
        {
            "platform" : "Hue",
            "name" : "Hue",
            "users": {
            },
            "lights": true,
            "nativeHomeKit": false,
            "sensors": true,
            "excludeSensorTypes": ["CLIPPresence", "Geofence"]
        },
        {
            "platform": "HarmonyHub",
            "name": "Hub",
        }
    ]
}

Then, start homebridge for the first time:

sudo -u homebridge homebridge

The output from this is important in two ways: homebridge-hue will connect to the Hue bridge, wait for you to press the button to authorise the pairing, and then display the username and token for this connection. You’ll need to copy the output and add it to the users key for the Hue platform entry in the configuration. You will need to restart homebridge for this config change to become effective.

Also, the terminal output will show a QR code you can use to connect homebridge as a bridge to HomeKit, using the Home app on your phone or iPad. You can also enter the code manually, in this example the code is 031-45-154.

Running homebridge as a daemon

There’s (at least) two ways to run homebridge in the background: using tmux(1) or daemon(8)

WIth tmux(1) (or screen(1)), you can run a terminal session independent of the current login. You can detach from that session at any time, and it will continue to run; you can also re-attach at a later time. This allows you to start homebridge, observe all the log output, and then detach from the session, keeping it running. If you need to look at the log output, you can reattach. This is most useful while you’re optimising the configuration, or trying out additional plugins.

For a more production-oriented setup, you can use daemon(8) and an rc(8) script. The following script /usr/local/etc/rc.d/homebridge creates a service homebridge that you can enable and disable from rc.conf(5):

#!/bin/sh
#
# PROVIDE: homebridge
# REQUIRE: NETWORKING SYSLOG
# KEYWORD: shutdown
#
# Add the following lines to /etc/rc.conf to enable homebridge:
#
#homebridge_enable="YES"

. /etc/rc.subr

name="homebridge"
rcvar="homebridge_enable"

load_rc_config $name

: ${homebridge_user:="homebridge"}
: ${homebridge_enable:="NO"}
: ${homebridge_facility:="daemon"}
: ${homebridge_priority:="debug"}

command="/usr/local/bin/${name}"
procname="/usr/local/bin/${name}"
home="$(eval echo ~${homebridge_user})"

pidfile="/var/run/${name}.pid"

start_cmd="${name}_start"

homebridge_start() {
	/usr/sbin/daemon -S -l ${homebridge_facility} -s ${homebridge_priority} \
		-u ${homebridge_user} -p ${pidfile} \
		/usr/bin/env -i \
		"HOME=${home}" \
		"PATH=/usr/local/bin:${PATH}" \
		$command
}

run_rc_command "$1"

Now the last thing I need to figure out is which Siri commands to use to activate a scene. Then I can switch on the entertainment center and dim the lights with a single voice command!

nsupdate woes

Over the past three days, I’ve been trying unsuccessfully to set up a fresh name server (using Ansible and Vagrant) to play around with nsupdate and some potential middleware to automate updating DNS zones. Unfortunately, I couldn’t find any good documentation on all the specifics, just a lot of how-tos that somehow all did’t really work for me. I kept getting this error:

client 127.0.0.1#60530: request has invalid signature: TSIG example.com: tsig verify failure (BADKEY)

I will upload my Ansible role for this to Github shortly, but I felt it necessary to spare the next person the pain of getting it all to work.

To use nsupdate, you need to give bind a key, associate that with a zone, and then use that key with nsupdate. Sounds easy enough, right? What all the tutorials fail to mention is that the key files and the name of the key entries in named.conf are all significant.

First, you need to decide what to call your key. It doesn’t matter for which zones you will use it, or from which hosts you will run nsupdate, but you will need to pick a name and stick to it. You can’t change it later, you will need to create a new key if you don’t like the name.

$ dnssec-keygen -a HMAC-MD5 -n HOST -b 512 mysamplekey

This will create two files. You need both of them, and you can’t change the files’ names.

Next up, you need to add the key to named.conf, and allow requests signed by that key to update a zone (or more):

key "mysamplekey" {
    algorithm hmac-md5;
    secret "base 64 encoded key";
};

zone "example.com" {
    allow-update { key "mysamplekey"; };
    type master;
    file "dynamic/example.com";
};

It is important to remember that “mysamplekey” needs to be the exact same string as from the key generation!

Armed with this configuration, you should be able to update example.com:

$ nsupdate -k Kmysamplekey+123+45678
debug yes
server 127.0.0.1
zone example.com
update add foobar 10 A 192.0.2.1
send

Ab Herbst muss man auch seinen PC rooten

Wer noch nichts davon gehört hat: Mit Windows 8 hat Microsoft die BIOS- und Systemhersteller „überzeugt“, dass PC nur dann mit Windows 8 geliefert werden dürfen, wenn diese SecureBoot unterstützen und per Default aktiviert haben. Gnädigerweise erlaubt Microsoft den Herstellern, SecureBoot abschaltbar zu machen. Wie einfach das geht, und ob es überhaupt implementiert wird, bleibt aber den Herstellern überlassen. Soweit so schlecht.

Fedora hat sich jetzt entschieden, über das Microsoft-Programm ihren Bootloader zu signieren, damit man in Zukunft Fedora booten (und installieren) kann, ohne SecureBoot auszuschalten.

Booting from an USB disk – even when your system doesn’t support it

I like using VMware Fusion on my Mac, but it has one shortcoming: it cannot boot from USB devices. You can use disk images (floppy, CD/DVD and harddisk) as well as a physical optical drive, but USB devices are not available. That’s unfortunate if you want to use VMware to prepare a hard disk for a machine, and want to test booting off that system before installing it in the machine.

When I install a new FreeBSD machine, I often start out from an existing FreeBSD machine and install directly from that running system, instead of booting off an install DVD. Obviously, using a virtual machine for this bootstrapping system, together with a USB hard disk adapter, is very convenient. But without being able to boot the VM off that USB disk, testing can be cumbersome.

I was very happy to come across Plop, a boot manager with many features. The most interesting one for me is it’s support for booting off USB devices without BIOS support. Plop includes its own U/O/EHCI driver, supporting standard USB 1.1 and USB 2.0 devices and ports.

Also very important: Plop can be run off a CD or floppy image, so you don’t need to (re-)configure your main hard disk. If I feel adventurous, I might look into patching the Plop BIOS extension into VMware, making booting even easier. For the time being, I’m using the floppy image, since none of my virtual (nor physical) machines have floppy drives any more.

Also, when you have an older machine which BIOS does not support booting off USB devices, Plop might be very helpful!

Getting sshd to start as early as possible

In FreeBSD, sshd by default gets started quite late in the boot process, about the same time a console will show the login prompt. There’s quite a few services that can make trouble and hang before that. Annoyingly, you can’t fix a stuck system via ssh, since it’s not started yet. But as it turns out, sshd can be started quite a bit earlier than FreeBSD does by default.

The rcorder keywords in /etc/rc.d/sshd normally look like this:

# PROVIDE: sshd
# REQUIRE: LOGIN cleanvar
# KEYWORD: shutdown

Change the rcorder keywords like so:

# PROVIDE: sshd
# REQUIRE: NETWORKING cleanvar
# BEFORE: mountcritremote
# KEYWORD: shutdown

 

Now sshd will be started right after the network has been configured.

Note that starting sshd before certain parts of the system are ready might give you temporary or permanent errors. For example, starting sshd before the user home directories are mounted might cause problems with logins. However, if your machine has all critical filesystems on local disks, making these changes should not pose any problems, and will allow you to log in while the rc scripts are still running, giving you the opportunity to fix any misbehaving services.

Running bash as root’s shell only when it’s not broken

I like bash, mostly for its interactive features over FreeBSD’s standard Bourne-compatible shell, ash.

Setting bash as the default shell for the root user however has a big downside: if you ever break bash or any of the libraries it depends on, you can’t log in as root anymore to fix it. I’ve tried quite a few ways to work around this, and I think I’ve finally figured out a good solution: leave the root shell as /bin/sh, and add this snippet at the end of /root/.profile:

[ -z "$BASH" ] && /usr/local/bin/bash -c 'true' && exec /usr/local/bin/bash

This will start bash, but only if the shell sourcing .profile isn’t bash, and bash can actually successfully be executed.

In FreeBSD 9, ash has apparently grown command name completion. Together with the editing functions (already available in FreeBSD 7), this might allow me to switch to ash as the default shell.

 

FreeBSD, CUPS and iPad printing

For the longest time, I couldn’t get CUPS configured on my FreeBSD server successfully. Between CUPS access rules, foomatic drivers and avahi announcements, I had terrible trouble making heads or tails of the nondescript error messages I was getting.

Spurned on by the arrival of an iPad, I finally sat down and worked through configuring CUPS and avahi. So I don’t have to go through all the fiddling again, here’s a recipe of what I did.

TEMPer USB Thermometer

Measuring temperature in a PC should be easy: after all, most mainboards have extensive monitoring capabilities for temperature and voltage levels built-in. Unfortunately, very few of these facilities are documented properly, and software support is lacking. Instead of trying to navigate the maze that is lm-sensors (which isn’t even available for FreeBSD), I decided to look for some USB-based solution.

There’s a reasonably cheap chinese USB thermometer called TEMPer. I got mine from Brando for 12 Euros. It’s a USB-to-serial chip from WinChipHead. It’s DTR, RTS, and CTS lines are used to connect a LM75 I²C temperature sensor. To talk to the LM75, you need some bit-banging driver.

I’ve put together a command line utility for the TEMPer that can program the built-in thermostat (TEMPer has a LED connected to that output) and print out temperature measurement data. It does it’s job, and might serve as an example on how to do I²C over a simple interface.

Patch to vmmouse to make it work in FreeBSD

Here’s a patch to the vmmouse port that activates the driver unconditionally. This makes the VMware mouse driver work in the default configuration in FreeBSD (7 and 8).

When xorg moved to use hal by default, the vmmouse driver needed to be registered with hal. This would work fine, except for the the current port version of hal (hal-0.5.11_25) not supporting a command line option that the probe script for vmmouse needs, and the matching code that determines whether to probe for VMware never matching on FreeBSD.

The patch unconditionally activates the vmmouse driver. This should be fine even when not running in VMware, as vmmouse should be compatible with the default xorg mouse driver.

FreeBSD ppp(8): work around invalid remote address

When connecting via a Huawai E169 UTMS USB stick through O2 Germany’s network, the data stick or the network suggests a PPP IPCP remote address of 0.0.0.0. FreeBSD refuses to ifconfig the tun interface with this endpoint address.

Fortunately, ppp(8) offers a configuration parameter to influence the IP addresses negotiated with the peer (ifaddr), and suggesting a different address will make the configuration work.

If you get this log output from ppp, you need to configure address selection:

IPCP: deflink: RecvConfigAck(4) state = Req-Sent
IPCP:  IPADDR[6] 10.68.235.57
IPCP:  PRIDNS[6] 193.189.244.197
IPCP:  SECDNS[6] 193.189.244.205
IPCP: deflink: State change Req-Sent --> Ack-Rcvd
IPCP: deflink: RecvConfigReq(47) state = Ack-Rcvd
IPCP:   [EMPTY]
IPCP: deflink: SendConfigAck(47) state = Ack-Rcvd
IPCP:   [EMPTY]
IPCP: deflink: State change Ack-Rcvd --> Opened
IPCP: deflink: LayerUp.
IPCP: myaddr 10.68.235.57 hisaddr = 0.0.0.0
Warning: iface add: ioctl(SIOCAIFADDR, 10.68.235.57 -> 0.0.0.0): Destination address required
Error: ipcp_InterfaceUp: unable to set ip address

Here’s my complete ppp.conf, with the ifaddr line included:

u3g:
	set device /dev/cuaU0.0
	set speed 115200
	set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0
	set authname internet
	set authkey  internet
	set log local phase ipcp
	set dial "ABORT BUSY TIMEOUT 2 \
		\"\" \
		AT OK-AT-OK \
		AT+CFUN=1 OK-AT-OK \
		AT+CMEE=2 OK-AT-OK \
		AT+CSQ OK \
		AT+CGDCONT=1,\\\"IP\\\",\\\"internet\\\" OK \
		AT+CGACT? OK-AT-OK \
		AT+CGATT? OK \
		AT+CGCLASS? OK \
		AT+COPS? OK \
		ATD*99***1# CONNECT"
	set crtscts on
	nat enable yes
	add default HISADDR
	disable dns

This applies to both 7-stable and 8-stable (with both the old and the new USB stacks). I’ve used u3g(4) on both occasions. The original ppp.conf for 3G modems is based off this one from Nick Hibma.

This is how it looks like when using ifaddr:

IPCP:  PRIDNS[6] 10.11.12.13
IPCP:  SECDNS[6] 10.11.12.14
IPCP:  PRINBNS[6] 10.11.12.13
IPCP: MS NBNS req 130 - NAK??
IPCP:  SECNBNS[6] 10.11.12.14
IPCP: MS NBNS req 132 - NAK??
IPCP: deflink: SendConfigReq(2) state = Req-Sent
IPCP:  IPADDR[6] 10.0.0.1
IPCP:  COMPPROTO[6] 16 VJ slots with slot compression
IPCP: deflink: RecvConfigReq(50) state = Req-Sent
IPCP:   [EMPTY]
IPCP: deflink: SendConfigNak(50) state = Req-Sent
IPCP:  IPADDR[6] 10.0.0.2
IPCP: deflink: RecvConfigRej(2) state = Req-Sent
IPCP:  COMPPROTO[6] 16 VJ slots with slot compression
IPCP: deflink: SendConfigReq(3) state = Req-Sent
IPCP:  IPADDR[6] 10.0.0.1
IPCP: deflink: RecvConfigNak(3) state = Req-Sent
IPCP:  IPADDR[6] 10.42.237.110
IPCP:  IPADDR[6] changing address: 10.0.0.1  --> 10.42.237.110
IPCP: deflink: SendConfigReq(4) state = Req-Sent
IPCP:  IPADDR[6] 10.42.237.110
IPCP: deflink: RecvConfigAck(4) state = Req-Sent
IPCP:  IPADDR[6] 10.42.237.110
IPCP: deflink: State change Req-Sent --> Ack-Rcvd
IPCP: deflink: RecvConfigReq(51) state = Ack-Rcvd
IPCP:   [EMPTY]
IPCP: deflink: SendConfigAck(51) state = Ack-Rcvd
IPCP:   [EMPTY]
IPCP: deflink: State change Ack-Rcvd --> Opened
IPCP: deflink: LayerUp.
IPCP: myaddr 10.42.237.110 hisaddr = 10.0.0.2
PPP ON freebsd-current>