Your prototype sends a reading, and it appears on a laptop. The next step sounds small: leave a few units with people and see how they use them. But the free message server that made the demonstration easy is now part of their experience. Who can read the messages? Who can send commands? Who will help when a unit stops connecting?
For a user trial, choose a broker whose access rules and operation you can control, either a managed service or a server someone on the team maintains. A public test broker is still useful for throwaway connection checks. It should not quietly become the infrastructure for real user data or real device control.
Our bench check used the MQTTX desktop client against a public test broker. This note covers what that connection showed and what has to change before a prototype leaves the bench. We have not run a private deployment or a full trial as part of it.
What the successful connection actually tells you
An MQTT broker receives messages from clients and forwards them to clients subscribed to matching topics. A topic is the message's routing name, such as trial/unit-01/temperature. MQTTX is a desktop client: it lets you inspect settings and messages without first debugging the board's application code.
In our setup the client connected to broker.emqx.io on port 1883 using MQTT 3.1.1, with automatic reconnection and Clean Session enabled. Those were demonstration settings, not a recommended configuration for a private trial. EMQ's public broker page describes the service as a shared test environment and warns that messages are visible to other users. Use invented readings there, never user names, locations, access codes or live control commands.
MQTTX then showed a connected session. That is a useful checkpoint: this client reached this endpoint with these settings. It does not show that another client received a message, that an unwanted subscriber is excluded, or that your microcontroller can use the connection settings you plan to deploy.
Decide what should keep working when the internet disappears
Start with the trial's location and purpose. For a room installation that must respond locally, a broker on the local network may be worth evaluating. For units spread across several homes, a managed remote broker may reduce the server work your team takes on. Neither removes the need to design how the device behaves when it cannot connect. Three starting points:
- One installation where local interaction matters during an internet outage: evaluate a local broker and a local control path. Someone still owns server power, backups, updates and on-site support.
- Several remote locations monitored centrally: evaluate a managed private broker. Someone still owns device credentials, topic permissions, account access and service limits.
- Local operation plus selected remote reporting: evaluate a deliberately limited link between local and remote systems. Someone still decides which data or commands cross that boundary and how failures are handled.
These are inputs to a design decision, not interchangeable recipes. If the local device still needs a cloud login before it does anything, putting a broker on the LAN will not make the product work offline.
A Home Assistant discussion from February 2021 shows the practical question: the author wanted some controls available locally without exposing them through the remote system. The thread explored multiple brokers and other arrangements without reaching a verified solution. For a trial, write down which commands may travel from which users to which devices before choosing an arrangement to enforce it.
A password answers only one of the access questions
Authentication asks who a connecting client is. Authorization asks what that client may publish or subscribe to. Encryption protects the connection in transit. A design can have one of these and still lack the others; using TLS with a shared public broker does not make the broker private.
Mosquitto's authentication guidance treats topic access control as a separate matter from allowing a client to connect. It is common to configure usernames and passwords and only later discover that every user can still reach every topic.
Take an illustrative two-unit trial. Unit A might publish its own readings while an operator can read both units. That does not mean unit A should be able to publish a command meant for unit B. Define those rights explicitly, and try a request that should be rejected. An obscure topic name is not a substitute for an enforced permission rule.
Change the desktop settings, then prove the board can follow
In MQTTX you disconnect, edit the saved connection and reconnect for a change to take effect. That makes it a good comparison tool when moving to a trial endpoint: check the host, transport, identity and permissions first from a client whose state you can see.
Then repeat the relevant checks on the actual board and firmware. A TLS connection that works from a laptop does not show that the microcontroller has compatible TLS support, the right trust configuration or enough resources for the intended workload. Treat that as an integration task, rather than assuming the new host and port are the only firmware changes.
Record a short connection profile for each trial build: broker hostname, transport and port, protocol version, how the device gets its identity, allowed topics, and who is responsible for replacing credentials. Keep the credentials themselves out of screenshots and shared notes. Sample Client IDs from a demonstration are just labels; copying one into every device is not an identity scheme.
Make the hand-over test specific enough to fail
Before giving a unit to a tester, agree on a small set of observable results. These are proposed trial checks:
- Connect with the intended device identity: the broker accepts it and the application receives the expected reading.
- Try an invalid identity: the connection is rejected and the device reports a useful state.
- Attempt a topic operation outside that identity's rights: it does not reach the protected recipient.
- Interrupt the network, then restore it: the device behaves as specified during the outage and resumes without manual repair.
- Withdraw one test unit: its access can be removed without disabling the others.
- Hand support to another team member: they can find the endpoint and account owner without receiving secrets in a shared document.
This also keeps the trial focused. If participants are meant to judge a physical interaction, do not let an unowned server or an unclear connection setup dominate their feedback. Log communication failures so that a network problem does not look like a rejected product idea.