Translate Like a Pro | 10050 — Mosquitto CLI Localization: mosquitto_pub, mosquitto_sub, MQTT Topics, Retained Messages and Unicode QA

Mosquitto CLI localization is the practical work of translating instructions for mosquitto_pub and mosquitto_sub without changing MQTT topics, command flags, payload bytes or delivery meaning. This guide explains how to publish and subscribe with Eclipse Mosquitto, diagnose missing messages, handle retained state and test UTF-8 text safely in a multilingual environment.

A reliable Mosquitto command-line translation is useful to IoT engineers, documentation writers, localization specialists, educators and technical support teams worldwide. The job is not to convert every word into the reader’s language. It is to make the human explanation easier to follow while leaving the machine contract exactly as the software expects.

Start with a disposable broker, a concrete topic, one subscribed client and one synthetic message. Observe the publisher, broker and subscriber separately. Do not treat a successful command as proof that a remote device acted, and do not mistake an old retained value for a fresh measurement. The chapters below provide examples, quality checks, repair strategies and an end-to-end review process.

Quick answer: what should be translated?

Translate natural-language explanations, instructional headings, warnings and user-visible display copy. Preserve executable flags such as -t, -m, -q, -r and -V, exact topic paths, JSON contract keys, MQTT reason codes and identifiers. Where a message contains translatable prose, first learn whether the application treats it as an opaque byte payload, a structured field or a screen label. Those three cases require different review methods.

A safe first publish-and-subscribe demonstration

Use these commands only against an authorized local test broker that you control. The subscriber runs first; the publisher runs in a second terminal. A local broker must already be running, with the listener and permissions configured for the test. The example makes no claim that port 1883 is secure for a network deployment.

mosquitto_sub -h localhost -p 1883 -t 'lab/translation/status' -v
# In another terminal:
mosquitto_pub -h localhost -p 1883 -t 'lab/translation/status' -m 'ready' -q 1

The output may show lab/translation/status ready on the subscribed terminal. That verifies receipt for this local sample, not a production guarantee. For a non-local broker, configure TLS, trusted certificates and authorized credentials instead of reproducing the unsecured laboratory shortcut.

The mental model: five different layers

There are at least five layers to read correctly: the human-language instruction; the shell that parses a command; the Mosquitto client and MQTT protocol; the broker that routes published messages; and the application or device that interprets the payload. A failure at one layer cannot be fixed merely by translating another layer more fluently. For instance, an emoji displayed as a square may indicate a font problem even when the bytes were transmitted correctly.

Good localization keeps evidence attached to its layer. An exit code belongs to a process; a QoS acknowledgment belongs to a protocol exchange; a subscriber transcript belongs to that subscriber’s observation; a thermostat reading belongs to the physical device. The careful writer makes it clear which of these events happened and which remains unverified.

A practical decision-by-decision handbook

1. Publishing and subscribing are different verbs

mosquitto_pub sends a message to a topic and exits after its publishing work; mosquitto_sub establishes a subscription and waits for deliveries. A translated quick-start must not present them as two forms of the same command.

A beginner sees a publisher exit successfully and asks where the received text went. It went to the broker, not into a local inbox. A subscriber must already be watching, or a retained message must be available.

Begin with the exact observation rather than a confident guess. Readers should be able to reproduce the situation in a harmless test and separate what a command printed from what a system actually did. The relevant vocabulary is part of the explanation, but the syntax and evidence remain fixed.

Practical verification: Run a subscriber on the lab topic before publishing a unique test value. Capture separately the publisher’s exit status and the subscriber’s displayed topic and payload.

2. Choose an explicit test broker

Without a broker address, sample commands commonly use the local host. That assumption is convenient in a tutorial but disastrous when copied onto a laptop with no broker listening or the wrong local service.

A student says that the message was lost, while the client simply failed to connect. The translated troubleshooting note must distinguish transport failure from an empty subscription.

Think of this as a contract between the documentation and the executable program. A sentence can be localized freely only if it is not itself an argument, identifier, property or protocol value. Readers should know which layer interprets a token before they copy it.

Practical verification: Record host, port, listener, permission and protocol version. Use an authorized disposable local broker before discussing production endpoints.

3. Preserve topic names as identifiers

The value following -t is a topic name, not a natural-language label that can be translated for readers. Changing telemetry/room1/state into another language changes routing semantics.

A French translator correctly translates ‘room temperature’ in the instruction but accidentally translates the literal topic string in the command. Producers and subscribers silently stop matching.

