It cost me six weeks of deep-dive engineering: a brand-new ESP32 platform, a complete build system overhaul, a cloud tunnel to escape CGNAT, support for an extra BLE device for fresh water level monitoring, and a safe OTA updater that won’t brick the system mid-download. Here is the full story of how it came together.

Phase 6: Hitting the Wall with the Cheap Yellow Display

The CYD-C5 is a wonderful little board for the money, but I kept bumping into its ceiling. The 2.8″ screen was cramped once I started adding solar and battery data. Moreover, the C5 was still a small single-core part. If I was going to live with this panel for years, I wanted room to grow.

Phase 7: The Big Leap — ESP32-P4 and a Proper 4.3″ Display

The new home for the project is a board called the JC4880P443C, built around Espressif’s ESP32-P4. On paper it’s a different league:

• Dual-core RISC-V at 400 MHz — I can pin the blocking LIN serial task to one core and let WiFi, the web server and the screen breathe on the other.
• 32 MB of PSRAM and 16 MB of flash — enough to hold a full framebuffer in memory and stop counting kilobytes.
• A 4.3″ 800×480 ST7701 RGB panel with GT911 capacitive touch — more than four times the pixels of the CYD-C5.

There’s a catch, and it’s a big one: the P4 has no built-in WiFi or Bluetooth. Radio is handled by a separate ESP32-C6 co-processor that the P4 drives over a high-speed SDIO link. Two chips, two firmwares, one device. That architecture would later cause some of the most interesting bugs in the whole project (more on that below), but it also meant I could eventually update the radio chip’s firmware through the main chip, over the air.

Phase 8: Leaving the Comfort Zone — From PlatformIO to ESP-IDF

The CYD firmware was built on the Arduino framework through PlatformIO — friendly, forgiving, and full of ready-made libraries. The P4 is so new that most of that ecosystem simply doesn’t support it yet. So I took the plunge and rewrote the entire build on Espressif’s native toolchain, ESP-IDF 6.0, driven by idf.py.

This was not a free afternoon. It meant swapping Arduino’s comfortable String and JSON helpers for lower-level C/C++, replacing the web server stack, and learning a long list of P4-specific quirks the hard way: linker settings for early silicon, an internal-RAM budget that had to be measured and trimmed, a USB serial console that fought me for control of the port, and a TLS engine whose hardware cryptography produced subtly invalid signatures on this chip revision — which I eventually had to disable in favour of software crypto. Every one of those traps now lives in a written “skill” file in the repository so I never have to rediscover it.

Lesson learned: when you adopt brand-new hardware, budget most of your time for the toolchain, not the features. The heater logic from Part 1 ported over in an afternoon. Getting it to build and flash reliably took weeks.

Phase 9: The Display, Reborn

With four times the pixels, I rebuilt the user interface from scratch in LVGL, the embedded graphics library. The screen is now three clean bands:

• A top bar with the outdoor temperature, a settings gear and live status dots (cloud, Bluetooth, WiFi, LIN)
• A central dashboard split between the heater controls and the energy panels
• A bottom status bar with the network name and IP.

I used FontAwesome icons rendered as a custom font subset so the controls look like real product UI rather than a hobby project — thermometer, flame, fan, water drop, solar panel, battery. Little touches crept in over the weeks: caret triangles for the setpoint and fan controls, a boiler “thermometer” gauge, animated power-flow lines between the solar/battery/inverter panels.

Phase 10: A Real Web App

The phone interface got the same treatment. Instead of embedding the web files inside the firmware binary, they now live in their own 8 MB filesystem partition and are served by the P4’s native HTTP server over a WebSocket connection. A build step automatically gzip-compresses every asset and stamps a version hash on each file, so browsers always refetch what changed and never serve a stale cached panel.

Crucially, the web UI now mirrors the physical screen: the same layout, the same panels, the same live data, kept in sync over the WebSocket. Touch the LCD and the phone updates; tap the phone and the LCD follows. It’s a Progressive Web App too, so it installs to the home screen like a native app, and it reflows cleanly from a desktop browser down to a phone in portrait.

Phase 11: Escaping CGNAT — A Cloud Tunnel of My Own

Here’s the problem that nearly stopped the whole project: my motorhome connects through a mobile router, and like most cellular connections it sits behind Carrier-Grade NAT. There is no public IP address to forward a port to. From the open internet, the panel is simply unreachable. Every “just port-forward it” tutorial is useless here.

The solution was to build my own secure reverse tunnel. A small Node.js bridge runs on my web server with a real public address; the firmware “dials out” to it over an encrypted WebSocket and holds the connection open. When I open the panel from my phone, my request goes to the cloud server, down through the tunnel, into the van, and back. The motorhome never needs to accept an incoming connection — it only ever makes outgoing ones, which CGNAT happily allows.

