Unusual, erratic behavior of Uninterruptible Power Supplies (UPS) during short-lived power fluctuations (power blips) is far from uncommon in network management (Server/Client) architectures where multiple NAS devices share a single UPS. Below is a detailed explanation:
1. Regarding inconsistent alert notifications
The underlying UPS management of the TOS system is built on the industry-standard Linux Network UPS Tools (NUT) framework. In this master-slave (Server/Client) mode, devices directly connected to the UPS serve as the Server (Master), while all other devices act as Clients (Slaves). The root cause of the single-device alert scenario likely stems from a race condition triggered by the interplay between polling time offsets and the event debounce mechanism:
- Characteristics of transient power blips: A grid flicker or voltage dip typically lasts only a few milliseconds to 1-2 seconds. The UPS detects the anomaly and switches to battery mode (On Battery, OB), but returns to mains power (Online, OL) within an extremely brief window.
- Polling Intervals: The UPS driver and the upsmon service on network clients read status periodically rather than as real-time streaming data.
- F4-424 Pro (the client that sent alerts): Its local upsmon process initiated a network query exactly during the narrow time window when the UPS briefly switched to OB state. It captured this transient state, prompting the local notification center to immediately send an email alert to the user.
- F6-424 (the client that did not send alerts): Its polling cycle may have been offset by several seconds relative to this window. By the time it requested status data from the server, the UPS had already returned to OL (mains power), so it mistakenly judged the entire event as normal.
- F4-425 Plus (the directly connected master server that did not alert): As the master server, the NUT service is designed with debounce/filtering logic for directly captured hardware-level events. For example, a state must remain stable for a full X seconds, or multiple consecutive polling results must match, before it is classified as a genuine "power outage event" and triggers upper-layer alerts. This was originally intended to prevent "alert storms" caused by minor grid noise, but during extremely short blips, the server filtered out the transient event. Meanwhile, network clients happened to capture the instantaneous state at the boundary without debounce buffering, creating this information asymmetry.
2. Why do the three devices show identical battery percentages but different remaining runtimes?
Identical battery percentage: The remaining battery percentage (% Remaining) is an absolute physical value directly measured and reported by the UPS's internal firmware (e.g., 100%). The server reads this data and broadcasts it unchanged to all network clients, so the figures are fully consistent.
Different remaining runtimes and the server cannot display them:
- Many UPS devices do not report accurate remaining runtime to the host system via the USB interface, or their built-in runtime estimation is imprecise, meaning the UPS server cannot directly retrieve and display this field.
- When official UPS remaining runtime data is unavailable in the NUT framework, each client device activates a local estimation mechanism. The system calculates usable runtime based on the NAS's hardware model, number of drive bays, system load, and built-in power consumption model.
- The F4-424 Pro, F6-424, and F4-425 Plus use distinct CPU architectures, motherboards, and different numbers of hard drives, so their local power draw varies significantly. Even with the same 100% battery level, their calculated supported runtimes will inevitably differ substantially.
Additionally, the three devices share UPS status via NIC #2. Please check whether the switch or network device connected to this port is also connected to the protected output of the same UPS. If the switch restarts during a transient power outage, it may also cause clients to trigger false alerts due to "network disconnection or expired data".
