Can you please describe this request/question in a bit more detail? I understand that you are about to add your new Antminers, but what are the configuration or operation you want to do here?

You can cancel the subscription to not get any future charges. You can still use Cloud Services for the period of time you paid for but there are no refunds.

I would however suggest to consider finding or waiting for a solution to the SSH restrictions in the recent Antminer firmware. There are quite a number of users in the community that all find the recent Antminer SSH restrictions a problem and are looking for solutions. Although there may not be any perfect solutions today, it might very well be available in the near future.

If you already upgraded your Antminer firmware to a version where SSH isn't enabled, it looks like these are the steps required to reset the firmware back to an older version:
https://support.bitmain.com/hc/en-us/articles/360019493654-S9-series-S9-S9i-S9j-S9-Hydro-Control-Board-Program-Recovery

I will include lolMiner 0.8.1 in the next release. It looks like Grin31 mining requires this command line parameter:
--coin GRIN-AT31

Good point. Maybe save both date and mining software version?

Previously it was only the name of the coin that was highlighted in blue color if any property was changed for the coin. Now it's the modified value itself that is blue. Sorry if I misunderstood your request about this earlier, but I hope you find the new implementation useful.

Thanks for the feedback - I will go ahead and add more log entries to make it possible to track down any update failures.

Awesome Miner version 6.3.2

 ASIC mining
  - Support for Antminer B7
 Integration
  - SrbMiner pool configuration will set the property for Nicehash automatically
  - Added CryptoNight HeavyX to XmRig by default
 User interface
  - Highlight modified coin properties in blue color on the Coins tab
 Mining software
  - GrinPro 2.1
  - TT-miner 2.2.2
  - Nanominer 1.2.1
 Corrections
  - Correction to trigger for detecting miner state

It's basically that with the latest firmwares from Bitmain, the lack of SSH results in that their miners always run in Restricted API mode. That limits the control from any application that want to remote manage Antminers, not only Awesome Miner. Bitmain is basically limiting the features of the miners by doing this.

Although I'm trying to get Bitmain to implement a new way to enable Privileged API access, my main point above was that all users of Antminer products should give their feedback to Bitmain about privileged API access. Bitmain must understand that they have removed a feature making it very difficult to manage their miners, and hopefully there will be enough users providing them with this feedback.

It would of course be great if they re-enabled SSH access, but if that isn't an option, making it possible to enable Privileged API access via the Antminer web interface would be one way forward.

Thanks! You are correct that it would be quite easy so just highlight the overridden properties, so I will go ahead and make that modification.

Thanks for the update. I might have identified the scenario better now. You can expect a correction no later than tomorrow.

Thanks for the comments Ralf.
If the activation of the rule doesn't work from the Action-button, it sounds like it's the action that isn't working. The Triggers are never considered when using this button.

Do you see any log entry "Detected miner state" in the Awesome Miner log file (toolbar: Tools -> Log File)?

One way to see what values Awesome Miner reads for these properties is to look in the Awesome Miner log file for "Dynamic update of coin property". These lines will indicate the coin to be updated, the property to be updated and the new value. Can you for example see the large variations of NetHash here?

Awesome Miner version 6.3.1

 ASIC mining
  - Support for Antminer Z11
 Features
  - Configuration of Network Hashrate and Block Time per coin
  - Added an additional way to calculate coin revenue, based on Network Hashrate, Block Time and Block Reward. Calculation method configurable per coin.
  - New trigger Detect Miner State to detect specific mining states
 Mining softare
  - SrbMiner 1.8.3
  - NBMiner 22.3
  - Gminer 1.38
  - Nanominer 1.2
  - Bminer 15.5
 Corrections
  - Improved compatibility for change of frequency on Antminers
  - Corrected calculation of average hashrate for benchmarks
  - Handle invalid JSON responses from JCE miner

Thanks for the nice feedback.

The plan is to add support for setting GPU properties like fan speed directly via the rule actions. Today you can use Clocking Profiles via the actions as discussed earlier, but it will be easier once you can do it without the profiles.

Hi Ralf,
I've looked into this earlier based on your previous feedback and I have now created a new Trigger type for you ("Detect Miner State") where you can detect this specific state.
Please let me know your feedback once the next version is released. Thanks!

In addition, I know that a number of Awesome Miner users already contacted Bitmain about providing a solution where their miners can be managed (via the Privileged API concept). It should be in Bitmains interest to let their customers can manage their miners in a good way.

I would actually encourage users of Antminers to contact Bitmain on this topic to push for a solution. Even if Bitmain want to disable SSH for some reason, they should still add a setting in their web interface to allow the user to enable Privileged API access.

