api v2, v2

[0xf0xx0]

supersedes: #667, plan deviated too far + was getting annoying with rebasing
discussion: #945
frontend is out of scope here
this deprecates the v1 api

new endpoints:

• /api/v2/status - live mining info, eg current pool, hashrate, power draw
  replaces /api/system/info
• /api/v2/config - miner config, eg pools, asic frequency, auto fan speed
• /api/v2/board - general board info, eg swarm color, versions (axeos, esp-idf, esp-miner), hostname
• /api/v2/asic - not much difference here

changes:

• api bools are json bools (0/1 -> false/true)
• ota and otawww endpoints are lowercase

closes: #621
closes: #945

[github-actions]

Test Results

19 tests  ±0   19 ✅ ±0   0s ⏱️ ±0s
 1 suites ±0    0 💤 ±0 
 1 files   ±0    0 ❌ ±0 

Results for commit 599b43c. ± Comparison against base commit 8dc659c.

♻️ This comment has been updated with latest results.

[mutatrum]

Can you show the output of this api?

[mutatrum]

Make pool an array, we're slowly moving towards > 2 pools, element 0 primary, 1 secondary.

#1236 adds array NVS keys, which is another puzzle piece. If we move pool into an array, that's another step closer.

[0xf0xx0]

yep! i also plan to make the fans an array as well, whats your plan on sensor names?

[0xf0xx0]

part of the motivation for this cleanup is the overloading of /info, so what do you think about something like

{
"active_pool": number /// pool idx
}

and then in /api/v2/config its

{
"pools": []pool_obj
}

? or we could have active_pool be a pool_obj so the info is more readily accessible?

[0xf0xx0]

Can you show the output of this api?

so far its closer to my latest comment on 945, still very much in progress though x3 some of the suggestions, like sensors, may need a deeper cleanup

/api/v2/status (heavy wip):

{
  "mining": {
    "hashrate": 1111.1529541015625,
    "expected_hashrate": 1173,
    "error_percentage": 0.0774148851633072,
    "best_diff": 3346084614,
    "best_session_diff": 44658088,
    "hashrate_monitor": {
      "asics": [
        {
          "total": 1111.1529541015625,
          "domains": [
            273.48809814453125,
            280.36831665039062,
            277.78823852539062,
            279.50830078125
          ],
          "error_count": 12543
        }
      ]
    },
    "shares": {
      "accepted": 9436,
      "rejected": 0,
      "rejected_reasons": []
    },
    "pool": {
      "pool_difficulty": 704,
      "pool_addr_family": 10,
      "stratum_url": "fe80::9a48:27ff:fe60:d3a1",
      "stratum_port": 5661,
      "stratum_user": "yipaxe",
      "stratum_suggested_difficulty": 512,
      "stratum_extranonce_subscribe": 0,
      "fallback_stratum_url": "10.42.0.1",
      "fallback_stratum_port": 5661,
      "fallback_stratum_user": "yipaxe",
      "fallback_stratum_suggested_difficulty": 512,
      "fallback_stratum_extranonce_subscribe": 0,
      "response_time": 16.423
    },
    "current_job": {
      "height": 925012,
      "scriptsig": "trunc",
      "network_difficulty": 152271405447597
    }
  },
  "power": {
    "power": 20.678009033203125,
    "input_voltage": 4750,
    "current": 14515.625,
    "core_voltage_actual": 1080
  }
}

[mutatrum]

One general comment: I think it would make sense to make new files for the JSON generation, that way http_server.c can be slimmed down quite a bit. This would also help with something like #1523. And I still have a websocket api in the back of my mind, which can leverage that.

[0xf0xx0]

like generating structs?

[mutatrum]

like generating structs?

No, just put the code that makes the JSON response objects separately from http_server.c.