Migrating from SmartThings to Zigbee2MQTT with Home Assistant

Posted by on

Sadly, Samsung seem to be winding down their SmartThings Zigbee/ZWave home automation setup and it has always been quite painful using devices that weren’t officially supported. I’ve recently migrated my non-SmartThings native devices to Zigbee2MQTT, here’s how I did it:

  • Purchase a SBC, in my case an OrangePi 4 running Armbian/Ubuntu – but a Raspberry Pi 4 is more mainstream. Set it up on your home network (perhaps you already have this running Home Assistant).
  • Buy a supported zigbee adaptor. I strongly recommend the electrolama zzh adaptor (this requires firmware flashing post purchase, but this is straightforward).
  • Install the adaptor, ideally via a USB extension cable.
  • Install zigbee2mqtt.
    • The version of node installed wasn’t recent enough; I downloaded a newer version.
    • As the name suggests, you’ll have to set up an MQTT server, typically mosquitto to receive the status messages.
  • Configure zigbee2mqtt / Home Assistant integration.
  • Add your zigbee devices.
  • Reconfigure your Home Assistant Automations etc if necessary.

Alpine Linux default gateway on different subnet

Posted by on

As Alpine Linux uses busybox for a lot of its system tools it won’t set up the necessary routing if you have a default gateway on a non-local subnet to the IP. You want /etc/network/interfaces to look something like this:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address IP.ADDR.ADDR.ADDR
netmask 255.255.255.255   # or whatever is netmask
up route add DEFAULT.GW.IP dev eth0
up route add default gw DEFAULT.GW.IP

then run alpine-setup again

Testing Enterprise Infrastructure changes with brownouts

Posted by on

Decommissioning or migrating services in enterprise environments will frequently reveal previously unknown dependencies which result in changes getting rolled back, wasting a lot of time.

To try and head these issues off you can test these changes with “brownouts”, shutting off the relevant infra temporarily (eg at a weekend) to expose any hidden dependencies.

When brownout testing, the following need to be borne in mind:

  • Dependencies may only be exposed for certain functions. Eg at startup, shutdown or other operations such as login. Thus a full test suit should be run and components restarted.
  • The effects of DNS, such as caching.
  • Regional differences.