สมัครรับข้อมูลและตอบสนองต่อคำสั่ง

Publishing sends data out; subscribing lets your device receive it. This is how the cloud sends commands back to hardware.

Tell the broker which topic you want with subscribe. From then on, matching messages are pushed straight to your device.

Incoming messages trigger a callback function you write. The broker calls it every time a subscribed topic gets a message.

Your callback receives the topic, the payload bytes, and a length. You register it once during setup.

Hook your function up with setCallback before connecting. The library then routes every message to it.

The payload is raw bytes, not a finished string. Build a String by looping over its length so you never read past the end.

Compare the message to known commands. A simple if check on the text is enough to map ON and OFF to actions.

Now do something real: flip a relay, move a servo, or change a light. This closes the loop from cloud to physical world.

If you subscribe to several topics, inspect the topic argument first. That tells you which device the command targets.

A dropped link forgets your subscriptions. After every reconnect, call subscribe again or you will hear silence.

Do quick work inside the callback and return fast. Long jobs there can stall the MQTT loop and miss new messages.

After a WiFi drop your device reconnects but stops responding to commands. What did the reconnect break?

You learned to subscribe, handle messages in a callback, read the payload, act on commands, and re-subscribe after reconnects. 🎉