Monitoring an Elegoo Centauri Carbon 2 3D printer from a Raspberry Pi: MQTT, a fragile camera and a bug that stole replies

I have an Elegoo Centauri Carbon 2, a pretty fast 3D printer, and I wanted to check its status from my phone: progress, temperatures, time left… without depending on Elegoo’s cloud. So I built my own web dashboard in Python that runs on the Raspberry Pi.

It works. But along the way I ran into several surprises you won’t find in any manual, because Elegoo doesn’t publish its protocol documentation. Here they are, in case you have this printer or any other that speaks MQTT.

How the printer talks: SDCP over MQTT

The printer uses a protocol called SDCP that runs over MQTT, a messaging system widely used in home automation: programs subscribe to “topics” and receive whatever is published there. The printer listens on port 1883.

With no official docs, I relied on what the community has reverse-engineered (Home Assistant projects and the like). That has a consequence: it can change with each firmware. For example, 02.x firmwares are known not to complete client registration, so my dashboard detects that and switches to a read-only mode: it monitors, but doesn’t send commands.

LAN Only: the app or your program, pick one

For the printer to open its local MQTT you have to enable LAN Only in its settings. And here’s the first surprise: with LAN Only enabled, Elegoo’s official app doesn’t work, because it requires pairing the printer with the cloud.

	Official app	My dashboard
LAN Only on	❌	✅
LAN Only off	✅	❌

They’re mutually exclusive. I chose the dashboard. To see it away from home I use a VPN to the router (WireGuard): the phone “joins” the home network and the dashboard works just like on the sofa.

The two codes (don’t mix them up)

The printer shows two different codes on screen:

• Access code (Settings → LAN Only): what local programs need, like my dashboard or the slicer over the network.
• PINCODE (Settings → Device): to pair the printer in the official app.

And careful: the access code is regenerated when you turn LAN Only off and on again. If your program suddenly stops connecting with a registration error, the first thing to check is whether it changed.

The camera that kept freezing

The printer has a camera. At first my dashboard showed it, and I also had OctoEverywhere (a service for remote access and AI failure detection) using it at the same time.

Result: the camera froze within hours. The video port stopped responding and the only way to recover it was restarting the printer. The command to relaunch the camera said “OK” but did nothing.

After two crashes I drew the conclusion: the firmware’s video process only handles one client, and doesn’t even cope well with connections opening and closing repeatedly (OctoEverywhere does that every few seconds for its AI).

The stable setup was:

• One single program uses the camera (the slicer on the PC, when I need it).
• My dashboard and OctoEverywhere only read status over MQTT, without touching the video.

Rule learned the hard way: with cheap devices, one service, one client. Don’t assume they handle several connections.

The wildcard that stole replies

This was the strangest one. For two days, the print costs my dashboard calculates kept appearing and disappearing with no pattern. Sometimes right, sometimes empty.

The cause was one line:

f"elegoo/{sn}/+/api_response"            # WRONG: receives other clients' replies
f"elegoo/{sn}/{client_id}/api_response"  # RIGHT: only mine

In MQTT, + is a wildcard: “anything in this position”. My dashboard had subscribed to the replies of every client connected to the printer, including OctoEverywhere. When a reply to another program’s question arrived, my dashboard took it as its own and overwrote its data.

By subscribing only to its own client_id, the ghost data disappeared.

The IP that changed

One day the dashboard stopped getting data. The printer kept printing happily. What had happened: the router had given it a different IP via DHCP, and the dashboard was still looking at the old one.

To find it, I scanned the network for whoever had port 1883 open, and confirmed it was the printer with the protocol’s own discovery feature. The permanent fix is a DHCP reservation on the router so it always gets the same address.

What I take away

1. If a manufacturer doesn’t document the protocol, make your program fail gracefully: read-only mode, a debug mode to see raw traffic…
2. In MQTT, subscribe to the minimum. Wildcards are handy, but they bring in messages that aren’t yours.
3. A fragile resource gets one client.
4. Fixed IP for any device your programs connect to.