Ask Home Assistant which hours are cheapest tomorrow and you end up somewhere you did not plan to be: a planner integration, a template sensor with a macro in it, a sorted list of hours, and an automation that compares the current hour against the result. It works, and people maintain exactly that setup for years. It is also a lot of moving parts for a question with a one-word answer — is now a good time?
The hub answers that question itself. It knows the prices for every 15-minute period, so it can work out which periods are cheap, and it publishes the result as a window: open or closed, until when, and when the next one starts.
What it does not do is act on it. That part is yours.
What a window is
You describe the rule; the hub evaluates it against the prices it has.
| Rule | What it means | Use it when |
|---|---|---|
| Price below a level | open while the all-in buy price — the market price with your contract's fees, taxes and VAT already on it (what that is made of) — is at or under your level, closing again above a second, higher level | your threshold is absolute: "while electricity is under 10 cents, whenever that happens" |
| Cheapest periods in a time span | open for the cheapest n periods inside a span you give | you need n periods and do not care when, within a stretch of the day |
| Cheapest periods before a time | open for the cheapest n periods between now and a deadline | something must be done by 07:00 and you want the cheapest way to get there |
Two levels rather than one in the first rule is not fussiness: a price hovering around a single number would make the window flicker on and off every period. Give yourself a gap.
Alongside the rules there are two plain flags — buy is cheap below and sell is low below — which say something about the price right now, with no planning and no hysteresis. The sell flag is the useful one on a site with generation: it is the signal that your own energy is worth more used than exported.
Eight rules is the limit. A ninth is refused rather than quietly dropped.
Read the state, not the message
This is the one piece of advice that decides whether your automation works.
The window state is republished at every 15-minute boundary, and immediately whenever anything changes — a window opening or closing, new prices arriving, a rule edited. It is a state, not an announcement.
So build on the current value. An automation that treats each publication as an event fires over and over through a long window, and misses the transition that happened while it was restarting. An automation that asks "is this window active?" is right at every moment, including the moment it comes back.
Reading it from Home Assistant: the two routes, as this is written
Here the honest answer depends on how you run the hub.
On the hub's own route, over MQTT, the state arrives as a retained message on rbgrid/<mac>/price — under a kilobyte, with one entry per rule: its name, whether it is active, until when, and when it next starts. Retained is the important word: anything that connects later gets the current state immediately, so a restart costs you nothing. The message is JSON, so the usual shape is an MQTT sensor with a template that pulls out the rule you care about — the hub's own reference carries a worked example of exactly that, with the field names.
On the ESPHome route, the windows are entities too: one binary sensor per rule, on the hub's device, on while the window is open, carrying when it closes and when the next one starts. Beside them sit a price-is-cheap flag, a sell-price-is-low flag and a rank sensor for the current period. They refresh every minute and immediately after each of the hub's price events.
So an automation is one state condition on one entity, on either route. The rank, since it appears in both places: it is where the current period sits among the periods of today that are known — 1 being the cheapest, and the denominator being how many periods the hub has prices for so far.
⚠️ If your integration is older than that, the windows are not entities and the state has to be asked for — through an action that returns the same structure the MQTT message carries. The recipe for that is a trigger-based template sensor, and it still works; it is simply no longer necessary. Update the integration and the step disappears.
One border worth keeping: the per-rule sensors were verified in test rather than watched opening on a live hub, because the bench was powered down before a window came round. The mapping is checked; the sight of it is not yet reported.
What an automation comes down to
The plumbing differs, as above. The logic does not, and once the state is where your automation can see it, it is three lines:
- Is the window called
Boileractive? — ask the state. - Yes → your automation turns the boiler's switch on.
- No → your automation turns it off.
Every decision after step 1 is Home Assistant's. The hub contributed one boolean and the reason for it.
And openings and closings are written to the hub's own log too, so you can read afterwards what happened while you were not watching:
price: window 'Boiler' on until <time>
price: window 'Boiler' off, next <time>
The one blueprint that ships, and what it is for
The integration brings two blueprints. The first, RBgrid — notify on hub events, does what its name says: it notifies. Its default list of event kinds covers hardware and connection events — reverse flow, a module gone missing or back, a node offline or online, a stuck bus, firmware, failures.
Price events are not in that default list. You can add the price kind yourself, and you will then be notified about windows — along with every other price event, including each successful fetch, because they share one kind and cannot be separated.
The second, RBgrid — cheap window turns a switch on and off, takes a window sensor and a switch, a light, a fan or an input boolean, with an option to invert. It is worth being exact about what that means, because it is the same limit as everywhere else in this article: the automation switches; the hub reports. The blueprint is a prepared automation, not a capability of the meter.
What the hub will never do
- It switches nothing. There is no relay on it and no setting that makes it turn anything on.
- It does not plan for you beyond the rule. A rule is a description of which periods qualify; the hub applies it and says what the answer is.
- There are no windows on the sell side. Windows use the all-in buy price. For export, the sell is low flag is the signal.
- Nothing happens without a set clock. Rules describe hours and days; a hub that has not synchronised its clock cannot place them.
When it didn't open and you expected it to
- Check the prices arrived — and read the next paragraph, because this is the common one. A rule about the cheapest periods of a span needs the prices for that span. The hub's log says what was stored and when.
- Check the two levels. Equal levels make a window flicker; a gap too wide keeps it shut.
- Check the clock. See above — it is the quiet one.
- Check which price the period used. If the source failed and your plan covered the period instead, the window was evaluated against the plan's rate, which is a different number. The log names the source for every period.
The night tomorrow's prices were late
This is worth its own paragraph, because it produces a window that looks wrong and is not.
The hub does not wait for prices and does not skip the hours it has no market price for. It ranks every period of the window at the price it would charge for that period — the market source, then your backup, then your plan's zone rate with its fees and VAT. Then it re-decides continuously, so when the prices do arrive, the window moves to the hours that are really cheapest among those still ahead.
Two consequences, and both are honest behaviour rather than faults:
- the window can open somewhere you did not expect — in the evening, if today's market prices there beat your plan's rate, or in the night at the plan rate when nothing else is known;
- the window can run shorter than you asked. A pick that has already run is not undone; if the new cheapest set includes periods that have passed, they count as chosen and can no longer run, and the hub does not top the night up with extra periods. The next day is normal.
If the prices never arrive at all, everything is ranked at your plan's rate and the window lands in the cheapest plan periods — typically the night zone, if your plan has one.
In every one of those cases the window opened correctly for the data the hub had at the time. The event log shows each move, and the price log's source column shows which periods were priced from the plan rather than the market.
Where to read more
- Price notifications and cheap windows — the full reference: every parameter, the published fields, and the worked example.
- Where your price comes from — how a period gets its price in the first place.
- Events — the hub's own log, including the window lines above.
- Two ways to run RBgrid — the route choice this article's last third depends on.