My Mesh: make repeater cards compact and fix misleading activity and health metrics #304

Summary

Improve the My Mesh repeater cards so they answer three practical questions: Has this repeater been active? Is it being used? Has anything changed?

The current cards devote too much space to observer names, while some prominent metrics and the activity chart need clearer meaning or a corrected data source.

Related: #262 covers observer-specific cards; #76 covers direct-RF attribution and the meaning of "Heard by". This issue focuses on repeater cards and should coordinate with, not duplicate or silently decide, those changes.

Evidence

User screenshots of staging My Mesh on 5 October 2026 show:

• Dokk1 with 42 observers and Kunsthall with 49: the full "Heard by" lists dominate the cards and stretch adjacent cards into large empty areas.
• A chart labelled 24h activity, despite being built from h.recentPackets, not complete hourly activity totals.
• Prominent values such as SNR · Good and Avg hops 10.0, without explaining attribution, sample scope or what they imply for the repeater.

Code inspection found that public/home.js passes h.recentPackets to buildSparkline(), which buckets those samples into 24 hours. GetNodeHealth() in cmd/server/store.go caps recentPackets at 20. On 5 October, Dokk1's 20 samples covered only approximately 55 minutes, making the rest of the day look empty. A read-only recheck on 6 October confirmed that the deployed frontend still uses this input and that the health response still contains only 20 recent packets.

Requested improvements

1. Correct the 24-hour activity chart — first priority

• Use actual hourly aggregates for the selected rolling 24-hour window, not the latest-packet preview.
• State what is counted: unique transmissions associated with the node, observations, or separately validated relay activity. These must not be interchangeable.
• Show counts and time ranges in accessible labels/tooltips.
• Distinguish known zero activity from missing/incomplete coverage. Do not imply a complete quiet day when the available history is incomplete.

2. Make the cards compact and consistent — first priority

• Show the observer count, a short preview (for example three names), and a View all action instead of listing every name inline.
• Let the full list open in a detail view or expandable panel without forcing all neighbouring cards to become excessively tall.
• Keep the status, key metrics, chart and actions easy to scan on desktop and mobile. Long names must not overflow; disclosure must work with keyboard and touch.

3. Explain the activity/status evidence

• Show Last own advert and Last attributed relay activity separately where supported by the available evidence.
• Explain which evidence drives the status badge. Recent observed activity is not proof of continuous uptime or a currently online device.
• Preserve uncertainty in relay identification; ambiguous short-prefix matches must not become a confident green status.
• Reuse existing liveness rules rather than creating contradictory thresholds just for the home page.

4. Avoid presenting downstream SNR as repeater signal quality

• The representative observation's SNR can describe the last transmitter heard by an observer, not the repeater named on the card; see Node "Heard By" card: decide whether to show direct-RF observers (defer) #76.
• Only present a measurement as direct signal from this repeater when its attribution supports that claim.
• Until the attribution decision in Node "Heard By" card: decide whether to show direct-RF observers (defer) #76 is made, clearly explain the existing metric or remove the repeater-quality judgement such as Good. Do not silently redefine shared health API metrics for other consumers.

5. Prefer clearly defined, useful traffic metrics

• Prefer a clearly labelled rolling-24-hour traffic count over an unexplained "Packets today" counter. State the population and time window.
• Consider comparison with the preceding 24 hours when comparable history exists; unavailable history must not be interpreted as zero, and a zero baseline must not produce an invalid percentage.
• De-emphasize or move Avg hops into details unless its route/sample meaning is explained. It must not suggest the repeater's distance from the user or a direct measure of repeater health.
• Do not label all node-associated traffic as traffic forwarded by that repeater unless forwarding attribution is established.

6. Show observed zero-hop and flood advert intervals

• Show the repeater's observed zero-hop advert interval and observed flood advert interval separately. MeshCore has independent schedules for local zero-hop and flooded adverts; do not merge their timestamps into one cadence.
• Derive each interval from distinct, confidently attributed adverts of the selected node within a stated observation window. Show the latest advert of each type and the sample count. Use a robust interval such as the median gap, not a configured-schedule claim; lost receptions and an incomplete observer view can make an observed interval longer than the device's actual setting.
• Show insufficient data rather than an interval when there are too few distinct adverts or incomplete history. Do not infer zero-hop from a flood advert merely because it was heard directly, or infer flood from relay observations of a direct advert.
• Keep the card compact: a short two-line cadence summary or an accessible detail view is enough. Reuse the existing node-health request and deduplicate observations of the same advert.

Suggested delivery order and constraints

1. Correct chart data and compact the observer list.
2. Improve status evidence and traffic labels.
3. Add separate observed zero-hop and flood advert intervals.
4. Add signal-quality refinements coordinated with Node "Heard By" card: decide whether to show direct-RF observers (defer) #76.

Reuse existing analytics/aggregates where suitable. Keep computation bounded, avoid fetching raw histories or adding a request per metric/card, and avoid new full-store scans under locks. Preserve current My Mesh selections, node/health/packet navigation and the observer-card work in #262. No firmware-role, ingestion or retention changes are requested.

Acceptance criteria

• A fixture with more than 20 transmissions spread across a day produces correct hourly counts, including earlier hours absent from the latest-packet preview.
• Window boundaries, missing coverage, empty data and duplicate observations are tested against the documented counting semantics.
• Cards with 0, 1 and 50+ observers remain compact; the full list is reachable by keyboard and touch without losing names.
• Advert and relay activity are distinguishable, with unknown/ambiguous evidence handled without false certainty.
• Signal and hop labels do not imply unsupported direct-RF quality or distance.
• Any previous-period comparison uses like-for-like windows and handles missing/zero baselines honestly.
• Desktop and mobile browser tests cover long names, mixed repeater/observer cards and existing navigation. Use synthetic fixture identities, not production identifiers.
• Zero-hop and flood advert intervals are computed separately from distinct own adverts, with a stated window, sample count and coverage caveat.
• Missing or insufficient advert history is not displayed as a normal configured interval; tests cover route classification and duplicate observations.
• The implementation documents its aggregation/query cost and does not introduce per-card full-history scans.