Aernode supports two integration concepts that should be kept separate: local data access and remote data transmission. Through Modbus RTU over RS485, a local system can read current measurement values from the station. Independently, the station can be configured to transmit records remotely to Aernode Cloud or to a project-specific external server.
These paths can coexist. Local Modbus access can remain available while remote transmission is active, so a project using Aernode Cloud or a configured external server can still read current station values locally where required. The main architectural decision is therefore where remotely transmitted data should be managed and which processing, storage, supervision and distribution functions the project wants Aernode Cloud or the external system to perform.
For integrators and technical project teams, the practical question is which data state each interface provides and where responsibility sits after the field measurement leaves the station.
How Aernode data can be accessed and routed
The Aernode monitor provides a local access channel and a configurable remote transmission path. Local access uses a pull model; remote transmission uses a push model. The two should not be treated as mutually exclusive architecture choices.
Local access through Modbus RTU
The Aernode Air Quality Monitor provides local data access through Modbus RTU over RS485. The downstream system actively reads the registers and receives the current measurement values available at the station when they are queried.
These are device measurement values, not unprocessed electrical sensor signals. The station has already performed the signal conversion and basic on-device processing or compensation needed to produce the measurement value exposed locally. Aernode Cloud centralized post-processing is not applied to the local Modbus value.
Local Modbus access can remain available while the station is also configured for remote transmission. If a local system needs history, additional processing, quality handling, reporting or distribution, those functions are implemented downstream only if required.
Direct transmission to an external server
Aernode can also be configured to transmit measurement data directly to a project-specific external server when the customer or integration partner wants to manage the remote data layer independently of Aernode Cloud. This is a remote push path: the station periodically sends records to the configured destination rather than waiting for the downstream system to query the device.
The transmitted record represents the aggregation defined for the parameter over the configured transmission interval. Depending on the variable and project configuration, that may be a mean, maximum, sum or another defined aggregate. The transmission interval defines when records are sent; it does not, by itself, define the aggregation function used to form every value.
The receiving server therefore gets a device-transmitted source record after the device-level processing required for measurement and transmission, but before the centralized adjustment, compensation and other post-processing that Aernode Cloud may apply using the applicable calibration model. If the project requires history, additional adjustment, QA, distribution, supervision or reporting, those functions are implemented in the customer or partner environment or intentionally omitted.
Transmission to Aernode Cloud
When the remote destination is Aernode Cloud, the station pushes its interval-based source records into the Aernode-managed data layer. Aernode Cloud receives the source record into the managed data layer and can then apply centralized adjustment, compensation and other post-processing using the applicable calibration model and processing configuration for the project or measurement channel.
The Cloud path separates the original device-transmitted record from the later adjusted dataset and adds managed history, supervision, user access, multi-site organization and authenticated downstream integration. External applications can consume Cloud-managed data through the Aernode REST API or supported exports rather than building the complete field-to-history layer themselves.
Local Modbus remains available independently of the remote transmission destination where local access is part of the device and project configuration.
Local values, transmitted records and Cloud-adjusted data are different
The same monitor can expose different data states at different points in the chain. They are not interchangeable simply because they refer to the same parameter or carry similar timestamps.
Local device value. A Modbus read returns the current measurement value available at the station at the time of the query. It includes the on-device signal conversion and basic processing required for that measurement, but not the centralized Aernode Cloud processing layer.
Device-transmitted source record. Remote transmission produces a record for the configured transmission interval using the aggregation defined for the parameter or project configuration. This is the record received by a directly configured external server, or by Aernode Cloud before centralized processing. Because it represents an interval-defined record rather than a point-in-time pull, it should not be expected to be numerically identical to a local Modbus value read at a nearby time.
Cloud source and adjusted datasets. Aernode Cloud stores the records received from the station as the Cloud source / raw dataset and also maintains adjusted data after centralized adjustment, compensation and other post-processing using the applicable calibration model. The historical resolution retained can depend on the applicable project and retention policy, while the distinction between source / raw and adjusted datasets remains explicit. In this context, Cloud raw means the original transmitted record before centralized adjustment. It does not mean an unprocessed electrical sensor signal, and it is not synonymous with a current local Modbus value.
A downstream application should know whether it is consuming a current device value, a transmitted source record, a Cloud source record or an adjusted dataset, and what temporal representation applies.
What does Aernode Cloud add?
Bypassing Aernode Cloud does not prevent Aernode from producing or transmitting measurement data. It means the project receives the data before the centralized Cloud processing and management stages, and any equivalent functions the project actually requires must be provided elsewhere.
Compared with local Modbus access and direct transmission to an external server, Aernode Cloud adds managed ingestion, history, centralized processing, dataset management, supervision and authenticated distribution. The table below shows the boundary without treating one path as inherently better than another.
| Capability / data characteristic | Local Modbus | External server | Aernode Cloud |
|---|---|---|---|
| Access / transport model | Local pull from device | Remote push from device | Remote push from device to Aernode-managed layer |
| Temporal representation | Current device value when queried | Record produced for configured transmission interval | Receives the same class of interval-based source record before Cloud processing |
| Aggregation | Current device measurement state; not the remote transmission aggregate | Parameter / configuration-defined aggregation for the interval | Source record reflects device transmission aggregation; additional Cloud processing may follow |
| Aernode Cloud post-processing | No | No | Yes, where configured |
| Original transmitted record retention | External architecture if required | External server responsibility | Stored as the Cloud source / raw dataset; historical resolution follows the applicable retention policy. |
| Adjusted dataset | External processing if required | External processing if required | Managed centrally where configured |
| Historical storage | External if required | External server if required | Aernode Cloud time-series history |
| Network / device supervision | Not provided by local data access itself | Not provided simply by receiving data | Aernode Web App / Cloud management layer |
| Authenticated downstream API | External architecture if required | External architecture if required | Authenticated Aernode REST API |
| Reporting / external use | External environment if required | External environment if required | Cloud data can feed API consumers and optional Reporting Tools |
| Local Modbus availability | This is the local access path | Can remain available in parallel with remote transmission | Can remain available in parallel with remote transmission |
The responsibility shift is most visible for projects using direct transmission to an external server. The station still produces and transmits the measurement record, but the customer or partner decides how that pre-Cloud record is stored, processed, supervised and distributed. Functions the project does not require can simply be omitted.
Inside the Aernode Cloud data layer
Aernode Cloud is organized around three functional layers. They turn the transmitted source record into a managed operational and data environment before measurements are distributed to other applications or reporting outputs.
Aernode Web App
The Web App is the operational interface for network management. It supports device status and network supervision, project configuration, user access, field-data review, calibration management and maintenance workflows. Remote diagnostics and configuration functions are available according to permissions and supported device functions.
Aernode Database
The database layer is the centralized environmental data backbone. It supports ingestion, time-series storage, historical data management according to the applicable retention and aggregation policy, Cloud source and adjusted datasets, metadata and calibration records, deployment-based organization and centralized post-processing. This is the main managed layer that a project using an external server would otherwise replace selectively in its own environment if those functions are required.
Aernode API
The Aernode API is the authenticated REST integration layer for Cloud-managed data. It makes selected Cloud datasets available to customer platforms, BI tools and analytical environments and supports structured exchange and exports such as CSV and JSON. Aernode Reporting Tools are a separate optional output layer for projects that need dashboards, historical analysis, reports, alerts or stakeholder-facing views.
Typical Aernode integration scenarios
Industrial local access. Aernode -> Modbus pull -> local gateway, SCADA or industrial data system. This suits industrial monitoring projects where current device values are needed inside an on-site operational environment. Remote transmission can still be configured independently for Cloud or external server use.
Partner-managed remote server. Aernode -> configured remote push -> partner or customer server. The receiving platform gets interval-based device-transmitted source records before Aernode Cloud centralized processing and manages whatever storage, additional adjustment, QA, API or reporting functions the project requires.
Aernode Cloud + customer platform. Aernode -> Aernode Cloud -> centralized history and processing -> authenticated REST API -> customer application. This path is useful when the external platform wants managed measurement history and defined Cloud data states without building the complete device-to-history layer.
Research / analytical workflow. Aernode -> Aernode Cloud -> source and adjusted datasets -> external analysis environment. This supports research workflows that need central history, traceable processing states and API or export access for their own analytical pipelines. Local Modbus may still be used separately when current field values are required on site.
What must be defined before integration starts?
Every project should define the meaning of the data at the integration boundary. Six questions are usually enough for pre-sales alignment:
- WHAT – Which parameter and unit must the receiving system consume?
- WHERE – How are the station, deployment and site identified?
- WHEN – What timestamp, sampling context and transmission interval apply?
- HOW IS THE VALUE FORMED – Is it a current local value or an interval-based record, and what aggregation rule applies where relevant: mean, maximum, sum or another defined aggregate?
- WHICH DATA STATE – Is the consumer using a local device value, a transmitted source record, a Cloud source / raw record or a Cloud-adjusted dataset?
- WHO OWNS THE NEXT STEP – Which system is responsible for storage, additional processing, QA or status handling, distribution, supervision and reporting?
Detailed register maps, remote-server transport settings, endpoint specifications, payload schemas and commissioning procedures belong in the applicable Aernode integration or partner technical documentation, not in this public Guide.
Which remote data path fits the project?
- Use direct transmission to an external server when the customer or partner wants to own the remote data layer and is prepared to implement or intentionally omit the downstream functions it requires.
- Use Aernode Cloud when the project wants Aernode to manage centralized history, source and adjusted datasets, post-processing, supervision and authenticated downstream access before data are consumed elsewhere.
Local Modbus does not need to be selected instead of either remote path. It is an independent local access channel that can remain available while remote transmission is active. The final design should therefore decide where remote data-management responsibility should sit, which data state each consumer needs and which functions belong in Aernode Cloud or the external system.
