Chapter 1 · Accepted product intent
The product and its purpose
MainsKeeper gives a fleet view of UPS condition and site connectivity when vendor monitoring, equipment-only sites, and ad-hoc host tools do not.
The problem
Operators often run multiple UPS units across multiple sites. Coverage is uneven: some racks have paid monitoring that still does not yield a coherent fleet picture; other rooms are equipment-only with no always-on workstation; sleeping laptops are mistaken for site witnesses. When connectivity fails, history needed for reconstruction is missing unless something buffered it locally.
MainsKeeper addresses that with collectors (and constrained probes) that read UPS sources, optionally check connectivity targets, upload evidence, and surface incidents — without controlling the hardware.
Figure 1. Multi-site product overview
Takeaway: Four example sites feed one fleet narrative: sites → collectors → UPSs → powered equipment.
Related: Site · Deployments · Gallery
Example sites
The design fleet uses four places as running examples. Names and readings in the prototype are fictional demonstration data.
| Site | What it illustrates | Namespace |
|---|---|---|
| Broadwater | Primary always-on Pi witness; dual UPS (rack USB + office network); revocation/re-enroll stories | broadwater-lan |
| Home | Multiple witnesses; ordinary sleeping workstation; witness-down ≠ site contact loss | home-lan |
| Shop | ESP32 probes; site contact lost when all witnesses silent | shop-lan |
| Duplex | Local probe confirms connectivity failure; backlog replay after WAN return | duplex-lan |
The step-by-step outage in this guide is Broadwater only: collector bw-pi-01 and UPS ups-bw-rack. See the Broadwater outage walkthrough. Duplex remains a shorter site example, not a second incident story.
Intended outcomes
Operational visibility
- Fleet and per-site status
- UPS power state and power-event history
- Configurable connectivity / heartbeat monitoring
- Alerts with meaningful evidence and timelines
- Historical reconstruction after connectivity returns (buffer replay)
Battery Assurance (separate)
- Evidence of observed battery-backed operation and reported tests
- Installation identity and replacement history
- Findings that stay open until documented resolution
Current operation (charge, estimate, freshness) is not the same as backup-capability evidence.
Figure 2. System context and external boundaries
Takeaway: Requests and returned data meet the UPS, the site network, operators, notify channels, and monitors. A scrape returns current gauges only.
Related: Monitoring-only · Glossary
Technical detail — MVP boundary
Accepted Monitoring only: no UPS self-test initiation, discharge tests, shutdowns, outlet switching, or other hardware writes. CLI service administers the collector service only.
Accepted UPS-monitoring and site-heartbeat roles are independently configurable. An ordinary sleeping workstation is not an expected always-on site witness.
Proposed Signed installers, native services, firmware, and production APIs remain implementation work.