Brilliant, Xiaomi, and Panasonic in Home Assistant

9 min read
home-automationhome-assistantraspberry-piiot

I wanted a single app to control everything in my home: the Brilliant smart switches throughout the house, a Xiaomi pedestal fan in the bedroom, and a Panasonic heat pump with a cloud connect module. Here's what I found after digging into the integrations, protocols, and trade-offs for each device.

TL;DR: Home Assistant is the right platform. All three devices can work with it, but each has its own quirks. The Pi 3B will run it — just barely.

The platform: Home Assistant

Home Assistant (HAOS) is the clear winner here. OpenHAB and Hubitat both exist, but HA has the largest community, the most integrations for these specific devices, a first-class ESPHome add-on that becomes important for some of the local-control approaches below, and — importantly for this project — a genuinely flexible frontend that can be customised well beyond the defaults.

Install it on the Pi 3B. But read the hardware section at the bottom first — there's a meaningful caveat.

Device 1: Brilliant smart switches

Brilliant's Australian switches (available at Bunnings) are Tuya OEM devices. Under the hood they speak the Tuya cloud protocol over WiFi, defaulting to Tuya's servers. There's no local API exposed by the stock firmware.

You have three paths:

Path A: LocalTuya (easiest, no hardware changes)

The LocalTuya custom integration (available via HACS) can talk to Tuya devices on the local network without going through the cloud. It needs two things: the device's local key and its device ID.

Get these from the Tuya IoT Developer Portal — create a free account, link your Brilliant devices via the Smart Life app, and retrieve the keys. Then map each datapoint (DP) for your switches and dimmers in LocalTuya's configuration.

Community members have confirmed this works for Brilliant plugs and switches. The DP mapping requires a bit of trial and error. This is where to start.

Path B: ESPHome flash (best long-term)

Older Brilliant switches with an ESP8266 chip can be flashed OTA using tuya-convert — no soldering required.

Newer models with WB2S, WB3S, or CBU (BK7231) chips can't use tuya-convert. For these, use Tuya CloudCutter with ESPHome's LibreTiny support (available since ESPHome 2023.9+). This requires opening the device casing (glued, not screwed) and connecting to the chip's UART pads.

The payoff: ESPHome-flashed devices appear natively in Home Assistant as local-push entities. No cloud, no key rotation, no Tuya servers. The ESPHome Devices database has a confirmed entry for the Brilliant wall switch.

Path C: Tasmota

The same process as ESPHome, but flashing Tasmota instead. Templates exist for the BL20925 smart plug. Control via MQTT or HTTP, integrating into HA via the official Tasmota integration. A valid option if you're already in the Tasmota ecosystem.

Recommendation: Try LocalTuya first. If the device keys rotate or reliability is poor, flash to ESPHome.

Device 2: Xiaomi pedestal fan

Xiaomi fans use the miio protocol — a proprietary but fully local LAN protocol. Once you have the device token, all communication is direct device-to-Pi with no cloud involved.

Integration: syssi/xiaomi_fan (HACS)

The built-in xiaomi_miio integration in HA focuses on air purifiers and humidifiers. For pedestal fans, install the syssi/xiaomi_fan custom component via HACS instead. It covers a wide range of models:

  • Smartmi: zhimi.fan.v2, v3, sa1, za1–za5
  • Mi Smart Fan / dmaker: dmaker.fan.1C, p5, p8–p11, p15, p18, p30, p39

You'll get fan speed, oscillation, natural/sleep mode, LED control, child lock, and timers as Home Assistant entities.

Getting the token

The token is a 32-character hex string stored in Xiaomi's cloud. The easiest extraction method: run Xiaomi Cloud Tokens Extractor. It logs into your Mi account and returns all device tokens. Alternatively, use miiocli cloud from the python-miio library.

Set a DHCP reservation for the fan's IP so it doesn't change. Then configure the integration with IP + token, and you're done — fully local from that point on.

Device 3: Panasonic cloud connect heat pump (CZ-TACG1 / DNSK-P11)

This is the trickiest device. The CZ-TACG1 and DNSK-P11 modules route all control through Panasonic's Comfort Cloud servers. There is no local API on the stock module.

Path A: Cloud integration (easier to set up)

panasonic_cc is the most widely-used community integration (HACS). Authenticate with your Comfort Cloud credentials and you get a climate entity with temperature control, modes, swing, Nanoe, ECONAVI, and energy monitoring.

Known gotchas:

  • Panasonic only allows one active cloud session per account. Opening the Comfort Cloud app while HA is connected will kick HA out. The fix: create a dedicated Panasonic account for Home Assistant and share the device to it.
  • SMS-based 2FA is required — not an authenticator app. Set this up in the mobile app before configuring the integration.
  • The session occasionally drops and needs re-authentication.
  • Cloud outages block control.

This path works and is straightforward, but it has operational overhead.

Path B: Local ESP control (harder, much more reliable)

The heat pump has an internal serial port (CN-CNT or CN-WLAN) — the same connector the CZ-TACG1 plugs into. You can replace it with a DIY ESP-based module that speaks directly to the heat pump over UART:

  • esphome-panasonic-ac — an ESPHome component that talks to the heat pump via the CN-CNT port. Needs an ESP32/ESP8266, a bidirectional 3.3V↔5V logic level converter, and some wiring. The heat pump appears as a native climate entity in HA via ESPHome.

  • Ingenious Makers P11 — a purpose-built ESP32-C3 PCB that physically plugs into the DNSK-P11/CZ-TACG1 slot. Updated in early 2025. Can be ordered assembled or built from PCBWay files. This is the plug-and-play local option.

