Pages:
Author

Topic: [NEW] free rig-monitor 4.0 (alpha released) - page 8. (Read 14736 times)

jr. member
Activity: 177
Merit: 2
I just published a development release with Fairpool support. I'd appreciate if anyone using FairPool could test it and provide feedback (and bugs). In case of the latter please attach a trace.

Thank you
jr. member
Activity: 177
Merit: 2
Oh I never tested that.
Anyways please check the latest dev release (2.0.d.7). It includes support for PhoenixMiner and a dashboard template.

Finally got around to testing (had a burst pipe in the basement). It seems as though it's not picking up all the details for all rigs. It shows the hashrates fine for all the rigs, but it is only reporting the gpu temp and fanspeed for one of the rigs.

Ok. Please send me a trace and I’ll take a look at it.
newbie
Activity: 30
Merit: 0
Oh I never tested that.
Anyways please check the latest dev release (2.0.d.7). It includes support for PhoenixMiner and a dashboard template.

Finally got around to testing (had a burst pipe in the basement). It seems as though it's not picking up all the details for all rigs. It shows the hashrates fine for all the rigs, but it is only reporting the gpu temp and fanspeed for one of the rigs.
jr. member
Activity: 177
Merit: 2
Hi, I'm get some errors when rig-monitor tries to get data from nanopool.
Today nanopool API is not working correctly: it gives me Error 0: undefined 8/10 times
 
Code:
ERROR: 2018/05/16 16:00:27 pool-monitor.go:32: Could not decode json response!
INFO: 2018/05/16 16:00:27 nanopool.go:116: minerGeneralInfo query failed!
INFO: 2018/05/16 16:00:27 nanopool.go:123: Querying NANOPOOL minerShares.
ERROR: 2018/05/16 16:00:27 pool-monitor.go:32: Could not decode json response!
INFO: 2018/05/16 16:00:27 nanopool.go:128: minerShares query failed!
INFO: 2018/05/16 16:00:27 nanopool.go:147: Querying NANOPOOL networkAverageBlockTime.
ERROR: 2018/05/16 16:00:28 pool-monitor.go:32: Could not decode json response!
INFO: 2018/05/16 16:00:28 nanopool.go:152: networkAverageBlockTime query failed!
INFO: 2018/05/16 16:00:28 nanopool.go:159: Querying NANOPOOL networkBlocks.
ERROR: 2018/05/16 16:00:28 pool-monitor.go:32: Could not decode json response!
INFO: 2018/05/16 16:00:28 nanopool.go:164: networkBlocks query failed!
INFO: 2018/05/16 16:00:28 nanopool.go:171: Querying NANOPOOL minerPayments.
ERROR: 2018/05/16 16:00:28 pool-monitor.go:32: Could not decode json response!
INFO: 2018/05/16 16:00:28 nanopool.go:176: minerPayments query failed!
panic: runtime error: index out of range

goroutine 34 [running]:
go-rig-monitor/pool.loadNanopoolData(0x10d90120, 0x4644b8, 0x10cfb3e0, 0x10d27e80)
        /Users/ramf/go/src/go-rig-monitor/pool/nanopool.go:328 +0x2ddc
go-rig-monitor/pool.Monitor(0x4644b8, 0x10cfb3e0, 0x10d8e0c0, 0x10d27e80)
        /Users/ramf/go/src/go-rig-monitor/pool/pool-monitor.go:68 +0x2e8
created by main.main
        /Users/ramf/go/src/go-rig-monitor/main.go:147 +0x954
after this errors rig-monitor exits
when I'm running without pool data -p -1 it's OK
Is it possible to handle this error and not to stop the rig-monitor but make it retry reading jason from nanopool ?

