Vigilar una impresora 3D Elegoo Centauri Carbon 2 desde la Raspberry Pi: MQTT, una cámara frágil y un fallo que robaba respuestas

Tengo una Elegoo Centauri Carbon 2, una impresora 3D bastante rápida, y quería ver su estado desde el móvil: progreso, temperaturas, cuánto queda… sin depender de la nube de Elegoo. Así que me hice un panel web propio en Python que corre en la Raspberry Pi.

Funcionar, funciona. Pero por el camino me encontré con varias sorpresas que no salen en ningún manual, porque Elegoo no publica la documentación del protocolo. Te las cuento por si tienes esta impresora o cualquier otra que hable MQTT.

Cómo habla la impresora: SDCP sobre MQTT

La impresora usa un protocolo llamado SDCP que viaja sobre MQTT, un sistema de mensajes muy usado en domótica: los programas se suscriben a «temas» y reciben los mensajes que se publican en ellos. La impresora escucha en el puerto 1883.

Como no hay documentación oficial, me basé en lo que ha reconstruido la comunidad (proyectos para Home Assistant y similares). Eso tiene una consecuencia: puede cambiar con cada firmware. Por ejemplo, se sabe que los firmwares de la serie 02.x no completan el registro del cliente, así que mi panel detecta esa situación y pasa a un modo solo lectura: vigila, pero no envía órdenes.

LAN Only: la app o tu programa, elige

Para que la impresora abra su MQTT local hay que activar LAN Only en sus ajustes. Y aquí la primera sorpresa: con LAN Only activado, la app oficial de Elegoo no funciona, porque exige vincular la impresora a la nube.

	App oficial	Panel propio
LAN Only activado	❌	✅
LAN Only desactivado	✅	❌

Son excluyentes. Elegí el panel. Para verlo desde fuera de casa uso una VPN al router (WireGuard): el móvil «entra» en la red de casa y el panel funciona igual que en el sofá.

Los dos códigos (no los confundas)

La impresora tiene dos códigos distintos en la pantalla:

• Código de acceso (Ajustes → LAN Only): el que necesitan los programas locales, como mi panel o el laminador por red.
• PINCODE (Ajustes → Dispositivo): para vincular la impresora en la app oficial.

Y cuidado: el código de acceso se regenera al desactivar y volver a activar LAN Only. Si un día tu programa deja de conectar con un error de registro, lo primero es mirar si ha cambiado.

La cámara que se colgaba

La impresora tiene cámara. Al principio mi panel la mostraba, y además tenía OctoEverywhere (un servicio para ver la impresora en remoto y detectar fallos con IA) usándola a la vez.

Resultado: la cámara se colgaba en cuestión de horas. El puerto del vídeo dejaba de responder y la única forma de recuperarla era reiniciar la impresora. El comando para relanzar la cámara decía «correcto» pero no hacía nada.

Después de dos caídas saqué la conclusión: el proceso de vídeo del firmware solo aguanta un cliente, y ni siquiera tolera bien que se abran y cierren conexiones seguidas (OctoEverywhere lo hace cada pocos segundos para su IA).

La configuración estable fue:

• Un solo programa usa la cámara (el laminador en el PC, cuando lo necesito).
• Mi panel y OctoEverywhere solo leen el estado por MQTT, sin tocar el vídeo.

Regla aprendida a base de caídas: con dispositivos baratos, un servicio, un cliente. No asumas que aguantan varias conexiones.

El comodín que robaba respuestas

Este fue el más curioso. Durante dos días, los costes de impresión que calcula mi panel aparecían y desaparecían sin ningún patrón. A veces bien, a veces vacíos.

La causa estaba en una línea:

f"elegoo/{sn}/+/api_response"          # MAL: recibe respuestas ajenas
f"elegoo/{sn}/{client_id}/api_response"  # BIEN: solo las mías

En MQTT, el + es un comodín: «cualquier cosa en esta posición». Mi panel se había suscrito a las respuestas de todos los clientes conectados a la impresora, incluido OctoEverywhere. Cuando llegaba una respuesta a una pregunta de otro programa, mi panel la tomaba como suya y machacaba sus datos.

Suscribiéndose solo a su propio client_id, los datos fantasma desaparecieron.

La IP que cambió

Un día el panel dejó de tener datos. La impresora seguía imprimiendo tan feliz. Lo que había pasado: el router le había dado otra IP por DHCP, y el panel la seguía buscando en la antigua.

Para encontrarla, escaneé la red buscando quién tenía el puerto 1883 abierto, y confirmé que era ella con la función de descubrimiento del propio protocolo. La solución definitiva es una reserva DHCP en el router para que siempre tenga la misma.

Lo que me llevo

1. Si un fabricante no documenta el protocolo, prepara tu programa para fallar con elegancia: modo solo lectura, modo depuración para ver el tráfico crudo…
2. En MQTT, suscríbete a lo mínimo. Los comodines son cómodos, pero traen mensajes que no son tuyos.
3. Un recurso frágil, un solo cliente.
4. IP fija para cualquier aparato al que se conecten tus programas.