The formula itself is correct and gives the exact same results are WhatToMine and CoinCalculators in general. There can however be specific coins that do something differently where you manually need to adjust the profit factor as it's not possible to compute the number of coins per day the standard way.

Yes, the plan is to add support for the "NetHash" way of doing the calculations as well, where Block Time is one of the factors. The idea is also have this configurable per coin so if you run into a coin where the standard way of doing the calculations doesn't give the expected results, you should be able to switch to this other mode.

It should be the average but excluding a few samples in the beginning as those first samples are typically too low. However, I did notice an issue here with long running benchmarks so I will make a correction for that case. Thanks for finding it.

Update - coin properties:
I've just finished the implementation for Network Hashrate and Block Time in the Coin Properties, together with a setting where you can select one of the following calculation methods:
- Difficulty, Block Reward and Exponential factor
- Network Hashrate, Block Reward and Block Time

Your observation is correct, it looks like Bitmain start to lock down their ASIC miners more with the recent firmware upgrades.

With SSH access disabled, Awesome Miner cannot connect and reconfigure the API access. This is the reason for the "Connection failure".

Update:
I've previously had a short conversation with Bitmain regarding the disabled SSH on Antminer S15, but it has not yet resulted in any solution being provided. I've reached out to them again on this topic to ask for a way to enable Privileged API access. Even if the SSH access still will be disabled, I would like to see the API setting being configurable in the web interface for the Antminer as an alternative solution.

Awesome Miner Version 6.3

 ASIC mining
  - Updates to Antminer T15 support to include temperatures
 GPU mining
  - Benchmark improved to allow selection of multiple GPU's to use
  - Added additional algorithms
 Features
  - Define custom data sources for coin properties; Difficulty, Block Reward and Exchange rate. Use expressions to load values from any JSON data source or plain value source.
  - The Reboot button in the main toolbar will be available for External Miners as well, performing a reboot over SSH
  - Updates to the built-in web interface, including a new dark theme (configurable in the Options dialog, Web section)
  - Custom filter expressions configurable per User Group when accessing the local web interface
  - Added menu entry to the Log File menu to only return the most recent log entries
  - Added additional options for duration of benchmark
  - Improved accuracy of device selection for benchmark in systems with mixed GPU types
 Integration
  - Added additional exchanges to the coin exchange filter feature
  - Automatically setup Phoenix Miner pool parameters when using with Zergpool ProgPow
  - Adjustments to CuckaRoo29s calculations
  - Adjustments to new API for CoinCalculators.io
  - Updated Exponential Factor for ARRR coin
 API
  - Added notes to API for Managed Miners and External Miners
  - Added Profit Factor to API for pools (/api/pools)
 User interface
  - Coins with modified properties will be indicated with a blue color for the coin name on the Coins tab, even when running in Compact List mode
  - Updated coin images
  - Mining software list visual updates
  - Negative mining profit can be displayed even if the revenue is zero or unknown
  - Added additional coin images
  - Network scan IP address range saved
 Mining softare
  - Added mining software: Nanominer 1.1.1
  - Added mining software: Miniz 1.2m
  - Added mining software: RhMiner 1.5 for RandomHash
  - SrbMiner 1.8.2
  - WildRig Miner 0.15.4 preview 18
  - CryptoDredge 0.18.0
  - NBMiner 21.4
  - TeamRedMiner 0.4.3
  - Bminer 15.4
  - TT-Miner 2.2.1
  - PhoenixMiner 4.2c, including ProgPow support
  - Gminer 1.37
 Corrections
  - Correction to the path used by the built-in web interface
  - Correction to worker name display when mining with TT-miner
  - The combinaton of using CoinCalculators.io, non-default exchange rate mode and exchange filtering could result in incorrect exchange rate for BTC.
  - Correction to JCE GPU Miner selection of GPUs to use
  - Correction to Bminer command line for specific combinations of pool algorithms
  - Improved detection of mining software crashes and recovery for the Managed Profit Switcher

The solution available today to set fan speed to 85% for a miner via the rules:
- Use rule action "Apply clocking profile", where you have a Clocking Profile set to 85% fan speed for example. That's the only property of the clocking profile so all this action will do is to change the fan speed and nothing else. No matter if you have few or many Clocking Profiles in general, you need one extra profile for setting only the fan speed to 85% in this case.

This could be simplified into the following in the future:
- Use a new action concept to "Apply clocking setting" where you could select that you want the "Fan" property to be set to 85% for example. This would remove the need of the Clocking Profile containing the 85% fan speed property.

There are no difference in behavior between these two ways, it's just that the second one doesn't require you to create a Clocking Profile for each fan speed level you want to set. In both cases, it's only the fan speed that is changed an no other overclocking settings.