Making that reliable over a flaky mobile link was its own saga: detecting a dead bridge in seconds rather than minutes, rebuilding a wedged connection automatically, surviving the server’s idle timeouts, adding password protection for the tunnelled web access, and teaching the bridge to shrug off the endless background noise of internet vulnerability scanners. The bridge eventually grew big enough to live in its own repository.

Phase 12: More Senses — Inverter and Fresh Water Tank Level

With memory to spare, I kept adding data sources. The panel now reads, in addition to the solar charger and battery BMS from Part 1:

• The Victron Multiplus inverter/charger over Bluetooth, showing live power flow in and out of the AC side — with animated arrows for charge vs. discharge.
• A wireless fresh-water tank sensor using the open BTHome standard.

Getting Bluetooth reception solid through the C6 co-processor took real detective work — modern Victron devices broadcast using BLE 5 “extended advertising”, which I had to explicitly enable, and I had to widen the scan window to claw back range that the radio chip was losing to WiFi coexistence. I added a serial scan command just to see, live, which devices were in range and how strong their signal was.

Phase 13: Updating in the Wild — Over-the-Air, Without the Fear

If I’m going to fix a bug while the van is parked, I need to push new firmware over the air — and I absolutely cannot afford for a half-finished download to leave the panel dead.

The system pulls releases straight from GitHub Releases, compares versions, and only nags me for a manual update on meaningful (minor/major) releases rather than every tiny patch. The download streams directly into a spare flash slot. The clever part is the safety net: after flashing, the new firmware boots into a probation period. It has to prove it can actually start up, get an IP and keep enough memory free; if it can’t, the panel automatically rolls back to the previous version on the next reboot. A bad update heals itself.

It can even update the web interface assets separately from the firmware, and reflash the ESP32-C6 radio co-processor through the main chip when their versions drift apart. Getting all of this stable over a slow mobile connection meant a long tail of fixes: pausing Bluetooth during downloads to free up memory, adaptive download throttling so the SDIO link to the radio chip wouldn’t choke, and keeping the cloud tunnel alive through the whole process so I can watch progress remotely.

I have, genuinely, never been so relieved as the first time a remote update completed, rebooted, and reconnected on its own.

Phase 14: Reorganizing the code and the knowledge

The code was a little bit unorganized after many tests, so it was refactored to a more modular system with test coverage. First, the tricky decoding logic — the byte-level parsers for every Bluetooth device, the LIN protocol checksums, the fault-log encoder — was pulled out into hardware-independent modules with automated tests. I can now verify the math that interprets a Victron broadcast or a heater frame.

Second, the repository now carries a set of detailed “skill” documents — one for the build-system traps, one for each Bluetooth protocol, one for the cloud tunnel, one for the OTA system, one for the Truma LIN frames. Every painful lesson is captured the moment I learn it, so the next time I (or anyone) touch that corner of the code, the landmines are already mapped. It’s the documentation I wish every hardware project shipped with.

Conclusion: From Proof of Concept to Daily Driver

Part 1 proved I could talk to the heater. Part 2 was about everything that turns a clever demo into something you trust with your family’s hot water on a winter night, hundreds of kilometres from your workbench.

• A bigger, dual-core brain with room to grow.
• A proper 4.3″ interface mirrored to a phone-friendly web app.
• A self-built cloud tunnel that punches through carrier NAT.
• A full picture of the van’s energy — solar, battery, inverter, water, weather.
• An over-the-air update system with a parachute, so I can keep improving it without ever opening the panel again.

The result is something that offers: global remote control and far richer telemetry than the original hardware, on a panel I can extend at will.

The project is open source. If you want to dig into the code, the protocol notes, or the cloud bridge, it’s all on GitHub — and I’d love to hear from anyone tackling the same problem in their own van.

The post Upgrading TruMinus: From CYD-C5 to the Power of Guition JC4880P443C appeared first on Víctor Dorado.

Note: You can view the code related to this project at https://github.com/vidorado/truminus

Introduction

If you own a motorhome with a Truma Combi heater, you’ve probably shared my frustration: You’d like to turn on your boiler 20 minutes before you come back to the van, so you can take a shower immediately, but the standard CPPlus controller doesn’t allow internet connectivity out of the box. Sure, you can buy an iNet Box, but it requires a yearly subscription and—here is the catch—your CPPlus unit must be “iNet Ready.” Mine wasn’t.

Instead of paying for a subscription and upgrading my hardware to a closed ecosystem, I decided to build my own solution. Inspired by the olivluca/truminus and olivluca/TrumaDisplay projects, my original plan was to build an iNet Box simulator that would sit in parallel on the Truma TIN bus. Even though my CPPlus didn’t say “iNet Ready,” it was a brand-new 2025 heater, so I gambled on it being compatible. Spoiler alert: I was wrong.

I’ve developed the core of the project using Claude Code and Kimi K2.6. It’s been an incredible experience acting as the orchestrator, focusing on the UX and QA, while letting the AI handle the heavy lifting of implementation details.

Phase 1: The “iNet” Gamble