A useful troubleshooting article offers a fork in the road: if the first observation appears, test the next layer; if it does not, check the earlier one. That is considerably more helpful than calling every unexpected result a translation mistake.

Practical verification: Keep executable paths byte-for-byte, even when surrounding prose changes language. Test an actual match using exactly the same topic on both sides.

4. Differentiate topic filter from topic name

Subscriptions may use topic filters with + and # wildcards, while a normal publish topic is a concrete name. Describing both as interchangeable addresses blurs an important asymmetry.

A guide suggests publishing to sensors/+/temp. That is a filter pattern, not a valid ordinary publish topic. The reader learns the wrong mental model.

For classroom work, ask learners to predict the result before running the example. They can then compare prediction, client result and broker-facing observation, noting any gap. The exercise teaches technical meaning as well as vocabulary.

Practical verification: Show one concrete publisher topic and one matching subscriber filter. Verify which client accepts the wildcard and where the wildcard has meaning.

5. Explain -m as a single payload

The -m option supplies one message payload directly on the command line. Shell quoting and Unicode encoding matter before the MQTT client even sees the bytes.

A shell consumes quote marks around Japanese text as syntax, then sends UTF-8 bytes. Another shell may perform variable expansion inside double quotes, changing what is published.

Pay attention to the difference between a representation and the underlying value. A terminal may display characters differently, a help page may simplify an explanation, and a client may apply output formatting, while the transmitted contract is unchanged.

Practical verification: Test ASCII, accented Latin, CJK and emoji examples. Compare the received bytes with the intended fixture instead of judging only the appearance of characters.

6. Explain -f as file content

The -f option loads the content of a file as a single published message. This is useful for preserving exact fixtures, including newlines, but does not mean that every line is sent separately.

A translator labels a JSON fixture ‘messages’ and assumes each JSON line becomes its own event. With file mode the content is one payload unless a different sending mode is chosen.

Many misleading translations begin as reasonable shortcuts. A phrase such as ‘delivered’ can be true at one boundary and false at another. Qualify the claim with the actor, the evidence, the time and any known limitations.

Practical verification: Create a small synthetic file and compare its byte length to the single received payload. State explicitly whether line boundaries are within one message.

7. Distinguish -s from -l

The stdin-file mode -s reads standard input as one message, whereas -l treats input lines as separate messages. A documentation change between the two alters event counts.

A pipeline writes three sensor readings. A script using -s publishes one payload containing three lines; -l can publish three separate messages. Those are not equivalent logs.

Design negative tests as carefully as successful ones. A well-built example shows what happens when an argument is wrong, an authorization is absent or a filter does not match, without encouraging readers to interfere with a real deployment.

Practical verification: Count publications at the subscriber and include the input fixture in the test report. Ensure the translated instructions preserve the intended transport unit.

8. Understand -q quality of service

The -q flag requests an MQTT QoS level, usually zero, one or two. QoS concerns protocol delivery arrangements; it does not promise the end application stored, understood or acted on the message.

A status screen says ‘device updated’ merely because a QoS 1 publication succeeded. The application might still reject the payload, or the device could be offline.

Keep screenshots and sample transcripts trustworthy. If a value has been anonymized, say so; if a result is illustrative rather than recorded, label it as a hypothetical example. Clarity about evidence is more educational than a tidy but misleading image.

Practical verification: Translate acknowledgments narrowly. Verify protocol delivery separately from device-state confirmation, and include any application acknowledgment as another observed event.

9. Handle retained publication deliberately

The -r option requests a retained message for the topic. A new subscriber may immediately receive a stored last value, and that observation is not necessarily a fresh sensor reading.

An operator calls a retained ‘door open’ value a live alarm. It may be hours old. Translation must signal retained state and timestamp separately.

Practical verification: Publish a distinct test value with and without retain in a disposable namespace; subscribe after publication and compare results.

10. Avoid dangerous retained clearing advice

A zero-length retained publication can remove a retained record for its topic. That is a state-changing operation and belongs in a guarded maintenance procedure rather than a casual translation example.

A colleague copies a ‘cleanup’ command into production and erases the last known status value. No linguistic explanation can repair the missing state.

Practical verification: Describe the semantics without offering unreviewed production cleanup. Require broker authorization, a list of exact topics, recovery expectations and an approved change window.

11. Client identifiers are operational

