If you are into off-grid solar, small cabins, RV setups, or just a garage tinkerer running a 12V system, chances are the Renogy Wanderer has crossed your radar. It is affordable, reliable, and does exactly what a PWM solar charge controller should do — keep your battery happy and your loads powered. But what happens when you want to talk to it from an ESP32? That is where the real adventure begins.
What is the Renogy Wanderer?
The Renogy Wanderer is a PWM (Pulse Width Modulation) solar charge controller available in 10A and 30A variants. Designed for small to medium off-grid solar setups — think RVs, boats, cabins, garden sheds, and yes, IoT-powered smart farming setups — it features a 4-stage PWM charging algorithm (Bulk, Boost, Float, and Equalization), a backlit LCD display, multiple protection functions (overcharge, over-discharge, short circuit, reverse polarity), and a built-in USB charging port.
The Wanderer-Li variant adds two important features: an RS232 communication port and Lithium battery mode. The RS232 port is how the BT-1 Bluetooth module plugs in — and it is also the rabbit hole this article is all about.
The LiFePO4 Problem — and the GEL Workaround
Here is something Renogy does not shout from the rooftops: the standard Wanderer does not have a dedicated LiFePO4 battery profile. The Wanderer-Li has a generic “Lithium” mode, but for those running LiFePO4 cells — pretty much the gold standard for DIY solar storage these days — this creates a small but important dilemma.
LiFePO4 batteries have a strict maximum charging voltage — typically 14.4V for a 12V pack. Push above that and the battery’s built-in BMS will disconnect and throw a fault. On the Wanderer, the FLU (Flooded) battery setting pushes charging voltage above 14.4V, which is exactly the wrong thing for LiFePO4. The controller will try to charge, the BMS will panic, disconnect the output, and you will be greeted with a lovely E04 error code on the LCD.
The workaround? Set the battery type to GEL. GEL batteries have a gentler charging profile that keeps voltage within safe limits for LiFePO4. It is not a perfect chemical match, but in practice it prevents the E04 disconnect and keeps your cells happy. Not an official Renogy recommendation — but the community has landed on this as the go-to solution.
TL;DR on battery settings for LiFePO4: Avoid FLU. Use GEL. Save yourself an E04 headache.
Adventure #1: RS232 Direct to ESP32 — The Meltdown
The Wanderer’s RS232 port uses an RJ12 connector and speaks Modbus RTU. The natural first instinct for any maker is: “I have an ESP32, I have an RS232-to-TTL converter module, let’s wire this up and read some registers.”
And that is exactly what was done here — with some spicy results.
The RS232 converter module got extremely hot almost immediately — hot enough to be a genuine concern about melting or damage. But that was not the only problem. With the ESP32 connected to both the RS232 converter and the Wanderer’s output simultaneously, a back-powering issue appeared. When the Wanderer’s load output was active, power fed back through the converter into the ESP32’s power rails — causing the ESP32 to behave erratically, hang on startup, or reset unexpectedly.
This is a known hazard with non-isolated RS232 converters. The RS232 voltage levels (±12V swings) and the lack of galvanic isolation mean the converter becomes a sneaky back-feed path when multiple power sources are in play. Lesson learned the warm way.
If you are planning direct RS232 comms with the Wanderer:
- Use an isolated RS232-to-TTL converter (look for modules with onboard optocoupler isolation)
- Do not share ground between the Wanderer output and ESP32 VCC unless you know exactly what you are doing
- Consider powering the ESP32 from a completely separate supply, not from the Wanderer’s load output through the converter
Or… skip RS232 entirely and go Bluetooth. Which brings us to the good part.
Adventure #2: Renogy BT-1 + ESP32 BLE — What Actually Works
The Renogy BT-1 is a Bluetooth module that plugs into the Wanderer’s RS232 RJ12 port and exposes the Modbus interface over BLE. Renogy sells it as a companion for their DC Home app, but it is perfectly usable with an ESP32 — once you navigate the gotchas that the documentation conveniently forgets to mention.
The BLE Service Map (Confirmed via nRF Connect)
This is the most critical piece of information — and the part that trips up almost everyone coming from online examples:
| Direction | Service UUID | Characteristic UUID | Properties |
|---|---|---|---|
| Send Modbus request | FFD0 | FFD1 | Write |
| Receive Modbus response | FFF0 | FFF1 | Notify |
You write to FFD1 but subscribe for notifications on FFF1 — and these live under completely separate services. Most examples online assume TX and RX share the same service UUID. They do not. Getting this wrong means your ESP32 sends commands into the void and receives absolute silence in return.
Other Gotchas You Need to Know
- Device name is empty during advertising. The BT-1 advertises with no name. Do not try to match by device name in your BLE scan callback — match by service UUID
FFD0instead. - Modbus address is 255 (0xFF), not 1. The Renogy Wanderer uses address 255. This is undocumented officially but confirmed by the community through painful trial and error.
- Only one BLE connection at a time. If the Renogy DC Home app is open on your phone, the ESP32 cannot connect. Force-close the app first.
- Power cycle the BT-1 if it stops advertising. After a connection drops unexpectedly, the BT-1 sometimes refuses to advertise until you physically unplug and replug it from the RJ12 port.
Register Layout — Confirmed Working
Based on community-verified reverse engineering (credit to wrybread’s RS232 sketch, which maps cleanly to the BLE Modbus interface), here are the working registers:
| Register | Value |
|---|---|
0x0100 | Battery SOC % |
0x0101 | Battery voltage × 0.1 V |
0x0102 | Charge current × 0.1 A |
0x0103 | High byte = controller temp °C, Low byte = battery temp °C |
0x0104 | Load voltage × 0.1 V |
0x0105 | Load current × 0.01 A |
0x0106 | Load watts |
0x0107 | Solar panel voltage × 0.1 V |
0x0108 | Solar panel current × 0.01 A |
0x0109 | Solar panel watts |
0x010B | Min battery voltage today × 0.1 V |
0x010C | Max battery voltage today × 0.1 V |
0x010D | Max charge current today × 0.01 A |
0x010F | Max charge watts today |
0x0111 | Charge Ah today |
0x0113 | Charge Wh today |
0x0115 | Controller uptime days |
0x000A | Info registers start (17 regs — ratings, versions, serial) |
Pro tip for efficiency: Read 0x0100 with a count of 35 to pull all live data in a single Modbus request. Read 0x000A with a count of 17 for controller info (hardware version, software version, serial number, rated current).
Putting It All Together
Once the BLE service map is right and your ESP32 is correctly subscribed to FFF1 notifications while writing to FFD1, the data starts flowing beautifully. Real-time solar panel voltage, charge current, battery SOC, load stats, temperature readings, and daily energy totals — all from a controller that costs a fraction of what MPPT alternatives charge.
From there the possibilities open up: publish readings to MQTT, feed them into Home Assistant, visualize energy production on Grafana, or trigger automations based on battery SOC thresholds. The Wanderer stops being just a charge controller and becomes a fully-fledged node in your smart energy monitoring system.
Final Thoughts
The Renogy Wanderer is a solid, budget-friendly PWM controller. It does its core job well. The BT-1 integration is genuinely useful once you get past the undocumented quirks — and that is exactly the kind of reverse-engineering puzzle that makes tinkering with this stuff so satisfying.
Just remember: GEL setting for LiFePO4, skip direct RS232 unless you have an isolated converter, and FFD1 to write, FFF1 to listen. Three things that would have saved hours of debugging — and one nearly-melted RS232 module.
Happy hacking. ☀️⚡