Mqtt on tsvinc

Record MQTT topics to a MikroTik router's SSD

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

This runs mosquitto_sub in a RouterOS 7.24 container and appends every message on a set of MQTT topics to a file on the router's SSD, one file per UTC day, with a timestamp on each line.

Tested on: a MikroTik router with RouterOS 7.24, the container package and a USB SSD (usb1-part1), image eclipse-mosquitto:2.1.2-alpine pulled from Docker Hub, broker in another container on the same container bridge (2026-11-02). The stop-signal behaviour of run.sh was re-checked in Docker 29.9.2 on Fedora 44 the same day.
Not verified: the rollback; the day switch of the file name (the recorder has run for less than a day); this exact order (my first deploy named another container's envlist, and I moved the running container to mqttrec later the same day); and the commands of steps 1, 3 and 6 as written here: my notes record what each step did, not these exact lines.
Needs: a container bridge with a gateway address on the router and an MQTT broker reachable from it; the router's container registry set to Docker Hub; a read-only MQTT user; SSH and SCP to the router; an external disk with free space.
Time: 20 min plus the image pull.
Risk: low. The container only opens an outbound MQTT connection and writes to one directory. Nothing rotates or deletes the files: about 3.5 to 5 MB a day, so a large SSD lasts decades, a small USB stick does not. Rollback removes one container, one mount, one envlist, one bridge port and one veth.

Before you start#

Placeholders used below:

Placeholder	Meaning (mine)
`<ROUTER>`	SSH `user@address` of the router, plus your own `-i <KEY>` options
`<DISK>`	the external disk (`usb1-part1`)
`<CT_BRIDGE>`	the bridge your containers' veths are ports of (`bridge-containers`)
`<CT_ADDR>` / `<CT_GW>`	a free address on that bridge for the recorder, and the bridge's gateway (`172.17.0.5`, `172.17.0.1`)
`<BROKER_IP>`	the broker's address as seen from the container bridge (`172.17.0.3`)
`<MQTT_USER>` / `<MQTT_PASSWORD>`	the read-only MQTT login the recorder uses

The registry is Docker Hub. remote-image pulls from the registry set in /container/config, and MikroTik's documented default is https://lscr.io/. Check registry-url in ssh <ROUTER> '/container/config/print'; if it isn't Docker Hub, set it as MikroTik's page shows: /container/config/set registry-url=https://registry-1.docker.io.
The broker accepts the read-only user and lets it subscribe to the topics you put into run.sh in step 2.
Backup: take a config export before step 1 (/export file=<DISK>/backups/<NAME>) and copy it off the router.

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.

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.

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

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: