Page 1 of 1
[Discussion] ODD Behavior UPS event
Posted: 19 Jun 2026, 18:38
by rfbjr
Background:
F4-425 Plus has the UPS connected via USB cable (NIC #2 192.168.3.1)
F4-424 Pro (NIC #2 192.168.3.2) TNAS UPS pointed to the 192.168.3.1
F6-424 (NIC #2 192.168.3.3) TNAS UPS pointed to the 192.168.3.1
Had power blip
Only the F4-424 Pro notified of the UPS battery/AC switch, not the F4-425 Plus which has the UPS directly attached to it.
No indication about anything on the F6-424 or F4-425 Plus

Re: [Discussion] ODD Behavior UPS event
Posted: 19 Jun 2026, 19:21
by Gremlin
I notice that all 3 devices show same % remaining, but clients have different times remaining. (Can't see time remaining on ups server}.
{FYI, I noticed the other day that we had a minor power fluctuation here. It sounded the ups alarm but did not trigger any response in any of my Tnas devices (3 off, likewise tied to single server) although it was enough to reset every electric clock in the house!
Re: [Discussion] ODD Behavior UPS event
Posted: 19 Jun 2026, 22:24
by EriChan
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".
Re: [Discussion] ODD Behavior UPS event
Posted: 19 Jun 2026, 23:15
by rfbjr
I will double check the 2.5g switch for the backup/UPS network is on the UPS, I believe so. Maybe this time I'll label the power supplies.
As for the rest thank you for the detailed explanation.
Update: All three network switches are on UPS.
I think it's time to give the whole process a test, I'll crawl under the table (groan) and pull the power cable from the UPS and watch what happens.
In theory all should shutdown after 10 minutes. (That's what I have the controlling NAS set to).
Actually there should be two tests, pull the plug, but restore the power say after 5min. All devices should indicate back on line power and keep chugging along.
Re: [Discussion] ODD Behavior UPS event
Posted: 26 Jun 2026, 08:32
by nikolasalexander1
It looks like a minor communication delay or a network broadcasting issue between the master NAS (the one directly connected via USB) and the slave units. Sometimes when a power blip is too short, the master device switches back to AC before it successfully broadcasts the shutdown or battery event to the other IP addresses on the network.
You might want to check the polling interval or the specific network slave settings under the UPS configurations on each unit to see if reducing the handshake timeout helps them sync better.
Re: [Discussion] ODD Behavior UPS event
Posted: 27 Jun 2026, 00:16
by rfbjr
This is the only screen I know of on the NAS for UPS settings.

Re: [Discussion] ODD Behavior UPS event
Posted: 27 Jun 2026, 02:29
by Gremlin
rfbjr wrote: ↑27 Jun 2026, 00:16
I reported his other post for advertising. I guess he omitted a link in this one

Re: [Discussion] ODD Behavior UPS event
Posted: 27 Jun 2026, 02:33
by rfbjr
Gremlin wrote: ↑27 Jun 2026, 02:29
rfbjr wrote: ↑27 Jun 2026, 00:16
I reported his other post for advertising. I guess he omitted a link in this one
