Triggers are smart automated actions that you can set up through the minerstat dashboard. In case of a selected event happening, a desired command will be fired. Triggers are a really customized way to solve different issues. Some are checked every minute, while others depend on the historical charts and not all triggers have all possible actions available.
In this post, we have collected 8 triggers that anyone can find useful as they save you from unpredictable and sometimes unsolvable events.
1. Share count trigger
Share count trigger will get fired if the number of shares is the same for the selected period. While you might think this doesn’t happen often, our tests rigs showed us that this is a must-have trigger. If the number of shares is the same for 20, 30 minutes, this means that you didn’t send any valid share to the pool for that time. This is the same as if you wouldn’t be mining for 20, 30 minutes.
The minimum amount of time you can select is 20 minutes. This is because the trigger checks historical charts and not real-time data.
A simple mining restart should solve this problem for you.
2. Efficiency drop trigger
Efficiency drop trigger will get fired when efficiency drops below a selected level. Efficiency is the ratio between accepted and total shares. For example, if you have 30 accepted and 70 rejected shares, the efficiency is 30/(30+70) = 30%.
This trigger is useful for ASIC machines, which can with time lose efficiency and start producing too many rejected shares. If that is the case, a reboot will solve the issue. On the other hand, if your GPU is losing efficiency, you might need to use other actions.
3. Rejected shares trigger
Rejected shares trigger will get fired when the number of rejected shares is equal to or more than a selected number. This trigger can help you escape getting too many rejected shares after a while of mining. If you, for example, have 100,000 accepted shares and start getting rejected shares, even 100 rejected shares won’t drop your efficiency (only for 0.1%), so the efficiency drop trigger wouldn’t be suitable for such a situation.
Select the number of rejected shares based on the number of shares you generate in some period. For example, if you would like to reset mining client after 20 minutes of getting rejected shares and you produce 10 shares per 10 minutes, you can set 20.
4. GPU count
GPU count trigger will get fired if any of the GPUs is missing on your worker. You set up the amount of GPUs that you have in your rig in the worker’s config, then if the system detects fewer GPUs than this number, it will fire an event. Usually, a power cycle works well with this type of trigger if your motherboard supports this function.
5. Consumption trigger
A consumption trigger can be used in two ways: to check if consumption decreased (dropped) for a certain percentage or if it increased for a certain percentage.
The first situation can happen if some of the GPUs aren’t properly detected anymore or if drivers crashed because of too intense overclocking (which can happen even if you were mining fine for weeks). The second situation can happen if overclocking values are for some reason not detected anymore or if drivers refuse to run it. It is still best to adjust your overclocking values in such a case, but if a reboot solves this for you temporarily, a trigger can save you.
Make sure to calculate percentage correctly - 5% on a single GPU machine can be too small of a difference, while it can present a drop on one GPU for a rig with 10 GPUs.
Power increase
You can calculate the increase in power consumption with the formula YOUR_REGULAR_CONSUMPTION*(100 + SELECTED_PERCENTAGE)/100.
For example, let’s say that your rig's regular consumption is 900 W. Then you use the formula 900*(100 + 5)/100 = 945. It means 945 is a 5% increase of 900 and the trigger will get fired if power consumption increases to 945 or more.
Another example, let’s say that your rig’s regular consumption is 120 W. Then you use the formula 120*(100 + 5)/100 = 126. It means 126 is a 5% increase of 120 and the trigger will get fired if power consumption increases to 126 or more.
Power drop
You can calculate the increase in power consumption with the formula YOUR_REGULAR_CONSUMPTION*(100 - SELECTED_PERCENTAGE)/100.
For example, let’s say that your rig’s regular consumption is 900 W and you set trigger “down by 10%”. Then you use the formula 900*(100 – 10)/100 = 810. It means 810 is a 10% drop from 900 and the trigger will get fired if power consumption drops to 810 or below.
Another example, let’s say that your rig’s regular consumption is 120 W and you set trigger “down by 10%”. Then you use the formula 120*(100–10)/100 = 108. It means 108 is a 10% drop from 120 and the trigger will get fired if power consumption drops to 108 or below.
6. Pool errors trigger
A pool errors trigger will be fired when the number of detected pool errors equals or is higher than a selected number. This can happen if the pool is having some issues or you have connection issues with the pool. In this case, you can fire a trigger that will switch to a different config template and mine on a different pool or the same pool with a different port.
7. Auth errors trigger
Similar to the pool error trigger, you can use the authorization error trigger, which gets fired if your pool rejected your login info. This isn’t that common to happen in the middle of the mining, but it is still good to have it in case it happens when you least expect it.
8. Inactive trigger
An inactive state is a state where your worker is online and trying to mine, but mining with 0 H/s. It is again common with ASIC machines, but can also happen with GPUs (in case your internal mining client watchdog is turned off). If a restart of the mining client or reboot solves your rig after being inactive, this will save you some time.
Join minerstat
Want to take your mining monitoring and management to the next level? Join minerstat and start for free.
