The big announcement at Google I/O ‘19 is that Google is discontinuing the Works with Nest API program. Nest is the only no-local-control ecosystem I have in my house, and it was so very clearly a mistake in hindsight. In order for an end user to integrate Nest with a third party product like Home Assistant, one needs a developer account. Right off the bat, Nest assumed that the only people who would want to do such a thing is other cloud-based services like Hue, or Amazon who would interact with Nest on behalf of a user, rather than a user themselves.

I currently have a developer account, and I use it with Home Assistant to do a number of automations tied to my Nest devices. There’s a lot of customized control over when the HVAC goes into away (eco) or home mode based on the arrival and departure - or expected arrival - of my home’s residents. More interestingly, a number of automations around Nest Protect enhance the safety of my home by unlocking the doors if people are home, turning on lights, and disabling the HVAC system in the event of an incident.

None of these would be possible if Nest shuts down the Works with Nest program, other than whatever specific partner integrations they allow. This is all in the name of “privacy,” which in Google’s mind is that your private information is only known by you and Google. Why, then, have they not assauged the hobbyist communitys concerns by announcing a local API option?

The protocols that Nest devices use are open source-ish, called Weave and Thread. Certainly they could open them up to allow me to control my own devices. Anyway, even if Google eventually figures it out and does the right not-evil thing, I figured I should look at alternatives.

For now, I’ve already replaced my thermostat with a Venstar ColorTouch T7850. It features a local API, and a home assistant component.

It’s not as pretty as a Nest’s round, sleek appearance but it’s works well and has full local control. The Nest Protects’ most likely replacement is a Z-wave device from First Alert, but for now I’ve kept them. I do like their voice announcements of the problem - in Spanish and English - and the pathlight feature when one walks down the hallway at night.

In UEFI 2.5, HTTP boot was introduced. This feature allows a UEFI host to network boot using HTTP instead of TFTP. If you enroll a trusted certificate authority on the server, then you can boot securely using HTTPS. This is a vast improvement over older mechanisms that make use of insecure protocols like TFTP.

Lukáš from the Foreman project proposed an RFC to enable this functionality in Foreman. Much of this is now implemented: Foreman has an HTTPBoot Smart Proxy module that serves the TFTP boot directory via HTTP, and makes Foreman aware of various DHCP settings. There are still some issues to be resolved before this is ready for users to use.

This blog post is mostly my notes from us researching how HTTP boot works, how grub2 supports HTTP boot, and how to test with libvirt. We used the edk2 firmware for QEMU/KVM, although much of these notes are generally applicable to hardware as well - we’ve tested on at least one real world baremetal server and was able to provision end-to-end using HTTPS.

Configure libvirt

Out of the box, QEMU will use BIOS. However, you can install the Tianocore firmware to get UEFI. This package is called edk2-ovmf on Fedora.

If you are on CentOS 7 or want to use the latest nightlies, you can get them from this fedora documentation. Last I checked, they don’t have TLS support compiled, which means you can’t enroll a TLS certificate to make HTTPS boot work. The Fedora firmware does support this.

After installing the firmware package on CentOS, you’ll also need to configure the nvram setting in /etc/libvirt/qemu.conf. Newer Fedoras are already aware of and will look in this path for firmwares:

nvram = [
  "/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd:/usr/share/edk2.git/ovmf-x64/OVMF_VARS-pure-efi.fd"
]

Once you do that, you can create an UEFI VM, by selecting a UEFI x86_64 firmware:

Configure DHCP

Your DHCP configuration must be aware of HTTP clients in order to set the filename to an URL. The relevant snippet from my own DHCP config is below. It’s important to set the vendor-class-identifier as HTTPClient, otherwise your host will not use the filename as an HTTP URL.

option arch code 93 = unsigned integer 16; # RFC4578

# This is for UEFI HTTP:
class "httpclients" {
  match if substring (option vendor-class-identifier, 0, 10) = "HTTPClient";
  log(info, "HTTP UEFI Client Detected");
  option vendor-class-identifier "HTTPClient";

  if option arch = 00:0F {
    filename "http://example.com/bootia32.efi";
  } else if option arch = 00:10 {
    filename "http://example.com/bootx64.efi";
  }
}

Boot loader

I’ve tested HTTP boot with both iPXE and grub2. If iPXE supports your network card, you might consider using it. It supports UEFI HTTP Boot well.

If you want to use grub2, hang on to your hat - there’s a number of bugs in any of the latest shipped versions, including in Fedora 30. Fixes that enable using relative paths will ship in Fedora 31. The bug for that is here.

If your grub2 configuration uses fully qualified paths in all places, you won’t need this patch, but you won’t be able to use your grub2 configuration for both legacy TFTP and HTTP clients.

Enrolling a CA Certificate

For libvirt, I created a VFAT image, and stored a copy of my CA certificate there:

$ dd if=/dev/zero of=/tmp/ca.img bs=1440K count=1
1+0 records in
1+0 records out
1474560 bytes (1.5 MB, 1.4 MiB) copied, 0.000856816 s, 1.7 GB/s
$ mkfs.vfat /tmp/ca.img
mkfs.fat 4.1 (2017-01-24)
$ sudo mount -o loop /tmp/ca.img /tmp/mnt
$ sudo cp /tmp/ca/ca.crt /tmp/mnt
$ sudo umount /tmp/mnt
$ sudo cp /tmp/ca.img /var/lib/libvirt/images

