Hello and welcome to this WAGO tutorial, where we’ll be demonstrating how to publish data via MQTT using WAGO Load Management. As with our previous tutorials on WAGO Load Management, we’re once again working with a CC100 controller, which has Load Management installed and licensed, and a PFC200 running a charging station simulation via a CODESYS 3.5 visualisation. To establish an MQTT connection, you’ll need access to a network-reachable MQTT broker. In our setup, the broker is hosted on an Edge Device within a Docker container. The principle behind MQTT communication is fairly straightforward and generally quite robust in operation. All communication parameters are defined within the broker. Secure and password-protected connections are also possible, though in this example, we’re sticking with the default settings. WAGO Load Management acts as a publisher, meaning it sends data to the broker in the form of a JSON string. Any other device wishing to access this data can register with the broker as a subscriber, and will then receive each newly published JSON string. Since many MQTT-enabled devices can both send and receive data, they’re commonly referred to as clients. In this video, we’re focusing specifically on the connection between WAGO Load Management and the broker — that is, how Load Management publishes data to the broker. To monitor what data is received by the broker, we’re using a free software tool called MQTT Explorer. You’ll find the MQTT connection settings under Configuration > Interfaces. Within this section, you’ll see all relevant MQTT parameters. First, we need to enable MQTT. Then, we specify the IP address and port of the broker. The default port is 1883; for encrypted communication, port 8883 is used. If the broker is password-protected, you’ll need to enter the appropriate username and password. Below that, you can define the transmission interval in seconds. In our case, a new JSON string is sent to the broker every 2 seconds. Next, we have the Quality of Service (QoS) settings, which determine the reliability of message delivery. There are three levels: QoS 0: The lowest level, often described as “fire and forget”. The publisher sends the JSON string at the end of each cycle and moves on. QoS 1: The publisher requests an acknowledgement from the broker for each message. If none is received, the message is resent until confirmation is received. This ensures delivery but may result in duplicate messages. QoS 2: A four-step handshake guarantees that each message is delivered exactly once. This is the most reliable but also the most network-intensive, typically reserved for critical applications like financial transactions, where duplicate messages are a problem. QoS is configured solely on the client side. The broker supports all levels and responds accordingly. It’s important to note that if the publisher and subscriber use different QoS levels, the lowest level will be applied across the communication chain, as per MQTT specifications. If the broker is configured for TLS encryption or uses certificates, these can be enabled on the client side as well. If your charging stations are connected via OCPP and user management is active, the RFID number used at the charging point can also be included in the JSON string. The Client ID becomes relevant when persistent session handling is enabled on the broker. It allows the broker to associate a reconnecting client with its previous session data. Each recorded value is stored in the JSON string as a topic. All topics are grouped under a main topic, which you can name here. Once connected to the broker via MQTT Explorer, you’ll see all datasets being sent. Our main topic, WALM, is listed. Expanding the topic tree reveals two topics being updated every two seconds. However, you might notice fewer data points than expected. That’s because no value changes have occurred yet. Switching to the simulation and increasing building consumption triggers updates in MQTT Explorer now showing topics for building consumption and total power usage. If PV generation increases, a new topic appears. When a charging session begins, another topic — charging power — is added and increases with each additional vehicle. This behaviour — sending topics only when values change — also applies after a controller restart or when a new client connects. To ensure all previously sent values are transmitted upon initialisation, you can enable 'retained messages'. This stores values in the controllers’s retain memory, making them available even after a restart. Once saved, we restart the controller… and upon reboot, we receive a flood of data — all MQTT-available topics from WAGO Load Management. Thanks to the retained flag, all values were written to the retain buffer and sent once the connection was re-established. The rear value: 'tst', is a UNIX timestamp. Now, any additional client can retrieve the dataset, parse the JSON string, and extract the required values. There are countless devices and methods to do this. In another tutorial, we’ll show how to achieve this using a WAGO controller and CODESYS 3.5. And that concludes the tutorial on publishing data via MQTT using WAGO Load Management. Please leave us a thumbs up if the video was helpful, subscribe to the channel, and contact the WAGO Support Centre if you have any questions.