Overview
The MQTT publishing endpoints allow you to manually send messages to the MQTT broker for testing and verification purposes. These endpoints are useful for:- Verifying data reception
- Testing MQTT connectivity
- Debugging sensor integration issues
- Contrasting information with other systems (e.g., Node-RED, EMQX dashboard)
Publish Latest Message
Endpoint
Query Parameters
MQTT topic destination (defaults to
SYSTEM/RESPONSE)Quality of Service level: 0, 1, or 2 (defaults to 0)
Response
Whether the message was published successfully
Success or error message
ID of the greenhouse from the cached message
MQTT topic where the message was published
Quality of Service level used
The RealDataDto object that was published
Response Example
This endpoint publishes the latest message received from the Redis cache. If no messages are available in the cache, it returns a 400 error.
Publish Custom Message
Endpoint
Query Parameters
MQTT topic destination (defaults to
SYSTEM/RESPONSE)Quality of Service level: 0, 1, or 2 (defaults to 0)
Request Body
The request body should contain aRealDataDto object with the following structure:
ISO 8601 timestamp
Temperature of Greenhouse 01 in °C
Humidity of Greenhouse 01 in %
Sector 01 status (0.0 or 1.0)
Extractor status (0.0 or 1.0)
UUID of the greenhouse
Tenant identifier for multi-tenancy
The RealDataDto supports 22 fields for temperature, humidity, sectors, and extractors across 3 greenhouses. See the Message Payload Structure section for the complete list.
Response Example
Publish Raw JSON
Endpoint
Query Parameters
MQTT topic destination (defaults to
SYSTEM/RESPONSE)Quality of Service level: 0, 1, or 2 (defaults to 0)
Request Body
Raw JSON string (no validation performed)Response Example
Message Payload Structure
TheRealDataDto object supports the following fields:
Temperature and Humidity (3 Greenhouses)
TEMPERATURA INVERNADERO 01- Temperature in °C (Greenhouse 01)HUMEDAD INVERNADERO 01- Humidity in % (Greenhouse 01)TEMPERATURA INVERNADERO 02- Temperature in °C (Greenhouse 02)HUMEDAD INVERNADERO 02- Humidity in % (Greenhouse 02)TEMPERATURA INVERNADERO 03- Temperature in °C (Greenhouse 03)HUMEDAD INVERNADERO 03- Humidity in % (Greenhouse 03)
Sectors (12 Fields)
INVERNADERO_01_SECTOR_01toINVERNADERO_01_SECTOR_04(Greenhouse 01)INVERNADERO_02_SECTOR_01toINVERNADERO_02_SECTOR_04(Greenhouse 02)INVERNADERO_03_SECTOR_01toINVERNADERO_03_SECTOR_04(Greenhouse 03)
Extractors (3 Fields)
INVERNADERO_01_EXTRACTOR(Greenhouse 01)INVERNADERO_02_EXTRACTOR(Greenhouse 02)INVERNADERO_03_EXTRACTOR(Greenhouse 03)
Additional Fields
RESERVA- Reserve valuegreenhouseId- UUID of the greenhousetenantId- Tenant identifier for multi-tenancytimestamp- ISO 8601 timestamp
Note the key format difference:
- Temperature/Humidity fields use SPACES:
"TEMPERATURA INVERNADERO 01" - Sector/Extractor fields use UNDERSCORES:
"INVERNADERO_01_SECTOR_01"
QoS Levels
MQTT supports three Quality of Service levels:At most once - Fire and forget. The message is delivered at most once, or it may not be delivered at all. Use for sensor data where occasional loss is acceptable.
At least once - The message is delivered at least once, but may be delivered multiple times. Use for actuator commands that must be received.
Exactly once - The message is delivered exactly once. Use for critical alerts that must not be duplicated.
Response Topic
By default, all published messages are sent to theSYSTEM/RESPONSE topic. This topic is used for:
- Verification: Hardware engineers can subscribe to verify that the API received data correctly
- Bidirectional Communication: Allows external systems to confirm message reception
- Testing: Useful for debugging MQTT integration issues
The response topic can be customized using the
topic query parameter or by setting the spring.mqtt.topics.response property in application.yaml.Error Responses
No Messages Available
400 Bad Request
Publication Failed
500 Internal Server Error