I noticed the same in my test setup and have created an issue (https://github.com/rodneymo/rig-monitorv2/issues/14) to handle these failures gracefully. I suggest you disable it in the meantime. I'll have a fix for it tomorrow.

check version 2.1.d.9. It should be fixed now.
jr. member
Activity: 177
Merit: 2
i didn't get what you meant by an agent being installed.  
I am using TP-Link HS110 and monitoring power using a bash script and power-cycle whenever it falls below the threshold value using curl http GET/POST requests, remotely (doesn't even have to be on same network).
Pretty sure the same thing can be done with a WeMo.  Or with IFFT.

I meant have a small piece of software running on the server which can receive a reboot signal from rig-monitor.
For TP-LINK I am using the provide API to read power usage and in the future reset the plug to restart the rig.
Indeed, Wemo also has an API for that. I just ordered one so I should be adding support soon.

Oh yea got it.  but I don't get how that would solve situation in case of a hard crash.  In normal situation doesn't a good mining software handle the soft reboot?

I am hoping that some syscalls are able to handle, but I won't know for sure until I test it.
jr. member
Activity: 177
Merit: 2
Hi, I'm get some errors when rig-monitor tries to get data from nanopool.
Today nanopool API is not working correctly: it gives me Error 0: undefined 8/10 times
 
Code:
ERROR: 2018/05/16 16:00:27 pool-monitor.go:32: Could not decode json response!
INFO: 2018/05/16 16:00:27 nanopool.go:116: minerGeneralInfo query failed!
INFO: 2018/05/16 16:00:27 nanopool.go:123: Querying NANOPOOL minerShares.
ERROR: 2018/05/16 16:00:27 pool-monitor.go:32: Could not decode json response!
INFO: 2018/05/16 16:00:27 nanopool.go:128: minerShares query failed!
INFO: 2018/05/16 16:00:27 nanopool.go:147: Querying NANOPOOL networkAverageBlockTime.
ERROR: 2018/05/16 16:00:28 pool-monitor.go:32: Could not decode json response!
INFO: 2018/05/16 16:00:28 nanopool.go:152: networkAverageBlockTime query failed!
INFO: 2018/05/16 16:00:28 nanopool.go:159: Querying NANOPOOL networkBlocks.
ERROR: 2018/05/16 16:00:28 pool-monitor.go:32: Could not decode json response!
INFO: 2018/05/16 16:00:28 nanopool.go:164: networkBlocks query failed!
INFO: 2018/05/16 16:00:28 nanopool.go:171: Querying NANOPOOL minerPayments.
ERROR: 2018/05/16 16:00:28 pool-monitor.go:32: Could not decode json response!
INFO: 2018/05/16 16:00:28 nanopool.go:176: minerPayments query failed!
panic: runtime error: index out of range

goroutine 34 [running]:
go-rig-monitor/pool.loadNanopoolData(0x10d90120, 0x4644b8, 0x10cfb3e0, 0x10d27e80)
        /Users/ramf/go/src/go-rig-monitor/pool/nanopool.go:328 +0x2ddc
go-rig-monitor/pool.Monitor(0x4644b8, 0x10cfb3e0, 0x10d8e0c0, 0x10d27e80)
        /Users/ramf/go/src/go-rig-monitor/pool/pool-monitor.go:68 +0x2e8
created by main.main
        /Users/ramf/go/src/go-rig-monitor/main.go:147 +0x954
after this errors rig-monitor exits
when I'm running without pool data -p -1 it's OK
Is it possible to handle this error and not to stop the rig-monitor but make it retry reading jason from nanopool ?

I noticed the same in my test setup and have created an issue (https://github.com/rodneymo/rig-monitorv2/issues/14) to handle these failures gracefully. I suggest you disable it in the meantime. I'll have a fix for it tomorrow.
newbie
Activity: 12
Merit: 0
Hi, I'm get some errors when rig-monitor tries to get data from nanopool.
Today nanopool API is not working correctly: it gives me Error 0: undefined 8/10 times
 
Code:
ERROR: 2018/05/16 16:00:27 pool-monitor.go:32: Could not decode json response!
INFO: 2018/05/16 16:00:27 nanopool.go:116: minerGeneralInfo query failed!
INFO: 2018/05/16 16:00:27 nanopool.go:123: Querying NANOPOOL minerShares.
ERROR: 2018/05/16 16:00:27 pool-monitor.go:32: Could not decode json response!
INFO: 2018/05/16 16:00:27 nanopool.go:128: minerShares query failed!
INFO: 2018/05/16 16:00:27 nanopool.go:147: Querying NANOPOOL networkAverageBlockTime.
ERROR: 2018/05/16 16:00:28 pool-monitor.go:32: Could not decode json response!
INFO: 2018/05/16 16:00:28 nanopool.go:152: networkAverageBlockTime query failed!
INFO: 2018/05/16 16:00:28 nanopool.go:159: Querying NANOPOOL networkBlocks.
ERROR: 2018/05/16 16:00:28 pool-monitor.go:32: Could not decode json response!
INFO: 2018/05/16 16:00:28 nanopool.go:164: networkBlocks query failed!
INFO: 2018/05/16 16:00:28 nanopool.go:171: Querying NANOPOOL minerPayments.
ERROR: 2018/05/16 16:00:28 pool-monitor.go:32: Could not decode json response!
INFO: 2018/05/16 16:00:28 nanopool.go:176: minerPayments query failed!
panic: runtime error: index out of range

goroutine 34 [running]:
go-rig-monitor/pool.loadNanopoolData(0x10d90120, 0x4644b8, 0x10cfb3e0, 0x10d27e80)
        /Users/ramf/go/src/go-rig-monitor/pool/nanopool.go:328 +0x2ddc
go-rig-monitor/pool.Monitor(0x4644b8, 0x10cfb3e0, 0x10d8e0c0, 0x10d27e80)
        /Users/ramf/go/src/go-rig-monitor/pool/pool-monitor.go:68 +0x2e8
created by main.main
        /Users/ramf/go/src/go-rig-monitor/main.go:147 +0x954
after this errors rig-monitor exits
when I'm running without pool data -p -1 it's OK
Is it possible to handle this error and not to stop the rig-monitor but make it retry reading jason from nanopool ?
jr. member
Activity: 177
Merit: 2

Yeah the output on refresh doesn't list current reported hashrate at the end (refresh is the equivalent of hitting 's' in the console of the miner). However, the reported GPU hashrate and shares do show in the log every 5 seconds. If you pull the data at an interval greater than 5 seconds you should be able to grep the gpu reported hashrate and shares 10 or so lines up.

Alternatively, JSONRPC works if you script it into your code. It is universal between Phoenix and Claymore so it should keep your code small as there would be no need to have different code for each miner. This can be achieved with netcat:



Problem is that json-rpc requires Ethman.exe which is only available on Windows. I figured out a way and am almost done with the development so I'll stick to the html output.

I’m not sure that it does. I just ran the commands fine without having ethman running on one of my miners and it responded just fine.

check out dev version 2.1.d8

There a a few things that are not clear to me with regards mapping the son fields to the influxDB fields. FYI, I try to map to existing one for consistency and ability to do cross-miner reporting

      "hr":                 json.TotalHashRate,   //this is the instant HR
      "avg_result_time":    json.TotalHashRateAvg, //This seems to be the average HR since miner started
      "target_hr":          r.TargetHashRate,
      "shares_total":       json.Shares.NumAccepted + json.Shares.NumRejected + json.Shares.NumInvalid + json.Shares.NumNetworkFail + json.Shares.NumOutdated,
      "valid_shares":       json.Shares.NumAccepted,
      "invalid_shares":     json.Shares.NumInvalid,
      "stale_shares":       json.Shares.NumRejected, // Are these rejected by the pool?
      "outdated_shares":    json.Shares.NumOutdated, // are these stale shares i.e. shares submitted and block has been closed and a new block generated?
      "networkfail_shares": json.Shares.NumNetworkFail, // have no idea about these

Let me know if that's ok with you or if I should do some re-mapping
jr. member
Activity: 177
Merit: 2
development version d.8 has been published. I'll graduate this version to 2.1 (beta) in the coming days.

What's new:
Added support for SRBMiner including dashboard template.
Added support for XMRig-proxy including dashboard template.
Added support for PhoenixMiner including dashboard template.
Added support for CastXmr including dashboard template.
Added support for bastardized versions of node-js-pool API (cryptonote-pool API) e.g. supportxmr.com.

Tentative scope for 2.2:
Fairpool support
Wemo Insight smart-plug support
Power Mgmt rules (reset rigs if power or hashrate KPIs go below a configured value)
jr. member
Activity: 177
Merit: 2

Yeah the output on refresh doesn't list current reported hashrate at the end (refresh is the equivalent of hitting 's' in the console of the miner). However, the reported GPU hashrate and shares do show in the log every 5 seconds. If you pull the data at an interval greater than 5 seconds you should be able to grep the gpu reported hashrate and shares 10 or so lines up.

Alternatively, JSONRPC works if you script it into your code. It is universal between Phoenix and Claymore so it should keep your code small as there would be no need to have different code for each miner. This can be achieved with netcat:



Problem is that json-rpc requires Ethman.exe which is only available on Windows. I figured out a way and am almost done with the development so I'll stick to the html output.

I’m not sure that it does. I just ran the commands fine without having ethman running on one of my miners and it responded just fine.

Oh I never tested that.
Anyways please check the latest dev release (2.0.d.7). It includes support for PhoenixMiner and a dashboard template.

For some weird reason the dashboard was not included in the d.7 release. Will add it in the d.8 release in a couple of hours.
full member
Activity: 729
Merit: 114
i didn't get what you meant by an agent being installed.  
I am using TP-Link HS110 and monitoring power using a bash script and power-cycle whenever it falls below the threshold value using curl http GET/POST requests, remotely (doesn't even have to be on same network).
Pretty sure the same thing can be done with a WeMo.  Or with IFFT.

I meant have a small piece of software running on the server which can receive a reboot signal from rig-monitor.
For TP-LINK I am using the provide API to read power usage and in the future reset the plug to restart the rig.
Indeed, Wemo also has an API for that. I just ordered one so I should be adding support soon.

Oh yea got it.  but I don't get how that would solve situation in case of a hard crash.  In normal situation doesn't a good mining software handle the soft reboot?
jr. member
Activity: 177
Merit: 2
i didn't get what you meant by an agent being installed.  
I am using TP-Link HS110 and monitoring power using a bash script and power-cycle whenever it falls below the threshold value using curl http GET/POST requests, remotely (doesn't even have to be on same network).
Pretty sure the same thing can be done with a WeMo.  Or with IFFT.

I meant have a small piece of software running on the server which can receive a reboot signal from rig-monitor.
For TP-LINK I am using the provide API to read power usage and in the future reset the plug to restart the rig.
Indeed, Wemo also has an API for that. I just ordered one so I should be adding support soon.
jr. member
Activity: 177
Merit: 2

Yeah the output on refresh doesn't list current reported hashrate at the end (refresh is the equivalent of hitting 's' in the console of the miner). However, the reported GPU hashrate and shares do show in the log every 5 seconds. If you pull the data at an interval greater than 5 seconds you should be able to grep the gpu reported hashrate and shares 10 or so lines up.

Alternatively, JSONRPC works if you script it into your code. It is universal between Phoenix and Claymore so it should keep your code small as there would be no need to have different code for each miner. This can be achieved with netcat:



Problem is that json-rpc requires Ethman.exe which is only available on Windows. I figured out a way and am almost done with the development so I'll stick to the html output.

I’m not sure that it does. I just ran the commands fine without having ethman running on one of my miners and it responded just fine.

Oh I never tested that.
Anyways please check the latest dev release (2.0.d.7). It includes support for PhoenixMiner and a dashboard template.
full member
Activity: 729
Merit: 114
Specific reason this is not open source?
any plans on making it open source?

That was probably the thing I thought the most about when I decided to re-write it golang. This is not set in stone and I'll re-evaluate the decision as time goes by.
My experience with rig-monitor 1.x, which is scripted and inherently open source was not really good. Got a bunch of ppl forking it, but only
one guy sporadically contributing. But, like I said I might re-evaluate the decision later on.

I currently just use a simple bash script to autoreboot my rigs when power consumptions falls below a threshold value (hard system crash).  Soft crashes can be handled with mining software but not the hard crashes.  In house mining software watchdog timers fail here too.

right, but that requires an "agent" to be installed on every rig. Right now I am looking at developing all 3 options below:
1) monitor hr and power usage KPIs and reset smart plug in case of failure (currently under development; will support both TPLINK and Wemo plugs)
2) use GPIO to trigger external relays (raspberry PI only)
3) develop "agent" that can be signaled to force rig reboot via syscall

i didn't get what you meant by an agent being installed.  
I am using TP-Link HS110 and monitoring power using a bash script and power-cycle whenever it falls below the threshold value using curl http GET/POST requests, remotely (doesn't even have to be on same network).
Pretty sure the same thing can be done with a WeMo.  Or with IFFT.
newbie
Activity: 30
Merit: 0

Yeah the output on refresh doesn't list current reported hashrate at the end (refresh is the equivalent of hitting 's' in the console of the miner). However, the reported GPU hashrate and shares do show in the log every 5 seconds. If you pull the data at an interval greater than 5 seconds you should be able to grep the gpu reported hashrate and shares 10 or so lines up.

Alternatively, JSONRPC works if you script it into your code. It is universal between Phoenix and Claymore so it should keep your code small as there would be no need to have different code for each miner. This can be achieved with netcat:



Problem is that json-rpc requires Ethman.exe which is only available on Windows. I figured out a way and am almost done with the development so I'll stick to the html output.

I’m not sure that it does. I just ran the commands fine without having ethman running on one of my miners and it responded just fine.
jr. member
Activity: 177
Merit: 2

Yeah the output on refresh doesn't list current reported hashrate at the end (refresh is the equivalent of hitting 's' in the console of the miner). However, the reported GPU hashrate and shares do show in the log every 5 seconds. If you pull the data at an interval greater than 5 seconds you should be able to grep the gpu reported hashrate and shares 10 or so lines up.

Alternatively, JSONRPC works if you script it into your code. It is universal between Phoenix and Claymore so it should keep your code small as there would be no need to have different code for each miner. This can be achieved with netcat:



Problem is that json-rpc requires Ethman.exe which is only available on Windows. I figured out a way and am almost done with the development so I'll stick to the html output.
jr. member
Activity: 177
Merit: 2

Hi! , thanks for your work, pretty awesome dashboard i'm running it using windows 10 in a miner without any problems

When castxmr v1.0.0 is executed using --remoteaccess you go to the miner http://127.0.0.1:7777 and you get this, no file extension:


I will provide you with an URL so you can test it in a message

edit1: well, i can't send you messages because I am considered a newbie

Thank you. I really appreciate it. I'll get on it as soon as I finish support for PhoenixMiner. I'll send you a message, maybe you can reply to it.
jr. member
Activity: 177
Merit: 2
Specific reason this is not open source?
any plans on making it open source?

That was probably the thing I thought the most about when I decided to re-write it golang. This is not set in stone and I'll re-evaluate the decision as time goes by.
My experience with rig-monitor 1.x, which is scripted and inherently open source was not really good. Got a bunch of ppl forking it, but only
one guy sporadically contributing. But, like I said I might re-evaluate the decision later on.

I currently just use a simple bash script to autoreboot my rigs when power consumptions falls below a threshold value (hard system crash).  Soft crashes can be handled with mining software but not the hard crashes.  In house mining software watchdog timers fail here too.

right, but that requires an "agent" to be installed on every rig. Right now I am looking at developing all 3 options below:
1) monitor hr and power usage KPIs and reset smart plug in case of failure (currently under development; will support both TPLINK and Wemo plugs)
2) use GPIO to trigger external relays (raspberry PI only)
3) develop "agent" that can be signaled to force rig reboot via syscall
newbie
Activity: 30
Merit: 0
I need a few more days. Unlike claymore the output from PhoenixMiner is not consistent e.g. most of the last paragraph does not include all the info. So I have to modified the regexs and logic.

Yeah the output on refresh doesn't list current reported hashrate at the end (refresh is the equivalent of hitting 's' in the console of the miner). However, the reported GPU hashrate and shares do show in the log every 5 seconds. If you pull the data at an interval greater than 5 seconds you should be able to grep the gpu reported hashrate and shares 10 or so lines up.

Alternatively, JSONRPC works if you script it into your code. It is universal between Phoenix and Claymore so it should keep your code small as there would be no need to have different code for each miner. This can be achieved with netcat:

Code:
echo '{"id":0,"jsonrpc":"2.0","method":"miner_getstat1","psw":"remote_monitor_password"}' | netcat MINERIP MINERPORT

If no password is used in the remote miner, you can remove the password and leave the psw in:
Code:
echo '{"id":0,"jsonrpc":"2.0","method":"miner_getstat1","psw":""}' | netcat MINERIP MINERPORT

And the result from PhoenixMiner is:
Code:
{"id":0,"jsonrpc":"2.0","result":["PM 2.9e - ETH", "210", "61831;75;0", "31883;29948", "0;0;0", "off;off", "65;0;60;39", "eth-us-east1.nanopool.org:9999", "0;0;0;0"]}

A legend of what the data is:
Code:
"PM 2.9e - ETH" miner version.
""210" running time, in minutes.
"61831;75;0" total ETH hashrate in H/s, number of ETH shares, number of ETH rejected shares.
"31883;29948" detailed ETH hashrate for all GPUs. (there are 2 on this output)
"0;0;0" total DCR hashrate in H/s, number of DCR shares, number of DCR rejected shares.
"off;off" detailed DCR hashrate for all GPUs.
"65;0;60;39" Temperature and Fan speed(%) pairs for all GPUs.
"eth-us-east1.nanopool.org:9999" current mining pool. For dual mode, there will be two pools here.
"0;0;0;0" number of ETH invalid shares, number of ETH pool switches, number of DCR invalid shares, number of DCR pool switches.

