Part 1 of 7 · Home Assistant Energy Build
Installing Home Assistant OS on a Raspberry Pi 5
The physical box and a clean Home Assistant OS install — the hardware choices, imaging, first boot and a fixed IP for the machine that will run the whole energy system.
This first part covers the physical box and getting a clean Home Assistant OS install onto it. Nothing here is energy-specific yet — but the hardware choices matter, because this machine is going to be the sole controller for a battery system that can trip the incoming breaker if it is mismanaged. Reliability of the host is a safety feature, not a nicety.
The hardware
The build runs on a Raspberry Pi 5 supplied as an iRasptek 8GB kit, later rehoused in a SunFounder Pironman 5-MAX case and migrated to NVMe storage. The final specification is:
| Item | Detail |
|---|---|
| Compute | Raspberry Pi 5, 8GB RAM |
| Case | SunFounder Pironman 5-MAX (active cooling, OLED, NVMe carrier) |
| Storage | Integral 256GB NVMe SSD (migrated from the kit's 64GB card) |
| OS | Home Assistant OS 17.3 |
| Network | Wired Ethernet into UniFi infrastructure, fixed IP 172.16.0.50 |
The 8GB model is the right choice here. Once the MQTT broker, GivTCP, HACS custom cards and several always-on integrations are running, memory headroom stops being optional. NVMe over the bundled SD card is also worth doing early: this instance writes history and recorder data continuously, and SD cards degrade under that workload.
Why Home Assistant OS, not a container
There are several ways to run Home Assistant — a Docker container, a Python virtual environment, a supervised install on generic Linux, or the full Home Assistant OS appliance image. This build uses Home Assistant OS (the appliance) deliberately. It is the only option that gives first-class access to the Add-on Store, and the entire architecture of this project leans on add-ons: the Mosquitto MQTT broker, GivTCP, the Terminal & SSH add-on, and the SunFounder Pironman add-on all install as supervised add-ons. On a bare container install none of those are available in the same integrated way.
Flashing the OS
Home Assistant publishes a ready-made image for the Pi 5. The cleanest route is the official Raspberry Pi Imager, which can write the Home Assistant OS image directly.
- Install and launch Raspberry Pi Imager.
- Under Choose Device, select Raspberry Pi 5.
- Under Choose OS → Other specific-purpose OS → Home assistants and home automation → Home Assistant OS, and pick the current build for the Pi 5.
- Under Choose Storage, select the target. For an NVMe build this is the SSD in a USB enclosure (write it, then move it into the Pironman carrier), or the SD card if imaging that first.
- Write, and wait for verification to finish before removing the drive.
Note — Do not apply the Imager's "OS customisation" options (hostname, Wi-Fi, SSH keys) to a Home Assistant OS image. Those settings target Raspberry Pi OS and are ignored — HA OS does its own onboarding on first boot, covered in Part 2.
First boot and finding the box
Seat the storage, connect Ethernet, and power on. The first boot takes several minutes while HA OS expands the filesystem and downloads the current Home Assistant core. Give it a good ten minutes before expecting anything.
Once it is up, the instance is reachable at:
http://homeassistant.local:8123If .local mDNS resolution is flaky on the network (it sometimes is behind managed switches), go to the router/controller and find the device by IP instead. On this build the box lives at:
http://172.16.0.50:8123Reserving a fixed IP
This step is easy to skip and expensive to skip. Half of what this Pi does is talk to other devices by address — the GivEnergy Gateway over the LAN, MQTT clients, the mobile app, the read-only dashboard user. If the Pi's own address moves, references break. On the UniFi network the address is pinned two ways:
- A DHCP reservation in the UniFi controller, mapping the Pi's MAC to
172.16.0.50, so it always receives the same lease. - Confirmed in Home Assistant under Settings → System → Network, where the IPv4 configuration can be pinned as a belt-and-braces measure.
Why it matters — Every downstream integration and every device that reaches the Pi assumes 172.16.0.50 is stable. Reserve it before building anything on top.
The Pironman 5-MAX add-on
The Pironman case adds active cooling, an OLED status display and RGB, all driven by an on-board controller. To surface fan and display control inside Home Assistant, SunFounder ships a dedicated add-on served from their own repository. It is added under Settings → Add-ons → Add-on Store → ⋮ (top right) → Repositories:
https://github.com/sunfounder/home-assistant-addonAfter the repository is added, the Pironman add-on appears in the store and installs like any other. It handles the case fan curve and OLED so the hardware runs cool and quiet under the continuous MQTT/recorder load this system generates.
One at a time — The rule that governs this whole build starts here: install one thing, confirm it is healthy and error-free, then move on. It is far cheaper to catch a bad add-on in isolation than to unpick it from a stack of six.
At the end of Part 1 there is a Pi 5 running Home Assistant OS on a fixed IP, cooled and reachable. Part 2 turns that blank instance into a working platform: onboarding, HACS, the MQTT broker, SSH access and log hygiene.
A personal home-energy project, shared as-is and not affiliated with any vendor mentioned. Settings and entity names change — check current vendor docs, and treat battery charge-rate configuration as a safety matter for your own installation.