Getting Error and exit of NPM: TypeError: Cannot call method 'indexOf' of undefined

[jedimstr]

I git pulled after your commit on loginterval and now I get the following trying to start npm:

> miner-dashboard@0.2.0 start /home/jedimstr/miner-dashboard
> npm install --production && grunt compile && node app

npm WARN package.json rickshaw@1.4.6 No repository field.
Running "handlebars:compile" (handlebars) task
File build/compiledTemplates.js created.

Running "copy:images" (copy) task
Created 1 directories, copied 1 files

Running "browserify:main" (browserify) task
>> Bundled build/public/javascripts/main.js

Done, without errors.
connect.multipart() will be removed in connect 3.0
visit https://github.com/senchalabs/connect/wiki/Connect-3.0 for alternatives
connect.limit() will be removed in connect 3.0
Express and Websocket server listening on port 3000

/home/jedimstr/miner-dashboard/lib/modules/miners/bfgminer.js:141
            avgHashrate = avgHashrateKey.indexOf('GHS') === 0 ? response.SUMMA
                                         ^
TypeError: Cannot call method 'indexOf' of undefined
    at module.exports.Module.extend.handleSummaryResponse (/home/jedimstr/miner-dashboard/lib/modules/miners/bfgminer.js:141:42)
    at /home/jedimstr/miner-dashboard/lib/modules/miners/bfgminer.js:51:41
    at Socket.<anonymous> (/home/jedimstr/miner-dashboard/lib/modules/miners/bfgminer.js:109:21)
    at Socket.EventEmitter.emit (events.js:117:20)
    at _stream_readable.js:920:16
    at process._tickCallback (node.js:415:13)

npm ERR! miner-dashboard@0.2.0 start: `npm install --production && grunt compile && node app`
npm ERR! Exit status 8
npm ERR! 
npm ERR! Failed at the miner-dashboard@0.2.0 start script.
npm ERR! This is most likely a problem with the miner-dashboard package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     npm install --production && grunt compile && node app
npm ERR! You can get their info via:
npm ERR!     npm owner ls miner-dashboard
npm ERR! There is likely additional logging output above.
npm ERR! System Linux 3.8.13-bone32
npm ERR! command "/usr/local/bin/node" "/usr/local/bin/npm" "start"
npm ERR! cwd /home/jedimstr/miner-dashboard
npm ERR! node -v v0.10.26
npm ERR! npm -v 1.4.3
npm ERR! code ELIFECYCLE
npm ERR! 
npm ERR! Additional logging details can be found in:
npm ERR!     /home/jedimstr/miner-dashboard/npm-debug.log
npm ERR! not ok code 0

[selaux]

Can you check wether there is a GHS 10s or MHS 10s key in the summary response of your miner?

[jedimstr]

None of them have 10s nodes... but CGMiner 4.2.0 has both GHS 5s and MHS 5s while BFGMiner 3.10.0 has just MHS 5s.

Here are some samples:

BFGMiner 3.10.0:

{
  "STATUS": [
    {
      "STATUS": "S",
      "When": 1395586057,
      "Code": 11,
      "Msg": "Summary",
      "Description": "bfgminer 3.10.0"
    }
  ],
  "SUMMARY": [
    {
      "Elapsed": 4850,
      "MHS av": 32826.693,
      "MHS 5s": 33150.317,
      "Found Blocks": 0,
      "Getworks": 292,
      "Accepted": 342,
      "Rejected": 22,
      "Hardware Errors": 918,
      "Utility": 4.231,
      "Discarded": 1794,
      "Stale": 0,
      "Get Failures": 1,
      "Local Work": 67449,
      "Remote Failures": 0,
      "Network Blocks": 8,
      "Total MH": 159198989.6341,
      "Diff1 Work": 36062.00000000,
      "Work Utility": 446.157,
      "Difficulty Accepted": 34497.96582759,
      "Difficulty Rejected": 1998.15876137,
      "Difficulty Stale": 0E-8,
      "Best Share": 24086,
      "Device Hardware%": 2.4824,
      "Device Rejected%": 5.5409,
      "Pool Rejected%": 5.4750,
      "Pool Stale%": 0.0000
    }
  ],
  "id": 1
}

CGMiner 4.2.0:

{
  "STATUS": [
    {
      "STATUS": "S",
      "When": 1395586378,
      "Code": 11,
      "Msg": "Summary",
      "Description": "cgminer 4.2.0"
    }
  ],
  "SUMMARY": [
    {
      "Elapsed": 6541,
      "GHS 5s": 200.10,
      "GHS av": 200.77,
      "Found Blocks": 0,
      "Getworks": 382,
      "Accepted": 4205,
      "Rejected": 142,
      "Hardware Errors": 907,
      "Utility": 38.57,
      "Discarded": 68031,
      "Stale": 60,
      "Get Failures": 1,
      "Local Work": 251796,
      "Remote Failures": 0,
      "Network Blocks": 11,
      "Total MH": 1313139005.8060,
      "Work Utility": 2792.84,
      "Difficulty Accepted": 289780.66048733,
      "Difficulty Rejected": 13685.24456317,
      "Difficulty Stale": 93.33866329,
      "Best Share": 141574,
      "Device Hardware%": 0.2970,
      "Device Rejected%": 4.4951,
      "Pool Rejected%": 4.5083,
      "Pool Stale%": 0.0307,
      "Last getwork": 1395586378,
      "MHS av": 200768.31,
      "MHS 5s": 200104.29
    }
  ],
  "id": 1
}

CGMiner 3.2.1 (old versions like this are used extensively for Scrypt Mining and as originating fork for SGMiner, etc.):

{
  "STATUS": [
    {
      "STATUS": "S",
      "When": 1395586342,
      "Code": 11,
      "Msg": "Summary",
      "Description": "cgminer 3.2.1"
    }
  ],
  "SUMMARY": [
    {
      "Elapsed": 95956,
      "MHS av": 2.77,
      "Found Blocks": 0,
      "Getworks": 4397,
      "Accepted": 7806,
      "Rejected": 201,
      "Hardware Errors": 0,
      "Utility": 4.88,
      "Discarded": 2009,
      "Stale": 0,
      "Get Failures": 1,
      "Local Work": 132393,
      "Remote Failures": 0,
      "Network Blocks": 1926,
      "Total MH": 265704.9641,
      "Work Utility": 2563.26,
      "Difficulty Accepted": 3996672.00000000,
      "Difficulty Rejected": 102912.00000000,
      "Difficulty Stale": 0E-8,
      "Best Share": 11545709
    }
  ],
  "id": 1
}

[selaux]

Damit, all these different API versions always break everything :wink:. Can you test with current master?

[selaux]

PS: It's okay that they dont have 10s nodes in fact they should have loginterval + s properties, but I didn't factor in if the properties is missing (in early API versions).

[jedimstr]

It's working now! Thanks!

BTW- the charts are not as flat now and are nicely active. Any way to configure the density/granularity of the timeframe shown?

[selaux]

Yep, but I see now that with the new more volatile hashrates the algorithm that I use produces, lets say, suboptimal results. I need to adapt it some more... Anyways its configurable per miner through the config file:

historicalDataStoredFor: 24 * 60 * 60 * 1000, // display the last 24 hours
historicalDataPrecision: 15 * 60 * 1000 // with a granularity of 15 minutes

[selaux]

I'll have another look at the algorithm that stores data with a certain precision this evening...

[selaux]

I renamed the configuration properties (and default values) in cb94e1f67535ece9ce0a8a83008fec321dca12ff: They now are:

chartTimespan: 24 * 60 * 60 * 1000,
chartPrecision: 5 * 60 * 1000