Esp32 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 %.

Pulling plugs on purpose

Sun, 18 Oct 2026 00:00:00 +0000

A test that passes tells you the thing works. That is the reading everyone defaults to, and the first power-bank test of the ESP32 bridge was a clean example of why it's wrong.

The bridge from the second UPS post runs off a USB power bank, which charges from the wall. The worry was simple: when the grid goes and the power bank stops charging, does it hold its output steady, or does the board reboot right at the start of the outage it is supposed to report? I cut the power bank's charging, and the board's uptime counter kept going, from 14160 seconds to 14180. No reboot.

The guard rails that said no

Sun, 18 Oct 2026 00:00:00 +0000

Script Error: failure: mountpoint usb1-part1 is used by log->file:/blockylog.0.txt (/disk/set *0 = *0) (/disk/set; line 7) (:import; line 1)
ABORT: whole SSD still shared (smb/media entries: 2)

That was the deploy script for the MQTT broker on the router, stopping itself at step 0. Nothing after that line ran: no router backup, no password file, no broker. The second line had been added to the script two minutes earlier.

The project behind the power station bridge hit several refusals like this one in a single day. Some came from scripts, one from a permission check in my tooling, one from a review note. Each one made the result better. The only expensive failure of the day came from a tool that didn't refuse at all.

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.