Connecting an iHome SmartPlug to Home Assistant

We moved recently into an apartment with a detached garage, and naturally, I wanted to incorporate that space into our home automation. To extend our network to the garage, I opted for powerline ethernet adapters, but soon discovered that the garage’s fluorescent light cuts the powerline connection.

To overcome this, I purchased an iHome iSP8 SmartPlug. It connects via wifi, which was a requirement since I don’t have a smart hub in the garage nor do I wish to add one there. It also includes a physical remote that I can mount near the now-disabled switch for the fluorescent lights.

Unfortunately, the setup process for the iSP8 was not a smooth one. I’m an Android user, and the iHome products are intended to be set up from an iOS device. They purport to support Android setup, but I was unsuccessful despite several attempts. I did manage to connect it to my network once, but the device wasn’t recognized by iHome’s cloud, leaving it orphaned.

In the course of debugging the setup, I noticed that my MacBook’s wifi adapter detected the plug’s wifi network not as a standard network, but as that of an accessory. This proved to be the key to joining the plug to Home Assistant via its HomeKit component.

To pair the iSP8 to Home Assistant via the HomeKit component:

  1. Reset the SmartPlug by holding down the device button for 15 seconds, until the wifi indicator alternates between red and green.
  2. Ensure the MacBook’s wifi adapter is enabled.
  3. From the MacBook’s list of detected wifi networks, select the iHome network from the “Accessories” section of the list (this will appear after, and separately from, the list of standard wifi networks).
  4. Airport Utility will open to configure the plug’s connection. When prompted, select the wifi network that the plug should join; only 2.4GHz networks are supported.
  5. After the plug joins the network (indicated by a solid green wifi light), unplug and replug the device. This is necessary for the device to fully join the network and be visible to Home Assistant.
  6. Confirm that the plug is visible on your network. This can generally be done via the admin interface or app that is used to configure your wifi.
  7. Restart Home Assistant to trigger it to scan the network for new HomeKit devices.
  8. Open Home Assistant and go to Configuration > Integration. If the plug doesn’t appear for configuration, click the plus icon to open the configuration wizard and select “HomeKit Accessory” from the choices.
  9. Select the iHome device from the list presented, then when prompted, enter the plug’s HomeKit PIN, including the dashes. If the dashes are omitted, pairing will fail.
  10. Confirm via the States developer tool that the switch is available in Home Assistant.

After one of the myriad failed attempts to set up the iSP8 via the iHome Control app, the plug was left in a state where it was connected to my network, but wasn’t recognized by the iHome cloud. At that point, I attempted to pair the device with Home Assistant, but the existing pairing with the app prevented Home Assistant from connecting to the plug. It is for this reason that the plug must be reset and joined to the network via Apple’s Airport Utility.

Compiling nginx with GitLab CI

Continuing my series on the fun I’m having with GitLab CI, it’s time to discuss using it to automate nginx builds. I’ve previously written about how and why I use a custom build, and a few months ago, I decided to remove the monotony from the process.

Now, when a new mainline release is available, or OpenSSL releases a new version, I update a few CI variables, run a pipeline, and a new nginx binary is available within a few minutes. I’m also able to build for multiple versions of Debian.

Continue reading Compiling nginx with GitLab CI

Automating plugin releases to WordPress.org using GitLab CI

I got started in WordPress development as many do, by writing a plugin. It, along with nearly a dozen others that I’ve released in intervening years, don’t require much attention, so I’ve generally neglected even the most-basic of maintenance: confirming each is compatible with the latest WordPress release and updating the readme accordingly. I’ve felt guilty about this for some time now, but it wasn’t until this weekend that that guilt compelled me to action.

Continue reading Automating plugin releases to WordPress.org using GitLab CI

Monitoring and culling stale GitLab Runner instances

After I set up GitLab’s continuous integration using DigitalOcean Droplets for autoscaling, I noticed that sometimes, a runner would fail, abandoning a Droplet that I’d manually need to destroy. While this problem was infrequent, it was troublesome-enough to warrant some automated solution. Not finding anything readily available, and thanks to DigitalOcean’s godo library, I put together a Go program to periodically cull stale Droplets.

Continue reading Monitoring and culling stale GitLab Runner instances

Four years of HSTS preloading

I recently wondered how long it had been since I added ethitter.com to the Strict Transport Security preload list, as it’s been several years. I added my domain without fully understanding the consequences, though I’ve been fortunate to avoid any problems that could’ve resulted.

Getting back to my original question, version control made it easy to find August 18, 2014 as the date my domain landed in Chromium’s list: https://src.chromium.org/viewvc/chrome?view=revision&revision=290306. At the time, it was one of less than 1,000 domains in the preload list; the bulk of the list was comprised of Google’s own domains. There are currently over 40,000 preloaded domains in Chrome/Chromium. It’s a good thing preloading hasn’t been an issue, it takes a while to get off the list.

Restoring performance after Spectre updates

Two weeks ago, the VPS that hosts this site moved to a machine that had been patched for the Spectre vulnerabilities. Immediately, I began receiving warnings about high load, and these alerts continued unabated for over a week. I tried moving services to other hosts, and I reduced the resources allocated to nginx and php-fpm, all to no avail.

As I continued to monitor and debug the situation, fail2ban regularly appeared among the top resource consumers, but I didn’t think much of it; fail2ban has always been a voracious resource user, but it’s an indispensable tool, so removing it wasn’t an option.

Continue reading Restoring performance after Spectre updates