Edge computing in IoT metering

When to process data on the device?

M-Bus meters often generate payloads that do not fit into a single message of the transmission technology. For NB-IoT, it is not recommended to exceed 512 bytes, and for LoRaWAN, the limit is 51 bytes. If a converter must send data exactly as read, it exceeds the network limit and must split the transmission into multiple messages. More messages mean higher power consumption, shorter battery life, and higher connectivity costs. Edge computing solves this problem directly at the source, before the data is sent.

VIF/DIF filtering: how an M-Bus payload fits into a LoRaWAN message

An M-Bus frame contains dozens of data fields: consumption in different units, timestamps, status bits, manufacturing details, and historical values. Most applications need only a handful of specific values. VIF (Value Information Field) and DIF (Data Information Field) are identifiers used to address and select the exact fields relevant to a given application within an M-Bus frame.

VIF/DIF filtering directly in the converter means only a selected subset of data travels to the cloud. Instead of the full M-Bus frame, a compact message is sent with the current volume, reading time, and status. It fits into a single LoRaWAN message, saves network capacity and battery life, and removes the need to reassemble data from multiple fragments on the server side. Without this filtering, many M-Bus meters become impractical for LoRaWAN use, as payloads typically exceed the capacity of a single transmission.

Adaptive sampling: fewer transmissions when values are stable

The second concrete advantage of local processing is the ability to adapt the transmission frequency. If a measured value stays within tolerance, there is no reason to send data at the same cadence as during a change. The converter evaluates locally whether a transmission is worth making or can be postponed.

Typical scenarios where adaptive sampling makes sense include meters in steady-state operation, where values change only within specific time windows, seasonally used equipment, and industrial meters in idle mode. Battery life improves due to fewer transmissions, the most energy-intensive operation, while network capacity increases as gateway load decreases.

What else can ACRIOS converters handle locally

Lua scripting on the converters opens up further functions that previously had to run in the cloud. For pulse-based water or electricity meters, the converter does not need to send each pulse individually, instead the script continuously calculates consumption and sends a ready-to-use value to the cloud in the required format. Reading data are validated at the source: the converter verifies that a value lies within the physically plausible range and that measurement continuity matches the history, so erroneous readings are filtered out before they ever reach the cloud.

The same script logic handles fault detection, monitoring patterns in the data and reacting to unusual behaviour such as long-term constant values, unexpected zero consumption, or values outside the expected range. Because scripts are updated separately from the firmware, adjusting a calculation or adding a new validation does not require a full firmware update of the device.

Data normalisation ensures that readings from a pulse input, from Modbus, or from M-Bus can arrive at the server in the same format (for example, JSON), even when the source-side data representation is significantly different.

Security of data at the edge

When part of the logic and data stays on a device in the field, the security perspective changes. The cloud typically has robust protection at the server level, whereas edge devices are physically accessible and often in unsecured locations. The key points that need to be addressed: encryption of data in transit and at rest, authentication of the device against the server, and controlled management of encryption keys.

ACRIOS converters forward data as a standard M-Bus frame with its own integrity controls. For NB-IoT, we enable source encryption using AES and signing using CMAC. Each converter has its own unique set of encryption keys that secure encryption and verification at the transmission level. We have covered the requirements introduced by the European in a dedicated article: Cyber Resilience Act

When edge computing makes sense, and when it does not? Edge computing is not a universal solution. The right choice depends on what a specific deployment actually needs.

Edge makes sense when

• The M-Bus payload does not fit into a single message of the transmission technology.
• The deployment runs on battery power, and every transmission shortens the lifetime.
• The network has limited capacity (LoRaWAN, NB-IoT in marginal coverage areas).
• Meters remain in a steady state for long periods, and the transmission frequency can be adjusted dynamically.
• The operator wants to reduce dependence on server or internet availability.
• Edge computing does not make sense where connectivity is stable, the application energy budget is not seriously constrained, and all analytics happen centrally. In such cases, local processing adds complexity without a matching benefit.

Key takeaways

Edge computing in metering is not a philosophical choice between cloud and device. It is a practical answer to specific technical constraints: payloads larger than the network limit, batteries that must last for years, and readings that need to be validated before they are sent further.

Data from end meters arrives unencrypted, and in sensitive deployments it is advisable to encrypt and digitally sign it at the source. ACRIOS converters address these tasks through Lua scripting and remote logic updates without firmware intervention.

This article is intended as a general overview. The right choice of data processing depends on the type of meters, the transmission technology in use, and the project requirements. We recommend always consulting the deployment with a specialist who takes the specifics of your installation into account.