Skip to content

use new miner_telemetry hashrate values and update openAPI schema - #202

Merged
GitGab19 merged 1 commit into
stratum-mining:mainfrom
GitGab19:update-hashrate-monitoring
Jul 27, 2026
Merged

use new miner_telemetry hashrate values and update openAPI schema#202
GitGab19 merged 1 commit into
stratum-mining:mainfrom
GitGab19:update-hashrate-monitoring

Conversation

@GitGab19

@GitGab19 GitGab19 commented Jun 29, 2026

Copy link
Copy Markdown
Member

This PR updates the openAPI schema to the latest changes introduced by stratum-mining/sv2-apps#553 and stratum-mining/sv2-apps#615.

It also makes dashboard use miner_telemetry hashrate values (measured from underlying apps through asic-rs) instead of the vardiff estimated ones.

In case the telemetry is not working (e.g. a miner is not properly supported by asic-rs), we fallback to the vardiff estimated value.

Closes #188
Closes #222
Closes #223

@GitGab19
GitGab19 marked this pull request as draft June 29, 2026 17:47
@GitGab19
GitGab19 force-pushed the update-hashrate-monitoring branch from 731ae9f to 59e3ffa Compare June 29, 2026 20:48
@GitGab19
GitGab19 marked this pull request as ready for review June 30, 2026 00:58
@GitGab19
GitGab19 marked this pull request as draft June 30, 2026 01:15
@GitGab19

Copy link
Copy Markdown
Member Author

@lucasbalieiro this PR is still draft because while testing it with my Bitaxe I noticed that the miner_telemetry values where not retrieved from both JDC and tProxy (expect for the make and model fields).

I won't have access to my Bitaxe for the next days, so I would appreciate your help on figuring out what's going on here.

I still don't know if the issue is in our apps, in the docker images, or related to docker networking stuff.

What I know is that if you run apps on our current main, it works like a charm, and all the values are correctly retrieved, so it seems there's a difference between the apps and the docker images..

@lucasbalieiro

Copy link
Copy Markdown
Collaborator

Ok, gonna check today.

@lucasbalieiro lucasbalieiro left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just posting a summary of what we've been discussing:

when tProxy/JDC runs inside a Docker container using the default bridge network, the peer IPs it observes are NATed by Docker. As a result, multiple ASICs appear to originate from the same bridge gateway IP instead of their actual LAN IP. The screenshot below confirms this behavior.
image

This is expected for bridge networking. See Docker's networking documentation: https://docs.docker.com/engine/network/port-publishing/.

The issue is that we need the miner's real LAN IP to make the HTTP request that fetches its telemetry.

This is probably not an issue for Umbrel, since we use network_mode: host, which avoids the bridge NAT. However, we also need to support Windows and macOS, where host networking is not a portable option.

I can think of a few approaches:

  • Keep using host networking where available and accept a different implementation on Windows/macOS.
  • Investigate Linux specific networking options such as direct routing, macvlan, or ipvlan, although these are not portable to Docker Desktop and would increase deployment complexity.
  • Perform a LAN scan to discover miners, fetch telemetry from each discovered IP, and then correlate the results using user_identity.

At the moment, the LAN scan seems like the most portable solution. The downside is that it duplicates logic that we intended to centralize in the sv2 apps, since sv2-ui would have to rediscover miners instead of relying on tProxy/JDC. (and sv2-ui is also running inside docker)

@GitGab19

GitGab19 commented Jul 8, 2026

Copy link
Copy Markdown
Member Author

@lucasbalieiro what happens if you enable host networking in your Docker Desktop?

Does the container see the real miner IP?

@lucasbalieiro

Copy link
Copy Markdown
Collaborator

currently exploring a new way.
using Docker Desktop version 4.34 and later

enabling Host Network manually. This comes disabled by default:

image

@GitGab19

GitGab19 commented Jul 17, 2026

Copy link
Copy Markdown
Member Author

With stratum-mining/sv2-apps#615 we are unblocking this PR.

I'll update this one as soon as we merge the one on sv2-apps.

@GitGab19

Copy link
Copy Markdown
Member Author

stratum-mining/sv2-apps#615 has been merged, I'll update this PR soon.

@GitGab19
GitGab19 force-pushed the update-hashrate-monitoring branch 2 times, most recently from d6c4512 to 03981f9 Compare July 22, 2026 16:39
@GitGab19

Copy link
Copy Markdown
Member Author

Alright guys, I updated the PR now, and it's finally ready for review and testing.

Here a recording of the final shape, where I connected my Bitaxe which is broken, and the UI correctly shows (unfortunately :P) 0 H/s:

Screencast.From.2026-07-22.18-30-10.mp4

@GitGab19
GitGab19 marked this pull request as ready for review July 22, 2026 16:41
@pavlenex

Copy link
Copy Markdown
Contributor

What happens when telemetry not matched meats telemetry matching device?
For Bitaxe try just changing thermal paste.

@lucasbalieiro lucasbalieiro left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm running from inside the sv2-ui docker image and it is getting the information needed.

Image

I'm gonna start to package this to the umbrel to see if we have something to improve before marking a release with this change.

@pavlenex

Copy link
Copy Markdown
Contributor

Lovely, I assume this one is good to go then.

@lucasbalieiro

Copy link
Copy Markdown
Collaborator

Lovely, I assume this one is good to go then.

No, please wait a few more hours. I've found a little problem. I'll probably be able to send a patch tomorrow morning (AFK right now).

I'm still unsure if the problem is related to the PR.

Comment thread server/src/config-generator.ts
@GitGab19
GitGab19 force-pushed the update-hashrate-monitoring branch from 03981f9 to d0eb6d1 Compare July 27, 2026 12:18
@GitGab19
GitGab19 requested a review from lucasbalieiro July 27, 2026 12:19
Use the miner telemetry additions from stratum-mining/sv2-apps#615 to optionally configure management-interface discovery and surface matched telemetry in the dashboard.

- accept an optional private miners' LAN CIDR during setup/settings and write [miner_telemetry] cidrs for Translator and JDC only when provided
- set Translator/JDC monitoring cache refresh to 5 seconds for fresher dashboard telemetry
- update OpenAPI/generated types for management_ip, miner_telemetry_status, and client_kind
- show management IP, telemetry status, and miner telemetry columns in the worker table
- use client_kind to exclude Translator Proxy aggregate rows while keeping vardiff hashrate fallback

Upstream: stratum-mining/sv2-apps#615
@GitGab19
GitGab19 force-pushed the update-hashrate-monitoring branch from d0eb6d1 to 860f3ad Compare July 27, 2026 13:04
@lucasbalieiro

Copy link
Copy Markdown
Collaborator

able to make it work on Umbrel

image

@lucasbalieiro lucasbalieiro left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK 860f3ad

@GitGab19
GitGab19 merged commit 4494e86 into stratum-mining:main Jul 27, 2026
5 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.

JDC/tProxy config updated in PR #615 Monitoring API updated in PR #615 Monitoring API updated in PR #553

3 participants