The -i or –id value selects an MQTT client identifier; it is not merely a friendly display name. Concurrent connections with the same ID can cause session takeover or disconnection.

Two translated examples reuse the same fixed client identifier. Students run them at once and mistake the resulting disconnect for a language or encoding failure.

Practical verification: Use distinct synthetic IDs in exercises. Note client-session policies and keep real fleet identifiers out of published screenshots.

12. Persistent sessions need conditions

The -c option controls clean-session behavior, while MQTT 5 also has session expiry configuration. Neither option means that every missed message will always be replayed.

A disconnected subscriber reconnects and receives fewer messages than expected because its subscription, QoS or expiry conditions did not support queued delivery.

Practical verification: Write down version, client ID, session policy, subscription QoS and broker limits before interpreting recovered messages.

13. Declare MQTT protocol version

The -V option chooses among supported MQTT protocol versions. Some flags and properties are specific to MQTT 5 and should not appear as universal MQTT behavior.

A translated command example copies a user-property flag into a 3.1.1 client session. The ensuing error is blamed on the language pack, not the protocol difference.

Practical verification: Begin each reproduction with the client version and requested protocol version. Test a minimal fixture before adding properties.

14. Separate payload text from bytes

MQTT messages carry payload bytes; readers often expect UTF-8 text, but arbitrary binary payloads are possible. Translation should not silently imply that every payload is human-readable.

A binary diagnostic packet renders as replacement characters in a console. A documentation editor changes the packet specification to repair its appearance and corrupts the example.

Practical verification: For textual fixtures, specify UTF-8 and compare hashes or bytes. For binary fixtures, show a safe hex representation and explain why it is not prose.

15. Understand subscriber output defaults

mosquitto_sub commonly prints message payloads by default, and -v adds topic information. A reader cannot infer topic routing from a payload-only transcript.

Two topics both publish the word ‘ready’. A screenshot without the topic leaves no evidence about which device or stream emitted each value.

Practical verification: Use verbose or documented format output when verifying routing. Include the topic, timestamp where appropriate, QoS and retain state in the test record.

16. Consider –format rendering

The subscriber’s formatting facility can show metadata and message content in structured ways. A convenience JSON mode is useful only if the payload’s representation and escaping are understood.

A raw payload contains a quotation mark and newline. Concatenating it into home-made JSON produces an invalid document, whereas an escaping-aware format can preserve structure.

Practical verification: Feed fixtures containing quotes, backslashes, line breaks and non-ASCII text. Parse the result as data and compare expected fields.

17. Separate message count from completeness

The -C option stops a subscription after a specified number of messages. It is useful in scripts, but a one-message capture cannot establish that no later messages exist.

A test guide promises a complete event history after collecting the first matching delivery. That output proves a sample was received, not that the stream ended.

Practical verification: State the capture limit as a limit. For completeness, use time windows, sequence numbers, retained-state expectations and independent producer records.

18. Account for timeouts

The -W option can limit how long a subscriber waits for messages. An elapsed timeout does not always mean the broker has no messages; authorization, filters and network paths matter.

A bilingual help page translates ‘timed out’ as ‘topic absent’. The result sends users to create unnecessary topics rather than diagnose delivery.

Practical verification: Show the exact filter, target broker, expected publisher and wait interval. Preserve timeout versus empty observation in every locale.

19. Validate topic filter exclusions

The -T filtering facility can exclude messages from printed output while the subscriber remains subscribed. A missing printed line may be deliberately suppressed, not undelivered.

A colleague adds an exclusion to quiet noisy telemetry, then claims the broker stopped forwarding those messages. The transcript is filtered at the client.

Practical verification: Compare unfiltered and filtered capture in the lab. Explain whether the option affects receipt, display, or subscription routing.

20. Keep TLS verification enabled

TLS choices such as –cafile, –capath and client certificate options determine trust and identity. Translation must not suggest bypassing hostname verification to quiet an error.

An inexperienced reader sees –insecure in a quick fix and carries it into production. The connection becomes vulnerable to impersonation despite encryption.

Practical verification: Use a locally trusted test certificate and show certificate-path diagnostics. Document trust-chain and hostname failures without recommending disabled verification.

21. Do not embed passwords in published commands

Credentials written in a command line may be visible in process listings, terminal history, logs or screenshots. Some client configurations support using protected option files instead.

A regional tutorial replaces an example password with a translated word but still teaches readers to paste real secrets into a shared chat.

