2GT-RichandClaude Opus 5
6c5b8ac21a
Closes #120. The Tower and band changes panel listed every handover, newest first, growing without bound. On a link that hands over several times a day it reads as a wall of near-identical rows — it answers what happened, but not what the pattern is, which is the question an operator actually has. Dwell totals now sit above it: how long the modem has spent on each band and on each cell, over 24 hours, 7 days or 30 days, ordered by time spent so the answer is the first row rather than something to be worked out. Visit counts sit alongside, because six brief stays and one long one are different situations that share a total. No new collection. History is already written on every change, so dwell is the interval between consecutive events — the same reconstruction used for WiFi roaming sessions. Three decisions worth recording. **The state in force when the window opened is included.** Without it, a link that changed once yesterday would report a few minutes of dwell across seven days, having silently dropped everything before the first change in range. The last event *before* the window is fetched specifically to anchor that first stretch. **Aggregated carriers each count for the whole stretch.** A period on B1 and B3 together credits both with the full duration, so band shares describe how much of the window each band was in use rather than dividing it between them. Totals can exceed 100%, which is the honest description of carrier aggregation rather than a rounding artefact. **Absence is reported as absence.** A segment whose cell was never reported is excluded rather than attributed to "unknown", a device with no history reads as "no changes recorded" rather than an empty panel, and a window longer than our records says so instead of implying the quiet period was real. Logic lives in utils/lteDwell.ts with 17 tests. Verified end to end against seeded history matching the reporter's own pattern: a 24-hour window covered exactly 24 hours, B3 correctly showed 19 of them against a five-hour stretch without it, cell totals summed to the window, and a 30-day request over 9 days of records reported itself truncated. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
MikroTik Manager documentation
Reference material for people already running the platform. If you are still deciding whether to try it, the project README is the better starting point.
| Document | Covers |
|---|---|
| Configuration | Environment variables, secret management and key rotation |
| Change Guard and Config Health | How the safety system works, its settings, and what to expect when it fires |
| Alerting | Alert rules, delivery channels, webhooks, scheduled reports, maintenance windows |
| Single sign-on (OIDC) | Identity provider setup, group-to-role mapping, break-glass behaviour |
| CAPsMAN | How centrally provisioned access points are modelled, and current limits |
| Cellular (LTE) | Signal, carriers, tower movement, and the data-cap reset SMS |
| SSH keys | Per-device keypairs, rotation, and what installing one costs |
| Bulk commands | Running one command across a fleet, in waves |
| Polling and scaling | Poller health, headroom, tuning, and clearing a backlog |
| API and automation | Scoped tokens, authentication, and driving the platform from scripts |
| Architecture | How the system is put together, for contributors |
Conventions used here
- Settings in the UI are stored in the database and apply without a restart.
- Environment variables live in
.envand require a container restart to change. - Anything described as read-only makes no writes to your devices.
Which version is this?
These pages describe a specific release, shown in the header. The platform ships frequently, so if something here does not match what you see, check that the version you are running matches the version you are reading.