newbie
Activity: 20
Merit: 1
Any ideia to develop it in cast xmrstack?

Thanks

Are you referring to this one? https://bitcointalksearch.org/topic/m.37051627

I posted there asking for a Json file and the URL to the remote management port. If you can provide both I can easily add support for it

Hi! , thanks for your work, pretty awesome dashboard i'm running it using windows 10 in a miner without any problems

When castxmr v1.0.0 is executed using --remoteaccess you go to the miner http://127.0.0.1:7777 and you get this, no file extension:
Code:
{
"total_hash_rate": 7381347,
"total_hash_rate_avg": 7268710,
"pool": {
"server": "xmr-us-east1.nanopool.org:14444",
"status": "connected",
"online": 16,
"offline": 0,
"reconnects": 0,
"time_connected": "2018-05-14 18:37:31",
"time_disconnected": "2018-05-14 18:37:31"
},
"job": {
"job_number": 1,
"difficulty": 120001,
"running": 15,
"job_time_avg": 0.00
},
"shares": {
"num_accepted": 0,
"num_rejected": 0,
"num_invalid": 0,
"num_network_fail": 0,
"num_outdated": 0,
"search_time_avg": 0.00
},
"devices": [
{
"device": "GPU0",
"device_id": 0,
"hash_rate": 1844253,
"hash_rate_avg": 1828105,
"gpu_temperature": 39,
"gpu_fan_rpm": 3657
},
{
"device": "GPU1",
"device_id": 1,
"hash_rate": 1845520,
"hash_rate_avg": 1764523,
"gpu_temperature": 41,
"gpu_fan_rpm": 3668
},
{
"device": "GPU2",
"device_id": 2,
"hash_rate": 1962401,
"hash_rate_avg": 1898305,
"gpu_temperature": 45,
"gpu_fan_rpm": 3749
},
{
"device": "GPU3",
"device_id": 3,
"hash_rate": 1729173,
"hash_rate_avg": 1777777,
"gpu_temperature": 45,
"gpu_fan_rpm": 3634
}
]
}

I will provide you with an URL so you can test it in a message

edit1: well, i can't send you messages because I am considered a newbie
Pages:
Jump to: