One of the two is wrong. Right now, like this one, you do not look at just one card, you look at all of them. Then a card, the hottest one that should be sent, is activated at 90% fan at 80 degrees, but now it turns out that another card of the same rig reaches 75 degrees and I lower the fans to 70% .. Is it more important to reduce 75 degrees or reduce 80 degrees?

Therefore the concept of temperature for a rig, should take into account only 1 card, the hottest. Because the change of speed is applied to ALL THE RIG. If the speed of the fans was independent by card, his vision would be accurate, but as it is not so, it is wrong.

I suppose I could use Atherburner only for the fans, its solution to put rules that jump at different temperatures is not valid. It can not be that I have a card at 84 degrees that would correspond to 100% of FAN, and suddenly because another card of the rig reaches 75 degrees, I lower all the rig to 75% of Fan. Obviously the card that is in 84 degrees will rise and to 86 I turn the miner to avoid problems of breakage by temperature.

Here there are only 3 solutions:

1- that the rules affect each card independently, it would be very good.

2 - Always take the value of the hottest card, this would be the optimal point, that always in the rules send the FAN the card with the highest temperature. This would be the best solution and faster in programming.

3.- re-use Aftherbuner at the same time as the native, only to control the fans.

You understand that as it is now, even with rules, if I have not activated the heat protection rule, I could have damaged cards. I like your native OC a lot, but the temperature should send the card with more heat, whatever it is inside the rig, and just follow that. If suddenly another card in the same rig exceeds the previous one in temperature, then that new card is the one that would take control of the entire RIG. TAl as it is now, yesterday I skipped the rigs every few minutes and they stopped. I could not give credit to my eyes, to see cards at 84 degrees to 100% and suddenly went down to 65% because another card had reached the goal of a rule and applied to the whole rig, that does not matter as you explain it But it's not good.

You give a greater control of fan as aftherburner or you guide by the card of more temperature of the rig, because if not, cards of those people who do not have rules of stopping the miner can be broken if it reaches 86 degrees as I have.

This kind of situations did not happen with the complete solution of aftherburner, although the connection with the main program is very bad, so I will use the native and I will see that I think so, use a fan speed curve in aftherburner, but this is already ahead of time It will be a problem for many as soon as the heat arrives.

Have you identified if it's a specific GPU property (like Core Clock, Fan speed, ...) that cause the failures? The Remote Agent log file (can be accessed via the toolbar Tools -> Log File -> Remote Agent) might give further details.

Thanks for the suggestion. Maybe it should be indicated on the actual coin in the Coins tab as well, for example using red text to indicate update failures.

Awesome Miner version 6.3.3

 Features
  - New trigger for device hashrate
  - Bulk edit of External Miner properties: SSH port and SSH credentials
  - Bulk edit of Managed Miner properties: Autostart miner
 Integration
  - Add additional block explorers for wallet balance
  - Add additional pools for Mining Dutch
 User interface
  - Menu of available rule triggers rearranged into groups to make it easier to find triggers
 Version notes
  - Improved logging for the Dynamic Update feature of coin properties
 Mining softare
  - SrbMiner 1.8.5
  - TeamRedMiner 0.4.4
  - lolMiner 0.8.1
  - WildRig Miner 0.15.5
 Corrections
  - Correction to the Change Pool Group operation to ensure correct pool priority for ASIC miners
  - Correction to the password parameter name for the Phoenix Miner pool configuration file

When I open https://explorer.ravencoin.world/api/getdifficulty in a web browser I do see the Cloud Flare protection page the first time I launch it. It basically indicates that they only allows web browser that can solve a Javascript challenge are allowed to move on to the actual page. Cloud Flare protected sites cannot be accessed as an API from applications like Awesome Miner that only load data without being a complete web browser.

There might be some solution to this, but not an easy one that I get in place right away.

First a general answer. The formula for calculating coins per day using Difficulty-Reward-ExpFactor works for almost all coins and the formula using NetHash works for many coins as well. There will however always be coins with some unique properties where either one or none of these formulas can predict the number of coins per day. That's not an indication that the formulas are wrong, just that they may not be usable in a few cases.

Coins based on CuckaRoo29 / CuckaToo31 / CuckooCycle coins are examples where you never will get any correct values out of the formulas.

I just wanted to highlight this in general as I assume you will play around with quite a number of coins to do these calculations, and eventually you will find coins where they do something unique and the numbers will look strange.

In this case I entered the sources of information as you did, and from what I can see the Difficulty and NetHash forumula gives almost the same result. It was only 1 - 2 percent difference between them. However, in my case I used Block Time 60 seconds (1 minute) as this is what both CoinCalculators.io and CoinToMine reports. If you entered Block Time 150 seconds, it probably explain the difference you got.

Thank you friend.

But sites where in the title are three words
I have more.

Hello, Patricke.

I noticed that when creating an API request for determining complexity, etc., the response does not recognize the name of the site of three words.

For example, https://explorer.ravencoin.world/api/getdifficulty.

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.

1st / Select any miner and you go down where the GPUs that compose it are.
2nd / Select GPU clocking
3º / In this box, select any card and put the value you want in the FAN
4th / Profile-> Save as->
5 /  and select only the FAN

You can do it for any value, the FAN, core, memory, etc ... It is very useful for partial configurations in the clocking profile 

En español para evitar el traductor.

1º/ Selecciona cualquier minero y te vas abajo donde están las GPU's que lo componen.
2º/ Selecciona alli GPU clocking
3º/ En este cuadro, selecciona cualquier tarjeta y pon el valor que quieras en el FAN
4º/ Profile->Save as->
5º/ y selecciona solo el FAN

Puedes hacerlo para cualquier valor, el FAN, core, memory, etc... Es muy util para configuraciones parciales en el clocking profile 
 

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?

Tienes que entrar enGPU Clocking->Cambiar el FAN de cualquiera-> Y cuando grabes el profile, marcar solo el FAN. Así ya tienes el profile 80% FAN

if I understand your question correct, then you can click the "define coin" button on Pool tab while mining on Zerg to override the profitability source for it, afaik.