Último Lançamento

Anteriormente, as operações rotineiras — reinício noturno do parque, troca de Pools programada — dependiam de uma pessoa que precisava estar presente no momento certo. Perdeu a hora, esqueceu, estava ocupado com outro incidente — a operação não era realizada. A nova seção Automation elimina completamente essa dependência.

Regras Programadas — a parte simples: você escolhe a área de aplicação (modelos específicos, o local inteiro, uma Scan Task), o tempo, a ação — e o Pulse executa isso sozinho, uma única vez ou regularmente.

Mais interessante — regras condicionais. Aqui, o valor não está na economia de tempo, mas na velocidade de reação. O Pulse monitora o estado dos dispositivos em tempo real e reage a desvios: o status mudou para Error, a temperatura excedeu o limite, a eficiência do Hashrate caiu, os ventiladores estão operando no limite. A condição é mantida por um tempo definido antes de ser acionada (para não reagir a um pico de curta duração), e entre acionamentos repetidos, há um Cooldown — separadamente para cada dispositivo.

A diferença entre "reiniciar um minerador travado em uma hora, quando o operador finalmente notar durante a ronda" e "reiniciar no momento em que o problema ocorre" — é a diferença entre Hashrate perdido e Hashrate salvo. Em um grande parque, a contagem chega a centenas de quilowatts-hora por mês.

Construtor de regras condicionais de automação com configuração de gatilhos e período de Cooldown

Configurar Overclocking manualmente em cada dispositivo não é escalável se você tem dez mil máquinas em vez de dez. A nova operação em grupo Performance config resolve isso de três maneiras:

• Exact — precisa de um Preset específico para um modelo específico? Você o define uma vez, e ele é aplicado a toda a seleção desse modelo.
• Gradient — você gerencia uma frota heterogênea e quer nivelá-la por um nível geral de carga (de Eco a Max), sem ter que lidar com cada modelo separadamente.
• Relative — você reage à situação e quer simplesmente mover as configurações atuais alguns passos para cima ou para baixo, sem se preocupar com qual Preset está ativo no momento.

O auto-switcher de Firmware é configurado diretamente no mesmo diálogo — não é necessário acessar as configurações de cada dispositivo separadamente.

A operação suporta condições de seleção. No alpha2, eram Status e Temperature; no alpha3, foram adicionados Hashrate Efficiency (relação entre o Hashrate real e o ideal para o Preset atual) e Power (consumo real da tomada). O sentido prático: é possível aplicar um Preset mais agressivo apenas aos dispositivos cuja eficiência já caiu abaixo de 90%, e deixar os que estão funcionando corretamente como estão — uma ação pontual em vez de em bloco.

O mesmo bloco de condições no alpha3 também foi conectado à configuração de resfriamento em grupo (Thermal config) — não é uma lógica recém-inventada, mas sim reutilizada.

Diálogo de configuração de desempenho em grupo com a possibilidade de seleção condicional de dispositivos

Quando um grupo de dispositivos é enviado para manutenção (por exemplo, um rack inteiro), cada um deles agora recebe uma sessão independente própria com seu identificador, mesmo que a razão seja a mesma para todo o grupo. O histórico de reparos de cada dispositivo específico permanece preciso e separável do histórico dos vizinhos — crítico para operadores que mantêm registros de manutenção por unidade, especialmente em um modelo de hosting.

Ao mesmo tempo, o tratamento de seleções mistas foi corrigido: se parte dos dispositivos selecionados já está em manutenção e parte não, a operação processa cada grupo corretamente, em vez de gerar um erro ou pular a operação inteira.

Filter Presets — se você abre o mesmo conjunto de filtros todos os dias ("Workers deste modelo com erros", "Firmware não padrão no local"), antes essa combinação precisava ser recriada a cada acesso. Agora ela é salva em um Preset nomeado e pode ser chamada com um clique. Os Presets são comuns dentro do local — configurado uma vez, disponível para toda a equipe.

Exportação de dados — a lista de dispositivos é exportada para CSV ou XLSX diretamente da interface, com a seleção das colunas desejadas e sua ordem, sendo gerada no servidor independentemente da paginação na tabela. Isso elimina a rotina que antes era realizada manualmente e abre algo que antes não existia: a transferência de dados para o cliente de hosting em um formato de tabela compreensível.

Exportação da lista de dispositivos em formato CSV ou XLSX com configuração das colunas a serem exportadas

Números de série no modo Custom mode e na exportação — dois tipos de dados de uma vez: o número de série da Control Board e os números de série de cada Hashboard (Board 1/2/3 S/N). Anteriormente, esses dados eram visíveis apenas para um dispositivo por vez. Agora eles podem ser exibidos em colunas para todo o parque de uma vez — isso resolve diretamente um cenário problemático: a verificação de números de série para uma reclamação de garantia ao fornecedor de um lote de equipamentos, sem a necessidade de abrir o cartão de cada dispositivo separadamente.

Exibição dos números de série das Hashboards na tabela de dispositivos e carregamento rápido de Filter Presets

Gerenciamento de notas em grupo — atribuir ou limpar uma nota para vários dispositivos selecionados em uma única operação. Um detalhe pequeno em termos de volume de trabalho, mas são esses pequenos detalhes que se acumulam em uma rotina significativa em um parque de milhares de máquinas.

No cartão do dispositivo, apareceu um quarto cartão de Pool — DevFee. Parte do Hashrate de qualquer dispositivo é destinada à comissão do Firmware — isso é normal e obrigatório para o funcionamento, mas antes não era visível na interface. Os usuários periodicamente escreviam para o suporte com a pergunta "para onde foi parte da minha potência" ou "por que as estatísticas não batem".

Agora, as estatísticas deste Pool de sistema são visíveis separadamente, com a mesma linguagem visual familiar dos Pools de trabalho — a questão é resolvida com um olhar para o cartão, e não com um ticket para o suporte.

Cartão separado do Pool de sistema DevFee nos detalhes do dispositivo

Os dispositivos MicroBT eram visíveis no Pulse desde o início — o monitoramento funcionava. Mas não era possível gerenciá-los diretamente: era preciso abrir a interface web de cada minerador separadamente, perdendo a própria essência de uma plataforma centralizada.

Agora, as operações básicas — Pause, Resume, Reboot, troca de senha, troca de Pools — funcionam para WhatsMiner através da API nativa do fornecedor, exatamente como para HashCore Firmware e Bitmain. Para operadores com um parque misto (e a maioria no mercado é assim), isso elimina a realidade inconveniente onde parte do equipamento é gerenciada a partir de uma única interface, e parte requer acesso separado.

Ambos os lançamentos são unidos por uma lógica: remover do trabalho do operador o que pode e deve ser feito automaticamente ou em massa, sem sacrificar o controle e a precisão do registro. Cada ação permanece visível no Activity Center com histórico completo, e os dados de cada dispositivo — incluindo manutenção e números de série — permanecem precisos mesmo durante operações em massa.

Pulse está em status alpha — estamos construindo a plataforma junto com aqueles que a utilizam. Já em desenvolvimento: Presets de Pools, agrupamento de dispositivos, rastreador de problemas técnicos, funções e direitos de acesso, relatórios, notificações por e-mail e Telegram, bem como a integração do agente diretamente no Firmware HashCore.

Conecte-se, teste as funções em sua fazenda e envie feedback — ele influencia diretamente o que será incluído no próximo lançamento.

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