Updates & Feature Releases 🚀
Max Reboot Limiting in Triggers
You can now limit the number of reboots a miner can undergo, helping prevent reboot loops and unnecessary wear and tear on your miners.
- Reboots will be occur every 20 minutes until maximum attempts are reached. (ex., if max reboots are defined as 3, then Foreman will attempt to reboot the miner 3 times every 20 minutes, so 60 minutes total)
- When a miner exceeds the reboot threshold (ex., 3 reboots), it can automatically be tagged for visibility.
- Users can now create trigger workflows to take action on miners that have the tag for max reboots reached
- Users can also update triggers to exclude miners that have been tagged by the tag created above.
Per-Miner Ticketing in Triggers
Triggers can now create a separate ticket for each miner, instead of grouping all affected miners into a single ticket.
- This is available as an option, so existing single-ticket behavior is still supported.
- To prevent ticket flooding, if a trigger would generate more than 2,000 tickets, the system automatically falls back to creating a single consolidated ticket.
Infrastructure-Initiated Setpoint Dispatches
Our latest feature introduces the ability to initiate single- or multi-step setpoint dispatches directly from infrastructure conditions, for any Modbus-compatible device.
- Example use cases:
- Behind the Meter site that operates off flare gas and uses PSI as the driving data point for mine operation, as the PSI drops, you can define what setpoint your site should automatically drop to in response.
- A site that has a Modbus meter to monitor site load can now use this data set a peak for their site to stay under. For example, if you are a site that wants to operate at 10 MW of consumption and you have 9 MW of miners and 1 MW of other usage on site, you could set your Infrastructure-Initiated Dispatch to have a max value of 8.5 MW and begin to curtail miners if you hit this threshold in order to stay below your 10 MW.
- Debounce control: You can configure how many consecutive telemetry windows must meet or fall below a threshold before a setpoint change is triggered — helping avoid false triggers from momentary fluctuations. Typical windows are ~1 minute, within consecutive windows before a change is made.
- Read more about it here in this article.
Comments
0 comments
Please sign in to leave a comment.