No cloud, no account management, instant response. Worth the setup effort if this is a permanent installation.

Recommendation: Start with panasonic_cc and a dedicated account. Plan the local hardware mod as a future upgrade once the rest of the system is stable.

The Raspberry Pi 3B: honest assessment

The Pi 3B (1GB RAM, Cortex-A53 at 1.2GHz) will run Home Assistant, but it's increasingly marginal:

  • HAOS at idle consumes 500–700MB of RAM. Each add-on costs more. Running HAOS + Mosquitto + ESPHome add-on + Node-RED simultaneously on 1GB pushes RAM to 90–100%, causing slowdowns and the occasional freeze.
  • Community reports from 2024 confirm Pi 3B users hitting system freezes and failed HA Core updates. This is a known and recurring issue.
  • For this specific setup (3 device types, modest automations), the Pi 3B will work — but it will be sluggish during HA updates and add-on installations.

Mitigations if you're sticking with the Pi 3B:

  1. Boot from a USB SSD — not an SD card. The Pi 3B needs a one-time OTP write (program_usb_boot_mode=1) to enable USB boot, then plug in an SSD via USB. This dramatically improves reliability and longevity.
  2. Run only essential add-ons. Disable the ESPHome add-on when you're not actively flashing devices.
  3. Don't run a media server or InfluxDB concurrently.
  4. Enable ZRAM compression.

A Pi 4 (4GB) or an Intel N100 mini-PC would remove all of these concerns. But for a starter setup with these three device types, the Pi 3B is viable.

Recommended setup order

  1. Install HAOS on the Pi 3B via a USB SSD.
  2. Install HACS.
  3. Xiaomi fan — extract token with Xiaomi Cloud Tokens Extractor, install syssi/xiaomi_fan via HACS, configure with IP + token. This is the easiest of the three.
  4. Panasonic heat pump — create a dedicated Panasonic account, configure SMS 2FA, install panasonic_cc via HACS.
  5. Brilliant switches — try LocalTuya first. Get local keys from the Tuya IoT Developer Portal, configure DPs. If unreliable, plan a flash to ESPHome.
  6. ESPHome add-on — install only when flashing devices, disable afterward to reclaim RAM.

Summary

Device Protocol Local control? Recommended path Difficulty
Brilliant switches WiFi / Tuya Yes (LocalTuya or flash) LocalTuya → ESPHome flash Medium
Xiaomi pedestal fan WiFi / miio Yes (after token extraction) syssi/xiaomi_fan via HACS Easy
Panasonic CZ-TACG1 WiFi / Comfort Cloud Only with hardware mod panasonic_cc (cloud) → ESP local Easy → Hard
Raspberry Pi 3B — Local server HAOS + USB SSD Marginal; Pi 4 preferred

The fully local setup — LocalTuya or ESPHome for Brilliant, miio for Xiaomi, ESPHome local mod for Panasonic — is achievable and removes all cloud dependencies. The cloud-based setup for Panasonic is the pragmatic starting point while you get everything else running.

The frontend

Getting devices into HA is one thing. Having a UI worth actually using is another.

HA's built-in dashboard system is called Lovelace. Out of the box it's functional but generic — a grid of tiles that works fine for initial testing but doesn't feel purpose-built for anything. The real customisation happens once you install HACS and pull in community card libraries. Mushroom gives you a clean, Material-style card collection. Bubble Card takes an iOS-inspired approach that suits touch screens well. Card Mod lets you apply raw CSS to any existing card, enabling deep visual overrides without writing a custom component. For most setups this combination covers everything.

If the default Lovelace approach isn't enough, HA exposes a full API. The WebSocket API is what HA's own frontend uses internally — real-time, bidirectional, and well-documented. Home Assistant ships an official npm package, home-assistant-js-websocket, that handles the auth flow, reconnection, and state subscription. From there you can build a standalone React, Vue, or Svelte app that talks directly to the Pi and renders however you want — no trace of HA's default look required. For React specifically, ha-component-kit wraps the WebSocket connection with hooks and ships pre-styled dashboard components to get moving faster.

A few friction points worth knowing before going down that path:

  • CORS — if your custom app is served from a different origin than HA, you need cors_allowed_origins in configuration.yaml.
  • React/Vue inside Lovelace — HA's frontend uses LitElement internally, which conflicts with other frameworks. The fix is embed_iframe: true in the panel config, which loads your app in an isolated iframe and passes the hass object via postMessage.
  • Auth on static files — files in /config/www/ (served at /local/) are not protected by HA's authentication. Custom Panels registered via panel_custom are; plain JS files are not.

For this project the goal is a single dashboard designed around how these three devices actually get used — not a generic smart home grid. The integrations and automations come first, but a custom interface built on the WebSocket API is where this ends up.

What's next: actually building it

The research phase is done. The next step is to put this into practice: install Home Assistant OS on the Pi 3B, get all three device types connected, and tie them together with automations that make them work as a system rather than three separate apps. Then build the interface around how the house actually runs, not around what HA ships by default.

I'll be writing it up as I go — what works, what doesn't, and where the documentation falls short of reality.