On most ESPHome energy monitors, changing most settings means editing YAML, compiling it, flashing the result and waiting. The documentation for the common energy chips says so in as many words: adjust a number, rebuild, install, look at the reading, repeat. Each pass costs a restart, and a restart costs measurement.
That loop is the thing people actually complain about — not the lack of features. So the useful question about running a meter inside Home Assistant is a narrow one: what can you change while it keeps running, and what still needs the loop?
What changes while the hub keeps running
All of this is an action sent to a running hub: it applies at once, needs no rebuild and no flash. Two of these rows have a part that waits for a restart, and they are footnoted below.
| Where | |
|---|---|
| Points: create, name, bind to a channel, rebind, role, phase, rating, group, sign inversion, delete and undelete | panel → Points |
| Modules: scan the bus, add one by address, see its model, firmware and state | panel → Points |
| Which clamp model is on a channel — by action, not by a button; the panel displays it | action + panel → Points |
| Tariff plan: zones by hour, grid fee, energy tax, levy, VAT | panel → Tariff |
| Plan currency | panel → Tariff |
| Price sources: provider, zone, backup, markup, factor, floors, sell-price mode, pricing every period of an hour at that hour's mean, stacking a plan zone on top of spot | panel → Prices |
| Cheap-window rules, up to eight | panel → Prices |
| Import peaks: shown here; the billing-cycle day is set by calling the integration's action from an automation or from Developer tools, rather than by a form | panel → Prices |
| Hub time zone, including one button to take Home Assistant's | panel → Prices |
| ESP-NOW nodes: pair, list, disable, enable, remove, pick which inputs they carry | panel → Network |
One thing in that list is topology rather than a setting: the supply role — your grid input — is set by creating or rebinding a point, not by editing one.
And deleting a point closes its accounting rather than erasing it: the history stays in flash, and there is an undelete.
The one exception: the I²C bus pins
Changing which pins the module bus uses needs the hub to restart. The panel says so where you do it, and it is honest about the consequence: modules on the old pins drop off until the restart happens.
That is the entire list of exceptions. Everything else above applies on a running hub.
What waits, and for how long
None of this is a rebuild. It is the difference between a setting taking effect and a record starting.
| Takes effect | Waits for | |
|---|---|---|
| A point you create, rename or bind | at once — live values and 15-minute periods | its flash history (the hourly records) starts after the next restart |
| A node you have just paired | the pairing itself | its points appear after a restart |
| Saving the whole points configuration at once | — | a restart; editing a single point does not |
| The I²C bus pins | — | a restart, and modules on the old pins drop off until then |
What does need YAML and an install
| An API encryption key | the ready-made image is built without one, so a key means your own configuration and an install |
| The component's version, if you build your own | raise ref: in external_components, then install |
| Anything else in your own YAML | by definition |
If you are not building your own configuration, the component's version arrives the same way the firmware does: a new ready-made image, installed over the air. No YAML involved.
Worth seeing in advance: these two rows are connected. The moment you want an API encryption key, you are building your own configuration — and from then on every install is yours to build, including the ones that would otherwise have been a ready-made image.
⚠️ Install over the air, not over USB. Flashed over USB with ESPHome's own tools —
esphome runto a serial port, or Manual download → Factory format — your build lands at the wrong address and the board boots nothing new: a blank board does not come up, and a board with an older image quietly keeps running the old one. Over the air only the application is sent, and the device places it using its own partition table. Do the first USB install with the ready-made factory image, then install your own build over the air.
Changing the hub's Wi-Fi
Not in the panel, and for the ready-made image not in YAML either.
When the hub cannot reach its saved network — a new router, a move — it opens its own setup access point about a minute later, with a captive portal: join it and pick the new network. The access point is rbgrid-hub-xxxxxx with the password RBGRID123; change that password once the hub is set up, the same way you would change any shipped default. Improv over USB works too: web.esphome.io → Connect → Change Wi-Fi.
Measurement does not stop while the hub is off the network. It keeps measuring and closing its periods; what is cut off is Home Assistant and the price fetch, until the link is back.
What is not a setting at all
This is where the honest answer differs from the one you might expect.
There is no calibration field — on either route, and not because it was left out of the panel. The rbAmp module is the measuring device: it returns voltage, current and power already calibrated, and that calibration is done on the module at the factory. RBgrid deliberately never writes it — the hub collects, books and prices what the module reports.
So if you are used to fitting a clamp against a reference meter: there is no per-channel trim, and no tool for one. The gain registers are writable in factory mode only; on a module you have bought, the write is refused.
The reason is where the calibration happens. Every channel of every module is calibrated in production, and choosing the clamp model converts that calibration to your clamp's rating. What is left over is the tolerance of your particular SCT-013, which is a property of the sensor and stated on its own line in the sensor's spec — not something the module claims to remove.
And if you do want to correct for your own instance, the place for it is your own software: a template sensor in Home Assistant multiplying the reading is a perfectly reasonable thing to do. The module will not do it for you, and nothing in the hub pretends to.
That model is a setting, and it does change at runtime — from the panel, in the point's Edit dialog, where "CT clamp model" lists the models the hub itself offers. The selector appears only when the module supports choosing one; a module that is not calibrated refuses the change and says so in the hub's own words.
⚠️ If you do not see that selector, your integration is older than the version that added it — on earlier ones the panel showed the clamp model and did not change it, and the way to set it was a call rather than a field. Updating is the short answer; the call still works if you would rather not.
Changing the model does not cost you the calibration. Set it when you connect a clamp, and set it again when you replace one; on the path the hub uses, the channel's calibration survives both the change and a restart.
What an install costs in measurement
An over-the-air install is a planned restart. The open hour and the lifetime totals survive it — measured on an S3 across four installs alternating two images.
The gap is a few seconds: during the upload itself the hub keeps measuring, and the core is back a few seconds after the restart. No 15-minute period is lost — though the one the restart falls in is short by those seconds.
What those seconds cost depends on which modules you have, and this is the part worth being precise about:
- STD modules — metering modules that keep their own energy counters: nothing. The energy is counted on the module, and the hub reads the counter difference after the restart.
- Basic modules — the clamp-reading kind, where the module measures power and the hub integrates it into energy: those few seconds are not counted. It is a negligible amount of energy. It is not zero.
So: a few seconds during the restart, rather than an uninterrupted record.
What this doesn't do
- It does not remove ESPHome from the picture. The device is an ESPHome device; the network side, the installs and your own YAML, if you keep one, are ESPHome's.
- It does not switch anything on or off. Every setting above is about measuring and pricing; what to do with a cheap window is your automation's decision.
- It does not make a restart free. It makes one rare, and says what the rare one costs.
Where to read more
- Run it inside Home Assistant — the route itself, and what the panel does.
- Two ways to run RBgrid, and how to choose — if you have not picked a route yet.
- Points and Sensors and modules — what a point is and how a module is addressed.
- Remote nodes — pairing, and what a node does on its own.