After an agent restart the status topic carries no device truth until the first print

[impuls42]

Observed

Restart labelfab-agent, then read the retained status topic:

{"v":1,"printer_id":"d30-workshop","state":"idle","model":null,"serial":null,
 "firmware":null,"battery_pct":null,"voltage_v":null,"media_ok":null,
 "tape_width_mm":15.0,"pending_labels":0,"error":null}

Everything the printer reports is null. InvenTree's Machines page therefore reads CONNECTED — media unreported after every agent restart, and only becomes truthful once something prints:

media=True fw=2.1.2 batt=100 voltage_v=4.18

Cause

SourceMqtt._on_connect publishes an initial PrinterStatus carrying only printer_id, state and tape_width_mm. The device fields are populated by _capture_feedback, which only runs inside a send. Nothing queries the printer at agent startup.

The tri-state handling is doing its job here — media_ok: null renders as "media unreported" rather than claiming health, which is correct. The gap is that the information is available and simply not fetched.

Why it is not a trivial fix

Connecting on startup to populate this would wake the printer on every agent restart. The D30 auto-powers-off by design, and device.idle_disconnect defaults to true precisely because a held-open socket just relocates the failure. So an unconditional startup probe trades a cosmetic improvement for battery drain and an unnecessary Bluetooth wake, on a device whose whole operating model is "asleep until needed".

Options, roughly in order of preference:

1. Persist the last-known device state across restarts (the spool DB is already there) and republish it on connect, clearly marked as last-known rather than live. No printer wake, and the common case — nothing changed while the agent was down — reads correctly.
2. An opt-in device.probe_on_start for setups where the printer is mains-powered and always awake.
3. Leave it, and let the driver render media unreported until the first job. Honest, just less useful than it could be.

Option 1 also survives the case where the agent restarts more often than it prints, which is the situation that produced this report.

[impuls42]

A day of running says this is more frequent than the title claims. It is not "after an agent restart" — it is after every broker reconnect, and those happen several times a day.

Evidence

The agent has been up 25h with NRestarts=0 and zero errors. The retained status right now:

state        = 'idle'
serial       = None
firmware     = None
battery_pct  = None
voltage_v    = None
media_ok     = None

All device truth gone, with no restart involved. The broker log explains it:

01:45:38  Client labelfab-d30-workshop closed its connection.
01:45:40  New client connected ... as labelfab-d30-workshop
03:28:48  Client labelfab-d30-workshop closed its connection.
03:28:50  New client connected ... as labelfab-d30-workshop
20:22:37  New client connected / closed          (a flap)

Each reconnect runs _on_connect, which publishes a hardcoded bare status, retained:

self.publish_status(PrinterStatus(
    printer_id=self.config.agent.printer_id,
    state="idle",
    tape_width_mm=self.config.tape.width_mm,
))

No serial, firmware, battery_pct, voltage_v or media_ok — so a reconnect destroys information that was correct a moment earlier. This publish is not merely uninformative, it is lossy.

Why it matters more than it looked

Reconnects are routine here: the Istio route for mqtt.sengine.cloud caps at a 24h timeout by design, and paho reconnects automatically and silently — nothing appears in the agent's journal, so from the agent side it looks like nothing happened.

Net effect: the device truth survives only from one print until the next reconnect. In steady state the InvenTree Machines page reads CONNECTED — media unreported most of the time, which is exactly what it shows right now, ~25h after the last print. The consumer side is working correctly; it is faithfully rendering a status that the agent has emptied.

Fix

Remember the last published status and republish that on reconnect, instead of synthesising a bare one:

• publish_status stores the status it just sent
• _on_connect republishes the stored one when there is one, and only falls back to the bare idle on a genuinely fresh start

That is a few lines and needs no new state store. It leaves the original case in this issue — a fresh agent process has nothing to republish — which is where persisting last-known state to the spool DB (option 1 above) would still help, and which is much rarer than a reconnect.

Worth noting the LWT interacts correctly with this: the will publishes disconnected, and a reconnect would then republish the last known good status rather than a bare one.