From LoRaWAN Reading to Application-Ready MQTT

How LG3120e and E2C Field turn decoded sensor data into MQTT messages your platform can actually use

A LoRaWAN sensor can be working perfectly and still be a long way from delivering useful information to the system that actually needs it.

Consider a hospital facilities team monitoring environmental conditions across a group of non-clinical support areas. Temperature, relative humidity and CO₂ are already visible locally at the gateway, but the organisation does not want another standalone interface for someone to check. It wants those readings inside its own facilities platform, where different buildings and sites can be viewed using a common data model.

At that point, the problem is no longer wireless connectivity. The sensor has joined the network, its payload is being decoded and the values are available.

The challenge is deciding what leaves the gateway.

The receiving application needs to know which device produced the reading, what the value represents, which engineering units apply, when the source was last updated and whether the information is still current. MQTT can provide an efficient delivery mechanism between the edge and the application, but the usefulness of the integration depends much more on the structure and meaning of the message than on the fact that it arrived.

With the Robustel LG3120e and E2C Field, supported LoRaWAN sensor data can be received and decoded locally, selected into Tag Groups and published through an MQTT broker to a customer application. The broker may be hosted locally or remotely; MQTT itself does not require the destination to be a public-cloud service.

The technical path is straightforward:

LoRaWAN sensor → embedded network server → decoded E2C Tags → Tag Group and payload formatting → MQTT broker → customer application

The integration work begins when we ask what each stage should mean to the system at the other end.

The broker is not the data contract

It is easy to treat MQTT configuration as a networking exercise: enter the broker address, choose a port, provide credentials, configure TLS, select a topic and wait for the Connected indicator.

Those things matter, but they only prove that a transport path exists.

The receiving application still needs a consistent definition of the data travelling across it.

For a facilities platform, an environmental reading might need to carry a stable device identifier, meaningful field names, known engineering units and clear timing information. The topic structure also needs to give the subscriber enough context to route the message appropriately.

An illustrative payload for a hospital support area might therefore represent something like:

{
  "device_id": "hospital-a-support-02-env-01",
  "temperature_c": 21.8,
  "humidity_pct": 47,
  "co2_ppm": 620
}

with an MQTT topic such as:

hospital/site-a/support-02/environment

The exact names are not important here; this is an illustrative application schema rather than the default E2C Field payload. What matters is that the gateway and application team agree what the fields mean before either side is configured.

The source material makes this point explicitly: device identifiers, field names, units, JSON data types, timestamp meaning, reporting interval and topic structure should be agreed with the application team before gateway configuration begins. Stable identifiers are particularly useful because the application should not depend on a room label that may later be renamed.

Define the contract before configuring the publisher

A useful MQTT data contract should answer questions such as:

Question	Example decision
Which device produced this reading?	Use a stable device identifier rather than only a human-readable room name
What does the value represent?	temperature_c, humidity_pct, co2_ppm
What type should the application expect?	JSON number rather than a numeric value encoded as a string
Which units apply?	°C, %RH, ppm
When was the source updated?	Define the meaning of every timestamp explicitly
Where should the message be published?	Agree a predictable topic hierarchy
How often should messages be sent?	Match reporting behaviour to the source and application need
What happens when data is stale or missing?	Define the application behaviour before commissioning

This is less glamorous than connecting a sensor, but it is the part that makes an integration maintainable.

Start with trusted Tags

Before designing the platform-facing message, the data at the edge needs to be trustworthy.

The LoRaWAN device should already be onboarded and its codec validated. In Data Collection, the project should inspect the actual published Tags and confirm the names, values, units, types and update times. A genuine new uplink should cause the relevant Tag update times to advance.

Only then does it make sense to create a Tag Group containing the measurements the application requires.

That order matters because it separates two very different problems. If a value is wrong before it enters the MQTT workflow, changing the topic or JSON structure will not fix it. Likewise, if the decoded source Tags are correct but the customer platform receives the wrong fields or types, the problem sits further downstream.