Practical verification: Use placeholders only in displayed syntax; explain secret-handling alternatives and redact both credentials and access tokens in QA artifacts.

22. Keep debug output separate from normal output

The -d option emits detailed protocol diagnostics that can help distinguish client connection, subscription and publish stages. Such output may expose operational details.

A localization screenshot uses verbose debug output as if it were the ordinary result. End users then expect protocol traces from the default command.

Practical verification: Label debug transcripts explicitly, redact sensitive fields and compare them with the intended normal user experience.

23. Interpret exit status cautiously

An exit code reports the command’s immediate outcome, not necessarily downstream application processing. Connection refusals and argument errors may produce different codes.

A pipeline checks only whether the publisher process returned zero and claims the thermostat accepted the command. Broker delivery is not a device-state proof.

Practical verification: Capture standard output, standard error, exit code and the subscriber observation. Add an application-level check when the result affects physical equipment.

24. Describe last-will messages correctly

An MQTT will is a broker-mediated message associated with an unexpected client disconnection and configured at connection time. It is not a guaranteed instant notification for every kind of outage.

A translated interface calls a will ‘final message from the device’. That implies the device itself sent it after a crash, which is often false.

Practical verification: Test a controlled disconnection scenario only in a synthetic lab. Distinguish broker publication, detection delay and actual device state.

25. Respect retained versus will-retain

Will-message retention and ordinary retained publication are different settings. When both concepts appear, a reader needs to understand which event set or cleared a stored value.

An example labels a retained offline status as evidence of current downtime without showing the time of the will or subsequent recovery message.

Practical verification: Log the will configuration, retain flag, receipt timestamp and later online update. State what remains unknown when a follow-up is absent.

26. Keep MQTT user properties intact

In MQTT 5, custom user properties can carry application metadata. Their names and values may be contract fields even when they look like ordinary English words.

The property key ‘language’ is sometimes a semantic key in data, not a heading that may be freely translated. Altering it may break downstream rules.

Practical verification: Maintain a schema field map: immutable keys, translated display labels and intentionally localized values. Validate the actual property set with a capable client.

27. Distinguish JSON strings from JSON contracts

A JSON payload may contain both localizable natural-language messages and rigid machine-readable keys, numerical types, booleans and identifiers. Do not translate every string automatically.

The source has status=’open’ as an enum and note=’The gate is open’ as prose. Only the note is necessarily appropriate for localization.

Practical verification: Ask the application owner which values form a protocol contract. Parse test payloads and assert types, key spelling and required fields.

28. Preserve numbers and units

Sensor values are quantities, not idioms. Localized decimal separators, units and timestamps may be appropriate for display but not for transport schemas expecting canonical numbers.

A French screen displays 21,5 °C, while a JSON numeric field must remain 21.5. Moving display formatting into the payload breaks parsing.

Practical verification: Maintain separate transport and presentation examples. Round-trip numeric fixtures including negative, zero and high-precision readings.

29. Guard topic hierarchy conventions

Topic-level conventions often encode region, site, device and measurement. The slash-separated hierarchy can be operational even when one segment resembles a country name.

A translator changes ‘us’ in an internal topic segment to a translated pronoun because it looks like a word, losing a device namespace.

Practical verification: Treat the hierarchy as a controlled identifier map. Document human-readable glosses alongside, not inside, executable topics.

30. Reproduce shell quoting per platform

POSIX shells and Windows shells do not interpret quotes, encodings and environment variables identically. A snippet tested on one platform must not be described as universal.

A PowerShell reader copies a Bash multiline command with backslash continuations and gets parsing errors before Mosquitto starts.

Practical verification: Offer single-line portable examples when possible and test platform-specific variants separately, showing which shell each belongs to.

31. Treat line endings as data when relevant

A file prepared on Windows can contain CRLF while a Unix file uses LF. For messages or signed payloads, the difference may matter even if text appears identical.

A fixture fails a byte-for-byte comparison after copying between systems, despite identical displayed words. The transport was correct; the input file changed.

Practical verification: Compare byte counts and checksums, preserve a canonical test fixture and document newline normalization explicitly if required.

32. Redact operational traces

Debug captures can contain client IDs, topic names, tenant details, IP addresses and messages. Localization review screenshots should never expose a real deployment inadvertently.

A screenshot for language review includes customer device identifiers under the caption. Those identifiers remain sensitive even though they are not passwords.

Practical verification: Use a disposable namespace and synthetic messages, then inspect screenshots and logs for connection details before sharing.

