Feature Request: Webhook / HTTP Callback Notifications on Register Changes

[cybcon]

Summary

Add support for configurable HTTP webhooks that notify external systems whenever a Modbus master writes to a register — enabling event-driven integration testing without polling.

Motivation

In integration test scenarios, it is often not enough to simply simulate a Modbus device — other systems in the test environment need to react to register write operations in real time. Currently, the only way to detect such changes is by continuously polling the mock server, which is cumbersome, error-prone, and adds unnecessary load. A webhook mechanism would allow external systems to be notified instantly and declaratively whenever a write occurs.

Proposed Behavior

When a Modbus master writes to a configured register, the mock server sends an HTTP POST request to a pre-configured callback URL:

POST https://your-test-system.internal/modbus-event
Content-Type: application/json

{
  "event": "register_write",
  "register_type": "holding",
  "address": 42,
  "value": 1337,
  "timestamp": "2024-11-05T14:23:00Z"
}

Configuration

Webhooks should be configurable per register, per register type, or globally as a catch-all. A simple configuration approach could look like this:

yamlwebhooks:
  - trigger: write
    register_type: holding
    address: 42
    url: https://your-test-system.internal/modbus-event
  - trigger: write
    register_type: coil
    url: https://your-test-system.internal/coil-event  # catch-all for all coils

Use Cases

• Asserting that a device-under-test correctly writes an expected value to a register during an automated test
• Triggering downstream actions in a test orchestration pipeline upon a register write
• Replacing fragile polling loops with clean, event-driven test logic
• Simulating supervisory systems that respond to PLC write operations

Expected Behavior

Webhook delivery should be attempted with a configurable timeout and retry count

• Failed deliveries should be logged clearly with status codes and response bodies
• Optionally, a secret/token header (e.g. X-Webhook-Secret) should be supported for basic authentication of the callback
• The feature should integrate naturally with the proposed REST API (see related feature request: REST API / HTTP Interface for Runtime Register Access)

Why This Matters

Modern integration testing demands event-driven workflows. Webhooks are a widely understood, zero-dependency mechanism that would make the mock server a first-class citizen in any automated test pipeline — enabling cleaner test design, faster feedback loops, and less boilerplate.