HashCore Pulse 1.0.0-alpha3: the platform learns to act on its own

Automation: rules instead of calendar reminders

Previously, routine operations — a nightly fleet restart, pool switching on schedule — depended on a person being in the right place at the right time. Missed the moment, forgot, was busy with another incident — the operation didn't happen. The new Automation section removes this dependency entirely.

Scheduled rules are the simple part: you choose the scope (specific models, the whole site, a scan task), set a time and action — and Pulse executes it automatically, once or on a recurring basis.

More interesting are conditional rules. Here the value is not time savings but reaction speed. Pulse watches device state in real time and responds to deviations: status goes to Error, temperature exceeds a threshold, hashrate efficiency drops, fans hit their limit. A condition must persist for a set duration before triggering (to avoid reacting to brief spikes), and a per-device cooldown controls how often the action can repeat.

The difference between "restart a hung miner an hour later when the operator finally notices during rounds" and "restart at the moment the problem occurs" is the difference between lost and saved hashrate. On a large farm, that's hundreds of kilowatt-hours per month.

Conditional automation rule builder with trigger and cooldown period settings

Performance presets: managing a fleet, not individual devices

Manually configuring overclocking on each device doesn't scale when you have ten thousand machines instead of ten. The new Performance config group operation solves this in three ways:

• Exact — need a specific preset for a specific model? Set it once, applied to the entire selection of that model.
• Gradient — managing a mixed fleet and want to normalize it to a common load level (from Eco to Max) without dealing with each model separately.
• Relative — reacting to a situation and just want to shift current settings a few steps up or down, without thinking about which preset is currently active.

The firmware auto-switcher is configured in the same dialog — no need to go into each device's settings separately.

The operation supports filter conditions. In alpha2 these were Status and Temperature; in alpha3 Hashrate Efficiency (ratio of actual hashrate to the ideal for the current preset) and Power (actual wall consumption) were added. The practical value: you can apply a more aggressive preset only to devices whose efficiency has already fallen below 90%, leaving healthy devices untouched — a targeted action instead of a blanket one.

The same condition block in alpha3 was also added to Thermal config group operations — reused logic, not reinvented.

Bulk performance configuration dialog with conditional device filtering

Service Mode: precise tracking during bulk operations

When a group of devices is sent for maintenance (for example, an entire rack), each now gets its own independent session with its own ID, even if a single reason is specified for the whole group. The repair history of each specific device stays accurate and separable from its neighbors — critical for operators who track maintenance per unit, especially in a hosting model where that history is shown to clients.

Mixed-selection handling was also fixed: if some selected devices are already in service mode and others are not, the operation now handles each group correctly instead of throwing an error or skipping the whole operation.

Less repetitive work in the interface

Filter Presets — if you open the same set of filters every day ("workers of this model with errors," "non-standard firmware on the site"), you had to rebuild that combination from scratch on every login. Now it saves as a named preset and can be recalled in one click. Presets are shared within a site — set it up once, available to the whole team.

Data export — the device list exports to CSV or XLSX directly from the interface, with column selection and ordering, generated server-side regardless of table pagination. This closes a workflow that was previously done manually and opens something that didn't exist before: sending hosting client data in a clean tabular format. Exporting device list in CSV or XLSX format with column customization

Serial numbers in Custom mode and in export — two types of data at once: the control board serial number and the serial numbers of each hash board (Board 1/2/3 S/N). Previously this data was only visible one device at a time. Now it can be shown as columns across the entire fleet — which directly solves a painful scenario: cross-referencing serial numbers for a warranty claim against a supplier, without opening each device's card individually. Hash board serial numbers display in the device table and quick loading of saved filter presets

Bulk note management — assign or clear a note on multiple selected devices in one operation instead of opening each device separately. Small in effort, but exactly these small things accumulate into meaningful daily overhead on a fleet of thousands.

DevFee: transparency where guesswork used to be required

A fourth pool card — DevFee — now appears in the device card. A portion of any device's hashrate goes to the firmware developer fee — this is normal and required for operation, but it was previously invisible in the interface. Users would periodically write to support asking "where did part of my power go" or "why doesn't the statistics add up."

Now the stats for this system pool are visible separately, using the same familiar visual language as the working pools — the question is answered with a glance at the card, not a support ticket.

Separate DevFee system pool card in device details

WhatsMiner: from observation to full control

MicroBT devices were visible in Pulse from the start — monitoring worked. But direct control wasn't possible: you had to open the web interface of each miner separately, losing the whole point of a centralized platform.

Now the basic operations — Pause, Resume, Reboot, password change, pool switching — work for WhatsMiner via the vendor's native API, the same way they work for HashCore Firmware and Bitmain. For operators with a mixed fleet (which is most of the market), this eliminates the awkward reality where part of the equipment is managed from a single interface and part requires a separate login.

Summary

Both releases share one logic: remove from the operator's workflow what can and should happen automatically or in bulk, without sacrificing control or tracking accuracy. Every action remains visible in the Activity Center with a full history, and data for each device — including maintenance records and serial numbers — stays accurate even during bulk operations.

Pulse is in alpha — we're building the platform together with those who work on it. Currently in development: pool presets, device grouping, a technical issue tracker, roles and access rights, reports, email and Telegram alerts, and embedding the agent directly into HashCore firmware.

Join, test features on your farm, and send feedback — it directly shapes what goes into the next release.

Register: https://hashcore.com/pulse