I then attached it to libvirt:

and enrolled the certificate in the Device Manager menu:

Assuming your DHCP configuration is setup correctly, then you can select HTTP boot from the Boot Manager, or reboot the host, and you will boot via HTTPS.

My “smart house” started out a few years ago as a couple of Hue light bulbs in my apartment. Now that we’ve bought a house, I started acquiring a few more smart things here and there, and over the last couple of months I finally decided to integrate them all together using an open source project called Home Assistant.

To be honest, I didn’t start out with a plan, and I wish I had. However, with few exceptions all the things I’ve bought play nicely together. Home Assistant has allowed me to develop a number of interesting things.

When no one is at home, the house puts itself in away mode: lights and televisions get turned off, my thermostat temperatures set to Eco mode, and all of the doors get locked. Presence detection is done through the Unifi module, which looks for devices on our main and Guest WLAN’s. Solar production is tracked, and in case of a grid failure, power-hungry devices like the space heater in our sunroom, or the A/C are turned off or adjusted.

Home Assistant is also fully integrated with Amazon Alexa through the HA Cloud project. I’m able to control all my devices through HA instead of using each platform’s integration. Custom skills even do things like report on my solar system, or answer questions about if someone is home.

I also use HADashboard and an old iPad mounted to the kitchen wall:

Home Network

Goal number one when we moved into the house was getting it wired for CAT6, and a small equipment rack installed in the basement. I switched over from DD-WRT to Unifi last year, and now that I’m in the house I’ve bought a few more Unifi things. My network consists of:

• UniFi security gateway
• 2x 8 port 60W POE Switch
• 1x 8 port switch
• 2x UniFi AP-AC-Pro

The main challenge was getting the CAT6 to the various rooms, and learning how to punch down a keystone jack. I ended up buying a spool of CAT6 on Amazon along with keystone jacks, wallplates, a cable tester, etc. It was slow-going at first, but I managed to finagle network drops to all the rooms I wanted: living room, office, kitchen for the access point, and the basement family room. Each room has several drops going to it, as I never really want to have to do this again! Although eventually I plan to add some POE cameras, so I may have to run some network drops outside.

The network is split into 3 VLAN’s, with limited connectivity between each:

• Main network
• Guest network
• Internet of Shit things

Lighting

My first “smart house” devices were Hue light bulbs, which work very well and have a wonderfully open API and developer-friendly attitude. I still have quite a few Hue devices, and plan to add a few more like the Hue Go. For wall switches however, now that I actually owned the property I could use a little bit more full featured smart switches instead. All my reading lead me to narrow down my options to Z-Wave switches from GE, Lutron Caseta and Insteon. Insteon has a large ecosystem of smart things, and came highly reccomended from a friend of mine. But Caseta devices were easily available locally, and they’re pretty, especially with the Claro wall plates.

I had heard bad things about Z-wave range and reliability, although I do actually own a few non-lighting Z-wave devices now. The downside to the others is that both Lutron Caseta and Insteon are proprietary protocols, with proprietary hubs. Lutron needs the Pro hub if you want an open telnet port for reliable integration with third party tooling. The consumer hub has been reverse engineered from the Android app, and there’s a Home Assistant component but it breaks every so often.

Z-wave seems to be the way to go if you want a more open protocol, and in retrospect now that I own a few Z-wave devices, I would probably have used it for my lights too.

But, I am happy with Lutron. It works well with Home Assistant, and their customer service is top notch.

Nest Ecosystem

Through my utility provider, I bought a Nest thermostat at a substantial discount. It was my first Nest product, and despite being owned by Google, has a pretty open API. I later bought Nest Protect fire alarms: they looked nice, and the nightlight feature was really handy to light up the hallway to the bathroom at 3 a.m. I’m very happy with these products. They integrate well with Home Assistant.

My last Nest product, however, was a different story.

Locks

Being happy with the other Nest products, I decided on buying a Nest x Yale lock. I made some assumptions that were wrong, based on my experience with other Nest devices and the “Works with Nest” logo on the box.

The lock has no API. It has no Amazon integration. It does, however, have integration with Google Home. I believe this is intentional on Google’s part to close down new Nest products from third party services, and suck people into Google Home. I sold my lock on eBay.

Now on the hunt for new locks, I came to the conclusion I might as well bite the bullet and get into Z-wave. I’m glad I did. I bought 2 used Yale 210’s on eBay, and a Schalge Camelot for the main door. They didn’t work seemlessly, but I ended up needing to write a patch to fix some quirks.

Solar

A big consideration for me when I bought the house was having a good potential for solar. My house isn’t in a perfect position, as it faces southeast/northwest, but I was able to get panels on both sides meaning in the end I fit a bigger system than I could have otherwise. I have 30x 295W panels, for a total of 8.85kW, and an underclocked SolarEdge 7.6kW inverter. In the first month of operation, I produced over 1100kWh - more than double our usage. The net metering credits from that production should help in the winter when there’s less sun.

In addition to the solar, I have a Powerwall 2. The Powerwall operates in backup mode, and will take over in case of a grid failure, powering the house by battery and available solar. Home Assistant sends out notifications, and enacts power conservation measures like adjusting the thermostat, and turning off power-hungry devices.

I’ve also integrated information about my solar from the SolarEdge API using Home Assistant’s REST sensors, which displays nicely on HADashboard: