Nut on tsvinc

The UPS said 2 minutes at 95 %

Mon, 02 Nov 2026 00:00:00 +0000

My storage box and gaming PC run on a DJI Power 2000 power station used as a UPS, and a monitor on my router decides when they shut down. At 11:39:39 on 1 November, twenty-three minutes into a power cut, my alert channels got this from it:

ups dji2000-t2: LOW BATTERY, its hosts should shut down (runtime 2m0s <= 20m0s (ABC))

And the same for the third tier, against its 8-minute limit. Two minutes of runtime left on the DJI. I could see the station's display at the time. It said about 95 %.

Three shutdowns, three causes

Mon, 02 Nov 2026 00:00:00 +0000

My storage box sits on a DJI Power 2000 used as a UPS. Over two days, 1 and 2 November, it went down a few times. Some of those had an obvious reason and some had none, and every time I looked, the DJI showed about 95 %. I went in looking for one fault: something that turns a full battery into a dead machine.

There were three, and only one of them was clearly the station.

The alert about the blackout needs the internet too

Sat, 17 Oct 2026 00:00:00 +0000

Part 5 left the observer able to shut machines down and unable to tell me anything, with one item still open: an alert for an observer that stops. The alerts looked like one function. Log the line, and if a notifier is configured, hand it over:

func alertf(format string, a ...any) {
	msg := fmt.Sprintf(format, a...)
	log.Print(msg)
	if alerts != nil {
		alerts.Send(msg)
	}
}

That function hasn't changed since. The file around it, notify.go, is now 217 lines, and its tests are another 197. Most of it comes from one inconvenient fact: a message about a power cut leaves through an internet uplink, and the cut can take the uplink with it. I can keep the router running on battery. I can't vouch for anything upstream of it.

A null battery reading cleared the low-battery alarm

Fri, 16 Oct 2026 00:00:00 +0000

Here is the first version of the observer handling a station at 12 % charge, on battery, followed by a reading where the bridge couldn't decode the charge:

=== RUN   TestProbeNullSoCClearsLB
    probe_test.go:20: soc 12 -> "OB DISCHRG LB"
    probe_test.go:25: then soc null -> "OB DISCHRG", battery.charge present=false
--- PASS: TestProbeNullSoCClearsLB (0.00s)

OB DISCHRG LB is the line that makes every machine on that tier shut down. One reading later, it was gone. A null in the bridge's JSON means "I couldn't read this field", and the observer had treated it as "nothing to worry about". With no charge in the latest reading, the low-battery check had nothing to compare against its threshold. LB dropped and battery.charge vanished from the replies. In a real outage the hosts would have been stood down while the battery kept draining.

Twenty-five percent is a countdown

Wed, 14 Oct 2026 00:00:00 +0000

Update, 2026-11-02: The thresholds in this design (60, 35 and 15 % for the three tiers, with the first tier also acting after 5 minutes on battery) are no longer the deployed ones. Since 2026-11-02 all three tiers act at 15 % or 8 minutes of runtime, with no on-battery timer. Why is in Three shutdowns, three causes.

The NUT client's man page has a sentence that decided most of this design before any of it was drawn: