[Awesome Miner] - Powerful Windows GUI to manage and monitor up to 200000 miners

[GoRdiE]

@patrike

Can be changed --devices to -d in the ccminer configuration?. To achieve greater compatibility in the user defined mining software. I do not know if this change would be detrimental to other mining software   

[MoparMiningLLC]

I have a question - I currently have 5 ASICs, 2 GPU and 2 CPU mining rigs connected to Awesome Miner. However on the dashboard, it shows a total of 9 and that all 9 are active. So far that is right - but then in the next area, it shows 2 GPU 8 CPU and 9 ASICs (I realize it is counting the cores for CPU but why does it have all the miners grouped under ASICs? And with my CPU's and GPU's it shows the profits that those miners make but not for the ASICs - I have to manually log into the pool to see that.

Is there also any way to link our wallets so that we can see our balances in the Awesome Miner Interface? - edit: I have found the area to do this and am working to add my various wallets. second edit... my main wallet generates a different address for each transaction, so it seems I have to link quite a few "wallets"

[moppidoo]

Hi to community.
Please, advice, is there any way, to do the following...
The situation: There is a managed local miner created with the selected ETH pool. There is a rule for this miner, that switch a pool to ETC at the specified time, and the 2nd rule, that switch the pool back to ETH, also st the specified time.
The problem: if the pool was changed to ETC, and during the miner work the rig hangs/crashes, after system reboot it's back to ETH, that selected in the managed miner settings.
The question: How to prevent switching back to ETH pool, after the rig crashes and Awesome Miner restarts? Is there any way to force Awesome to remember the last settings?

Tnanks in advance.

(hypothesising) Have you tried creating this rule with 2 Time triggers? such that it gets checked say, every 5 minutes with the first trigger, and then make a following trigger based on Time/Week of the day and select "Match All" (AND), maybe it'll do the trick.

maybe you have to clone several of the above rules since the Time option only triggers at particular instant and not between x:xx to y:yy, maybe Patrike can see about this type of implementation, you'd have to make a request though.

I personally used a similar triggers to switch pool (groups), but the way I did was to have the high preference pool switch trigger at every 15min and low priority pools at 100min, bit of borrowed idea from DevFees, but of course, works rather differently as they are 2 concurrent running rules rather than a fixed percentage and overlaps are obviously, different as time lapses.

[patrike]

I might need a bit more details about this scenario. Is TeamRedMiner added as a Managed Software? Compatible with Ccminer or similar? Have you explicitly enabled a few algorithms for it in the same dialog where you set the compatibility?

Yes, it is added as managed software, CCMINER command line compatible with no API. Lyra2Z algo enabled.

From what I can see, the only scenario this can happen is if the miner is a Managed Profit Miner (not Managed Miner) and that Awesome Miner doesn't think the pool algorithm can be used for this software.

Can you share the log lines just above those you provided, saying something like "GetStaticSortedPools, Enginetype: ". On that line it should also list the algorithms.

In the Managed Software configuration, I assume you made sure that it's not only says "Enabled" in the Default-column, but that it also says "Enabled" (or "Default") in the next column called "Enabled / Disabled"?

[patrike]

@patrike

Can be changed --devices to -d in the ccminer configuration?. To achieve greater compatibility in the user defined mining software. I do not know if this change would be detrimental to other mining software   

This is a good point and I was considering making this change when I found out that some ccminer clones uses "--device" while other uses "--devices", while "-d" looked like a more universal solution. I was however a bit afraid of breaking things, but I can investigate this in more detail and make the change next time I make a development version available. Thanks for your feedback.

[patrike]

I have a question - I currently have 5 ASICs, 2 GPU and 2 CPU mining rigs connected to Awesome Miner. However on the dashboard, it shows a total of 9 and that all 9 are active. So far that is right - but then in the next area, it shows 2 GPU 8 CPU and 9 ASICs (I realize it is counting the cores for CPU but why does it have all the miners grouped under ASICs? And with my CPU's and GPU's it shows the profits that those miners make but not for the ASICs - I have to manually log into the pool to see that.

Is there also any way to link our wallets so that we can see our balances in the Awesome Miner Interface? - edit: I have found the area to do this and am working to add my various wallets. second edit... my main wallet generates a different address for each transaction, so it seems I have to link quite a few "wallets"

The ASIC count for Dashboard will be fixed in the new release that will be available soon.

[patrike]

Awesome Miner version 5.6.1

- Added a guide for Antminer and ASIC miner troubleshooting - can be accessed via the Antminer Diagnostics dialog
- Notification actions can be configured with a custom authorization header for webhooks
- Added more predefined Block Explorers for wallet balance
- Include more detailed information about the Awesome Miner license and subscription via the status bar button for license information
- Z-enemy miner 1.21
- CryptoDredge 0.9.2
- EWBF Equihash Miner 0.6
- Bminer 10.4, with support for Personalization flag
- Correction to path for uploaded software on Remote Agent for Linux
- Correction to ASIC device count on dashboard when running a system with a mix of GPU and ASIC miners

[moppidoo]

WildRig Multi 0.11.6 Beta is Becoming Even More Useful Multi-algorithm Miner

Hi Patrike,

+1 for integrating it into AM

The miner is somewhat using compatible commandline + API as XMRig so I could add it to AM as custom software without issue. But reading from the API seemed to have a bit of issue with the hashrate units so far.

eg, mining HMQ1725, API reports hashrate of 5000 kH/s, but AM is reading 5 kH/s FYI.

edit: it applies to tribus, bcd as well (i suspect all) that kH/s are all parsed as H/s

I will take a look at this one. Thanks for your suggestions.

Hi Patrike,

Seems they have fixed the API reporting unit from kH/s to H/s so on unit inconsistencies side of things, this is not an issue anymore

0.11.9
- speedup x16r/x16s in some cases on final step
- fixed regress for simd, so should speedup x16r/x16s and return speed for other algos(bcd, sonoa, etc.)
- added hex algo
- now intensity can be set using sgminer-like numbers(old one supported too)
- improved API a bit, now threads contains hashrate per GPU, not per thread, so it should be correct now for HiveOS/etc.
- fixed GPU numbering at start when --opencl-threads used

0.11.8
- regen job now per GPU, should increase poolside hashrate
- added x16r, x16s and timetravel algorithms
- 30% boost for hmq1725
- grouped print of hashrate per GPU when use --opencl-threads parameter
- H/s unit in API instead of kH/s

But....now a new issue arises and I don't know which party should handle this, as suggested, it's more optimal to run multiple threads per GPU (via --opencl-threads) as per example posted in software's thread, but since the update to 0.11.9 from 0.11.6, AM is only reporting hashrate of 1 thread (I think it's the first) from each GPU, so say, my hashrate is now 8MH/s (4 MH/s per GPU) but running 3 threads per GPU, it is reporting 2.3MH/s to AM (or AM is reading 2.3 MH/s from the API anyway), below is the API output from the hashrate section:

Code:

    "algo": "hmq1725",
    "donate_level": 2,
    "uptime": 2928,
    "hashrate": {
        "total": [
            8331449,
            8336995,
            8342576
        ],
        "highest": 8444092,
        "threads": [
            [
                1133473,
                1132772,
                1133680
            ],
            [
                1141292,
                1140633,
                1130904
            ]
        ]
    },

[MoparMiningLLC]

The ASIC count for Dashboard will be fixed in the new release that will be available soon.

thank you!

[STSMiner]

Hi patrike,

Re: Registration code:  Upgrade code issued

Does the old Reg code still work as well ?

[Calvinz89]

I configured rules for idle/use scenarios, but "stop miner" will also trigger if I manually press a Start button
How to prevent that?

[andrucrypt]

WildRig Multi 0.11.6 Beta is Becoming Even More Useful Multi-algorithm Miner

Hi Patrike,

+1 for integrating it into AM

The miner is somewhat using compatible commandline + API as XMRig so I could add it to AM as custom software without issue. But reading from the API seemed to have a bit of issue with the hashrate units so far.

eg, mining HMQ1725, API reports hashrate of 5000 kH/s, but AM is reading 5 kH/s FYI.

edit: it applies to tribus, bcd as well (i suspect all) that kH/s are all parsed as H/s

I will take a look at this one. Thanks for your suggestions.

Hi Patrike,

Seems they have fixed the API reporting unit from kH/s to H/s so on unit inconsistencies side of things, this is not an issue anymore

0.11.9
- speedup x16r/x16s in some cases on final step
- fixed regress for simd, so should speedup x16r/x16s and return speed for other algos(bcd, sonoa, etc.)
- added hex algo
- now intensity can be set using sgminer-like numbers(old one supported too)
- improved API a bit, now threads contains hashrate per GPU, not per thread, so it should be correct now for HiveOS/etc.
- fixed GPU numbering at start when --opencl-threads used

0.11.8
- regen job now per GPU, should increase poolside hashrate
- added x16r, x16s and timetravel algorithms
- 30% boost for hmq1725
- grouped print of hashrate per GPU when use --opencl-threads parameter
- H/s unit in API instead of kH/s

But....now a new issue arises and I don't know which party should handle this, as suggested, it's more optimal to run multiple threads per GPU (via --opencl-threads) as per example posted in software's thread, but since the update to 0.11.9 from 0.11.6, AM is only reporting hashrate of 1 thread (I think it's the first) from each GPU, so say, my hashrate is now 8MH/s (4 MH/s per GPU) but running 3 threads per GPU, it is reporting 2.3MH/s to AM (or AM is reading 2.3 MH/s from the API anyway), below is the API output from the hashrate section:

