This link appears to only have the readme file included. Yes. Sorry that’s because in the meantime I fixed several bugs. The latest dev version is 2.2.d6 I just posted another dev version 2.2.d7, which adds automatic reload of rig, pool and power management rules in case of configuration file changes, during runtime. |
|
|
|
This link appears to only have the readme file included. Yes. Sorry that’s because in the meantime I fixed several bugs. The latest dev version is 2.2.d6 |
|
|
|
I have just create a mining overview example dashboard that combines rig, pool and market data. See picture below. This example will be included in future releases, but in the meantime you can download it from here https://github.com/rodneymo/rig-monitorv2/issues/10 |
|
|
|
|
For those of you using CastXMR, version 2.1.2 has been released. It adds support for "mining_time" and updates the "Rig Overall status" panel on the respective dashboard template.
|
|
|
|
|
Would you mind if I add this to future release packages? Of course I'll add the necessary info and license about the author
|
|
|
|
Hi all,
version 2.1 (stable) has been released. Besides the new features this version solves multiple memory management issues so I suggest you upgrade ASAP.
rodneymo
Trying it out now. The last release still errored out for the same influxdb timeout with the 30s limit. I seem to have found another issue with the parsing. My Nvidia card sometimes errors out and the driver stops reporting fanspeed. After that happens, rig-monitor does not report the fanspeed or the temperatures for the other cards despite them being available in the html output. HTML output: https://pastebin.com/JYRwbNbSGrafana just lists all 3 cards as 0 for fanspeed/temps. Fix in 2.1.1 |
|
|
|
Hi all,
version 2.1 (stable) has been released. Besides the new features this version solves multiple memory management issues so I suggest you upgrade ASAP.
rodneymo
Trying it out now. The last release still errored out for the same influxdb timeout with the 30s limit. I seem to have found another issue with the parsing. My Nvidia card sometimes errors out and the driver stops reporting fanspeed. After that happens, rig-monitor does not report the fanspeed or the temperatures for the other cards despite them being available in the html output. HTML output: https://pastebin.com/JYRwbNbSGrafana just lists all 3 cards as 0 for fanspeed/temps. About the timeout, I think we need to rule out a grm issue as I have been running it on a raspberry PI 1 for almost days without issues. Could you PM you config file, I'll set up my simulator to see if everything checks out. Also, what's the command you are using to start grm? and are you running it as a service or from the command line? I'll. take a look at the Nvidia output and provide you a fix. |
|
|
|
|
Hi all,
version 2.1 (stable) has been released. Besides the new features this version solves multiple memory management issues so I suggest you upgrade ASAP.
rodneymo
|
|
|
|
So another issue I'm finding is the program seems to quit after about an hour (longest it's ran for me is 1.5hr). The last entry is: ERROR: 2018/05/21 21:27:49 influxdb.go:39: DBDaemon could not write record batch to influxDB...
I can fire the app back up and it runs fine. Any ideas? I had that problem before. Are you running it on a laptop? Check your power settings. Nah, on an RPI. Try to increase the influx write interval eg 30s. If that doesn’t work then send me a trace together with the influx log Below is after increasing to 30s in the rig-monitor conf. Influx log (line 499 has the timeout): https://pastebin.com/qE4v6rr1rig-monitor log with console output at the end: https://pastebin.com/k55KpGbMAs you can see, this was almost 1 hour on the button. So far all have crashed at 15min intervals around an hour. New (stable) version 2.1 has been released. That issue should be permanently fixed in that version. I have it running for many hours now and both influxDB connection as well as memory usage are stable. |
|
|
|
So another issue I'm finding is the program seems to quit after about an hour (longest it's ran for me is 1.5hr). The last entry is: ERROR: 2018/05/21 21:27:49 influxdb.go:39: DBDaemon could not write record batch to influxDB...
I can fire the app back up and it runs fine. Any ideas? I had that problem before. Are you running it on a laptop? Check your power settings. Nah, on an RPI. Try to increase the influx write interval eg 30s. If that doesn’t work then send me a trace together with the influx log Below is after increasing to 30s in the rig-monitor conf. Influx log (line 499 has the timeout): https://pastebin.com/qE4v6rr1rig-monitor log with console output at the end: https://pastebin.com/k55KpGbMAs you can see, this was almost 1 hour on the button. So far all have crashed at 15min intervals around an hour. Found some memory leaks, which have been fixed in 2.1.d17. I have tested it on my raspberry PI 1 and it's been running fine for almost 3 hours now. |
|
|
|
So another issue I'm finding is the program seems to quit after about an hour (longest it's ran for me is 1.5hr). The last entry is: ERROR: 2018/05/21 21:27:49 influxdb.go:39: DBDaemon could not write record batch to influxDB...
I can fire the app back up and it runs fine. Any ideas? I had that problem before. Are you running it on a laptop? Check your power settings. Nah, on an RPI. Try to increase the influx write interval eg 30s. If that doesn’t work then send me a trace together with the influx log |
|
|
|
I tried with v 2.1d14 and this are the results: 1) python file "tplink.py" works 2) grm process says : "...response from rig decoded" 3) in grafana "power_usage" is still 0 ok. I don't have a 2.0 hw version of the plug so we need to troubleshoot
this on a trial and error basis ...
Which OS are you using?
I'm using raspbian pi@grafpi ~ $ cat /etc/os-release PRETTY_NAME="Raspbian GNU/Linux 8 (jessie)" NAME="Raspbian GNU/Linux" VERSION_ID="8" VERSION="8 (jessie)" ID=raspbian ID_LIKE=debian HOME_URL=" http://www.raspbian.org/" SUPPORT_URL=" http://www.raspbian.org/RaspbianForums" BUG_REPORT_URL=" http://www.raspbian.org/RaspbianBugs" Python 2.7.9 Is there a way to check how the script is saving the decoded info ? because the info from tplink are retrieved... We are so close! I noticed that your output of tplink.py is different from mine! Your example: You should get something like this: Sent: {"emeter":{"get_realtime":{}}}
Received: {"emeter":{"get_realtime":{"current":4.879063,"voltage":222.073153,"power":1068.699166,"total":2252.117000,"err_code":0}}}
My output: Sent: {"emeter":{"get_realtime":{}}}
Received: {"emeter":{"get_realtime":{"voltage_mv":221694,"current_ma":2360,"power_mw":518328,"total_wh":11976,"err_code":0}}}
names of parameters are different... Yes, I had already coded that part but as I cannot test it .... Could you check test version 2.1.d14a I have added extra tracing info Still 0s in grafana, but the grm message is slightly different: INFO: 2018/05/21 21:03:01 tplink.go:39: TPlink script execution succeeded! INFO: 2018/05/21 21:03:01 tplink.go:66: TPlink smart-plug response for rig03 rig decoded! version 2.0 517792 OK. I am going to fix the tracing using one of my production rigs/smart plugs. Tomorrow I'll provide you another build. Thanks a lot! Now I got values in grafana, but I cannot understand them: 1) selecting "power_usage" mean 1m >> 258 2) selecting "power_usage" last 1m >> 362 here is my dashboard >> https://snapshot.raintank.io/dashboard/snapshot/KxLC269ZD4h3x2fxtHLEgDVkKHN4nP5Eand this is my python output: Sent: {"emeter":{"get_realtime":{}}} Received: {"emeter":{"get_realtime":{"voltage_mv":226559,"current_ma":2310,"power_mw":518346,"total_wh":21482,"err_code":0}}} 226 volts OK 518 Whats OK (4 RX 570 GPU) Have you check the power detail template dashboard? Are the values showed there correct? |
|
|
|
|
Show Posts
