Latest Release

Previously, routine operations — nightly farm restarts, scheduled Pool changes — relied on a person being present at the right moment. Missed the time, forgot, was busy with another incident — the operation was not performed. The new Automation section completely removes this dependency.

Scheduled Rules — the simple part: you select the scope (specific models, entire site, scanning task), time, action — and Pulse performs it itself, once or regularly.

More interesting are Conditional Rules. Here, the value is not in saving time, but in reaction speed. Pulse monitors device status in real-time and reacts to deviations: status went into Error, temperature exceeded the threshold, Hashrate efficiency dropped, fans are running at their limit. The condition is held for a specified time before triggering (to avoid reacting to a brief spike), and a cooldown period applies between repeated triggers — separately for each device.

The difference between "restarting a frozen miner an hour later, when the operator finally notices it on a round" and "restarting it the moment the problem occurs" is the difference between lost and saved Hashrate. For a large farm, this amounts to hundreds of kilowatt-hours per month.

Conditional automation rule builder with trigger and cooldown period settings

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

• Exact — need a specific preset for a specific model? Set it once, and it applies to the entire selection of that model.
• Gradient — manage a heterogeneous fleet and want to align it to a general load level (from Eco to Max) without dealing with each model separately.
• Relative — react to a situation and simply want to shift current settings a few steps up or down, without considering which preset is currently active.

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

The operation supports selection conditions. In alpha2, these were Status and Temperature; in alpha3, Hashrate Efficiency (the ratio of actual Hashrate to the ideal for the current preset) and Power (actual wall consumption) were added. Practical meaning: a more aggressive preset can be applied only to devices whose efficiency has already dropped below 90%, while working ones are left as is — a targeted action instead of a block one.

The same condition block in alpha3 was also connected to group cooling settings (Thermal config) — not newly invented logic, but reused.

Group performance configuration dialog with conditional device selection capability

When a group of devices (e.g., an entire rack) is sent for maintenance, each of them now receives its own independent session with its identifier, even if the reason is specified as one for the entire group. The repair history of each specific device remains accurate and separable from its neighbors' history — critical for operators who track maintenance for each unit, especially in a hosting model.

At the same time, the handling of mixed selections has been corrected: if some selected devices are already in maintenance and some are not, the operation processes each group correctly instead of an error or skipping the entire operation.

Filter Presets — if you open the same set of filters every day ("workers of this model with errors," "non-standard firmware on the site"), previously you had to reassemble this combination each time. Now it's saved as a named preset and called with one click. Presets are shared within the site — set up once, available to the entire team.

Data Export — the device list is exported to CSV or XLSX directly from the interface, with selection of desired columns and their order, generated on the server regardless of table pagination. This eliminates routine tasks previously performed manually and enables something that wasn't possible before: providing data to a hosting client in a clear tabular format.

Exporting device list in CSV or XLSX format with configurable columns

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 visible only for one device at a time. Now they can be displayed as columns for the entire farm at once — this directly addresses a painful scenario: verifying serial numbers for a warranty claim to a supplier for a batch of equipment, without needing to open each device's card separately.

Display of Hash board serial numbers in the device table and quick loading of filter presets

Group Note Management — assign or clear a note for several selected devices at once with a single operation. A small detail in terms of work volume, but it's these small details that accumulate into a significant routine on a farm with thousands of machines.

A fourth Pool card has appeared in the device card — DevFee. A portion of any device's Hashrate goes to firmware fees — this is normal and necessary for operation, but previously it was not visible in the interface. Users periodically wrote to support asking "where did part of my power go" or "why don't the statistics match."

Now the statistics for this system Pool are visible separately, using the same familiar visual language as the working Pools — the question is answered by a glance at the card, not a support ticket.

Separate DevFee system Pool card in device details

MicroBT devices were visible in Pulse from the very beginning — monitoring worked. But direct management wasn't possible: it required opening the web interface of each miner separately, losing the very essence of a centralized platform.

Now basic operations — Pause, Resume, Reboot, password change, Pool change — work for WhatsMiner via the vendor's native API, just like for HashCore Firmware and Bitmain. For operators with mixed farms (and most on the market are such), this eliminates the inconvenient reality where some equipment is managed from a single interface, while others require separate access.

Both releases are united by a single logic: to remove from the operator's work what can and should be done automatically or in bulk, without sacrificing control and accounting accuracy. Every action remains visible in the Activity Center with a complete history, and data for each device — including maintenance and serial numbers — remains accurate even during mass operations.

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

Join us, test the features on your farm, and send us your feedback — it directly influences what will be included in the next release.

Registration: https://hashcore.com/ru/pulse