My first approach was conservative. I didn’t want to remove the original CPPlus, so I planned to build a “Man-in-the-Middle” device. Using an ESP32 C3 Supermini, I tried to emulate an iNet Box to sit alongside the original controller on the TIN-Bus.

I had high hopes. My heater was a brand-new 2025 model, and I assumed Truma would have made it compatible by default. I spent time trial-and-error-coding the emulation layer, but the heater simply wouldn’t recognize the device. The lesson? If the screen doesn’t say “iNet Ready,” it really isn’t.

The first prototype with the ESP32 C3 and wires everywhere

Phase 2: Pivoting to the CYD (Cheap Yellow Display)

Since I couldn’t “talk” to the CPPlus, I decided to replace the CPPlus. I moved the project to the ESP32-2432S028, popularly known as the CYD (Cheap Yellow Display). This gave me a 2.8-inch touchscreen and some GPIOs.

To make it fit the motorhome’s aesthetic, I designed a custom PCB the exact same size as the screen. This “sandwich” design meant the unit would be deep but have a small footprint on the wall, making it much easier to mount.

The Software Grind: I spent hours at my desk iterating on the UI (AI doesn’t hit the bullseye with C++ and embedded hardware as quick as with other more common technologies like PHP, Javascript… etc.

I wanted a professional feel, with intuitive menus and a built-in web server. The biggest headache was the ESP32’s memory. Between the graphic library (LVGL/TFT_eSPI), the Wi-Fi stack, and the web server, I kept hitting “Out of Memory” crashes. It took many some nights of code optimization and AI-assisted debugging to get the loop running smoothly.

The CYD display showing the main menu

Phase 3: Field Testing & Reverse Engineering

Once the UI was stable, it was time to move from the desk to the van. This is where things got real. I used WomoLIN logs as a baseline, but since my heater was so new, the commands didn’t match perfectly, so I had to perform Live Sniffing. I connected the CYD in parallel with the original Truma panel and watched the hex codes fly by.

Working inside the van, wires connected to the Truma unit

The “Cold Sweat” Moment: During one of these tests, the heater suddenly locked up. A red light started flashing: Error E545. I searched every manual—nothing. The heater was unresponsive. I had to literally dismantle the furniture to reach the Combi unit’s core. After a few tense minutes of panic, I found the physical reset button. A long press later, the “clac-clac” of the diesel pump returned. I’ve never been so happy to hear a clicking noise in my life.

The Truma unit

Phase 4: Adding the “Pro” Features (Victron & Ultimatron)

Since I had a powerful screen, I figured: why stop at the heater? I wanted a “Command Center.”

1. Victron SmartSolar MPPT: I connected to it via bluetooth based on chrisj7903/Read-Victron-advertised-data project. I had to fix some decryption issues because my newer MPPT used a slightly different frame format than the open-source libraries I found.
2. Ultimatron LiFePo4: I integrated the battery status via Bluetooth/Serial based on the sergkh/node-ultimatron-battery project.

Now, in one single glance, I could see my room temperature, manage my heater and boiler, and check my solar harvest and my battery percentage.

Screen showing the Solar and Battery stats

I also dedicated significant time to fine-tuning the web server to mirror the physical display’s state. By implementing a real-time WebSocket (WS) connection, I ensured that any change on the web interface is instantly reflected on the screen and vice versa, creating a seamless, zero-latency synchronization

Landscape view of the web app

Portrait view of the web app

Phase 5: 3D Case Design & Installation

The final hurdle was physical. In my van, the auxiliary drop-down bed partially covers the original control area. I had to mount the new panel as low as possible so I could still see the temperature while lying in bed.

I used Shapr3D to design a bespoke enclosure. I wanted it to look factory-spec, so I added a recessed Truma logo. A friend printed it for me on a multi-color Bambu Lab printer, and the result was incredible. To hide the old screw holes in the wood, I used a matching wood-effect vinyl—the integration is seamless.

Wood Machining & Panel Adaptation

The physical integration was a delicate part of the project. In my motorhome, the auxiliary drop-down bed partially blocks the original control area when lowered. I had to study the dimensions carefully to reposition the new system as low as possible without losing visibility or functionality.

After taking precision measurements, I proceeded to machine the original wooden panel. This required immense patience; it was crucial not to splinter the plywood while creating the exact cutouts for the CYD screen and the internal electronics. Ensuring everything was aligned and firm, while taking advantage of the empty space behind the panel, was a major milestone

Conclusion

Developing this controller was a significant technical challenge. Reversing the proprietary TIN-bus protocol and resolving critical errors, such as the E545, required nerves of steel and extensive debugging.

The result is a system that outperforms the original hardware in responsiveness and telemetry. It now offers global remote access and a data granularity that exceeds the official iNet Box’s capabilities. Future iterations may include water level monitoring, but the current focus is the system’s deployment in a live environment.

The post Advanced Motorhome Truma Control Panel: A Custom ESP32 CYD Journey appeared first on Víctor Dorado.