Deploy a SubNode Application with WEDA

Use this guide after Build a SubNode Application. You need a published image and the application's configuration files. WEDA deploys the image to a WEDA Node; the running SubNode then registers and reports through that Node.

Creating an image or starting it manually with Docker Compose does not complete this WEDA deployment workflow. Check both the WEDA-managed container and the SubNode device and data.

Prepare the Target Node and Files

Before you start, confirm:

• The target WEDA Node is Activated, Connected and in your intended Org. Deploy to this Node's Device ID.
• The image is in a registry reachable by the Node and supports its CPU architecture. The walkthrough uses registry.example.com/weda/my-first-subnode:1.0.0; replace this illustrative image reference.
• The application was packaged without UseMockCloud(). Local demo dispatchers are removed if you adapted the custom-command example.
• You have the Node's local messaging endpoint and matching credentials.

On the Linux edge device, prepare these example paths:

Host path under /opt/Advantech/weda/node/my-first-subnode/	Contents
config/devicecfg.json	SubNode name, Device and Sensor settings
config/systemcfg.json	Local WEDA Node connection and authentication
config/appsettings.json	Logging and simulator configuration if used
config/customcfg.json	The generated custom configuration file
data/	A writable persistent directory for the application's runtime data

Copy the four configuration files from your application and adapt them for this device. Ensure each file exists before deployment. A WEDA Stack does not transfer these host files simply because the Compose definition references them.

For a Node using local username/password authentication, configure config/systemcfg.json as follows:

{
  "WedaNode": {
    "Url": "nats://127.0.0.1:4224",
    "AuthStrategy": "UserPassword",
    "Username": "YOUR_LOCAL_NATS_USERNAME",
    "Password": "YOUR_LOCAL_NATS_PASSWORD"
  }
}

Use the actual local-service credentials, not a Cloud API token. Match the authentication strategy to your Node. The SDK template's localhost:4222 is an example setting; the standard WEDA Node local messaging port is 4224.

Keep real credentials in the target configuration, outside the published image. Make the configuration files readable and the data directory writable by the container's runtime user. Retain the data directory across image updates.

Prepare the Image-Based Compose Definition

Save this as docker-compose.yaml, replacing the image and host paths as needed:

services:
  subnode:
    image: registry.example.com/weda/my-first-subnode:1.0.0
    network_mode: host
    restart: unless-stopped
    volumes:
      - /opt/Advantech/weda/node/my-first-subnode/config/devicecfg.json:/app/devicecfg.json:ro
      - /opt/Advantech/weda/node/my-first-subnode/config/systemcfg.json:/app/systemcfg.json:ro
      - /opt/Advantech/weda/node/my-first-subnode/config/appsettings.json:/app/appsettings.json:ro
      - /opt/Advantech/weda/node/my-first-subnode/config/customcfg.json:/app/customcfg.json:ro
      - /opt/Advantech/weda/node/my-first-subnode/data:/app/.weda

The generated SDK Compose file builds from a source checkout. This deployment definition uses image: so the target pulls the packaged application. Keep the exact image tag consistent with the version you published.

The example uses Linux host networking. Here, 127.0.0.1:4224 refers to the edge device's WEDA Node. In an isolated container network, loopback refers to the container; configure a reachable Node endpoint for that network.

Check the result: The Compose file references your published image and the prepared files on the target device. It contains no local build: dependency.

Register, Create the Stack and Deploy

Use the same Org throughout:

1. Configure registry access. In Registries, prepare a configuration for the image's registry host. Follow Registry Management. Your workstation's docker login used for pushing the image does not configure WEDA's registry access for deployment.

2. Create a Container Stack. In Container Stacks, create a Compose Stack named my-first-subnode and upload docker-compose.yaml. Follow Container Stack Management. Keep the saved stackConfigId and stackRevisionId.

3. Deploy the selected revision. Select Deploy, choose the target WEDA Node and submit. Follow Container Deployment & Commands for Console and REST steps. The deployment target is the parent Node, not the SubNode Device ID that the application obtains later.

4. Check the reported deployment. Match the Node, Stack and revision IDs. Confirm the subnode container is running and inspect pull, startup, configuration and connection errors.

Check the result: WEDA reports the intended Stack revision on the target Node, and its application container is running. Creating the Stack or accepting a deployment request alone does not verify that the SubNode has connected.

Verify the SubNode Device and DataStreams

Check the application side after container deployment:

1. In the target Node's Org, find the SubNode device. Use List devices by Organization to confirm type: SubNode and parentDeviceId matching the target Node. Record the SubNode's deviceId. Check its own connectivity as well as the parent Node's status.

2. Use List data streams with that orgId and SubNode Device ID. For synchronized Sensor streams, inspect managedBy: System, dataSource.type: WedaSubNode and dataSource.sourceEntityId, the source Sensor's resource ID. Check the expected name and dataType, then copy the dataStreamId.

3. Use Retrieve the latest value of a specific data stream with the same device and stream IDs. Confirm a recent dataObject.timestamp and the expected dataObject.value. Repeat while the source is reporting. 204 No Content means no latest value is available.

Check the result: WEDA manages the container, the SubNode appears under the correct Node, and its current readings reach Cloud. A running container or an Activated label alone does not establish this complete result.

Verify an Application-Defined Command

Use this step only if your image implements and declares a custom command. The basic template does not supply the RC example's sensor.read handler.

Cloud caller -> WEDA command API -> WEDA Node -> SubNode handler
Cloud caller <- Command history and result <- SubNode response

For the optional SDK v1.2 RC custom-command example described in the build guide:

1. Connect the adapted application through WEDA Node and confirm its uploaded command catalog declares sensor.read. Local demo dispatch does not check this catalog or Cloud authorization.

2. Follow Invoke Custom Commands using the SubNode's Device ID. The public REST request body for the example has this shape:

   {
     "deviceCommand": "sensor.read",
     "parameters": {
       "deviceName": "MyFirstDevice",
       "sensorName": "temperature_sensor"
     },
     "timeoutSeconds": 30
   }

   Use your actual configuration key and Sensor name. Do not send the SDK README's deviceCmd / respTopic envelope as the REST body.

3. After 202 Accepted, retain reqSeqId and follow the matching command history entry. Check its final result or failure and inspect the returned Sensor value and timestamp. Acceptance alone is not execution success.

Check the result: The request travels through Cloud and WEDA Node to your handler, and its correlated result contains the expected reading. The local example's tag.set and props.get are further references, not commands supplied by every SubNode.

Maintain and Troubleshoot the Deployment

Use WEDA's deployment and container commands for the managed Stack. For an application update, publish a new image tag, save a new Stack revision and deploy that revision. A container restart does not select a new revision.

Symptom	What to check
Image pull fails	Registry host, Org registry configuration, image tag, architecture and Node access to the registry
Container repeatedly restarts	Application logs, configuration-file existence and format, file permissions and startup failures
Container runs but no SubNode appears	UseMockCloud(), Node endpoint/authentication and SubNode registration errors
SubNode exists but no current values arrive	Sensor configuration upload, reporting settings, source connectivity, schema and telemetry-send errors
Local command works but Cloud invoke fails	Target SubNode ID, uploaded catalog, Org permissions, connectivity and command-specific parameters

Keep persistent runtime data when replacing the container. Local recording still depends on configured retention and available storage.

For connection alternatives, see the SDK Node-connection guide (v1.1.0). The SDK image build and architecture notes (v1.2 RC) provide additional packaging examples. Use the version-specific WEDA guides linked above for this Learning Hub's registry, Stack and deployment procedures.