Proving each layer independently avoids debugging the entire path at once.

Publishing more often does not create fresher measurements

MQTT publishing frequency and sensor reporting frequency are easy to confuse because both result in messages moving through the system.

They are not the same thing.

Suppose an environmental sensor sends a genuine LoRaWAN update every five minutes. E2C Field could theoretically publish the current Tag value every ten seconds, but that does not turn the sensor into a ten-second measurement device. Most of those MQTT messages would simply repeat the most recently available reading.

The source documentation is explicit about this distinction: E2C Field can publish periodically, when values change, or using a combination of both, but the reporting pattern should be chosen around the application’s requirements and the sensor’s own update behaviour. Publishing every ten seconds cannot create fresh measurements from a sensor that reports every five minutes.

For a facilities platform, this distinction affects more than bandwidth.

A dashboard may show a value arriving regularly and give the impression that the underlying measurement is equally current. Analytics may count multiple publications as independent observations. Alerting logic may assume that repeated messages represent fresh sensor activity.

The application therefore needs to understand source freshness, not simply message arrival frequency.

That is why the data contract should make the age or update status of a measurement interpretable at the destination.

“What time is this value from?” is not always a simple question

Time becomes even more important once data leaves the gateway.

E2C Field’s MQTT publishing workflow distinguishes between publishing time and individual Tag update time. The MQTT publishing guide defines groupTime as the publishing time, while each Tag’s time represents that Tag’s last update time. Neither should automatically be described as the original sensor measurement time without confirming what the device and integration actually provide.

Those differences matter whenever the customer platform is expected to reconstruct history.

Imagine that a Tag last updated at 10:05 and E2C Field publishes it at 10:07. Both timestamps may be technically valid, but they answer different questions:

• 10:05 tells the application when the source Tag was last updated.
• 10:07 tells it when this particular MQTT publication occurred.

Treating them as interchangeable can make stale data appear current or place information incorrectly on a historical trend.

The safest approach is not to invent a universal timestamp rule. It is to define the meaning of the available timestamps for the specific sensor, E2C configuration and receiving application, then verify that the destination uses them as intended.

In operational environments where records may later be compared across devices, systems or sites, that clarity is far more useful than simply adding another timestamp field to the JSON.

Use the default payload when it already solves the problem

Customisation is not automatically an improvement.

E2C Field can publish a default JSON structure containing group metadata and a payload organised by Tag name, including information such as device, Tag, time and value. If the receiving application can consume that structure cleanly, there is little value in adding transformation logic simply to make the integration look more bespoke.

That is an important engineering principle because every custom transformation becomes another component that has to be understood, tested and maintained.

Where the customer application genuinely requires a different schema, E2C Field Function Code can transform the outgoing message. In that case, the integration should use the actual Tag names and data structures shown by the installed system rather than assuming that a decoder field and an E2C Tag will always share the same name.

Data types deserve similar attention. If a source value arrives as a string but the receiving contract expects a JSON number, that conversion should be deliberate and validated rather than left to the downstream application to infer.

The goal is not maximum transformation at the edge. It is the minimum transformation needed to create a clear, stable interface between systems.

Connect to the broker with production behaviour in mind

Once the message contract is understood, the MQTT connection itself becomes much more conventional.

The broker administrator should provide:

• broker address
• port
• supported MQTT version
• authentication requirements
• TLS settings
• any required client-ID conventions

The gateway should use a unique client ID, and connectivity from the gateway network to the intended broker should be verified before troubleshooting the publishing layer.

In E2C Field, the MQTT service is created under Data to Cloud using those connection parameters. Internet-facing connections should use TLS, and production data should not be sent through public test brokers.

The Publish configuration then selects the required Tag Group, MQTT topic and Quality of Service (QoS). One small terminology point is worth noting: Topic Alias in E2C Field is the label for the publishing configuration; the subscribing application still uses the actual MQTT Topic.

