A node is an ESP32 that measures somewhere your hub can't reach by cable — a sub-panel in a detached garage, a pump in its own shed, an appliance on the far side of the house — and sends its readings over radio.
The first question is always the same, and nobody can answer it for you: will it reach? That depends on your walls, your panel, your building. What we can tell you is that you can find out in about ten minutes, with nothing mounted and nothing drilled.
So do that first.
Before you start
A node needs three things, and the first one surprises people:
- A module that measures voltage. On v1.1.7 a node records energy only if one of its rbAmp modules measures voltage. With current-only modules it will show you live current and store nothing — no periods, no history, no cost. So the set for a node is a single-phase rbAmp set with voltage measurement.
- An original ESP32 with 4 MB of flash and no PSRAM. Not an S2, S3 or C3 — the node firmware isn't built for them.
- A hub that is on your Wi-Fi. The radio the node talks to is the Wi-Fi radio, so a hub with no network has nothing for a node to find.
⚠️ For any work inside an electrical panel, call a qualified electrician.
Pair it where it will live
Not on the bench. The whole point of the next ten minutes is to test the path the node will actually use, so take it to the spot, power it there, and pair it from where you stand.
Points → Nodes → open the pairing window. You choose how long the window stays open — anywhere from 10 seconds to 10 minutes. Power up the node inside that window and the two find each other: they exchange keys, and the node's points appear in the app straight away, with history from the first hour. Neither device restarts.
You never pick a radio channel. The node scans for the hub and locks onto it by itself — on our bench, in under four seconds.
⚠️ The pairing window has no PIN. While it is open, any RBgrid node in range that asks to pair will be paired. Open it only when you are about to power up your own node, close it after, and check the node list to see what joined.
The three numbers
Once paired, the node's card shows the link. These are what replace a promise about distance:
- Signal — the strength of the last message the hub heard from this node.
- Lost packets — the share the node missed over the last minute or so. It isn't there until the first full window has passed, so give it a minute before you read anything into it.
- Last heard — how long ago the hub heard from the node at all.
There is no pass mark, and we won't invent one. The firmware has no signal or loss threshold, so a number that looks respectable on one site means nothing on another. What you watch for is behaviour:
Leave it ten minutes with the load actually running — the pump pumping, the charger charging — and watch that lost packets stay at zero and the node stays online. A link that is fine while everything is idle and falls apart when the motor starts is the one that will waste your afternoon, and it only shows itself under load.
If that holds, mount it. If it doesn't, you have learned it for the price of standing in a shed, not of drilling a wall.
When it isn't good enough
In the order people usually try them:
- Move the node. A metre matters more than you would expect, and the node is the thing that moves — not the clamp leads. Extending sensor wiring to bring the measurement to the hub is the wrong way round, and it is exactly what a node exists to avoid.
- Get the antenna out of the metal. A node sealed inside a steel enclosure is talking through a box.
- Run a cable to a better spot for the node, and keep the radio hop short.
What the hub does while the link is down
This is the part worth knowing before you worry about a marginal link.
A node keeps its own time and closes each 15-minute period by its own clock. If the hub is unreachable, the node holds those finished periods in memory — on v1.1.7, up to eight of them, about two hours — and sends them when it gets back. They are filed and priced by the time they were measured, not the time they arrived. A two-hour outage costs you nothing at all.
Past that, the ninth period pushes out the oldest, and that one is gone for good. So the question for a flaky link is not "did I lose data" but "was the gap longer than two hours".
Two things the hold does not survive:
- A node that loses power loses the queue and the period in progress.
- A node that boots while the hub is unreachable keeps its energy, but files it at the wrong time. Its clock comes from the hub, so until it has heard from one it can't close a period. On v1.1.7 everything it measured in the meantime then arrives in its first record, which covers the whole stretch from power-up to the end of the first full 15-minute period — and is filed as if it all happened in that one period. Nothing is lost; a day of running blind simply lands in a single quarter-hour of your history.
When something looks wrong
The hub calls a node offline after about fifteen seconds without a word from it, and logs it as an event — on MQTT too, if you use it, along with a per-node status topic and a signal sensor in Home Assistant.
⚠️ Out of range and switched off look identical. The app cannot tell them apart, and neither can the API. What distinguishes them is what happened before: a link going bad usually drifts first — lost packets rising, signal falling, the node flapping between online and offline. A power cut is a clean drop with good numbers right up to the last moment.
A marginal link shows up as lost packets above zero and gaps in the live values. Your records are more robust than the live view: periods are re-sent until the hub acknowledges them, so they keep arriving late and still land in the right hour, as long as you are inside the two-hour hold.
If the router changes its Wi-Fi channel, the node notices the silence after about eight seconds and goes looking for the hub again. Nothing restarts, and the periods closed in the gap are held.
Turning the hub's node radio off behaves the same way: the nodes keep closing their periods and hold up to eight of them, then send them when the radio comes back. What you lose is the live view for that stretch, and anything older than the hold — not your records.
Moving or removing a node
Removing a node deletes its points and their history. That is worth reading twice before you tidy up a list.
A node doesn't stay married to a hub it can't hear. After about 150 seconds without a reply it marks itself unpaired and starts asking to pair again on its own; reset it and it asks straight away. So moving a node to another hub — or re-pairing one you removed — is: open the pairing window on the hub you want, then reset the node, or simply wait two and a half minutes. Erasing its flash is an option for a clean start, not a requirement.
⚠️ That is also the other half of the warning above. A node anywhere in range that has lost its own hub will be asking to pair — so an open window with nothing of yours powering up is an invitation to whatever else is listening.
And one that catches people out: a node has no over-the-air update. The hub updates itself from the app; the node does not. New firmware goes on over USB, the same way it went on the first time — so put it somewhere you can still get at it with a cable.
What a node is not
It is a sender. It has no display, no web interface, no storage of its own, and it does nothing on its own if the hub disappears beyond holding those two hours. The measuring is done by the rbAmp modules attached to it; the node reads them and passes it on.
On v1.1.7 it also doesn't do three phases: phase grouping belongs to the hub and its own input module, and a node takes a single-phase set.
⚠️ A node does not add history. Its points share the same twelve history slots as everything wired to the hub — a node you add takes slots from points you already keep. → Which loads are worth a history slot
Next
- Sensors and modules · Points
- What the release changed: RBgrid v1.1.7
- Questions → Support