Files
pnoker 1fa2d6f0cf docs(comments): fill the real comment gaps across the repository
A comment-health audit driven by an AST scanner (regex scanners kept
false-positiving on annotation-separated javadoc; the AST pass with
constructor and @Override-implementation exemptions is what produced a
trustworthy worklist) ended with a much smaller true gap than the raw
numbers suggested: class-level javadoc is already at 100% repository-wide.

What actually gets filled here:

- AnalyticsModel: all 30 nested records of the S19 analytics facet get
  maintainer-voice javadoc (the @Schema descriptions serve the API side;
  these serve code readers).
- The whole entity/ext family (29 files, 47 nested classes): every
  Content/Ui/Validation/Security/AppliesTo/Template/Dedup/... schema
  class states what it actually holds — read from the fields, not
  templated.
- Adapter families: the @Bean methods of all six MQ adapters, all four
  TSDB adapters and the three DB dialect adapters get one-line
  maintainer docs (what binds to what, what is overridable).
- Nested support types across data/agentic/constant/public/facade:
  NotifyBindKey, CacheTuning, Credential, dashboard VOs' Item/BucketVO,
  ExpireListener (plus its null-doc placeholder javadoc replaced with a
  real contract), agentic chat/stream VOs' choice/delta/usage shapes,
  tool-context records, RequestHeader envelopes, FleetSummary,
  visualization Type/Scale codes.
- PointValueSampleConverter's boundary methods now state the port-side
  contract (quality default injection point, batch order preservation).

Comment drift fixed: the class javadoc of the can/mqtt/opc-da driver
skeletons claimed "see TODO markers in method bodies" — those markers
do not exist; the claims are corrected to plain work-in-progress notes.
The genuine TODOs (zigbee API verification, lwm2m lookup, ethernet-ip
CIP framing, CAN JNI) stay: they mark real unimplemented behavior.

Vendored-code boundary: the opc-da module carries a ported
org.openscada library (46 files, package org.openscada.*). Its trivial
accessors stay bare on purpose — filler comments on get/set pairs are
exactly the kind of noise this pass exists to remove — but the
non-obvious JIStruct wire-decoder methods (getStruct/fromStruct
FILETIME + three DO wrappers) now document the COM bridge shape.

Gates: full-repo compile green; data/model/constant/agentic/public
test suites green.
2026-08-24 21:23:39 +08:00

2.3 KiB

DC3 Driver Virtual

Overview

dc3-driver-virtual is the Virtual Driver of the IoT DC3 platform, designed for testing and development purposes. It simulates device communication by generating random point values on a configurable schedule without connecting to real hardware.

Module Information

  • Group ID: io.github.pnoker
  • Artifact ID: dc3-driver-virtual
  • Driver Name: Virtual Driver

Driver Attributes (Device-level)

Attribute Description
Host Simulated target hostname
Port Simulated target port

Point Attributes

Attribute Description
Tag Point tag identifier

Command Attributes (write)

Attribute Description
Payload Template Template for the command payload
Response Template Template for parsing the response

Event Attributes

Attribute Description
Event Code Path Path to the event code in payload
Payload Path Path to the event payload

Data Collection Schedule

The module application.yml and its profile-specific variants are authoritative for attribute codes, types, default values, scheduling, health, and local buffering. Keep this README aligned when that metadata changes.

Configured in application-dev.yml:

dc3:
  driver:
    schedule:
      read:
        cron: '0/1 * * * * ?'   # Every second

Running Locally

1. Start Infrastructure and Center Services

make up-db
make up-dev GROUP=core

2. Build and Run

mvn -s .mvn/settings.xml -pl dc3-driver/dc3-driver-virtual -am package
java -jar dc3-driver/dc3-driver-virtual/target/dc3-driver-virtual.jar

3. Verify Registration

The driver logs show gRPC registration with Manager Center on startup:

Driver register success, service name: dc3-driver-virtual

Testing

Run the module tests from the repository root:

mvn -s .mvn/settings.xml -pl dc3-driver/dc3-driver-virtual -am test
  • dc3-common-driver — Driver SDK for registration, scheduling, and RabbitMQ integration