You have decided to measure your own circuits and watch them in Home Assistant. The clamps are cheap, they go round a wire without touching it, and there is no shortage of people who have done it.
What almost nobody tells you first is that there are two different ways to run this. They end up looking much the same on the Energy dashboard. They are not the same underneath — and moving from one to the other later means starting your history from zero.
So this is an article about the choice, not about the wiring. Both routes run the same metering core on your own ESP32 and measure the same way. What differs is where you set it up, what the device can talk to, and what reaches Home Assistant.
Make the choice before you start collecting history
The move between the two routes is a reflash over USB with the other image. It is not offered as an over-the-air update in either direction, nothing is migrated for you, and the browser installer offers a full erase when you install afresh.
⚠️ Pick the route before you start collecting history. Switching later means reflashing over USB, entering your points, modules, tariff plan and windows again, and starting the recorded history from zero. On the standalone route, export what you have as CSV first if you want to keep it.
That is the whole of the migration advice, and it is here rather than at the end of the article because it is only useful before the decision. Both directions are a fresh start; neither is the cheap one.
What is the same either way
Most of what you are buying the thing for does not depend on the route:
- The measurement. Same metering core, same clamps, same 15-minute periods closed on the device.
- Market prices. The hub fetches the day-ahead price for your zone itself, applies your contract — zones, fees, taxes, VAT — and prices each 15-minute period with the price of that period.
- Cheap windows. Rules for "below a level", "cheapest periods in a span" and "cheapest before a time", evaluated on the device.
- Import peaks. The highest 15-minute and hourly import at the grid input, per billing cycle.
- Remote nodes. ESP-NOW nodes are the same device and the same firmware on both routes.
- The record is the device's. Hours are closed and priced on the hub, so whatever Home Assistant is doing — restarting, updating, switched off — does not change what was measured.
- No cloud in the path. Neither route needs an account anywhere, which is the part people ask about most and get least often:
"Also, it seems like none of them are local which sucks majorly." — ncd, Home Assistant forum thread 607039
What differs
| The hub's own app | Inside Home Assistant | |
|---|---|---|
| Where you set it up | the hub's web app, at the hub's own address | the RBgrid panel in Home Assistant |
| Web app | yes | no |
| How Home Assistant sees it | MQTT discovery | the ESPHome native API |
| A broker to run | yes, if you want Home Assistant | none |
| MQTT, REST, WebSocket | yes | no — ESPHome owns the network side |
| Market prices, plan, zones | yes | yes |
| Cheap windows | state published on MQTT | a Home Assistant event for your automations |
| Import peaks | in the app | shown on the panel's Prices tab, read-only; the billing-cycle day is set by an action, not a form |
| Remote ESP-NOW nodes | in the app | paired and listed on the panel's Network tab |
| Hourly history into Home Assistant statistics | no — live totals only | yes, up to 30 days at setup, then hour by hour |
| Config backup and CSV export as files | yes | no |
| Price attribution shown for you | the app's Prices page | the panel renders it |
Two rows in that table are worth reading twice.
The broker. If you run the hub on its own route and want it in Home Assistant, you need an MQTT broker — that is how the two meet. A hub used only through its own web app needs none. On the Home Assistant route there is no broker at all, because ESPHome's own protocol does the talking.
The history import. This is the one real asymmetry — and it is an addition, not a replacement. Home Assistant keeps its own hourly statistics on both routes, from the live values it receives; that part does not change. What the ESPHome route adds is a second set of rows: the integration writes the hub's own hourly book into long-term statistics beside them, and the first import reaches back, so up to 30 days of what the hub already recorded arrive in one pass — if the hub was already running before you set the integration up. Those rows do not duplicate anything on your dashboard until you choose them as its source. On the MQTT route there is no second copy; Home Assistant's statistics are the ones it computed, as always. Nothing is lost on the hub either way.
If Home Assistant is already your interface
Flash the ESPHome image, adopt the device, and the RBgrid panel in Home Assistant becomes the place where you set everything up: points, modules, the tariff plan, the windows. There is no second app to keep and no broker to run.
Getting there has two shapes, and both are ordinary: either flash the ready-made factory image for your board from a browser and adopt the device as you would any ESPHome device, or — if you already keep your ESPHome devices as YAML — add the component as an external source and build it into your own configuration. Updates afterwards are the standard ESPHome ones: you install them from the ESPHome dashboard, and a failed image falls back to the previous one. The exact steps, including the one export that produces a board which will not boot, are on the ESPHome route page.
Specifically, on this route:
- Peaks are on the panel's Prices tab, in an Import peaks (capacity tariff) card: the day the billing cycle starts, the highest 15-minute average, the highest hour. You read them there; to change the cycle day you call the integration's action from an automation or from Developer tools.
- Nodes are on the panel's Network tab: pairing, the list, each node's state, signal, firmware and which inputs it carries. A node that goes missing shows as offline there, is counted on the Overview card, is written into the hub's log on the Events tab, and is raised as a Home Assistant event — so an automation can tell you about it.
- Prices come with the source credited in the panel, as the provider's terms require.
What you give up is the list in the table: no web app, no MQTT, no REST, no WebSocket, and no configuration backup or CSV you can keep as a file.
That last one is narrower than it sounds, and worth not misreading: the 15-minute price periods are still there. The panel's Prices tab charts every period the hub holds — today and tomorrow — with each period's origin when more than one source is in play, and an action returns the same thing as JSON, so an automation can hand it to anything you like. What is missing is a file, not the data.
If you want the hub to stand on its own
The hub serves its own web app at its own address. Tariffs, points, history and prices are set there, and it does not need Home Assistant to be useful — which matters if Home Assistant is one of several places you look, or if you would rather the meter not depend on it at all.
From there, Home Assistant is optional: run a broker, point the hub at it, and the points arrive by MQTT discovery. REST and a WebSocket are there too, for a dashboard of your own or anything else that speaks HTTP. And both a configuration backup and a CSV export exist as files you can keep somewhere else.
If this is your route, the step-by-step from flashing to the Energy dashboard is written up separately: A power meter for Home Assistant, from flashing to the Energy dashboard.
Per-circuit cost: what Home Assistant cannot do on its own
This is the part that sends people round in circles, and it is worth understanding before you choose, because it is the same on both routes.
Home Assistant's Energy dashboard will happily cost your whole house. It will not tell you what the heat pump cost, because cost belongs to a grid source there, not to a device. The workaround people reach for is to declare each appliance as its own electricity source, which does produce a number and is also plainly wrong:
"I add individual device as a electricity source just to see running costs. Which is pretty stupid." — degreal, thread 334932
That thread has been open since 2021. The other half of the problem is the tariff itself: zones, standing fees and VAT end up in template sensors and utility_meter helpers, and they are fragile in a way that is hard to debug because nothing errors — the number is simply wrong:
"Nope still collecting on 'peak' no matter what I put in offpeak." — a user in thread 313300
"I really struggled with this - it's actually really simple but there are a couple of gotchas to know about." — steve_jo, thread 484105
What changes when the tariff lives on the meter is that the arithmetic stops being yours to assemble. The plan — zones by hour, fees, taxes, VAT — is configured once on the device, and every point is costed separately, live and hour by hour, with export valued at its own price.
⚠️ But be clear about where that money appears, because it is not inside the Energy dashboard. Home Assistant has no cost field for an individual device — that is the gap, and no integration can fill it from outside. What you get instead is the figure in three places you can use: a cost entity per point, live, to put on any card; hourly cost per point in long-term statistics, for a statistics card; and the panel's own Points and History tables. The dashboard still shows your points as devices with their energy. So per-circuit money is read beside the dashboard, not in it — which is the honest shape, and better than the workaround, but it is not the dashboard column you may be picturing. No template sensor is in the path, which removes a class of problems rather than all of them: the zone boundaries and the VAT are applied where the energy is measured, not reassembled downstream.
⚠️ One honest limit. What reaches Home Assistant's statistics is hourly, because that is the shortest period Home Assistant stores. The 15-minute periods stay on the hub, where the applied-price log keeps them as CSV. If your contract moves in 15-minute periods, the device is the place where that resolution exists — Home Assistant will show you hours of it.
Three questions that settle it
- Is Home Assistant where you look at everything, or one of several places? If everything already lives there, the ESPHome route removes an app and a broker. If it is one of several, the standalone hub keeps its own front door.
- Do you want somewhere to look when Home Assistant is down? The measuring carries on regardless, on both routes. But on the ESPHome route the panel is part of Home Assistant, so while that is down you have nowhere to open.
- Do your own tools need MQTT, REST or a WebSocket? If yes, the choice is made for you: they exist only on the standalone route.
If after that it is still a tie, take the standalone hub — not because you can leave it with your history, because you cannot: nothing moves either way, and that is true of both routes. Take it because its data leaves as files. A CSV export and a configuration backup are things you can keep somewhere else, and on the day you change your mind that is the difference between starting the record again with the old one in hand and starting it again without.
What this doesn't do
- Neither route switches anything on or off. The hub measures and prices; what to do about a cheap window is your automation's decision, not the meter's.
- Neither route gives Home Assistant 15-minute resolution. The periods are the device's; Home Assistant stores hours.
- No history moves between the routes. A switch is a reflash and a fresh start, in both directions.
- The route does not change how the device measures. Same core, same clamps, same periods — only the surroundings differ.
Where to read more
- Which of the two you want — the same choice, in two cards, with the links out.
- Run it inside Home Assistant — the ESPHome route, including what the panel does.
- Market prices — how the day-ahead price and your contract turn into a cost per period.
- Import peaks and Remote nodes — the two features that work on both routes and surface differently.
- History and record quality — what the hub keeps, and how it marks an hour it could not complete.
- A power meter for Home Assistant — the standalone route, step by step.
- The hardware — hub, modules and clamps.