Part 2 of 7 · Home Assistant Energy Build
Initial setup: HACS, MQTT and SSH
Turning a blank Home Assistant OS instance into a working platform: onboarding, the Mosquitto MQTT broker, HACS, shell access, users, and taming MQTT log noise.
Part 1 left a bare Home Assistant OS instance running on the Pi. This part builds the foundation everything else depends on. The order matters: the MQTT broker has to exist before GivTCP (Part 3) can publish to it, and HACS has to exist before any of the custom dashboard cards can be installed.
Onboarding the instance
Opening the instance for the first time launches the onboarding wizard. Create the owner account with a strong password, set the home's location (used for sun position, which the automations later rely on for solar timing), confirm the unit system and time zone, and let it complete device discovery. Nothing exotic here — but get the location and time zone right, because cheap-rate windows and sunrise/sunset logic are anchored to them.
The Mosquitto MQTT broker
The entire battery integration runs over MQTT, so the broker is installed first. Home Assistant ships Mosquitto as an official add-on.
- Go to Settings → Add-ons → Add-on Store.
- Find Mosquitto broker, install it, and start it.
- Enable Start on boot and Watchdog.
- Create a dedicated Home Assistant user for MQTT (Settings → People/Users) — Mosquitto authenticates MQTT clients against Home Assistant accounts. GivTCP will log in with these credentials in Part 3.
When Mosquitto starts, Home Assistant auto-discovers it and offers to set up the MQTT integration. Accept it. From this point the broker is live at the Pi's address on the standard port 1883, ready for GivTCP to publish battery telemetry into it.
Installing HACS
HACS (the Home Assistant Community Store) is what makes the custom cards and community integrations in later parts available — Power Flow Card Plus, the BottlecapDave Octopus integration, the Greenness Forecast card and the myenergi integration all come from HACS.
HACS installs by running its downloader from a shell inside the instance, which is why the Terminal & SSH add-on (below) is useful to have alongside it. Once downloaded, HACS is added like any integration under Settings → Devices & Services → Add Integration → HACS, and requires a one-time GitHub authorisation via device code. After that, the HACS panel appears in the sidebar and community content installs from there.
Note — HACS itself is not in the official Add-on Store — it is a custom component. Installing it is a one-off manual step; everything downloaded through HACS afterwards is a couple of clicks.
Terminal & SSH access
Shell access is invaluable for editing YAML directly, running the HACS installer and inspecting logs. This build uses the Terminal & SSH add-on (the basic community version), configured with a password rather than keys for simplicity on the LAN.
The add-on is configured from its Configuration tab in the add-on page — the password is set in the add-on's YAML options block there, for example:
ssh_forwarding: false
username: hassio
password: "your-strong-password-here"
authorized_keys: []
Caution — A password-authenticated SSH endpoint is fine on a trusted, firewalled LAN behind UniFi. Do not expose port 22 (or the add-on's port) to the internet. Remote access to this instance should go through a VPN or Nabu Casa, never a forwarded SSH port.
Suppressing MQTT log noise
Once GivTCP is publishing (Part 3), the MQTT number platform becomes extremely chatty — every charge-rate and target-SOC value publishes as an MQTT number, and the default log level buries genuine warnings under a wall of routine MQTT traffic. The fix is a targeted logger block in configuration.yaml that raises only the noisy component to critical, leaving everything else at its normal level:
logger:
default: info
logs:
homeassistant.components.mqtt.number: critical
This keeps the log readable without hiding anything that actually matters. Reload the configuration (or restart) for it to take effect.
Users and the read-only account
This system is watched by more than one person, and not everyone should be able to change battery settings. Home Assistant's user model supports this directly: alongside the owner account, a second non-administrator "Solar" user is created for a colleague. That account is a standard user (admin toggle off), and it is later pointed at a duplicate, control-free dashboard (Part 7) so it can observe generation, state of charge and flows without being able to touch charge schedules or operating modes.
Getting the account model right early avoids retrofitting permissions later, and it maps cleanly onto the dashboard split that comes at the end of the series.
With MQTT live, HACS installed, shell access in place and the log under control, the platform is ready. Part 3 connects the first real device: the GivEnergy battery system, over GivTCP.
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.