use new miner_telemetry hashrate values and update openAPI schema - #202
Conversation
731ae9f to
59e3ffa
Compare
|
@lucasbalieiro this PR is still draft because while testing it with my Bitaxe I noticed that the 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 |
|
Ok, gonna check today. |
lucasbalieiro
left a comment
There was a problem hiding this comment.
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.

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, oripvlan, 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)
|
@lucasbalieiro what happens if you enable host networking in your Docker Desktop? Does the container see the real miner IP? |
59e3ffa to
b73698a
Compare
|
With stratum-mining/sv2-apps#615 we are unblocking this PR. I'll update this one as soon as we merge the one on |
|
stratum-mining/sv2-apps#615 has been merged, I'll update this PR soon. |
d6c4512 to
03981f9
Compare
|
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 |
|
What happens when telemetry not matched meats telemetry matching device? |
|
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. |
03981f9 to
d0eb6d1
Compare
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
d0eb6d1 to
860f3ad
Compare



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_telemetryhashrate values (measured from underlying apps throughasic-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