Topic: [ANN] RigHound - remotely manage all your mining rigs (Read 5866 times)

Update:
A few minor UI fixes.  Sorry I had a major hardware failure at my data center and this kinda took over my life for about a week.  More coming soon.

Coming soon:
Still working on the alerts mechanism.  Also re-architecting this a bit while I finish the Windows agent which will allow you to view/control your rigs without setting up any firewall/nat rules. 

Still looking for more users and more feedback!

Update:
Rig status/hashrate/pool info now updating automagically behind the scenes every 60 seconds.  It's a little bit unreliable - maybe 5% of the time it will report a rig down when it's really not, but I'm working on improving this.  The "Refresh status" link is still there if you really want up-to-the-second stats, but will likely be removed once I'm confident the auto-refreshing is working solid.

Coming soon:
Various UI improvements
User-defined threshold-based alerting mechanism (text msg/email alerts)

All this NAT & port-forwarding stuff with your firewall/router sucks.  I'm probably going to build an agent that runs on your local network to handle communicating with your miners, this will require *no* firewall configuration, just fire it up on any machine on LAN and remotely control all miners on that network.

Nope, sorry on deleting pools, I will add a delete button soon

Yay, the pool switching issue is no longer! Just to make sure, you can't delete pools yet can you?

I also noticed that the last rig on the list is not showing GPU data (just the rig name and runtime), but everything else works.

**Also, I noticed a rig showing -1.00MH/s.  It turns out that this card was in DEAD state.

Update

35 users have signed up so far, and only about 30 rigs are being monitored.  It seems the majority of users appear to be signing up just to "snag" one of the limited quantity of alpha accounts and have no mining rigs configured.  I'm opening up the alpha period to 60 years - we need more!

Would love to hear some more feedback from those of you who are using the system.

I was afraid of that - good to know, thanks.  It is definitely happening far less often receiving in 8k chunks rather than the 2k chunks I was using previously, and it was only happening when the data returned was greater than the receive buffer size.  As I said, time will tell on whether this is stable.

The issue is not whether you use TCP/IP or HTTP.

But it is a known issue with cgminer - sometimes it sends truncated data; closes socket before everything is sent. I don't know how often that appears for JSON format, I use non-JSON custom format, it is shorter and easier to parse (when not using 3rd party JSON libs), but it happens here and there anyway.

Thanks again for the input.  I've run into this as well.

Short version:
Every time you change pools, RigHound first checks to see if your instance of cgminer has that pool in it's "pools" list, and if it doesn't, adds it.  Then, it commands cgminer to switch to that pool.

The problem occurs when cgminer's "pools" list gets larger than maybe 3-4 pools in it.  I haven't figured out why yet, but for some reason sometimes I get back truncated JSON results (like, I get back 3 pools and only half the 4th's pools info).  Part of the problem may be that I'm using a raw TCPIP socket connection rather than an HTTP request (I'm convinced raw TCP/IP is faster), this means I have to build my own buffering/receive mechanism rather than the built-in HTTP ones, and I'll be the first to admit there may be some bugs there.

It doesn't happen all the time, and not with every rig, so it's tough to troubleshoot.  I'm working on this along with a better, faster & automatic way to refresh your rig's status (so you don't have to click the "Refresh" button and wait FOREVER).  Stay tuned, I'm making changes & improving this every day!

**EDIT**
Just implemented a possible fix for this, time will tell if it works consistently - as an added bonus, the "Refresh Status" button is about 2x faster as well

very usefull tool. Well done.

I have another question, is it possible to use this
 --api-listen --api-groups P:restart:addpool:removepool:switchpool:enablepool:save:* --api-allow P:98.174.25/24 --api-port 7077

on my .conf file ??

ABSOLUTELY!  Bulk rig management is definitely coming in the near future, including scheduling (mine at pool A for X hours then switch to pool B).  *Maybe* even some auto-profitability switching stuff (not sure I want to head down that path).  Right now I'm mostly concentrating on connectivity & reliability in reaching out to your rigs & controlling them.

Looking great!
I have a suggestion, could you add an option to change ALL of your rigs' pools at the same time?!

Updates today:
Miscellaneous UI bugfixes
Rig total uptime displayed next to individual device statistics

Up next
Automatic refresh of mining rig statistics - so you don't have to click the "Refresh status" button to update your current pool info, hashrate, etc.

Thanks both of you for reporting this.  I found the issue, you should be able to add new pool workers now.

Hint:  RigHound configuration is easier when you use the same worker name for your rig at all your pools.  You can set the "Default Worker name" from the Edit Miner window.  If you do this, when you add new pool workers, they will be associated with the correct mining rig automatically.

same here

A Page Error Has Occured.
Page Address http://www.righound.com/EditPool.aspx?PoolID=18&rwndrnd=0.5987433409617642
Error Object reference not set to an instance of an object.
This information has been sent to the RigHound support team, who will investigate what happened and do what is necessary to prevent it from happening again. If this is the first time this error has occured, please close and reopen your web browser and try again.


Awsome project! keep up the good work !!

Thanks for the input.  I get an email any time an error is thrown, I've seen several related to adding pool workers to come across but I can't seem to duplicate the issue, every time I try to add pool workers it seems to work fine.  I'll keep trying to figure out.

Hey, I'm trying to add workers on the pool settings, but I keep getting an error,

Page Address ***
Error Object reference not set to an instance of an object.

API Key doesn't change anything either, although you stated it's for future use.

No, you cannot.  Each running instance of CGMiner can only listen on one API port.  If you are using CGWatcher that's fine - just configure RigHound to use API port 4028 and they can both monitor your rig!

Hi,

can i ask my cgminer to listen to several ports?

*UPDATE*

"My Rigs" screen now shows individual device statistics for each mining rig:

Individual hashrate, accepted/rejected and temp for each GPU/ASIC device (temp not shown in screenshot because my GPU does not support it)