Code:

    "algo": "hmq1725",
    "donate_level": 2,
    "uptime": 2928,
    "hashrate": {
        "total": [
            8331449,
            8336995,
            8342576
        ],
        "highest": 8444092,
        "threads": [
            [
                1133473,
                1132772,
                1133680
            ],
            [
                1141292,
                1140633,
                1130904
            ]
        ]
    },

Hi, it's a bug in miner API, I will fix it in newer version. Just found that I forgot "+" in formula...

[patrike]

WildRig Multi 0.11.6 Beta is Becoming Even More Useful Multi-algorithm Miner

Hi Patrike,

+1 for integrating it into AM

The miner is somewhat using compatible commandline + API as XMRig so I could add it to AM as custom software without issue. But reading from the API seemed to have a bit of issue with the hashrate units so far.

eg, mining HMQ1725, API reports hashrate of 5000 kH/s, but AM is reading 5 kH/s FYI.

edit: it applies to tribus, bcd as well (i suspect all) that kH/s are all parsed as H/s

I will take a look at this one. Thanks for your suggestions.

Hi Patrike,

Seems they have fixed the API reporting unit from kH/s to H/s so on unit inconsistencies side of things, this is not an issue anymore

0.11.9
- speedup x16r/x16s in some cases on final step
- fixed regress for simd, so should speedup x16r/x16s and return speed for other algos(bcd, sonoa, etc.)
- added hex algo
- now intensity can be set using sgminer-like numbers(old one supported too)
- improved API a bit, now threads contains hashrate per GPU, not per thread, so it should be correct now for HiveOS/etc.
- fixed GPU numbering at start when --opencl-threads used

0.11.8
- regen job now per GPU, should increase poolside hashrate
- added x16r, x16s and timetravel algorithms
- 30% boost for hmq1725
- grouped print of hashrate per GPU when use --opencl-threads parameter
- H/s unit in API instead of kH/s

But....now a new issue arises and I don't know which party should handle this, as suggested, it's more optimal to run multiple threads per GPU (via --opencl-threads) as per example posted in software's thread, but since the update to 0.11.9 from 0.11.6, AM is only reporting hashrate of 1 thread (I think it's the first) from each GPU, so say, my hashrate is now 8MH/s (4 MH/s per GPU) but running 3 threads per GPU, it is reporting 2.3MH/s to AM (or AM is reading 2.3 MH/s from the API anyway), below is the API output from the hashrate section:

Code:

    "algo": "hmq1725",
    "donate_level": 2,
    "uptime": 2928,
    "hashrate": {
        "total": [
            8331449,
            8336995,
            8342576
        ],
        "highest": 8444092,
        "threads": [
            [
                1133473,
                1132772,
                1133680
            ],
            [
                1141292,
                1140633,
                1130904
            ]
        ]
    },

Hi, it's a bug in miner API, I will fix it in newer version. Just found that I forgot "+" in formula...

Thanks for the update. I was just about to point out that Awesome Miner is only reading the first value for each GPU (the current hashrate), which in this case would be GPU0: 1133473 and GPU1:1141292. If these numbers are made into the total numbers for all GPU threads in the next update, it should be working fine with Awesome Miner.

