SL651 Driver

dc3-driver-sl651 connects SL651-2014 hydrological telemetry stations to IoT DC3 — it listens on a TCP port, passively receives telemetry reports pushed by remote stations, and turns the element at a configured position in the report body into a point value.

SL651-2014 is the hydrological monitoring data communication protocol used in the water-conservancy industry. Unlike field protocols such as Modbus, where the master actively reads slaves, SL651 is a server-side protocol: telemetry stations scattered in the field (rain gauges, water-level stations, etc.) push their collected data to a central server on their own schedule. This driver is that central server — it starts an SL651 TCP server on a listen port, waits for stations to connect and report, parses the telemetry elements out of the report body, matches the station address to a Device, and forwards the configured element as a PointValue.

Because data arrives asynchronously and unsolicited from the stations, this is a listener driver rather than a polling one: the SDK read/write methods do not participate in collection (by design read returns null and write returns false), scheduled reads are disabled (schedule.read.enable: false), and only the device health check remains.

• Driver name / code: SL651 Hydrological Telemetry Driver / Sl651Driver
• Type: DRIVER_CLIENT

Terms first

• Station address: the address in the SL651 report header that identifies the sender. The driver takes its hex string and matches it against the device's deviceCode or deviceName (case-insensitive).
• Telemetry element: an ordered list of measured values in one report body (water level, rainfall, voltage, …); a Point picks one of them by its index index.

Driver configuration (device-level driver-attribute)

When onboarding an SL651 station, fill in these attributes on the Device:

Attribute	code	Type	Default	Description
Listen Port	port	INT	5001	TCP port the SL651 server listens on
Auth Password	pwd	STRING	0000	Remote station authentication password

The port is driver-level and shared by every station in the process

port decides which TCP port the whole driver process listens on; every station reporting to that port shares one server. Different stations are distinguished by their station address (i.e. the device's deviceCode/deviceName), not by port. Changing port triggers a server restart.

Point configuration (point-attribute)

Each collected Point needs just one attribute — its index into the report body's element list:

Attribute	code	Type	Default	Description
Element Index	index	INT	0	Zero-based index into the telemetry body element list

When a report arrives from a station, the driver collects all elements in the report body into an ordered list; the Point's index selects which one to take (index=0 takes the first). Points whose index is out of range are skipped for that round.

Collection and health

• Collection mode: passive listening, with no active read cycle (schedule.read.enable: false). The driver does have an internal custom schedule cron 0/5 * * * * ?, but collection itself is triggered by station reports and is not bound to that cycle.
• Health/online: device health check defaults to cron 0/15 * * * * ?, with a lease timeout of 45 seconds — a station that reports within the timeout is considered online; see Device for the mechanism.

Minimal onboarding example

Onboard a water-level station with station address 12345678 reporting to local port 5001:

1. Create a Device using SL651 Hydrological Telemetry Driver, and set the device code deviceCode to 12345678 (it must match the address the station reports), with driver attributes port=5001 and pwd=0000.
2. Add a water-level Point to the Profile bound to the device (set pointTypeFlag to match the reported element's actual type, READ_ONLY), and set the point attribute index=0 (take the first element of the report body).
3. Start the driver and let the station push data; as soon as the station reports, the matched Point shows up in PointValue.

Common pitfalls

The device code must equal the station address, or the data is dropped

The driver matches the station address (hex string) in the report header against the device's deviceCode or deviceName (case-insensitive). If they do not match, the report is silently dropped — you will see the driver receiving reports yet no point values. Confirm the address the station actually reports, and copy it verbatim into deviceCode before onboarding.

index is the "Nth element" of the body, not a register address

index is the element-list index the driver parses out, zero-based, matching the order of elements in the station's report one-to-one. It is not an SL651 identifier code, nor any register address. The element order is determined by the station configuration, so confirm which value each index maps to against the station's report content before onboarding.

This is a read-only listener driver — do not configure write commands

In this driver SL651 only receives reports and never sends downstream — write returns false by design, so there is no command-attribute, and configuring a write command on a Point has no effect. For remote control of a station, use the station's own downlink channel; it is outside this driver's scope.

Further reading

• Driver — the general driver model and registration mechanism
• Attribute and Config — the three-layer origin of attributes like port / index
• Device onboarding — a complete onboarding walkthrough
• IEC104 Driver — another industrial SCADA protocol driver
• Listening Virtual Driver — the same passive-listener, report-triggered collection paradigm