EEZ Studio MQTTEvent: Register Handlers Before Starting the Connection

When an EEZ Dashboard appears to miss its first MQTT connection event, inspect setup order before adding reconnect logic. The documented sequence creates the connection object, registers event handlers and then starts the connection.

The MQTTInit guide places MQTTEvent after initialization. The MQTTEvent guide places MQTTConnect after handler registration and defines the event names and handler types. The editor's corresponding MQTT component definitions are pinned to the inspected v0.29.0 commit.

The fixture discussed here is a Dashboard with a disposable local broker. It does not establish the native transport integration or supported project types for an embedded firmware target.

Register against the object that will connect

MQTTInit creates and initializes an object:MQTTConnection through its assignable Connection expression. MQTTEvent's Connection expression identifies the object whose events it will handle. The subsequent connection action must use the intended same object.

That object relationship is as important as the visual order. A copied event component may still reference an older connection variable while the connect component uses a newly initialized one. Both components can look correctly configured in isolation, yet the handler is attached to a different connection.

Write the setup sequence as an explicit local responsibility: initialize this connection, register these handlers on it, then connect it. Avoid relying on an unrelated startup branch to finish registration at a convenient time. The documentation provides a deliberate ordering contract; a fortunate event timing in one run does not replace it.

Choose Flow and Action handlers intentionally

MQTTEvent supports a Flow handler that adds an output, or an Action handler that calls a selected User action. These are two ways to route an event, not evidence that the event is handled merely because its name appears in the list.

For a Flow handler, inspect the resulting output and its intended continuation. For an Action handler, verify the selected User action and its diagnostic effect. A renamed or copied action selection can be wrong even when the connection succeeds.

Start with one visible connect handler. Add message processing only after that basic registration is clear. The documented message event carries a system structure with topic and payload; a generic connection-state label is not a substitute for inspecting those fields when subscriptions are later introduced.

Connect and Reconnect mean different things

The documentation describes Connect as successful connection or reconnection. Reconnect denotes an attempt to reconnect after a connection was terminated. Therefore a reconnect event is not evidence that the client is online again.

Keep those states distinct in the diagnostic display. A reconnect attempt can be followed by more attempts, an error or a later successful connect. Do not turn an attempt notification directly into an application-ready flag.

Likewise, successful connection alone does not prove that subscriptions, application synchronization or message processing have completed. This article does not define those later policies. Its purpose is to establish that the intended event handler is registered and that each observed event is interpreted according to its documented meaning.

Exercise the setup without production subscriptions

Use a local test broker and a disposable connection with no sensitive credentials. Register a connect handler that increments a diagnostic count or shows an unmistakable marker, then start the connection. Record which connection object and handler configuration were used.

Next, cause a controlled broker interruption and observe reconnect attempts separately from the next successful connect. Do not claim a fixed number or timing of attempts; the selected MQTT runtime and configuration determine that behavior.

Test the alternate handler type only after the first route works. This keeps event registration, User action selection and network conditions from changing simultaneously. If two independent connection objects are part of the product, label their diagnostics separately instead of merging every event into one global connected indicator.

No broker connection was made for this article. The useful acceptance trace begins before the first connect call: it shows the object being initialized, its handlers being registered and the resulting events reaching the intended destination. That is a more targeted fix than adding retry code around a handler that was never attached to the right object.