# What Is WEDA SubNode? Connecting Industrial Devices to WEDA **URL:** \ **Category:** WEDA Developer Zone\ **Created:** [September 21, 2026, 5:20am UTC](https://forum.aim-linux.advantech.com/t/what-is-weda-subnode-connecting-industrial-devices-to-weda/1522 "2026-09-21T05:20:48Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![AlvinCA.Wang](https://avatars.discourse-cdn.com/v4/letter/a/b5a626/32.png) [@AlvinCA.Wang](https://forum.aim-linux.advantech.com/u/AlvinCA.Wang)\ **Post date:** [September 21, 2026, 5:20am UTC](https://forum.aim-linux.advantech.com/t/what-is-weda-subnode-connecting-industrial-devices-to-weda/1522/1 "2026-09-21T05:20:48Z")
# What Is WEDA SubNode? Connecting Industrial Devices to WEDA ```plaintext Industrial equipment | | Modbus / MQTT / HTTP v SubNode application | v WEDA Node | v WEDA Core ``` **WEDA SubNode brings industrial device data into WEDA through an application running at the edge.** It handles device communication and configurable data processing, while WEDA Node provides the connection to WEDA Core. Connecting a PLC or sensor involves more than reading a value. You also need to interpret the data, apply calibration, define reporting intervals, and make the results available to your applications. SubNode provides reusable components for these tasks, so you can focus on the equipment and application logic. This article introduces the C#/.NET SubNode SDK and shows how to run your first application with simulated data. ## Where SubNode Fits In a deployed WEDA environment, a SubNode application runs as a container on an edge gateway alongside WEDA Node. It reads equipment data, applies any configured processing, and publishes telemetry to WEDA Node for forwarding to WEDA Core. A SubNode application appears as a device in WEDA. Its configured sensors become DataStreams that can be used by capabilities such as Alert Policies and Reports. For the platform integration details, see [SubNode in the WEDA Learning Hub](https://learn.advantech.com/weda/docs/Function_Explanation/SubNode/). ## How SubNode Organizes Your Equipment ```plaintext SubNode application +-- Device: Power meter | +-- Sensor: Voltage | +-- Sensor: Current | +-- Sensor: Power +-- Device: Environmental monitor +-- Sensor: Temperature +-- Sensor: Humidity ``` Within the SDK, a SubNode application groups devices, and each device contains sensors representing individual measurements. For example, a power meter can expose voltage, current, and power as separate sensors. Each sensor can have its own reporting and processing configuration. The `Device` objects in this hierarchy belong to the application’s SDK model; they should not be confused with separate cloud device registrations. For supported device types, you can configure connections and sensor mappings through JSON. When you need custom behavior, you can extend the SDK in C#. ## What the SDK Provides SubNode combines several building blocks for device integration: | Capability | What you can do | | --- | --- | | Device communication | Work with protocols such as Modbus TCP/RTU, MQTT, and HTTP, or implement a custom integration. | | Sensor configuration | Define measurements and reporting intervals in `devicecfg.json`. | | Data processing | Apply calibration, unit conversion, and filters before reporting telemetry. | | Application development | Start from project templates and extend device behavior using C# interfaces and classes. | A sensor’s processing path can look like this: ```plaintext Raw measurement | v Transform: calibration or unit conversion | v DSP filter: moving average or Kalman filter | v Processed telemetry ``` Transforms run before DSP filters, and both stages are optional. For example, you might calibrate a temperature reading and then apply a moving average to smooth fluctuations. See the [Data Pipeline guide](https://github.com/Advantech-WEDA/WEDA-Sub-Node/blob/release/v1.1.0/docs/wiki/en/05-data-pipeline/01-overview.md) for configuration examples. ## Run Your First SubNode Application You can explore the SDK before connecting physical equipment. The `wedabuilder` template includes a Modbus simulator and uses a mock cloud service by default. You need **Git and the .NET 10 SDK**. The [repository README](https://github.com/Advantech-WEDA/WEDA-Sub-Node) describes local setup and the available Dev Container environment. The following example uses the public `release/v1.1.0` branch: ```bash git clone --branch release/v1.1.0 https://github.com/Advantech-WEDA/WEDA-Sub-Node.git cd WEDA-Sub-Node dotnet new install ./templates/wedabuilder mkdir apps cd apps dotnet new wedabuilder -n MyFirstSubNode cd MyFirstSubNode dotnet run ``` Create the project under `apps/` as shown. The template uses relative references to the SDK source inside the repository. With the default template configuration, the application: - Starts a local Modbus simulator. - Connects to `127.0.0.1:5020`. - Reports the configured `temperature_sensor` at a one-second interval. - Uses a mock cloud service to exercise the application locally. **This sandbox does not upload telemetry to WEDA Core.** Connecting to WEDA requires a running WEDA Node and the corresponding connection configuration. The [Start with Template guide](https://github.com/Advantech-WEDA/WEDA-Sub-Node/blob/release/v1.1.0/docs/wiki/en/02-getting-started/03-start-with-template.md) explains the generated files and how to customize the application. The current defaults are available in the [template configuration](https://github.com/Advantech-WEDA/WEDA-Sub-Node/blob/release/v1.1.0/templates/wedabuilder/devicecfg.json). ## Try It with Your Equipment Once the simulator is running, choose one measurement from your equipment and map it to a SubNode sensor. Start by checking the raw value, then add any required calibration or filtering. For source code, templates, and device examples, explore the [WEDA SubNode repository](https://github.com/Advantech-WEDA/WEDA-Sub-Node). What equipment are you connecting to WEDA, and which protocol does it use? Share your use case in the comments.