PrintStash v0.9.0: cinco proveedores de impresora

La v0.9.0 de PrintStash amplió el soporte de impresoras de Moonraker y Bambu por LAN a cinco tipos de proveedor. Añadió conexiones en beta para OctoPrint, PrusaLink y Elegoo Centauri, además de una configuración guiada de Moonraker para las impresoras Elegoo Neptune 4.

La versión también puso el comportamiento de cada proveedor detrás de una matriz de capacidades común. Los botones y los diagnósticos de la API podían así reflejar lo que una impresora configurada admite de verdad.

OctoPrint y PrusaLink

El proveedor en beta de OctoPrint conectaba con una instancia local de OctoPrint u OctoPi mediante una API key. Admitía estado en vivo, subida de G-code y arranque explícito, inventario y borrado de archivos remotos, y controles de pausa, reanudación y cancelación.

El proveedor en beta de PrusaLink cubría impresoras FDM locales sin pasar por Prusa Connect. Las instalaciones actuales usaban autenticación Digest con usuario y contraseña, mientras que las versiones antiguas podían usar una API key. Su conjunto inicial de capacidades coincidía con el de OctoPrint.

Ninguno de los dos proveedores devolvía a PrintStash el consumo medido de filamento. La matriz de compatibilidad mantiene explícito ese límite y los demás de cada proveedor.

Impresoras Elegoo

Las Elegoo Neptune 4, Pro, Plus y Max recibieron un preajuste guiado respaldado por el proveedor estable de Moonraker. Conservaron el flujo habitual de Moonraker para archivos, control y trabajos medidos.

El proveedor en beta de Elegoo Centauri usaba SDCP local sobre WebSocket para la Carbon original y una conexión MQTT local protegida con código de acceso para la Carbon 2. Las dos informaban del estado y podían arrancar un archivo que ya estuviera en la impresora, pausar, reanudar o cancelar.

La subida y el inventario remoto de archivos siguieron desactivados en las Centauri porque el firmware no exponía una API de archivos confirmada apta para esas operaciones.

Subida por LAN en Bambu y arranque opcional

Bambu por LAN ganó la subida de G-code en texto plano a la caché local de la impresora mediante FTPS implícito. Un comando MQTT local aparte podía arrancar el trabajo subido.

Solo subir siguió siendo el comportamiento por defecto. Había que marcar Start print immediately para un arranque automático. PrintStash comprobaba que la impresora informara de estar inactiva o lista antes de crear el trabajo de transferencia, para no dejar un registro de subida atascado con una impresora ocupada o inalcanzable.

El inventario y el borrado remotos en Bambu siguieron sin estar disponibles.

Las capacidades gobiernan la interfaz

Cada proveedor declaraba si admite estado, subida, arranque, controles de trabajo, inventario remoto, G-code en bruto, y filamento medido. El frontend derivaba de esos valores qué controles había disponibles y explicaba las acciones no admitidas.

Una batería de conformidad compartida comprobaba el registro, las credenciales obligatorias, el rechazo de operaciones no admitidas antes de tocar la red, y el tratamiento común de errores. Eso redujo las ramas específicas de cada proveedor en el frontend y en la API.

Los envíos a proveedores mezclados siguieron siendo posibles. Las impresoras que solo admiten subida seguían siendo seleccionables, y Send & Print dejaba de estar disponible cuando alguno de los proveedores elegidos no podía arrancar el archivo subido.

Fiabilidad y rendimiento

• Los reintentos de conexión y de suscripción usaban una espera exponencial acotada.
• Un proveedor recuperado limpiaba su estado obsoleto de desconectado o de error tras una actualización correcta.
• Los fallos de conexión de Bambu llegaban al hub común de impresoras en lugar de dejar un estado falso de conectado.
• Los envíos duplicados del formulario de añadir impresora se ignoraban.
• Las escrituras de progreso en vivo sin cambios se agrupaban en intervalos de cinco segundos.
• Tres fallos consecutivos de base de datos al sincronizar trabajos abrían un cortacircuitos por impresora con retardos de reintento crecientes.
• Los cambios de tema dejaron de aplicar transiciones a todos los elementos y pseudoelementos.
• Las páginas de impresora, estadísticas, perfiles, ajustes y organización compartieron un mismo ancho y contenedor de scroll.

Node.js 24 pasó a ser la versión fijada para el frontend y para las compilaciones de release.

Actualiza con:

docker compose pull
docker compose up -d

El diff de v0.8.5 a v0.9.0 contiene todos los cambios de interfaz y de implementación.