Último lanzamiento

Antes, las operaciones rutinarias —el reinicio nocturno de la flota, el cambio de Pools programado— dependían de una persona que debía estar presente en el momento adecuado. Si se perdía el momento, se olvidaba o se estaba ocupado con otro incidente, la operación no se realizaba. La nueva sección Automation elimina completamente esta dependencia.

Las Reglas programadas son la parte sencilla: se selecciona el ámbito de aplicación (modelos específicos, la ubicación completa, una Scan Task), la hora, la acción, y Pulse lo ejecuta por sí mismo, una sola vez o regularmente.

Más interesantes son las reglas condicionales. Aquí el valor no reside en el ahorro de tiempo, sino en la velocidad de reacción. Pulse monitorea el estado de los dispositivos en tiempo real y reacciona a las desviaciones: el Status pasó a Error, la temperatura superó el umbral, la eficiencia del Hashrate disminuyó, los ventiladores funcionan al límite. La condición se mantiene durante un tiempo determinado antes de activarse (para no reaccionar a un pico momentáneo), y entre activaciones repetidas, se aplica un Cooldown — por separado para cada dispositivo.

La diferencia entre «reiniciar un minero bloqueado en una hora, cuando el operador finalmente lo note en una ronda» y «reiniciar en el momento en que surge el problema» es la diferencia entre Hashrate perdido y guardado. En una flota grande, esto se traduce en cientos de kilovatios-hora al mes.

Constructor de reglas condicionales de automatización con configuración de disparadores y período de Cooldown

Configurar el Overclocking manualmente en cada dispositivo no es escalable si no tiene diez máquinas, sino diez mil. La nueva operación grupal Performance config lo resuelve de tres maneras:

• Exact — ¿Necesita un Preset específico para un modelo concreto? Lo configura una vez y se aplica a toda la selección de ese modelo.
• Gradient — Gestiona una flota heterogénea y desea nivelarla a un nivel de carga general (de Eco a Max), sin tener que ocuparse de cada modelo por separado.
• Relative — Reacciona a la situación y simplemente desea mover la configuración actual unos pasos hacia arriba o hacia abajo, sin preocuparse por qué Preset está configurado actualmente.

El auto-switcher de Firmware se configura directamente en el mismo diálogo, sin necesidad de acceder a la configuración de cada dispositivo por separado.

La operación admite condiciones de selección. En alpha2 eran Status y Temperature; en alpha3 se añadieron Hashrate Efficiency (relación entre el Hashrate real y el ideal para el Preset actual) y Power (consumo real de la toma de corriente). El sentido práctico es que se puede aplicar un Preset más agresivo solo a los dispositivos cuya eficiencia ya ha caído por debajo del 90%, y dejar los que funcionan correctamente como están — una acción puntual en lugar de una masiva.

El mismo bloque de condiciones en alpha3 también se conectó a la configuración de enfriamiento grupal (Thermal config) — no es una lógica reinventada, sino reutilizada.

Diálogo de configuración de rendimiento grupal con la opción de selección condicional de dispositivos

Cuando un grupo de dispositivos se envía a mantenimiento a la vez (por ejemplo, un rack completo), cada uno de ellos ahora recibe su propia sesión independiente con su propio identificador, incluso si la razón es la misma para todo el grupo. El historial de reparaciones de cada dispositivo individual sigue siendo preciso y separable del historial de los vecinos, lo cual es crítico para los operadores que llevan un registro de mantenimiento por cada unidad, especialmente en el modelo de hosting.

Al mismo tiempo, se ha corregido el manejo de selecciones mixtas: si una parte de los dispositivos seleccionados ya está en mantenimiento y otra parte no, la operación procesa cada grupo correctamente en lugar de generar un error o omitir toda la operación.

