Power on tsvinc

The DJI went silent for four hours

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

Part 4 ended on a rule for the observer, the Go service on my router that turns two power stations' readings into NUT (Network UPS Tools) status for the machines they keep running: a DJI that stops answering for minutes is an alert in its own right, never a sign that the grid is fine. On 20 October the DJI Power 2000 stopped answering at about 13:10. It answered again a little before 18:00, after I power-cycled it. While the grid was up, nothing alerted me to the silence.

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.

The pin template was for a different plug

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

The smart plug's vendor app put its energy monitoring behind a subscription. The metering chip inside measures voltage alongside current and power all the same, whatever the app agrees to show. I wanted that voltage. Read off a plug on wall power, it says whether the grid is up, and my power-station UPS needed exactly that: a second opinion on the grid from something not behind a battery.

So the plug had to leave Tuya's firmware for OpenBeken, an open firmware for the Beken chips in most Tuya plugs. That took one evening. Getting the pins right took the next day, because the template I borrowed was for a different plug, and the plug's own leftover settings were the only thing that knew.

The DJI's grid flag is labeled charge type

Thu, 15 Oct 2026 00:00:00 +0000

Update, 2026-11-02: The station's minutes field has a second meaning. Byte 4 of its battery record (tag 0x3020) is a time type, and while it is 1 the minutes are a recharging time, the time to full charge, not a runtime. The bridge now leaves runtime_min out whenever that byte says recharging, and the observer ignores the field while input power flows. The story is in The UPS said 2 minutes at 95 %.

Secure session ready. Battery: ?

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

Porting a key exchange from Python to C++ should be the boring part. The Python works, it is already validated against this exact station, and mbedTLS ships every primitive it uses: MD5, AES-CBC, P-256, ECDSA, ECDH. Translate, compile, flash. The first run on the ESP32 went along with that, right up to the last line:

found AC180<redacted> XX:XX:XX:XX:XX:XX rssi=-57
connected, mtu=517
KEX: challenge answered
KEX: challenge accepted
KEX: pubkey sent
KEX: pubkey sent
KEX: secure session ready
handshake 1913 ms
RESULT BATTERY_SOC=? DC_OUTPUT_POWER=? AC_OUTPUT_POWER=?

Every step of the handshake reported success. Then came the reads, the part that was supposed to be easy, and the first three came back as question marks. The capture ended there.

The power went out twice. My UPS log saw it once.

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

Thirty lines of log, one outage. Twenty-two lines on grid, seven on battery, one back on grid. Clean, readable, and short by one event: the plug came out of the wall twice.

The setup itself works. A BLUETTI AC180 portable power station sits between the wall and my workstation as a UPS. Linux reads it over Bluetooth LE, through an encrypted link, with no account and no pairing, in about nine seconds per read. What it can't do is tell you about anything that happens between two of those reads. Neither can anything else built on polling. This one put it in writing.

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: