RBgrid v1.2.1

The last release this blog told you about was v1.1.7. Three have shipped since, and between them they change what the hub does with money: it can now follow the market price for your zone, period by period, and it keeps the price it used beside the energy it used it on.

Get it

Settings → Hub firmware, upload main_release.bin from the latest release — main_release_s3.bin on an ESP32-S3 — then install the matching rbgrid-ui_<version>.zip. An update over the air from v1.1.x keeps your settings, points, tariff, tokens and history.

⚠️ If you are on v1.2.0 and use dynamic prices, update. On v1.2.0 the price stores shared the hub's small settings memory with the open hour and the energy counters' anchors; once it filled, a restart could lose part of the hour being measured. v1.2.1 moves them into the file system and frees that memory on the first start. Prices, settings and history are kept.

The hub can follow a market price

Until now the hub priced your energy from the plan you entered: zones, charges, VAT. From v1.2.0 it can take the price of each 15-minute period from a market source instead, and book that period's energy at that period's own price.

Your plan does not stop mattering. It is the fallback for any period no price covers, and on a spot source its per-kWh taxes, grid fee and levy, and its VAT, are applied on top of the market price. A source that already publishes the retail price — an all-in source — is taken as it is, so nothing is counted twice.

The sources the hub fetches: Energy-Charts (Fraunhofer ISE, the zones published under CC BY 4.0), Nord Pool, Elpriset just nu (SE), Hva koster strømmen (NO, hourly), EnergyZero (NL, all-in) and Octopus Agile (UK, all-in). Home Assistant can also push prices in, for a supplier none of those covers. Each source carries the attribution its licence asks for, and the hub carries that text with the price.

You set a primary source and, if you want, a backup; where neither has a price, the plan prices the period. Your contract goes on top as a factor and a markup, with floors for buy and sell, three ways to value export, and pricing at the hour's mean for contracts settled per hour. Negative prices are kept as they are unless you set a floor.

And the part worth having: every price the hub booked is logged per 15-minute period, with the source it came from, for 40 days — on the Prices page, as a CSV download, and over the API. A cost figure you can trace back to the price that produced it, rather than take on trust.

⚠️ The hub converts no currencies. Your price zone and your tariff plan must trade in the same one.

The history record format is unchanged, so anything already reading the hub needs no change.

→ How dynamic prices work

Cheap windows, published for your automations

Up to eight rules mark the periods you care about: below a price, with hysteresis so it does not flicker; the cheapest N periods of a day or of a time range; or N periods before a time something must be done by. They work on a fixed time-of-use plan too, not only with market prices.

⚠️ The hub switches nothing itself. It publishes a notification — the price now, where this period ranks in the day, which windows are open, and two flags — and something else decides: a Home Assistant automation, a diverter, a charger. It is at GET /api/v1/signal and on the retained MQTT topic rbgrid/<mac>/price, refreshed every 15-minute period and the moment anything changes.

→ Knowing when energy is cheapest

Import peaks

For tariffs that charge for the hardest you pulled rather than only for what you used, the hub keeps the highest 15-minute and hourly import at the grid input, and the heaviest days, for each billing cycle — with a start day you choose from 1 to 28.

Metering only: no charge is added to any figure, and peaks work whether or not you use dynamic prices.

→ Import peaks

The ESP32-S3, and nodes that keep five days

v1.1.8 added support for the ESP32-S3 on the N16R8 module, alongside the ESP32-WROVER. Its image is a separate one — main_release_s3.bin — and the USB set is in its own zip.

Remote nodes got node firmware 1.5 in the same release:

• Finished 15-minute periods are kept in the node's own flash until the hub has them — about five days, and they survive a power cut on the node.
• A node follows only the hub it is paired with. On 1.4, a second RBgrid hub on the same Wi-Fi channel could cost a node its clock sync while energy kept arriving. A node paired under 1.4 needs no re-pairing.
• All four of a node's inputs report live values, and a node's point settings survive a restart.
• An input with current but no voltage behind it books no energy — the hub will not invent it from a nominal voltage — and still shows live current.

⚠️ A node is flashed over USB and has no over-the-air update. The hub can be updated over the air; the node cannot, and the update to 1.5 writes all three files, because 1.5 adds the flash partition the periods live in. Put a node where you can still reach it with a cable.

v1.1.8 also let a point be marked as measured inside another one — a charger inside a metered sub-panel — so the app stops subtracting that load twice from the unmetered figure. The hub's own totals are unchanged: they are taken at the input. And mqtts:// now checks the broker certificate's dates: one that has expired, or is not valid yet, is refused.

From v1.2.0 a node going quiet, and coming back, are lines in the hub's own event log — readable without a broker.

→ Remote nodes

One more thing: RBgrid now runs two ways

Alongside the firmware in this post, the same metering core is published as an ESPHome package: the hub becomes a device Home Assistant manages, with no web app and no broker to run. Same measurements, same tariffs, same dynamic prices. The Home Assistant integration is installed by adding it in HACS as a custom repository — it is not in the default list, so searching HACS finds nothing until you have added it.

→ Run it inside Home Assistant

The three releases

The full list of changes is in CHANGELOG.md.