Question 1

Why is rbAmp 5 V-powered but the I²C bus is 3.3 V?

Accepted Answer

The module has its own microcontroller doing the measurement, and it needs clean, stable power to keep the ADC readings accurate. So the module takes 5 V on VCC and runs it through an on-board low-noise regulator that derives the 3.3 V its MCU actually runs on. Because the MCU is a 3.3 V part, the I²C lines (SDA/SCL) operate at 3.3 V logic — they're 5 V-tolerant, but they idle at the host's 3.3 V level. In short: power the module at 5 V (4.5–5.5 V; below 4.5 V the ADC loses accuracy), wire the I²C bus at 3.3 V logic. On an ESP32 or classic Arduino that's automatic — the bus follows the host's 3.3 V rail, independent of the 5 V supply.

Question 2

Do I need external I²C pull-up resistors for rbAmp?

Accepted Answer

For a single module, no — the rbAmp PCB carries built-in 4.7 kΩ pull-ups on SDA/SCL to 3.3 V. For a multi-module bus, keep the pull-ups on one module and disable them (a solder jumper) on the rest, so the parallel combination doesn't drag the bus resistance too low. See the multi-module build.

Question 3

Is the rbAmp module isolated from mains?

Accepted Answer

Yes — there's a galvanic isolation barrier inside between the mains side (voltage sense, CT input) and the low-voltage side (I²C). The module's GND is the host's ground, not mains neutral, so wiring the LV side to your Arduino/ESP32 is safe. Don't open the enclosure — it voids the factory calibration.

Question 4

How accurate is rbAmp?

Accepted Answer

±0.5 % of reading per channel, with the matched rbAmp CT, after calibration and across the bulk of the range (accuracy widens near the very low end, as it does for any meter). It measures true active power — the mean of instantaneous voltage × current over the line cycle, with per-channel phase compensation — not current × assumed-voltage apparent power. A generic SCT-013 through a generic burden is looser than the matched CT. For a whole-panel figure summed across several modules, expect around ±1 % (module-to-module spread adds up). More on the physics: how CT energy measurement really works.

Question 5

Does rbAmp measure real power or just current?

Accepted Answer

Real (active) power, in watts, computed on the module per channel — plus voltage, current, power factor, and frequency. Because it has both the voltage and the current for each channel, reactive and low-power-factor loads read honestly; you're not multiplying current by an assumed voltage.

Question 6

Which boards and frameworks can I use with rbAmp?

Accepted Answer

Anything that speaks I²C: ESPHome / Home Assistant, Arduino / C++ (ESP32, Uno, Nano, STM32, RP2040…), Python on a Raspberry Pi or other Linux SBC, and ESP-IDF. All four client libraries are open and local — no cloud, no lock-in — over a documented I²C protocol.

Question 7

What I²C bus speed should I use, and why 50 kHz on ESP32?

Accepted Answer

It depends on the host driver, not the board brand: Host / driver Bus speed ESP-IDF i2c_master — ESPHome, MicroPython-ESP32, Arduino-ESP32 50 kHz STM32 HAL · RP2040 · non-ESP32 Arduino (AVR/STM32duino) · Linux SBC (kernel I²C) 100 kHz The ESP-IDF i2c_master driver's transaction timing interacts with the module's I²C recovery window at 100 kHz and produces intermittent read NACKs, so 50 kHz is the standing recommendation on ESP-IDF-based masters (that includes Arduino-on-ESP32, which wraps the same driver). Every other master runs the module at 100 kHz cleanly. The axis is the driver, not the board.

Question 8

Can I put several rbAmp modules on one I²C bus?

Accepted Answer

Yes — that's a core feature. Modules share one I²C bus and differ only by address. Add circuits by adding modules on the same two wires, behind one host — no extra microcontroller, no serial-port juggling. For coherent energy across modules, one broadcast latch snapshots them all on the same instant. See the builds: whole panel on one ESP32 and multi-module Arduino bus.

Question 9

How do I change an rbAmp module's I²C address?

Accepted Answer

On current firmware it's a plain, production-ready operation — no special mode, jumper, or factory tooling. You stage the new address, arm the change, and commit it (a two-phase, magic-armed sequence so an address can't change by accident); the module reboots at its new address. Do it one module at a time, with the others disconnected, so there's no address clash. Your library exposes it directly (e.g. prepareAddressChange() / commitAddressChange(), or a fleet-provisioning helper).

Question 10

How does rbAmp handle energy (Wh), and does it survive a reboot?

Accepted Answer

Energy is integrated over exact wall-clock intervals: the module latches a measurement window atomically and the host integrates true active power over the elapsed time, so there's no on-device counter to quantize or drift. In the ESPHome component, the accumulated energy is persisted to the ESP32's NVS, so an energy total survives a reboot or brownout without a gap or reset in Home Assistant. In a bare-Arduino sketch, the host owns the running total — persist it yourself (e.g. to an SD card) if you need it across power cycles.

Question 11

Does rbAmp need the cloud or a subscription?

Accepted Answer

No. It's fully local and open — a documented I²C protocol with open ESPHome, Arduino, Python, and ESP-IDF libraries. Nothing phones home; you own your data.

Question 12

Does rbAmp work with the Home Assistant Energy Dashboard?

Accepted Answer

Yes — via ESPHome the module's energy sensor lands in the Energy Dashboard out of the box. See the 15-minute Home Assistant setup.

rbAmp — Frequently Asked Questions

Power & hardware

Accuracy

I²C & boards

Addressing & multi-module

Energy

Integration

Related posts

Log Your Energy Data to an SD Card with Arduino — Timestamped CSV, No Cloud

Does rbAmp work with the Home Assistant Energy Dashboard?

How does rbAmp handle energy (Wh), and does it survive a reboot?

How do I change an rbAmp module's I²C address?