These details are relatively easy to prove. The more important commissioning work comes after the connection succeeds.

“Connected” is only the beginning of the test

A commissioning client such as MQTTX can confirm that the gateway is publishing to the expected topic, but the final acceptance test should take place in the real receiving application wherever possible.

The project should compare the received message with the agreed contract and the source Tags, checking:

• device identity
• field names
• numeric types
• units
• timestamps
• topic
• publishing behaviour

Then wait for a genuine new sensor report and confirm that the update propagates through the complete path.

An unchanged value is not automatically a fault. Environmental conditions can remain stable across multiple valid reports. What matters is whether the receiving application can distinguish a legitimate unchanged measurement from information that has simply stopped updating.

If the broker connection is healthy but expected data is missing, the investigation should move through the path methodically: verify the source Tags, Tag Group membership, Publish configuration, MQTT topic and any Function Code transformation.

A green Connected indicator confirms the network session. It does not confirm that the application is receiving the correct information.

One reading can serve more than one operational need

Sending data to a wider platform does not require the local building-management path to disappear.

The same decoded edge readings can support separately configured destinations. Selected values may be exposed locally as BACnet/IP objects for a BMS while another set of messages is published over MQTT to an estate-wide facilities or analytics platform.

The two paths solve different problems.

The BMS may provide immediate local operational visibility, while MQTT provides a flexible way to move selected information into a broader application that aggregates data across departments, buildings or sites.

E2C Field’s role is not simply to duplicate every raw sensor event onto another protocol. Its useful contribution is the ability to select, group and format Tags around the requirements of the destination.

That also means an existing native MQTT integration may sometimes already provide what the project needs. The source material notes that ChirpStack can publish device events, including decoded data where an appropriate codec is configured. The additional value of the E2C Field workflow is greatest where the customer wants selected and formatted Tags aligned to an existing data contract rather than a direct stream of device-centric events.

MQTT delivery and offline buffering are different things

An upstream platform or broker will not always be reachable.

Where E2C Field store-and-forward is configured, pending MQTT reports can be buffered locally while the LG3120e remains powered and continues receiving and processing sensor data. Once the broker becomes reachable again, cached reports can be forwarded according to the configured recovery behaviour.

It is important not to confuse this with MQTT QoS.

QoS controls aspects of MQTT message-delivery behaviour. Selecting a QoS level by itself does not create local offline storage for an extended upstream outage. The gateway buffering function is what retains configured pending reports while delivery is unavailable.

During commissioning, the upstream connection should be interrupted deliberately, local Tag updates confirmed, and the destination checked again after reconnection. Delayed reports should appear meaningfully in the application’s history, with timestamp and late-arrival behaviour understood rather than assumed.

Prove one complete path before scaling the fleet

A successful MQTT integration does not need to begin with hundreds of sensors.

One supported sensor, one validated Tag Group, one broker and one receiving application are enough to prove the important things: identity, meaning, type, freshness, timing, publication behaviour and outage recovery.

Once that end-to-end contract is stable, the configuration becomes something the project can repeat rather than reinvent.

That is ultimately what makes the MQTT layer useful.

The objective is not merely to move LoRaWAN data away from the gateway. It is to turn device-specific wireless readings into information that another application can consume confidently, without needing to understand the radio network, payload codec or internal naming conventions that produced them.

For a hospital facilities team, a multi-site building operator or any organisation bringing wireless monitoring into an established application environment, that distinction matters.

MQTT provides the route. A well-designed data contract makes the route worth using.

Bringing LoRaWAN data into your own platform?

Start with the application rather than the broker: define the measurements, identifiers, units, timestamps, reporting behaviour and payload structure the receiving system actually needs.

Robustel or your integration partner can then help validate the LG3120e + E2C Field configuration needed to turn supported LoRaWAN sensor data into a reliable MQTT integration for your facilities or operational monitoring platform.