Filter Presets — si cada día abre el mismo conjunto de filtros («Workers de este modelo con errores», «Firmware no estándar en la ubicación»), antes tenía que volver a crear esta combinación cada vez que accedía. Ahora se guarda en un Preset nombrado y se invoca con un solo clic. Los Presets son compartidos dentro de la ubicación — se configuran una vez y están disponibles para todo el equipo.

Exportación de datos — la lista de dispositivos se exporta a CSV o XLSX directamente desde la interfaz, con la selección de las columnas necesarias y su orden, y se genera en el servidor independientemente de la paginación en la tabla. Esto elimina la rutina que antes se realizaba manualmente y abre una posibilidad que antes no existía en absoluto: la transferencia de datos al cliente de hosting en un formato tabular comprensible.

Exportación de la lista de dispositivos en formato CSV o XLSX con configuración de las columnas a exportar

Números de serie en modo Custom y en la exportación — dos tipos de datos a la vez: el número de serie de la Control Board y los números de serie de cada Hashboard (Board 1/2/3 S/N). Antes, estos datos solo eran visibles para un dispositivo a la vez. Ahora se pueden mostrar como columnas para toda la flota a la vez, lo que resuelve directamente un escenario problemático: la verificación de números de serie para una reclamación de garantía al proveedor por un lote de equipos, sin necesidad de abrir la ficha de cada dispositivo por separado.

Visualización de los números de serie de las Hashboards en la tabla de dispositivos y carga rápida de Filter Presets

Gestión de notas en grupo — asignar o borrar una nota a varios dispositivos seleccionados en una sola operación. Un detalle menor en cuanto a la carga de trabajo, pero son precisamente estos pequeños detalles los que se acumulan en una rutina considerable en una flota de miles de máquinas.

En la ficha del dispositivo apareció una cuarta tarjeta de Pool — DevFee. Parte del Hashrate de cualquier dispositivo se destina a la comisión del Firmware — esto es normal y obligatorio para el funcionamiento, pero antes no era visible en la interfaz. Los usuarios escribían periódicamente al soporte preguntando «dónde se fue parte de mi potencia» o «por qué las estadísticas no coinciden».

Ahora las estadísticas de este Pool del sistema son visibles por separado, con el mismo lenguaje visual familiar que los Pools de trabajo — la pregunta se resuelve con un vistazo a la tarjeta, y no con un ticket de soporte.

Tarjeta separada del Pool del sistema DevFee en los detalles del dispositivo

Los dispositivos MicroBT eran visibles en Pulse desde el principio — el monitoreo funcionaba. Pero no era posible gestionarlos directamente: había que abrir la interfaz web de cada minero por separado, perdiendo la esencia misma de una plataforma centralizada.

Ahora las operaciones básicas — Pause, Resume, Reboot, cambio de contraseña, cambio de Pools — funcionan para WhatsMiner a través de la API nativa del proveedor, exactamente igual que para HashCore Firmware y Bitmain. Para los operadores con una flota mixta (y la mayoría en el mercado lo son), esto elimina la incómoda realidad donde parte del equipo se gestiona desde una única interfaz, y otra parte requiere un acceso separado.

Ambos lanzamientos comparten una misma lógica: eliminar del trabajo del operador lo que se puede y debe hacer de forma automática o masiva, sin sacrificar el control y la precisión del registro. Cada acción permanece visible en el Activity Center con un historial completo, y los datos de cada dispositivo —incluido el mantenimiento y los números de serie— se mantienen precisos incluso durante las operaciones masivas.

Pulse está en estado alpha — estamos construyendo la plataforma junto con quienes la utilizan. Actualmente en desarrollo: Presets de Pools, agrupación de dispositivos, rastreador de problemas técnicos, roles y derechos de acceso, informes, notificaciones por email y en Telegram, así como la integración del agente directamente en el Firmware de HashCore.

Únase, pruebe las funciones en su granja y envíenos sus comentarios — estos influyen directamente en lo que se incluirá en el próximo lanzamiento.

Registro: https://hashcore.com/es/pulse