Skip to content

feat(mqtt-bridge): add continuous polling mode#383

Open
groupsky wants to merge 5 commits intomainfrom
feat/mqtt-bridge-continuous-polling
Open

feat(mqtt-bridge): add continuous polling mode#383
groupsky wants to merge 5 commits intomainfrom
feat/mqtt-bridge-continuous-polling

Conversation

@groupsky
Copy link
Copy Markdown
Owner

Summary

Adds continuous polling mode that polls devices with minimal delay (1ms) instead of waiting for the configured interval. This enables maximum data throughput for time-sensitive applications where users want to read from devices as fast as possible.

Implementation

  • Type Definition: Added optional mode field to PollingConfig type ('interval' | 'continuous')
  • Scheduler Logic: Modified scheduleNextPoll() to use 1ms delay for continuous mode
  • Validation: Added Zod schema validation for the mode field
  • Tests: Comprehensive test coverage including backoff behavior in continuous mode
  • Documentation: Updated README with configuration examples and explanations

Configuration Example

{
  "deviceId": "sensor1",
  "driver": "@ya-modbus/driver-ex9em",
  "connection": {
    "type": "rtu",
    "port": "/dev/ttyUSB0",
    "baudRate": 9600,
    "slaveId": 1
  },
  "polling": {
    "interval": 2000,
    "mode": "continuous"
  }
}

Technical Details

Why 1ms instead of 0ms?

  • Prevents test infinite loops with Jest fake timers
  • Allows other event loop tasks to execute
  • Matches real-world setTimeout(..., 0) behavior
  • Still provides effectively immediate polling (next event loop tick)

Backoff Logic

  • Continuous mode respects maxRetries and retryBackoff settings
  • After exceeding maxRetries, uses retryBackoff interval
  • On success, returns to continuous mode (1ms delay)

Testing

All 298 tests pass, including new tests for:

  • Continuous mode polling with minimal delay
  • Default mode when not specified (interval)
  • Backoff behavior in continuous mode
  • Recovery to continuous mode after backoff

Breaking Changes

None - this is a backward-compatible feature addition.

Checklist

  • Tests added and passing
  • Documentation updated
  • Type definitions updated
  • Validation added
  • Backward compatible

Add optional 'mode' field to PollingConfig to support:
- 'interval' (default): Poll at fixed intervals
- 'continuous': Poll immediately after receiving response

This enables maximum data throughput for time-sensitive applications.
Add test coverage for:
- Continuous mode polls immediately (0ms delay) after response
- Default mode remains interval-based when not specified
- Backoff logic still applies in continuous mode
- Recovery from backoff returns to continuous mode

Tests currently fail - implementation follows in next commit.
Add continuous polling mode that polls devices with minimal delay
(1ms) instead of waiting for the configured interval. This enables
maximum data throughput for time-sensitive applications.

Implementation:
- Check polling mode in scheduleNextPoll()
- Use 1ms delay for continuous mode (next event loop tick)
- Use interval delay for interval mode (default)
- Backoff logic applies to both modes when maxRetries exceeded

The 1ms delay (vs 0ms) ensures:
- Minimal latency while avoiding test infinite loops
- Allows other event loop tasks to execute
- Matches real-world setTimeout(fn, 0) behavior
Add Zod schema validation for the optional polling mode field:
- Accepts 'interval' (default behavior)
- Accepts 'continuous' (minimal delay between polls)
- Rejects invalid mode values

Test coverage:
- Valid interval mode configuration
- Valid continuous mode configuration
- Invalid mode value rejection
Add documentation for the new polling mode configuration option:
- Explain interval vs continuous modes
- Show example configuration with continuous mode
- Document the minimal 1ms delay for continuous polling

Users can now configure devices for maximum throughput by using
continuous mode, which polls immediately after receiving responses.
@pkg-pr-new
Copy link
Copy Markdown

pkg-pr-new bot commented Feb 21, 2026

Open in StackBlitz

@ya-modbus/cli

npm i https://pkg.pr.new/@ya-modbus/cli@383

@ya-modbus/device-profiler

npm i https://pkg.pr.new/@ya-modbus/device-profiler@383

@ya-modbus/driver-ex9em

npm i https://pkg.pr.new/@ya-modbus/driver-ex9em@383

@ya-modbus/driver-loader

npm i https://pkg.pr.new/@ya-modbus/driver-loader@383

@ya-modbus/driver-or-we-516

npm i https://pkg.pr.new/@ya-modbus/driver-or-we-516@383

@ya-modbus/driver-sdk

npm i https://pkg.pr.new/@ya-modbus/driver-sdk@383

@ya-modbus/driver-types

npm i https://pkg.pr.new/@ya-modbus/driver-types@383

@ya-modbus/driver-xymd1

npm i https://pkg.pr.new/@ya-modbus/driver-xymd1@383

@ya-modbus/emulator

npm i https://pkg.pr.new/@ya-modbus/emulator@383

@ya-modbus/mqtt-bridge

npm i https://pkg.pr.new/@ya-modbus/mqtt-bridge@383

@ya-modbus/transport

npm i https://pkg.pr.new/@ya-modbus/transport@383

commit: e03914d

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant