Edge SDK -- Configuration Guide

Overview

The Zequent Edge SDK is configured primarily through Quarkus application.properties and environment variables. Configuration covers the edge identity, gRPC service endpoints, MQTT broker settings (for adapters that use MQTT), and operational parameters.

Table of Contents


Configuration Methods

Priority Order (highest to lowest)

  1. Environment Variables (e.g., ZEQUENT_EDGE_SN)
  2. System Properties (e.g., -Dzequent.edge.sn=...)
  3. .env file (automatically loaded by Quarkus)
  4. application.properties (defaults)

Quarkus maps property names to environment variable names by converting to uppercase and replacing dots and hyphens with underscores. For example:

PropertyEnvironment Variable
zequent.edge.snZEQUENT_EDGE_SN
zequent.edge.asset-typeZEQUENT_EDGE_ASSET_TYPE
quarkus.grpc.clients.live-data-service.hostQUARKUS_GRPC_CLIENTS_LIVE_DATA_SERVICE_HOST

Edge Identity Configuration

These properties identify your edge adapter instance to the platform. They are mapped through the EdgeClientConfig interface using Quarkus @ConfigMapping(prefix = "zequent.edge").

PropertyEnvironment VariableRequiredDescription
zequent.edge.endpointEDGE_ADAPTER_TARGET_ENDPOINTSYesThe address this adapter is reachable at (host:port)
zequent.edge.snZEQUENT_EDGE_SNYesSerial number of the managed device
zequent.edge.asset-typeZEQUENT_EDGE_ASSET_TYPEYesAsset type enum value (see below)
zequent.edge.asset-vendorZEQUENT_EDGE_ASSET_VENDORYesAsset vendor enum value (see below)

Asset Type Values

ValueDescription
ASSET_TYPE_DOCKDocking station
ASSET_TYPE_DRONEStandalone drone
ASSET_TYPE_VEHICLEGround vehicle
ASSET_TYPE_RCRemote controller
ASSET_TYPE_UNKNOWNUnknown type

Asset Vendor Values

ValueDescription
DJIDJI
VENDOR_UNKNOWNUnknown vendor

Profile-specific Endpoint

The zequent.edge.endpoint property is typically set per profile to reflect the correct address for each environment:

# Dev: direct local address
%dev.zequent.edge.endpoint=localhost:9001

# Docker: configurable via env, defaults to service name
%docker.zequent.edge.endpoint=${EDGE_ADAPTER_TARGET_ENDPOINTS:edge-adapter-dji:9001}

# Kubernetes: use K8s service name
%k8s.zequent.edge.endpoint=edge-adapter-dji

Example

zequent.edge.sn=YOUR_DEVICE_SN
zequent.edge.asset-type=ASSET_TYPE_DOCK
zequent.edge.asset-vendor=DJI

gRPC Client Configuration

The edge adapter connects to platform services (Live Data, Connector) via gRPC. Each client is configured using the standard Quarkus gRPC client properties.

The adapter connects to three platform services. In local dev, set host and port directly. In Docker/Kubernetes, service discovery is handled via Stork (see below).

ServiceEnvironment Variable (Host)Default HostEnvironment Variable (Port)Default Port
Live DataLIVE_DATA_SERVICE_HOSTlocalhostLIVE_DATA_SERVICE_PORT8003
ConnectorCONNECTOR_SERVICE_HOSTlocalhostCONNECTOR_SERVICE_PORT8010
Mission AutonomyMISSION_AUTONOMY_SERVICE_HOSTlocalhostMISSION_AUTONOMY_SERVICE_PORT8004

Local Development

quarkus.grpc.clients.live-data-service.host=localhost
quarkus.grpc.clients.live-data-service.port=8003

quarkus.grpc.clients.connector-service.host=localhost
quarkus.grpc.clients.connector-service.port=8010

quarkus.grpc.clients.mission-autonomy-service.host=localhost
quarkus.grpc.clients.mission-autonomy-service.port=8004

Stork-based Service Discovery (Docker / Kubernetes)

In %docker and %k8s profiles, gRPC clients use Stork for service discovery instead of direct host/port configuration.

Docker (static list):

%docker.quarkus.grpc.clients.connector-service.name-resolver=stork
%docker.stork.connector-service.service-discovery.type=static
%docker.stork.connector-service.service-discovery.address-list=${CONNECTOR_SERVICE_HOST:connector-service}:${CONNECTOR_SERVICE_PORT:8010}
%docker.stork.connector-service.load-balancer.type=round-robin

Kubernetes (dynamic discovery):

%k8s.quarkus.grpc.clients.connector-service.name-resolver=stork
%k8s.stork.connector-service.service-discovery.type=kubernetes
%k8s.stork.connector-service.service-discovery.k8s-namespace=default
%k8s.stork.connector-service.service-discovery.application=connector-service
%k8s.stork.connector-service.service-discovery.refresh-period=5s
%k8s.stork.connector-service.load-balancer.type=round-robin

The same pattern applies for live-data-service and mission-autonomy-service.


MQTT Configuration

Many edge adapters use MQTT to communicate with the physical device (e.g., DJI docks use MQTT for OSD telemetry, service commands, and state updates). MQTT is configured through the SmallRye Reactive Messaging MQTT connector.

Broker Configuration

PropertyEnvironment VariableDescription
zequent.mqtt.broker.hostMQTT_BROKER_HOSTMQTT broker hostname
zequent.mqtt.broker.usernameMQTT_DOCK_USERNAMEMQTT username for dock communication
zequent.mqtt.broker.passwordMQTT_DOCK_PASSWORDMQTT password for dock communication

The reactive messaging channels use separate credentials for the cloud backend connection:

Environment VariableDescription
MQTT_USERNAMEUsername for cloud messaging channels
MQTT_PASSWORDPassword for cloud messaging channels
MQTT_BROKER_PORTMQTT broker port (default: 8883)

Channel Configuration Pattern

Each MQTT channel (incoming or outgoing) follows this pattern:

# Incoming channel
mp.messaging.incoming.<channel-name>.connector=smallrye-mqtt
mp.messaging.incoming.<channel-name>.topic=<mqtt/topic/pattern>
mp.messaging.incoming.<channel-name>.host=<broker-host>
mp.messaging.incoming.<channel-name>.port=8883
mp.messaging.incoming.<channel-name>.username=<username>
mp.messaging.incoming.<channel-name>.password=<password>
mp.messaging.incoming.<channel-name>.ssl=true

# Outgoing channel
mp.messaging.outgoing.<channel-name>.connector=smallrye-mqtt
mp.messaging.outgoing.<channel-name>.host=<broker-host>
mp.messaging.outgoing.<channel-name>.port=8883
mp.messaging.outgoing.<channel-name>.username=<username>
mp.messaging.outgoing.<channel-name>.password=<password>
mp.messaging.outgoing.<channel-name>.ssl=true

Typical Channels for a DJI Adapter

Channel NameDirectionTopic PatternPurpose
osdIncomingthing/product/+/osdOn-screen display / telemetry
stateIncomingthing/product/+/stateDevice state changes
statusIncomingsys/product/+/statusTopology updates
status_replyOutgoing(dynamic)Topology update replies
cloud-to-dockOutgoing(dynamic)Commands sent to the dock
services-replyIncomingthing/product/+/services_replyReplies to service commands
requestsIncomingthing/product/+/requestsDevice-initiated requests
drc-upIncomingthing/product/+/drc/upDRC (Direct Remote Control) upstream data

Object Storage Configuration

If your adapter needs to upload files (e.g., KMZ flight plans) to object storage:

PropertyEnvironment VariableDescription
storage.usernameS3_USERNAMES3 user identifier
storage.endpointS3_ENDPOINTS3-compatible endpoint URL
storage.access-keyS3_ACCESS_KEYAccess key
storage.secret-keyS3_SECRET_KEYSecret key
storage.regionS3_REGIONStorage region
storage.bucketS3_BUCKETTarget bucket name
storage.object-key-prefixS3_OBJECT_KEY_PREFIXPrefix for all object keys

Monitoring and Observability

All monitoring properties are disabled by default and should be enabled via environment variables.

PropertyEnvironment VariableDefaultDescription
quarkus.micrometer.enabledMICROMETER_ENABLEDfalseEnable Micrometer metrics
quarkus.micrometer.export.prometheus.enabledPROMETHEUS_ENABLEDfalseEnable Prometheus exporter
quarkus.micrometer.export.prometheus.pathPROMETHEUS_PATH/q/metricsMetrics endpoint path
quarkus.micrometer.binder.jvmMICROMETER_BINDER_JVMfalseEnable JVM metrics
quarkus.micrometer.binder.systemMICROMETER_BINDER_SYSTEMfalseEnable system metrics
quarkus.micrometer.binder.http-server.enabledMICROMETER_BINDER_HTTP_SERVER_ENABLEDfalseEnable HTTP server metrics
quarkus.micrometer.binder.grpc-server.enabledMICROMETER_BINDER_GRPC_SERVER_ENABLEDfalseEnable gRPC server metrics
quarkus.micrometer.binder.grpc-client.enabledMICROMETER_BINDER_GRPC_CLIENT_ENABLEDfalseEnable gRPC client metrics
quarkus.otel.traces.enabledOTEL_TRACES_ENABLEDfalseEnable OpenTelemetry tracing
quarkus.otel.metrics.enabledOTEL_METRICS_ENABLEDfalseEnable OpenTelemetry metrics
quarkus.otel.logs.enabledOTEL_LOGS_ENABLEDfalseEnable OpenTelemetry log export
quarkus.otel.exporter.otlp.endpointOTEL_ENDPOINThttp://jaeger-all-in-one:4317OTLP collector endpoint
quarkus.otel.resource.attributesOTEL_RESOURCE_ATTRIBUTESservice.name=edge-adapter-djiOTel resource attributes

Environment-Specific Examples

Local Development

zequent.edge.sn=YOUR_DEVICE_SN

quarkus.redis.hosts=redis://localhost:6379

zequent.mqtt.broker.host=your-broker.example.com

The gRPC client endpoints default to localhost on their respective ports in dev mode, so no extra configuration is needed unless the services run on different hosts.

Docker Compose

The docker profile uses Stork for service discovery. Set host/port via the short env var names:

services:
  edge-adapter:
    image: ghcr.io/zequent/edge-dji:latest
    ports:
      - "9001:9001"
    environment:
      - EDGE_ADAPTER_TARGET_ENDPOINTS=edge-adapter:9001
      - ZEQUENT_EDGE_SN=YOUR_DEVICE_SN
      - CONNECTOR_SERVICE_HOST=connector-service
      - CONNECTOR_SERVICE_PORT=8010
      - LIVE_DATA_SERVICE_HOST=live-data-service
      - LIVE_DATA_SERVICE_PORT=8003
      - MISSION_AUTONOMY_SERVICE_HOST=mission-autonomy-service
      - MISSION_AUTONOMY_SERVICE_PORT=8004
      - QUARKUS_REDIS_HOSTS=redis://redis:6379
      - MQTT_BROKER_HOST=your-broker.example.com
      - MQTT_USERNAME=backend
      - MQTT_PASSWORD=secret
      - MQTT_DOCK_USERNAME=dock
      - MQTT_DOCK_PASSWORD=secret

Kubernetes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: edge-dji
spec:
  template:
    spec:
      containers:
      - name: edge-dji
        image: ghcr.io/zequent/edge-dji:latest
        ports:
        - containerPort: 9001
        env:
        - name: ZEQUENT_EDGE_ENDPOINT
          value: "edge-dji:9001"
        - name: ZEQUENT_EDGE_SN
          valueFrom:
            secretKeyRef:
              name: edge-secrets
              key: device-sn
        - name: QUARKUS_GRPC_CLIENTS_LIVE_DATA_SERVICE_HOST
          value: "live-data-service"
        - name: QUARKUS_GRPC_CLIENTS_CONNECTOR_SERVICE_HOST
          value: "connector-service"
        - name: QUARKUS_REDIS_HOSTS
          value: "redis://redis:6379"

Troubleshooting

Problem: Adapter cannot connect to platform services

Check 1: Verify gRPC client settings:

echo $QUARKUS_GRPC_CLIENTS_LIVE_DATA_SERVICE_HOST
echo $QUARKUS_GRPC_CLIENTS_LIVE_DATA_SERVICE_PORT

Check 2: Test network connectivity:

nc -zv $QUARKUS_GRPC_CLIENTS_LIVE_DATA_SERVICE_HOST $QUARKUS_GRPC_CLIENTS_LIVE_DATA_SERVICE_PORT

Check 3: Look for connection errors in the logs:

gRPC stream failed for device XXXXX: UNAVAILABLE

Problem: Telemetry not arriving at the platform

Check 1: Verify the device serial number matches what is configured:

echo $ZEQUENT_EDGE_SN

Check 2: Look for telemetry stream logs:

Started gRPC telemetry stream for device XXXXX
Telemetry response received for device XXXXX

Check 3: Ensure the Live Data Service is running and reachable.

Problem: MQTT messages not being received

Check 1: Verify MQTT broker connection:

echo $ZEQUENT_MQTT_BROKER_HOST

Check 2: Check that MQTT topics match the device model's expected patterns.

Check 3: Look for MQTT connection logs on startup.

Problem: Configuration not taking effect

Check 1: Environment variables take precedence over application.properties. Verify no conflicting env vars are set.

Check 2: Quarkus caches configuration at startup. Restart the application after changing properties.

Check 3: Use Quarkus dev mode (./mvnw quarkus:dev) for live reload during development.

Was this page helpful?