The Hermes Home Hub: A Fully Offline Smart Home Controller

The Hermes Home Hub is a purpose-built hardware device designed to replace cloud-dependent hubs like those from Amazon, Google, and Samsung. It runs a stripped-down Linux distribution with Home Assistant and a local Zigbee coordinator, ensuring all automation, sensor data, and control stay within your home. The hub features a 5-inch capacitive touchscreen for local control, a physical kill switch for the Wi-Fi radio (so you can verify it's truly offline), and an e-ink status display that shows system health without powering the main screen. The entire system is designed from the ground up to never phone home, log user behavior, or require an internet connection. Updates are sideloaded via USB or a local network share. The case is 3D printed from recycled PLA, and the main board is based on the Raspberry Pi Compute Module 4, with an integrated TI CC2652 Zigbee module and an ATSAMD21 coprocessor for real-time sensor polling. The software stack is fully open source (Home Assistant, ZHA, MQTT broker) and the firmware for the coprocessor is auditable. This is not a product—it's a manifesto in a box.

Every major smart home hub on the market today is a privacy nightmare. They require internet connectivity, send usage data to cloud servers, and often serve ads or upsell subscriptions. Even 'local' hubs like Hubitat have opt-out telemetry. For privacy-conscious users, there is no ready-made hub that offers verifiable, hardware-enforced offline operation without sacrificing features like voice control (via local wake word) or complex automations. The alternative is to cobble together a Raspberry Pi and hope nothing phones home. Hermes is the purpose-built, no-compromise answer.

• Build a fully offline smart home hub that never requires an internet connection.
• Support Zigbee, Z-Wave, and local Wi-Fi (via ESPHome devices) with all processing on-device.
• Provide a touchscreen UI for local device control and automation editing.
• Ensure zero data collection: no logs, no analytics, no telemetry—even for diagnostics.
• Achieve a sub-10-second boot time and less than 5W idle power consumption.
• Design a modular, repairable enclosure with accessible ports and a physical radio kill switch.

• Cloud connectivity or remote access (no VPN, no cloud bridges).
• Voice assistant integration (to keep the attack surface minimal).
• Support for proprietary cloud-dependent devices (e.g., Philips Hue hub v1).
• High-resolution display or fancy animations (focus on function over form).
• Mass-market ease of use; this is a DIY kit for tinkerers.

• Hardware: Raspberry Pi Compute Module 4 (CM4) with 2GB RAM, 16GB eMMC; TI CC2652P Zigbee module; ATSAMD21G18 coprocessor; 5-inch DSI touchscreen (800x480); 2.9-inch e-ink display; physical toggle switch for Wi-Fi/Bluetooth radio; custom PCB with power management (TPS65987D).
• Enclosure: 3D printed (PLA) with snap-fit joints, ventilation slots, and a recess for the kill switch.
• Software: Home Assistant OS (custom build without default cloud integrations); ZHA (Zigbee Home Automation) with local coordinator; Mosquitto MQTT; ESPHome for custom device firmware; local Web UI served on port 8123 (LAN-only).
• Tools: KiCad for PCB design; FreeCAD for case design; PlatformIO for coprocessor firmware.

The hub is structured around three processing tiers: Tier 1 - Application (CM4): Runs Home Assistant, the MQTT broker, and local web server. All user data (automations, device states) is stored on eMMC. No outgoing network connections except DHCP and mDNS (for local discovery). The Wi-Fi radio is hardware-switched and defaults to off; if enabled, it's only for connecting to a local LAN for device communication (no internet). Tier 2 - Zigbee Coprocessor (CC2652): Handles all Zigbee mesh network duties. Communicates with the CM4 over UART via ZHA. The coprocessor firmware is based on open-source Z-Stack and can be reflashed via USB. Tier 3 - Sensor Polling Coprocessor (ATSAMD21): Manages low-power sensor inputs (e.g., temperature, humidity, motion) over I2C and GPIO, waking the CM4 only when events occur. This keeps the main CPU in deep sleep during idle, reducing power draw. The e-ink display shows a minimal dashboard (time, device count, battery status) and is updated every 5 minutes or on button press. The main touchscreen sleeps after 30 seconds of inactivity. All data is stored locally; there is no cloud backup, no analytics, and no way for the device to phone home (hardware kill switch ensures Wi-Fi is cut).

• Interference issues: The CM4's Wi-Fi radio, even disabled, might cause RF noise on the Zigbee module. Mitigation: proper shielding and separation on PCB.
• Bricking potential: Users may flash incompatible firmware or damage the eMMC. Mitigation: a recovery jumper that forces USB boot.
• Limited device support: Some popular smart devices (e.g., Ring cameras, Nest thermostats) require cloud. Hermes simply won't support them. This reduces market appeal but aligns with privacy goals.
• Complex software build: Home Assistant OS is not designed for offline-first. Custom stripping of unnecessary packages increases maintenance burden. Mitigation: create a public GitHub repo with build scripts.

• Should we include a local voice assistant (e.g., Rhasspy or Porcupine) at the cost of extra processing power? Current plan: no, but leave a microphone header for future add-ons.
• What is the best way to distribute firmware updates? USB drive? LAN file share? We plan to support both, but need to design an update mechanism that works without internet.
• How to handle user onboarding without a cloud account? Likely a First-time-wizard on the touchscreen that sets up Wi-Fi (if desired) and scans for Zigbee devices.

The plan was drafted during a summer of intense privacy research, but real life intervened—a new job and a cross-country move sidelined the project. By the time I had a workshop again, Home Assistant had matured enough on standard Raspberry Pis that the custom hardware felt less urgent. The design files and notes are still on a GitHub repo, waiting for someone with more time and a 3D printer.

The name 'Hermes' was chosen for the Greek god of boundaries and transitions—the hub stands at the boundary between your home and the outside world, and controls transitions (lights on/off, door locks, etc.). The logo is a stylized caduceus made from a Zigbee symbol.