33. Do not imply end-to-end exactly-once processing

MQTT QoS 2 describes a delivery exchange between protocol participants. An application still needs its own idempotency and state rules to prevent duplicate business actions.

A payment-triggered workflow treats ‘exactly once’ as proof that only one invoice was created. Replays, restarts and application retries can still change business outcomes.

Practical verification: Translate the protocol-level guarantee precisely, and test the business consequence separately with trace IDs and duplicate fixtures.

34. Verify ordering at the right scope

Observing one subscriber receive three values in order is not a proof of total ordering across multiple publishers, sessions or downstream services.

A status dashboard reorders values after processing and someone edits a translation to claim the broker guaranteed global order.

Practical verification: Build a small sequential fixture, add publisher identifiers and timestamps, and describe only the ordering actually demonstrated.

35. Make error explanations actionable

A localized error page should tell readers whether to check the command syntax, network, authorization, topic filter, protocol version or payload encoding, rather than presenting one generic failure label.

The phrase ‘cannot connect’ is not a sufficient troubleshooting diagnosis. Different failures require different owners and different corrections.

Practical verification: Group symptoms by reproducible observation and keep exact error text beside a plain-language explanation; never silently rewrite error codes.

36. Use versioned documentation

Mosquitto CLI options evolve across releases. Instructions that work in one client build may be absent or behave differently in an earlier installed version.

A translated manual quotes a new option without stating its minimum supported release; learners on older systems assume the translation is defective.

Practical verification: Record the local client version and link to its matching manual. Do not infer backward compatibility from a current online reference.

37. Publish a localized glossary without editing command syntax

Glossaries are useful for publish, subscribe, retained message, session, broker and acknowledgment; they become harmful if they suggest translating CLI flags.

A training slide renders ‘-t’ as a translated initial letter to make it memorable. The resulting command fails immediately.

Practical verification: Write a two-column glossary: translated explanation on the left, literal runnable syntax on the right. Re-run every snippet after editing prose.

Eight realistic multilingual review cases

1. A French temperature display

A sensor publishes JSON with the machine key temperature_c and the string note ‘Room stable’.

Keep temperature_c intact, translate the note for the user-facing display, retain the canonical JSON numeric value and verify the decoded Unicode characters.

Evidence to collect: Confirm the raw bytes, parser result and localized screen separately. A pleasing display is not evidence that the transport contract survived.

The educational goal is to state the observable result accurately. The review should identify the reader’s task, the machine-readable elements that must remain stable, the human words that may change and the independent check that detects a mistake. This separates a trustworthy translated procedure from one that only sounds natural.

2. A Japanese room-status label

A lab publishes the payload ‘準備完了’ to lab/room-a/status while the subscriber watches lab/+/status.

Keep the UTF-8 fixture and exact topic filter; show the difference between a wildcard subscription and the concrete publish topic.

Evidence to collect: Check whether the terminal can render Japanese, then compare bytes in case fonts are missing or glyphs are substituted.

3. A Spanish retained-alert review

The first subscription shows ‘puerta abierta’ before any new message is published by the current test.

Identify it as retained state rather than a freshly sampled alarm; seek a source timestamp and current device verification.

Evidence to collect: Report the age and retained flag where available, and avoid promising the door is open at the moment the reader logs in.

4. A Korean multiline fixture

A translator builds a three-line UTF-8 device report with headings and readings, then selects -f for the publication.

Explain why it is one MQTT payload containing newlines. Do not rewrite the sample as three independent events.

Evidence to collect: Compare received byte size and line endings; repeat with line mode only as an explicitly different exercise.

5. A European decimal separator

A translated screen uses a comma decimal separator, but the transport field follows a JSON numeric contract.

Keep machine values such as 19.75 numeric. Localize the presentation layer and label the unit rather than changing JSON grammar.

Evidence to collect: Test that the original and localized clients parse the same number and calculate the same threshold behavior.

6. A missing device update

The publisher exits successfully with QoS 1, but the physical device does not change state.

Say that the publication completed at the observed layer; do not translate that into a promise of successful actuation.

Evidence to collect: Check the subscriber, application validation, device acknowledgment and real-world sensor feedback as separate steps.

7. A support screenshot with secrets

An operator submits a debugging transcript to a multilingual documentation team.

Remove tokens, hostnames, client IDs and customer payloads; substitute synthetic values while preserving meaningful diagnostic structure.

Evidence to collect: Have a second reviewer inspect both visible text and terminal history metadata before using the screenshot publicly.

8. A copied command on Windows

A learner pastes a long Bash command with continuation characters into PowerShell and sees a syntax failure.

Keep the semantics but provide a tested shell-specific version or a single-line variant. Identify the terminal used.

Evidence to collect: Check that an argument reaches Mosquitto unchanged by testing a small Unicode fixture, not merely by seeing a zero exit code.

Quality-assurance checklist for a release

1. Pin the exact Mosquitto CLI and protocol versions tested, including differences across older installations. For each check, retain the smallest reproducible synthetic input, the expected output and the actual result. A pass without an observable artifact is difficult for another team to audit or repeat.

2. Preserve flags, topic names, placeholders, JSON keys, QoS numerals and message properties as required by the application contract. For each check, retain the smallest reproducible synthetic input, the expected output and the actual result. A pass without an observable artifact is difficult for another team to audit or repeat.

3. Test one ordinary ASCII message and several UTF-8 fixtures, including combining characters, emoji, quotes and line breaks. For each check, retain the smallest reproducible synthetic input, the expected output and the actual result. A pass without an observable artifact is difficult for another team to audit or repeat.

4. Keep a byte-level fixture and capture the subscriber output separately so that display problems do not masquerade as transport corruption. For each check, retain the smallest reproducible synthetic input, the expected output and the actual result. A pass without an observable artifact is difficult for another team to audit or repeat.

5. Validate a happy path, a wrong topic, a connection failure, an authorization failure and an expired or retained-state scenario as applicable. For each check, retain the smallest reproducible synthetic input, the expected output and the actual result. A pass without an observable artifact is difficult for another team to audit or repeat.

6. Confirm that examples do not leak customer information, passwords or live infrastructure identifiers. For each check, retain the smallest reproducible synthetic input, the expected output and the actual result. A pass without an observable artifact is difficult for another team to audit or repeat.

7. Use an independent reviewer to repeat each localized instruction in the stated shell and environment. For each check, retain the smallest reproducible synthetic input, the expected output and the actual result. A pass without an observable artifact is difficult for another team to audit or repeat.

8. Document what the CLI proves and what requires broker, device or application evidence. For each check, retain the smallest reproducible synthetic input, the expected output and the actual result. A pass without an observable artifact is difficult for another team to audit or repeat.

Frequently asked questions

Should I translate MQTT topic names?

No, not unless the software architecture explicitly changes the topic contract and all publishers, subscribers, permissions and routing rules together. A topic is often a machine identifier. Translate the accompanying description and offer a glossary instead of rewriting executable topic paths.

A useful follow-up is to reproduce this point on a disposable topic with a small synthetic fixture, write down the version and preserve the observed output. That record helps readers distinguish an explanation from a promise about every deployment.

Does QoS 2 guarantee that a device performs an action exactly once?

No. QoS 2 concerns protocol delivery behavior. A device application may retry, reject, duplicate or process a business action separately. A localized guide should qualify any exactly-once statement by the layer to which it applies and describe application-side verification.

How can I tell a retained message from a current reading?

Use subscriber metadata and an application timestamp when available, and seek a fresh publication or live device confirmation. The broker’s retained value represents stored last-known state for a topic; it is not an automatic guarantee of current physical truth.

Why does Japanese or Arabic text look corrupted?

The payload may have been encoded incorrectly, the shell may have altered arguments, a program may have decoded with the wrong character set, or the terminal font may lack glyphs. Compare known UTF-8 bytes before making claims about the transport or translation.

Can I put a password directly into a translated example?

Use synthetic placeholders rather than real credentials, and teach safer secret handling. Command-line arguments can enter shell history, logs and process inspection. Never publish a working secret simply because it appears in a convenient tutorial.

What does mosquitto_sub -v prove?

It can make the topic and payload visible in that subscriber’s output, which is valuable routing evidence. It does not prove that every subscriber received the message or that another service accepted, stored or acted on it.

When should I use -f instead of -m?

Use file input when a known fixture must be preserved accurately, especially for multiline or larger content. Use -m for a small controlled payload that is safe to pass through the shell. Test exact bytes for both rather than assuming the two inputs are always identical.

Where can I check the current CLI syntax?

Use the installed program’s help output and the matching official Mosquitto manuals. Options vary by client release, and a current online reference may describe features unavailable on an older system. Test the example in the environment named in the guide.