[patrike]

Hi patrike,

Re: Registration code:  Upgrade code issued

Does the old Reg code still work as well ?

Hi,

If you have a license, for example Standard Edition and then you upgrade it to Professional Edition, you will receive a new license code for Professional Edition. Because you only paid for the price difference when upgrading, you need to use the new code you got for the Professional Edition. Your old code for Standard Edition can no longer be used and will eventually expire.

[patrike]

I configured rules for idle/use scenarios, but "stop miner" will also trigger if I manually press a Start button
How to prevent that?

I think the reason it will trigger Stop Miner is because the rule will detect that the system is in use if you press the Start button.

I assume the miner is running on the Awesome Miner computer itself, and not on a Remote Agent?

[0x000216]

I need to have the capacity to switch between various mineworkers and furthermore include ewbf digger for zcash. Is there an approach to include ewbf or other right now non-recorded diggers and have them show measurements so it can participate in the multi motor benefit exchanging?

[moppidoo]

Hi, it's a bug in miner API, I will fix it in newer version. Just found that I forgot "+" in formula...

Thanks for the update. I was just about to point out that Awesome Miner is only reading the first value for each GPU (the current hashrate), which in this case would be GPU0: 1133473 and GPU1:1141292. If these numbers are made into the total numbers for all GPU threads in the next update, it should be working fine with Awesome Miner.

Thanks to you both for looking into the issue!

[moppidoo]

I need to have the capacity to switch between various mineworkers and furthermore include ewbf digger for zcash. Is there an approach to include ewbf or other right now non-recorded diggers and have them show measurements so it can participate in the multi motor benefit exchanging?

Both EWBF zcash and Equihash miners are by default supported and included in AM, benchmarking and profit switching works pretty much out of the box with these 2 miners

[alucard20724]

i found someone attempting to try and scam using awesomeminer

https://bitcointalk.org/index.php?topic=5042170.new#new

their site address is
https://blokchain.su/

which is an exact duplicate of awesomeminer.com home page

[patrike]

i found someone attempting to try and scam using awesomeminer

https://bitcointalk.org/index.php?topic=5042170.new#new

their site address is
https://blokchain.su/

which is an exact duplicate of awesomeminer.com home page

Thanks for pointing this out. They even copied the copyright notice - amazing guys. Hopefully it will smell enough scam so no one will download their malware.

I think everyone knows this already, but I might as well point it out:
1) The Awesome Miner software should always be downloaded from the official web site
2) If someone is trying to sell a license at a discount, I can assure that it's not a valid license they are trying to sell
3) I've also received reports from users that downloaded a 5000 miner version of Awesome Miner and ended up with a great collection of malware on their systems. I probably don't need to point out that it wasn't downloaded from the official web site in this case.