Overview In this post, I show how to use the MQTT Retain message to simplify an IoT system. I will use a Smart Home example to explain this topic. Smart Home example We have two “smart” light bulbs connected to the MQTT Broker. Based on the structure of our IoT system, we defined the following general MQTT Topic structure: OWNER_ID/HOUSE_ID/ROOM_ID/light So the Topic structure for this specific deployment is following:

Overview Over The Air (OTA) update is the single most important feature of an IoT solution. You might not agree with me, but please let me explain. OTA The OTA allows updating: firmware/operating system business application configuration files security posture of an IoT device …once this device was shipped to the customer and/or installed in a hard-to-reach location. Most important feature? An IoT solution should realize the business needs of a customer/user.

Overview The MQTT was designed to support messaging in low bandwidth scenarios; by using Topic Aliases, we can reduce the bandwidth requirements even further. MQTT Topic Alias The Topic Alias is a property introduced in the MQTTv5. It reduces the network bandwidth required for the MQTT communication. A Topic Alias is an integer value that is used to identify the Topic instead of using the Topic Name. This reduces the size of the PUBLISH packet and is useful when the Topic Names are long and/or we work with extremely limited network bandwidth.

MQTT cheat sheet Term Explanation Diagram Client A program or device that uses MQTT. Client:opens the Network Connection to the Serverpublishes Application Messages that other Clientssubscribes to request Application Messagesunsubscribes to remove a request for Application Messagescloses the Network Connection to the Server Server (Broker) A program or device that acts as an intermediary between Clients which publish Application Messages and Clients which have made Subscriptions. Server:accepts Network Connections from Clientsaccepts Application Messages published by Clientsprocesses Subscribe and Unsubscribe requests from Clientsforwards Application Messages that match Client Subscriptionscloses the Network Connection from the Client Connection Connects the Client to the Server.

Overview Simulated IoT Environment is useful in many cases: to learn a new IoT concept/application to verify system design assumptions to test data models to simulate physical devices during the back-end development to perform a load-test of the back-end system Those are the most common use cases based on my experience. Today I will talk about a simulated environment focused on application, communication, and data modeling. I will not cover the physical layer and low-level firmware simulation (I do not have hands-on, production experience in those areas).

Video Metadata Metadata gives meaning to data. Data without meaning is simply a noise without value. In the IoT domain, device metadata describes a device. Device metadata can include: device MAC address firmware version assignment to a room (in Smart Home solution) Telemetry data Telemetry data describes an environment sensed (using sensors) by the device. That might be: temperature heartbeat rate battery level Telemetry data also should be described by metadata (but let’s keep this example as simple as possible).