Skip to content

fix(whatsminer): correct inverted is_mining logic across all backends#187

Merged
b-rowan merged 5 commits into256foundation:masterfrom
ankitgoswami:fix/whatsminer-is-mining
Mar 19, 2026
Merged

fix(whatsminer): correct inverted is_mining logic across all backends#187
b-rowan merged 5 commits into256foundation:masterfrom
ankitgoswami:fix/whatsminer-is-mining

Conversation

@ankitgoswami
Copy link
Contributor

@ankitgoswami ankitgoswami commented Mar 18, 2026

Summary

  • V1/V2: parse_is_mining was inverted — the btmineroff/mineroff field means "miner is off", so "true" means mining is OFF, but the old code returned true (mining active). Added fallback extraction at /Msg/mineroff for newer firmware responding to the legacy API.
  • V3: Had no implementation (trait default always returned true). Now extracts the working field from get.device.info at /msg/miner/working.
  • Named intermediate variables (miner_off, working) to match the actual API field names so the inversion logic is self-documenting.

Test plan

  • Unit tests for parse_is_mining covering mineroff="true", mineroff="false", and missing field
  • Verified against M60SVK40 (V3 backend): pause()is_mining=false, resume()is_mining=true
  • Verified against M50SVH50 (V2 backend, fw 20240624): pause()is_mining=false, resume()is_mining=true
  • Verify against a V1-era WhatsMiner

🤖 Generated with Claude Code

@b-rowan
Copy link
Member

b-rowan commented Mar 18, 2026

{
  "STATUS": "S",
  "When": 1773871985,
  "Code": 131,
  "Msg": {
    "mineroff": "false",
    "mineroff_reason": "",
    "mineroff_time": "",
    "FirmwareVersion": "20230803.11.REL",
    "power_mode": "",
    "hash_percent": ""
  },
  "Description": ""
}

From V2 miner. V1 should be the same.

@b-rowan
Copy link
Member

b-rowan commented Mar 18, 2026

{
  "STATUS": "S",
  "When": 1773872028,
  "Code": 131,
  "Msg": {
    "mineroff": "false",
    "mineroff_reason": "",
    "mineroff_time": "",
    "FirmwareVersion": "20240924.14.Rel",
    "power_mode": "normal",
    "power_limit_set": "3300",
    "hash_percent": "0"
  },
  "Description": ""
}

Another firmware version.

@b-rowan
Copy link
Member

b-rowan commented Mar 18, 2026

{
  "STATUS": "S",
  "When": 1773872068,
  "Code": 131,
  "Msg": {
    "mineroff": "false",
    "FirmwareVersion": "20230208.18.Rel",
    "power_mode": "normal",
    "hash_percent": "0"
  },
  "Description": ""
}

Older still. This might be closer to the V1 API.

@b-rowan
Copy link
Member

b-rowan commented Mar 18, 2026

{
  "STATUS": "S",
  "When": 1773872125,
  "Code": 131,
  "Msg": {
    "mineroff": "false",
    "mineroff_reason": "",
    "mineroff_time": "",
    "FirmwareVersion": "20250214.16.1",
    "power_mode": "",
    "power_limit_set": "2147483647",
    "hash_percent": ""
  },
  "Description": ""
}

Here's the result from a V3 device.

V1/V2: The `btmineroff`/`mineroff` field means "miner is off", so
"true" means mining is OFF. The old code checked `l != "false"` which
returned true (mining) when the miner was actually paused. Also added
a fallback extractor at `/Msg/mineroff` for newer firmware responding
to the legacy API.

V3: Had no implementation (always returned true). Now extracts the
`working` field from `get.device.info` which directly indicates
whether the miner is active.

Verified against M60SVK40 hardware: pause() correctly flips
is_mining to false, resume() flips it back to true.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@ankitgoswami ankitgoswami force-pushed the fix/whatsminer-is-mining branch from 7814f51 to 9ac2e17 Compare March 18, 2026 22:19
ankitgoswami and others added 2 commits March 18, 2026 15:28
Update V1 status.json fixture to use "mineroff" at /Msg/mineroff
matching real firmware responses (confirmed across fw versions
20230208 through 20250214). Add is_mining assertion to V1 integration
test. Add V2 parse_is_mining unit tests.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Add full data parser integration tests for V2 and V3 backends with
realistic fixture data. V2 fixtures based on fw 20230803 sample data
from PR review. V3 fixtures based on real M60SVK40 API responses.

Both tests exercise the complete collect → parse pipeline and assert
on is_mining along with hashrate, wattage, pools, fans, and other
parsed fields.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@b-rowan
Copy link
Member

b-rowan commented Mar 18, 2026

I'll see if I can confirm V1 results tomorrow, we have some M20s laying around that use 1.4.0

…ct modules

Move integration tests (full pipeline with MockAPIClient) into
`integration_tests` modules, keeping unit tests (direct parser
calls) in `tests` modules. No logic changes.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@ankitgoswami ankitgoswami force-pushed the fix/whatsminer-is-mining branch from a9e63e2 to ae58cb0 Compare March 18, 2026 22:55
@ankitgoswami ankitgoswami marked this pull request as ready for review March 18, 2026 23:00
@ankitgoswami
Copy link
Contributor Author

I left the /SUMMARY/0/btmineroff extraction path in assuming it was for V1

@b-rowan
Copy link
Member

b-rowan commented Mar 18, 2026

I left the /SUMMARY/0/btmineroff extraction path in assuming it was for V1

That's my guess too, but it might be one or the other for V1/V2, I'll know more tomorrow.

@b-rowan
Copy link
Member

b-rowan commented Mar 19, 2026

{
  "STATUS": "S",
  "When": 1773930539,
  "Code": 131,
  "Msg": {
    "btmineroff": "true",
    "Firmware Version": "'20220919.15.REL'"
  },
  "Description": "whatsminer v1.4.0"
}

V1 is in fact the one with btmineroff.

- V1: use /Msg/btmineroff (confirmed by real V1 hardware, fw 20220919)
- V2: use /Msg/mineroff only (remove btmineroff fallback)
- Revert parse_is_mining to extract_map one-liner style
- Remove redundant unit tests covered by integration tests
- Update V1 status.json fixture with real V1 response data

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@b-rowan b-rowan merged commit be9ad51 into 256foundation:master Mar 19, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants