Aye... Thanks.
Errr... I don't think the variable change thing really solves the original problem. The problem was it would constantly trigger if conditions were met, not only once when they're first met.
So I have two different variables, and a rule that triggers turning miners off if one variable is true. Then I have another rule when both variables are false that turns things back on. However, if it's setup normally the miners will keep resetting (turning off) as long as one of the variables is true and with the 'detect change' wont be able to know the correct state that both need to be in to turn things back on.
Thanks for the feedback. If I understand correctly, your rules looks something like this today. Rule#1: If Var1=true or Var2=true -> Stop miners Rule#2: If Var1=false and Var2=false -> Start miners Do you think this concept could work? Rule#1: If Var1=true or Var2=true -> Set Var3=true Rule#2: If Var1=false and Var2=false -> Set Var3=false Rule#3: If Var3=true and Var3 has changed -> Stop miners Rule#4: If Var3=false and Var3 has changed -> Start miners This way the actions for Rule#3 and #4 should only run once. |
|
|
|
|
Awesome Miner version 9.9.3
ASIC mining
- Added support for Antminer D9
- Antminer L7 pause (sleep) and resume supported
Features
- New rule action to save current miner hashrate to Profit Profile
- Check variable trigger can be configured to detect variable changes
Integrations
- Added MagicPool.co mining pool
Changes
- The total number of temperature values in the miner list has been increased from 20 to 32
- No automatic cleanup of global variables
Mining software
- BzMiner 14.1
- CpuMiner-Opt 3.22.1
- Gminer 3.31
- Lolminer 1.72
- Miniz Miner 2.0c4
- Rigel 1.3.10
- SrbMiner-Multi 2.2.3
- XmRig 6.19.1
Corrections
- Correction for recent TeamBlackMiner API changes
- Correction to Rigel miner API processing for GPUs
|
|
|
|
Is there anyway to setup rules taking precedent over other rules, so if one is active or has been triggered, another that adjusts the same condition wont trigger?
This should be possible to solve using the variable concept. You have a trigger called "Check variable" and an action called "Set variable". The variable can either be set on a global scope or set per miner. You can design the first rule to set a variable to "1" when running. The second rule could check the variable value and only run if the value is "0". This way you can have one rule to change the behavior of when another rule should run. Looks like when I restart AM, some of the global variables disappear from tools > rules > variables? Do they automatically show up when rules get called that trigger them or if they aren't there will the program throw a error? Also how do you get something to trigger once on a variable state change? Seems they're set to constantly repeat. You can set time limit, but that's not applicable nor do I want triggers to run when the variable states don't change. Thanks When starting Awesome Miner, all global variables not referenced by any rule will be removed. The original idea was to avoid getting a large number of unused variables but there can be scenarios where this behavior isn't preferred. I will remove the automatic cleanup of global variables in the next release. If you would reference a variable that doesn't exist it will be considered to have a value of 0 if you read it and it will be created if you write to it. It's true that the "Check trigger" will run every 5 seconds if the condition is true. Can you combine with "Limit actions to run at most once every" or "Limit actions per day" depending on the behavior you want? Another possibility is to make use of a second variable that you set to "1" in the rule action and you check for it to not be "1" in the trigger condition. Isn't that just a loop or completely break the automation till it's manually reset? I saw the run X number of minutes, but when you have a interaction that's semi-random in nature, you can't set something like that up. I think 'on state change' instead of running in a loop would be possible and often times preferable depending on what you're looking for. I agree that there can be scenarios where a change detection is easiest. I think it will be quite fast to add to the existing Check Variable trigger so you can expect it in the near future. |
|
|
|
Hi patrike, I did some more tests. Teamredminer dual mining is not working like it should. Awesomeminer doesnīt add the part for the second coin, i must add the whole commandline by myself. Hashrates is shown correctly. The other thing is a little bit strange, but i will do some further tests. Kaspa+Zil is working as it should on 1 rig - AM show me the kaspa pool and hashrate, but on an other rig AM only show me the zil pool with the kaspa hashrate. Commandline is identical  Thanks for the feedback. For mining with TeamRedMiner, only a few algorithm combinations are enabled for dual based on the documentation for TRM. What are the algorithm combination you are trying here? Could you please send me the command line you use to manually launch TRM dual mining and I will try the same with Awesome Miner. You can send the command line to me via PM. Thanks! The other thing is a little bit strange, but i will do some further tests. Kaspa+Zil is working as it should on 1 rig - AM show me the kaspa pool and hashrate, but on an other rig AM only show me the zil pool with the kaspa hashrate. Commandline is identical Is this also for TeamRedMiner? |
|
|
|
Is there anyway to setup rules taking precedent over other rules, so if one is active or has been triggered, another that adjusts the same condition wont trigger?
This should be possible to solve using the variable concept. You have a trigger called "Check variable" and an action called "Set variable". The variable can either be set on a global scope or set per miner. You can design the first rule to set a variable to "1" when running. The second rule could check the variable value and only run if the value is "0". This way you can have one rule to change the behavior of when another rule should run. Looks like when I restart AM, some of the global variables disappear from tools > rules > variables? Do they automatically show up when rules get called that trigger them or if they aren't there will the program throw a error? Also how do you get something to trigger once on a variable state change? Seems they're set to constantly repeat. You can set time limit, but that's not applicable nor do I want triggers to run when the variable states don't change. Thanks 1)can I pay with cryptocurrency for the full version? 2)For residents of the Russian Federation, are there sanctions from awesome miner? I've responded to the message you sent via the contact form on our web site. |
|
|
|
Is there anyway to setup rules taking precedent over other rules, so if one is active or has been triggered, another that adjusts the same condition wont trigger?
This should be possible to solve using the variable concept. You have a trigger called "Check variable" and an action called "Set variable". The variable can either be set on a global scope or set per miner. You can design the first rule to set a variable to "1" when running. The second rule could check the variable value and only run if the value is "0". This way you can have one rule to change the behavior of when another rule should run. Looks like when I restart AM, some of the global variables disappear from tools > rules > variables? Do they automatically show up when rules get called that trigger them or if they aren't there will the program throw a error? Also how do you get something to trigger once on a variable state change? Seems they're set to constantly repeat. You can set time limit, but that's not applicable nor do I want triggers to run when the variable states don't change. Thanks When starting Awesome Miner, all global variables not referenced by any rule will be removed. The original idea was to avoid getting a large number of unused variables but there can be scenarios where this behavior isn't preferred. I will remove the automatic cleanup of global variables in the next release. If you would reference a variable that doesn't exist it will be considered to have a value of 0 if you read it and it will be created if you write to it. It's true that the "Check trigger" will run every 5 seconds if the condition is true. Can you combine with "Limit actions to run at most once every" or "Limit actions per day" depending on the behavior you want? Another possibility is to make use of a second variable that you set to "1" in the rule action and you check for it to not be "1" in the trigger condition. |
|
|
|
Is there anyway to setup rules taking precedent over other rules, so if one is active or has been triggered, another that adjusts the same condition wont trigger?
This should be possible to solve using the variable concept. You have a trigger called "Check variable" and an action called "Set variable". The variable can either be set on a global scope or set per miner. You can design the first rule to set a variable to "1" when running. The second rule could check the variable value and only run if the value is "0". This way you can have one rule to change the behavior of when another rule should run. |
|
|
|
Hi Patrike, big thanks for 9.2.2 update, this small add-on with variable for profit profile rule is great, i can realise a functionality for individual profit profile changing in batch. Another suggestion: Can you please improve a "Save hashrate" function to made it possible to save hashrate for all selected miners, where every miner saves his own hashrate/power values. Regards.
The plan is actually to expose the Save Hashrate feature as a rule action. This way you can either schedule it to automatically run on a regular basis or you can enable manual activation (in the Properties of the rule) to make it possible to manually execute for all selected miners. I will make sure this feature gets prioritized as there have been similar requests in the past. |
|
|
|
Hi Patrik, since we have so many Templates and Profiles and all the different coins needs different clocks, I have a suggestion to make our life a little bit easier without all the mess of different clocking profiles. In the "Managed Miner Properties" -> "GPU Clocking Profiles", it would be a great idea to add a pure clocking section (maybe like in the picture below as an example). This would save so many clocking profiles, which wouldn't be needed anymore and clocking could be done directly in the profile.  Thanks for all your hard work! Thanks for the suggestion. This could be one way forward. There is however an existing concept you can use to reduce the number of clocking profiles, at least as long as you only need a single configuration per Managed Miner. On the GPU clocking tab for a selected miner in the main window, you a button "Apply and save for miner". This will create a default profile for the miner that all clocking settings will be saved to. This way you don't have to create the profile manually unless you need multiple configurations. |
|
|
|
Hi Patrik, my answer to your post: https://bitcointalk.org/index.php?topic=676942.msg61876439#msg61876439Thanks for the update! The new AM version works much better with Rigel, but one more strange bug. 1a) If I don't change the "Device Order", mostly the last card, but sometimes also one or more cards between, shows wrong numbers or missing informations. - GPU -> Missing texts - Clock -> Wrong clocks and missing voltage - Fan -> Wrong speed - Temperature -> Missing hotspot - Progress & Performance is fine.  2a) If I manually set the "Device Order", everything is correct.  1b) Here another example without changed Device Order.  2b) And with changed Device Order, everything is correct.  Do you still need the API report or can you reproduce it without? Thanks for your hard work! EDIT: I would say this behavior is only visible running the miner with admin privileges. Without it seems fine. But I need them because of the OC settings build in the miner. EDIT 2: One more strange thing: If I have multiple instances of the Rigel miner running (in admin mode) and I try to stop one or more instances, all other miners randomly start and stopping all the time. I have to stop all, wait until all have stopped and than start them again. Please send me the API reports for the scenario where the GPUs are not displayed with the correct information. The scenarios without manually setting the Device Order is of interest here (so the icon should be the blue info-icon). The Rigel implementation is currently not working well when stopping one instance when you run multiple instances in admin mode. There will be one change to this in the next release. |
|
|
|
Nice!!!! I found something strange - if i mine kaspa + zil with teamredminer AM, show me the zil pool behind the miner name and not the kaspa pool, but the kaspa pool should be the first pool.  In pool tab it show me both.  Is it normal that i see the hashrate and average hashrate only for the first coin on the main tab. On GPU Tab i see the hashrate for both algos and the average for both - this is nice.EDIT: Ok in ETC+KAS i see both hashrates in the MainTab And a question about zil mining - will it be added for all miners? I mine kas+zil with teamredminer for example. gminer, trex, srbminer and miniz miner also have the ability for +zil. Next request is about GPU selection for Intel - i canīt select it.   Thanks overall for this update. Thanks for the observations and suggestions. I think I've managed to reproduce the TeamRedMiner dual pool display issue For the Intel GPU selection - which mining software are you using here? Do you see the Intel GPUs on the System tab for this miner? |
|
|
|
|
Awesome Miner version 9.9.2
GPU mining
- Dual mining with TeamRedMiner
Features
- Use variables for rule action to apply a Profit Profile to miners
- Include the date a miner was created in the miner list CSV export
Mining software
- BzMiner 13.3.0
- CpuMiner-Opt 3.21.2
- DynexSolve 2.2.5
- Lolminer 1.69
- Nanominer 3.7.7
- Rigel 1.3.8
Corrections
- Correction to context menu for groups in the Groups tab
- Correction to Antminer K7 default pool operation
- Correction to Rigel miner GPU list when only specific GPUs are selected for mining
|
|
|
|
Hi Patrik, just played around with the Rigel miner and it doesn't work well. My AM is the newest version 9.9.1, Rigel is the newest version 1.3.8. If I start Rigel in the first instance on a rig with multiple cards, AM only shows 1 card mining. The GPU tab also shows that 1 card only. - The hashrate is correct from all cards together. - The wattage is only the wattage of that 1 card. - The profit is correct from all cards together.  If I start Rigel in a second instance on that same rig, the status only shows "mining". No temps, no GPUs in the GPU tab. - Hashrate is correct. - No wattage. - Profit is correct.  Right now its only possible to run 1 instance of the Rigel miner per rig, but it only shows 1 card. So every rule with the expected number of mining devices wont work correctly. If I connect multiple instances, AM gets in trouble or the Rigel API is broken, or whatever... Can you please check that? Thanks! Thanks for the report. I was only able to reproduce and correct one of the issues here. In case you select specific GPUs to be used for mining, Rigel will still report the GPU in the API and Awesome Miner didn't react to this correctly. The result could be that no GPU showed up in the GPU tab in Awesome Miner. This will be corrected in the next release. When using all GPUs I've not been able to identify any issues. After you applied the new Awesome Miner version, can you please try again and then collect the API Report (toolbar Tools -> API Report) for the miner when you run into this issue. |
|
|
|
Hi Patrike, can you please improve a rules functionality. AM need a "rule group", where user put all rules and can trigger all rules in this group with simple rule trigger. I want realise scenario where on defined time the profit profile of every rig will be changed. Every rig have individual profit profiles 1 and 2. Now AM allow only one rig per rule and if you have 100 rigs you need 200 rules (set profile 1, set profile 2)
I want group all this set rules in one group and activate only with one simple rule. Or AM have another trick for this scenario?
upd. If with "rule group" you have problem, then please improve "Apply Profit Profile" action, where user can define a rig for which selected Profit Profile must be set.At the moment will be choosed only rig or whole rig group where rule was called. Or simple show please a C# code example where i can select miner and apply profile.
Or another variant:
i define a rig variables with names of profile1 and profile2.
Execute rule on top level group of miners and C# function recieve a List object with all rigs.
I select each list element and read variable "profile1" or "profile2" (depend of rule which was manual executed)
I apply profit profile wich was found by name from variable "profile1" or "profile2"
Logic is simple, but no documentation.... I know, all what i need is in "Context" object.
I need examples for this steps. How to read user defined variable, how to find by name profit profile, how to apply profile)))
Regards.
The easiest solution here would be to improve the existing Apply Profit Profile rule to allow you to specify a variable name. You could then add a variable with this name for each of your miners, specifying the name of the Profit Profile you want the rule to apply. |
|
|
|
Hi Patrik, can you please add dual mining support for TeamRedMiner in the Managed Miner Properties? If I switch from (for example) Lolminer to TeamRedMiner, the Dual Mode config below the "Path" disapears. Right now, I have to put everything of the Dual/Triple mining part into the password field. It works, but AM just shows the first coin, not the second coin. Thanks  Edit: Will you add Triple mining support in the properties? Yes, I took the entire command line in the miner properties. The problem with Teamredminer and dual and triple mining is that a different API port is used for each coin. I don't think that's easy to implement. But I also asked Patrik a few weeks ago, so I hope he can solve it I noticed that TeamRedMiner has started to provide an alternative way to get dual coin monitoring details, without having to use a different API port that would have made it complex. You can expect TRM dual mining support soon. |
|
|
|
Awesome Miner version 9.9.1
Mining software
- BzMiner 13.2.1
- Lolminer 1.68
- Rigen 1.3.7
Corrections
- Correction to temperature display in the web interface
- Correction to wallet balance for Dogecoin
- Correction to DynexSolve integration
Hi Patrike, Rigel is still sometimes leaving one of its processes active after AM shuts it down. Regards, ...jim Thanks for the feedback. I've noticed that there is a command line flag to disable the built-in watchdog feature of Rigel (--no-watchdog). In the next release I will make sure it's disabled as I suspect it could cause the issues you describe here. |
|
|
|
|
Awesome Miner version 9.9.1
Mining software
- BzMiner 13.2.1
- Lolminer 1.68
- Rigen 1.3.7
Corrections
- Correction to temperature display in the web interface
- Correction to wallet balance for Dogecoin
- Correction to DynexSolve integration
|
|
|
|
Hi Patrike, strange bug in ver 9.9 on DNX coin mining. If i start mining, AM show on start 307 acepted shares. If i switch mining to other algo, then acepted shares counter begint from 0. On other my locations, DNX show same bug, but with other starting value of acepted shares. Check pls. Regards.
Thanks for the report. I have an idea what the problem could be here - please try the latest version that is about to be released. |
|
|
|
|
Awesome Miner version 9.9
ASIC mining
- Added support for Antminer KA3 (Kadena)
- Added support for Antminer K7
- Added support for iPollo G1
Features
- Updated design for the Miner Groups tab
- Store created time for Managed Miners (already supported for External Miners)
- Display created time for both Managed and External Miners
Improvements
- Reduce data size for cloud web
- Improved compatibilty with latest Windows 11 update
Mining software
- New mining software: DynexSolve
- New mining software: Rigel 1.3.6
- BzMiner 13.1.1
- CpuMiner-Opt 3.21.1
- Gminer 3.28
- Miniz Miner 2.0c3
- NbMiner 42.3
- Lolminer 1.67
- SrbMiner-Multi 2.1.0
- TeamBlackMiner 1.91
- TeamRedMiner 0.10.9
- TT-miner 2023.1.7
- WildRig Miner 0.36.6b
- XmRig 6.19
Corrections
- Correction to NbMiner password parameter
- Correction to Binance BTC exchange rate
- Correction to Hammer D10 share count
|
|
|
|
Hi Patrike, something wrong with DNX coin revenue calculation. DNX hashrate in profit profile is in H/s. If i change from H/s to GH/s, AM begin to show some revenue. But if i am wrong, why AM not show negative revenue? Regards.
Thanks for the feedback. I have updated the calculations for DNX and it should automatically work in your Awesome Miner now (or within the next few hours). The revenue (mining income before electricity cost) can never go below zero. The profit can however be negative. |
|
|
|
|
Show Posts
