-
Notifications
You must be signed in to change notification settings - Fork 33
Multi UPS Monitoring Guide
This page is dedicated to Multi-UPS operations in Nutify. It explains how multi-target monitoring works, how target context is resolved, and how to operate safely day-to-day.
Multi-UPS mode lets one Nutify instance monitor multiple UPS targets, local and/or remote, with independent target configuration.
Typical use cases:
- home lab with multiple UPS devices
- branch/remote UPS monitoring from one dashboard
- mixed topology (local primary + remote additional targets)
-
Target: one UPS endpoint (
ups@host). - Primary target: default fallback target.
- Active target: current UI context selected in TopBar.
- Fleet view: aggregate overview across all targets.
Target-aware pages/APIs resolve context in this order:
- explicit
target_idrequest override - session active target
- primary enabled target fallback
Operational best practice:
- when scripting APIs, pass explicit
target_id
When multiple enabled targets exist:
- topbar target selector is active
- values in topbar represent selected target
- target-scoped tabs (Notify, Reporter, PowerFlow) follow selected target
Daily rule:
- verify target in TopBar before any write action
Open Multi-UPS Monitoring from topbar action.

Use fleet view to:
- compare target health quickly
- detect offline/degraded targets
- triage where to investigate first
Do not use fleet view as replacement for per-target detailed configuration.
Multi polling runs per target.
Behavior goal:
- one target failure should not block polling of other targets
Practical impact:
- partial fleet incidents remain isolated
- healthy targets continue updating normally
Use System -> Advanced -> NUT Manager to:
- add/edit/remove targets
- enable/disable targets
- set primary target
- force poll-now
After target changes:
- verify target appears in topbar selector
- switch target and verify page data updates
- validate notifications/reports routing per target
Use this pattern:
- configure global providers once (
System -> Provider) - select target A and configure Notify/Reporter
- switch to target B and configure Notify/Reporter
- repeat for all critical targets
Never assume target B inherits target A routing automatically.
In mixed scenarios:
- primary target is local
- additional targets are often remote
Best practice:
- validate local target first
- add remote targets one by one
- test each target immediately after save
State and inventory:
GET /api/multi-nut/stateGET /api/multi-nut/targets
Target control:
POST /api/multi-nut/targets/<id>/poll-nowPOST /api/multi-nut/targets/<id>/primary
Context session:
GET /api/multi-nut/active-targetPOST /api/multi-nut/active-target
Reports:
GET /api/multi-nut/report
- open fleet view and check status summary
- switch through critical targets in topbar
- inspect Power/Battery/Voltage for anomalies
- inspect Events for each critical target
- validate delivery channels on high-priority targets
If one target is failing:
- confirm only that target is degraded
- run poll-now for affected target
- inspect connection credentials and host reachability
- verify events/logs for target-specific errors
- keep other targets running and monitored
- editing target-scoped settings on wrong active target
- confusing fleet view with active-target detailed context
- not setting a reliable primary target fallback
- adding remote target with wrong UPS identifier format
Multi setup is healthy when:
- all expected targets appear in topbar selector
- target switching refreshes dashboard context correctly
- fleet page reflects consistent status per target
- target-specific Notify/Reporter settings are persisted and working
- Main + Topbar + Multi-UPS Guide
- Multi-UPS Monitoring Guide
- Sidebar Data Pages Guide
- Reports and Notifications End-to-End Guide