Everything worked on the desk. Home Assistant was running on the old laptop. Time to connect the real garage door opener, put a button on my phone, and make it reachable from outside the house.
My opener has a 6-pin green spring-clamp terminal block with little orange tabs. My jumper wires were too thin to stay put.
What I learned:
The morning after my first successful test, the wires had slipped half out of the opener.
What I learned: on a spring-clamp terminal you press the orange tab down first (small screwdriver or pen tip), push the wire in, then release the tab. I had just been shoving wires into the holes, so the spring never clamped. A gentle tug test tells you immediately.
On the relay’s three screw terminals the middle one is COM. I had put a wire into NC (normally closed), which would mean “button held down” whenever the relay is off. Wires go to COM + NO. Polarity doesn’t matter on the opener side.
In configuration.yaml:
rest_command:
toggle_garage:
url: "http://<pi-ip>:5000/api/toggle"
method: "POST"
rest:
- resource: "http://<pi-ip>:5000/api/ping"
scan_interval: 30
sensor:
- name: "Garage API Status"
unique_id: garage_api_status
value_template: "{{ value_json.status }}"
What I learned:
found character '\t' that cannot start any token → YAML forbids tabs. Spaces only.rest sensor needs a restart.rest_command.toggle_garage before building UI.rest_command.toggle_garage. (In my Finnish UI: Muokkaa kojelautaa → Lisää kortti → Painike.)/api/webhook/<id> can now open the door.After the Pi had sat untouched for a while, SSH greeted me with a cascade of errors:
no matching key exchange method found ... diffie-hellman-group1-sha1
no matching host key type found. Their offer: ssh-dss
no matching cipher found. Their offer: aes128-cbc,...
Host key for 192.168.x.50 has changed
…and after forcing all the legacy options, Connection closed by remote host.
What I learned: check the router’s DHCP client list before fighting SSH. The Pi’s IP had changed, and a completely different (and much older) device had taken over the old address. All those legacy crypto errors came from that device, not my Pi. With the Pi’s new IP, SSH just worked, no legacy flags needed. If SSH suddenly starts complaining about ancient algorithms, first ask: am I even talking to the right machine? Two fixes:
/api/ping + systemctl status garage.service tells you within seconds whether everything survived.To open the door when I’m not on the home Wi-Fi, I went with Tailscale instead of opening ports on the router.
What I learned:
use_x_forwarded_for and trusted_proxies.On antiX, tailscale up failed with failed to connect to local tailscaled; it doesn't appear to be running. Install scripts assume systemd, which starts tailscaled for you; on antiX’s init it doesn’t happen. Start it yourself, then log in:
sudo tailscaled &
sudo tailscale up
To survive a reboot, tailscaled has to be added to antiX’s own service management.
http://100.x.x.x:8123).And it worked. With tailscaled running on the laptop and the Tailscale VPN switched on in my phone, I could open Home Assistant from outside the house and tap the garage button. No ports opened on the router, and nothing exposed to the public internet. The one thing to remember is that the Tailscale VPN has to be connected on the phone; without it, the 100.x address goes nowhere.
Phone (HA app, via Tailscale)
→ antiX laptop running Home Assistant in Docker
→ REST call over Wi-Fi
→ Raspberry Pi 1 (Flask, behind a Wi-Fi extender's Ethernet port)
→ USB serial
→ Arduino Uno
→ Keyes relay (COM + NO)
→ garage door opener push-button terminals
dmesg, ssh -v and the router’s client list answer most “why doesn’t it work” questions.From “can I make my garage door talk to an API?” in early July to opening it from my phone over Tailscale in October: it works. 🚗🚪
]]>I could now open the door with curl. For a phone-friendly UI I wanted Home Assistant, and the Pi 1 is far too weak for it. What I did have was an old Fujitsu Siemens laptop (1.8 GHz CPU, 2 GB RAM) dual-booting Windows Vista and Lubuntu 18.04. This post is about turning it into a server, which included a genuinely clever workaround.
The Wi-Fi card wouldn’t connect: nmcli device showed it as unavailable, and the GUI said “device not managed”.
Debugging path:
lspci -knn | grep -A3 Network # Atheros AR242x, but no "Kernel driver in use"
sudo modprobe ath5k # load the driver
dmesg | grep -i ath # driver happy, card named wls1
rfkill list # nothing blocked
What I learned: the driver was fine; Netplan was configured so that NetworkManager didn’t manage the card. The fix was a three-line file in /etc/netplan/:
network:
version: 2
renderer: NetworkManager
sudo netplan apply
…and Wi-Fi networks appeared.
cat /etc/os-release showed 18.04.5, out of support since April 2021 (Lubuntu flavours only got three years).I wiped Windows Vista too. Nothing on it was needed.
This is where things went sideways. Every installer stick failed:
| Attempt | Result |
|---|---|
| Debian netinst via Startup Disk Creator | “This is not a bootable disk” |
Debian, written with dd |
same |
| Full Debian DVD, different stick | same |
| Ventoy (MBR) + ISO | Black screen, blinking cursor |
| Ventoy GPT for UEFI | Not even listed |
antiX via Ventoy, then via dd |
Black screen, blinking cursor |
Things I learned along the way:
sudo apt install exfat-fuse exfat-utils before you can copy ISOs onto it.umount, not unmount. (Yes, really.)The machine booted its existing GRUB from the hard drive perfectly. So instead of fighting the BIOS, I let GRUB start the antiX live system straight from the disk:
# 1. Mount the ISO and copy the kernel + initrd into /boot
sudo mkdir -p /mnt/iso
sudo mount -o loop ~/Downloads/antiX-*.iso /mnt/iso
sudo cp /mnt/iso/antix/vmlinuz /boot/vmlinuz-antix
sudo cp /mnt/iso/antix/initrd.gz /boot/initrd-antix.gz
# 2. Copy the live filesystem folder to the root of the disk
sudo cp -r /mnt/iso/antix /
sudo umount /mnt/iso
Then add a menu entry to /etc/grub.d/40_custom:
menuentry "Install antiX from hard disk" {
insmod ext2
set root=(hd0,5)
linux /boot/vmlinuz-antix from=hd antiX=all
initrd /boot/initrd-antix.gz
}
sudo update-grub
Each error on the way taught something:
| Error | Meaning / fix |
|---|---|
no such partition / you need to load the kernel first |
GRUB couldn’t find the partition. df /boot said /dev/sda5; with insmod ext2, (hd0,5) worked. |
file /initrd-antix.gz not found → kernel panic |
The initrd line was missing the /boot/ prefix. |
Could not find file antix/linuxfs |
The live system needs the whole antix/ folder copied to the disk root. |
Then: antiX booted to a desktop. 🎉
The graphical installer showed an empty partition list, because the live system was running from /dev/sda5 and the installer locked the disk.
What worked:
cli-installer in a terminal./home, and install GRUB to the MBR (legacy BIOS).antiX doesn’t use systemd, which tripped up nearly every guide:
docker.io from the repos didn’t give me a working docker command. Following Docker’s official Debian instructions did.sudo service docker start → docker: unrecognized service. Try sudo /etc/init.d/docker start, or start dockerd directly.sudo docker run hello-world is the “is it alive?” test.docker: invalid reference format = a copy-pasted multi-line command with broken \ line breaks. Put it on one line:sudo docker run -d --name homeassistant --privileged --restart=unless-stopped \
-m 1G --memory-swap 1G \
-v ~/homeassistant:/config \
--network=host \
ghcr.io/home-assistant/home-assistant:stable
More things I learned:
-m 1G --memory-swap 1G caps Home Assistant’s memory so it can’t starve the whole laptop. Changing it means docker stop, docker rm and docker run again; your config survives in ~/homeassistant.--restart=unless-stopped brings the container back if the Docker daemon starts at boot. On a SysV-style init that’s sudo update-rc.d docker defaults.sudo chown -R $USER:$USER ~/homeassistant fixes “Permission denied” when editing configuration.yaml.renderer.service, /etc/init.d and update-rc.d.Next up: finally connecting the real garage door, and reaching it from outside the house.
]]>With the Arduino clicking on command (Part 1) and the Raspberry Pi finally reachable (Part 2), it was time to connect them:
Laptop/phone → Wi-Fi → extender → Pi (Flask API) → USB serial → Arduino → relay
Plug the Arduino into the Pi with a USB data cable, then:
ls /dev/ttyUSB* /dev/ttyACM* # clones often show up as ttyUSB0
dmesg | tail -n 20 # look for "ch341-uart ... attached to ttyUSB0"
lsusb # is it on the bus at all?
Let your user access serial ports without sudo (log out/in or reboot afterwards):
sudo usermod -a -G dialout $USER
Before writing any Python, talk to the Arduino directly:
sudo apt install screen
screen /dev/ttyUSB0 9600
# type o → relay clicks
# exit with Ctrl+A, then \
import time
import serial
from flask import Flask, jsonify
SERIAL_PORT = "/dev/ttyUSB0"
ser = serial.Serial(SERIAL_PORT, 9600, timeout=1)
time.sleep(2) # the Arduino resets when the port opens
app = Flask(__name__)
@app.route("/api/toggle", methods=["POST"])
def toggle():
ser.write(b"o")
return jsonify({"status": "triggered"})
@app.route("/api/ping", methods=["GET"])
def ping():
return jsonify({"status": "ok"})
if __name__ == "__main__":
app.run(host="0.0.0.0", port=5000)
The /api/ping endpoint turned out to be very handy later for health checks in Home Assistant.
Running the script by hand doesn’t survive a reboot, so it became a systemd unit at /etc/systemd/system/garage.service:
[Unit]
Description=Garage Door API
After=network.target
[Service]
ExecStart=/usr/bin/python3 /home/<user>/garage/garage_server.py
WorkingDirectory=/home/<user>/garage
Restart=always
User=<user>
[Install]
WantedBy=multi-user.target
My first systemctl start failed with Unit garage.service not found.
What I learned: systemd doesn’t watch that folder. After creating or editing a unit file you must run:
sudo systemctl daemon-reload
sudo systemctl enable --now garage.service
sudo systemctl status garage.service
sudo journalctl -u garage.service -n 50 --no-pager # when something's off
The service started, but couldn’t talk to the Arduino. The culprit was my forgotten screen session from step 2, still holding /dev/ttyUSB0.
screen -ls # list sessions
screen -X -S <session_id> quit # kill one
sudo fuser /dev/ttyUSB0 # who is using the port?
sudo fuser -k /dev/ttyUSB0 # make them stop
sudo systemctl restart garage.service
TIL: a serial port is exclusive. Serial Monitor,
screen, a stray Node script: any of them will silently block your service.
From my laptop:
curl -X POST http://<pi-ip>:5000/api/toggle
Click. The whole chain worked end to end.
At this point anyone on my Wi-Fi who knows the Pi’s IP can “press the button”. Easy first improvements:
X-API-KEY) and return 401 without it.screen → curl.daemon-reload after every unit file change./ping endpoint from day one.Next up: I needed a proper home for Home Assistant, which meant reviving a very old laptop.
]]>In Part 1 I decided a Raspberry Pi would host the API and talk to the Arduino over USB. The Pi I had is a first-generation Model B: no Wi-Fi, two USB ports, and a very old Raspbian on the SD card. Getting it reachable on my network turned into the longest chapter of the whole project.
Buying advice I got (and would repeat):
What actually happened:
wpa_cli -i wlan0 reconfigure failed with Failed to connect to wpa_supplicant - wpa_ctrl_open: No such file or directory.sudo raspi-config had no network options at all. That’s the tell that you’re on a very old Raspbian (Wheezy/Jessie era). Back then Wi-Fi was configured in /etc/network/interfaces:
auto wlan0
allow-hotplug wlan0
iface wlan0 inet dhcp
wpa-ssid "YOUR_SSID"
wpa-psk "YOUR_PASSWORD"
Still nothing, so I checked whether the hardware was even seen:
lsusb # only the internal hub + Ethernet chip, no dongle
dmesg | tail -n 20 # the real story
What I learned from dmesg: the dongle was detected for a moment (a Realtek chip, driver r8188eu), then two things went wrong:
rtlwifi/rtl8188eufw.bin was missing (error -2), andUSB disconnect, most likely the Pi 1’s USB port browning out when the radio powered up.So: missing firmware and not enough power. Two problems that look like one.
TIL:
lsusbtells you if the hardware is there now.dmesgtells you what happened when you plugged it in. Readdmesgfirst.
Instead of fighting the dongle, I put a Wi-Fi range extender with an Ethernet port next to the Pi. The extender joins the home Wi-Fi and the Pi just sees a normal wired network.
Setting up a TP-Link extender, three ways:
http://tplinkrepeater.net (or 192.168.0.254).Configure it next to the router, then move it roughly halfway to where you need the signal.
The Ethernet LEDs on the Pi were lit, but the Pi never got an IP address. Things worth checking:
192.168.x. range, they can’t talk.In the end the quickest fix was a fresh SD card image.
I flashed a new image with Raspberry Pi Imager and used its settings (gear icon) to enable SSH and create my own user. The Pi booted and showed its IP. SSH said Connection refused.
What I learned about debugging SSH, in order:
ping the Pi. If ping works, the network path is fine and the problem is the SSH service or the address.ssh -v user@ip shows where the handshake stops.
Clear the old fingerprint if you’ve connected to that IP before:
ssh-keygen -R 192.168.x.x
ssh in the boot partition of the SD card, or borrow a keyboard and run sudo systemctl enable --now ssh.Also: you can’t SSH to a MAC address. You can use the MAC address in your router to find, or permanently reserve, the Pi’s IP.
Eventually I was in. 🎉
dmesg > guessing.ssh -v → confirm the IP → clear known_hosts.Next up: the Python bridge that turns an HTTP request into a relay click.
]]>I can open my garage door with a remote. I wanted to open it with an API call instead. I know how to write the software, but I had no idea what electronics sit between “HTTP request” and “door moves”. This post covers the first few days: figuring out the hardware, digging through an old microcontroller kit, and getting a relay to click on my desk.
The wall button on a garage door opener doesn’t send any power anywhere. It just shorts two low-voltage terminals together for a moment. That’s called a dry contact.
So the whole “smart” part boils down to: something that can briefly connect two wires when told to. That something is a relay.
Optional extra I’ve parked for later: a magnetic reed switch on the door frame to know whether the door is actually open or closed.
I had an old kit from Hobby Components lying around. Relevant finds:
S (signal), + (5V) and - (GND), plus three screw terminals: NC, COM, NOWhat I learned: the Uno has no networking at all. To expose an API you need something with Wi-Fi or Ethernet. The options were:
| Option | Notes |
|---|---|
| ESP8266 (ESP-01) module next to the Uno | Runs at 3.3V, talks to the Uno over serial with AT commands. Fiddly. |
| Replace the Uno with an ESP32 / Wemos D1 | Built-in Wi-Fi, can host the API itself. Logic is 3.3V, so a 5V relay may need a level shifter. |
| Uno + Raspberry Pi over USB | Pi runs the API in a “real” language, Uno only flips the relay. |
I chose the last one: an old Raspberry Pi as the brain and the Arduino as the muscle. (Spoiler: the Pi being old became its own adventure, see Part 2.)
Before touching the garage at all, test on the desk with the Arduino plugged into the computer.
| Relay pin | Arduino pin |
|---|---|
+ |
5V |
- |
GND |
S |
Digital pin 7 |
Leave the COM/NO screw terminals empty during the bench test.
What I learned: many of these cheap relay modules are active LOW: writing LOW to the signal pin turns the relay on. So the sketch starts by writing HIGH to keep it off.
const int relayPin = 7;
void setup() {
pinMode(relayPin, OUTPUT);
digitalWrite(relayPin, HIGH); // relay off (active LOW module)
Serial.begin(9600);
}
void loop() {
if (Serial.available() > 0) {
char c = Serial.read();
if (c == 'o' || c == 'O') {
digitalWrite(relayPin, LOW); // "press the button"
delay(500);
digitalWrite(relayPin, HIGH); // "release"
}
}
}
Open the Serial Monitor at 9600 baud, type o, press Enter → click, click. The little LED on the relay blinks with it.
Bonus check: put a multimeter in continuity mode across COM and NO. It should beep for exactly the half second the relay is closed.
My first instinct as a JavaScript developer was to drive the board from Node.js with Johnny-Five. It timed out.
What I learned: Johnny-Five needs the StandardFirmata sketch uploaded to the board first (File → Examples → Firmata → StandardFirmata, the plain one, not the Plus version). Without it the computer and the board don’t speak the same protocol. In the end I didn’t need Johnny-Five at all, because a ten-line sketch listening on serial was simpler.
Uploading anything to the Uno failed with:
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00
This means the computer is shouting down the cable and the board isn’t answering. The checklist that helped:
Bluetooth-Incoming-Port; look for /dev/cu.usbmodem… (or /dev/cu.wchusbserial… on clones).The Arduino pins are small and I was nervous about bridging two of them with solder. Alternatives that are perfectly fine for this phase:
Next up: getting a first-generation Raspberry Pi onto my network, which took far longer than the electronics.
]]>