Back to AMQP Module

Releases

AMQP / RabbitMQ Module for Ignition 8.3

Every published version of the module, with the Ignition and broker versions it has been verified against, plus a direct download for the .modl asset and the user manual.

  1. v1.0.1

    v1.0.121 Sept 2026

    AMQP 0-9-1 / RabbitMQ connectivity for Ignition 8.3: broker connections, Event Stream source and handler, system.amqp scripting, and a MassTransit-compatible preset.

    Ignition:
    8.3.0+
    Broker:
    RabbitMQ 3.8+ (AMQP 0-9-1)
    Other:
    Event Stream module (optional, for the AMQP source and handler)

    Changes

    • Fixed: the AMQP Consumer could stop receiving messages while its connection still showed as healthy. It happened with messages carrying a header whose value is empty (null), which RabbitMQ produces for devices that publish over AMQP 1.0 and send null properties. IPC-CFX equipment does this on every heartbeat. Once the number of these messages reached the prefetch count, the stream stalled. They are now received normally and the empty header is kept. Scripts can also send None as a header value.
    • Fixed: message bodies compressed with gzip or deflate reached the decoder still compressed. They are now decompressed first, up to 128 MiB, both in the AMQP Consumer and in system.amqp.getMessage. A message forwarded to an error queue keeps its original compressed body.
    • A message whose properties cannot be read is no longer left unacknowledged on the queue for good. It goes to the error queue with its body and envelope intact, or is discarded with a log line when no error queue is configured.
    • The README and user manual now explain how to consume messages from devices that publish over AMQP 1.0 to RabbitMQ 4, such as IPC-CFX equipment, and why no translation layer is needed in between.

    Known issues

    • There is no store-and-forward outbox. A publish attempted while the broker is unreachable fails immediately instead of being buffered.
    • Static handler headers cannot be edited in the Designer. Opening and saving a file-provisioned event stream there drops any headers configured in its config.json.
    • Confirm Mode PER_BATCH and PER_MESSAGE currently behave the same way. Every message is confirmed individually.
    • A config edit made immediately after another one can be missed by a single configuration scan. This is Ignition platform behaviour and it is silent, so re-scan until the Gateway's view agrees.
    • A device that publishes over AMQP 1.0 and sends its body as an amqp-value or amqp-sequence section, rather than a data section, is not supported: RabbitMQ delivers those messages in a format the module does not decode. IPC-CFX and most devices that send JSON over AMQP use data sections and are not affected.
  2. v1.0.0

    v1.0.028 Jul 2026

    AMQP 0-9-1 / RabbitMQ connectivity for Ignition 8.3: broker connections, Event Stream source and handler, system.amqp scripting, and a MassTransit-compatible preset.

    Ignition:
    8.3.0+
    Broker:
    RabbitMQ 3.8+ (AMQP 0-9-1)
    Other:
    Event Stream module (optional, for the AMQP source and handler)

    Changes

    • Licensed module. The EULA ships inside the .modl and is shown on install. The module is fully functional during Ignition's standard trial period, and a purchased licence is activated under Platform > System > Licensing.
    • Broker connections are Gateway config resources, listed and health-checked under Connections > Service Connectors.
    • Multi-node host lists, TLS with optional hostname verification, and automatic recovery with exponential backoff.
    • The broker password is stored as an Ignition secret, either embedded ciphertext or a Referenced secret provider, and resolved on every connect attempt, so a rotated secret needs no restart. The username accepts ${ENV_VAR} indirection.
    • Several broker connections can run side by side. One that faults does not affect the others.
    • Event Stream source "AMQP Consumer": prefetch-based backpressure, ON_HANDLED, ON_DELIVERY and AUTO ack modes, and DEAD_LETTER, REQUEUE or DROP failure handling with bounded redeliveries.
    • Event Stream handler "AMQP Publisher": publisher confirms, mandatory and persistent flags, {metadata} placeholders in routing keys, static headers, and a Designer dry run.
    • MassTransit preset for both the source and the handler, covering the full envelope, MassTransit's RabbitMQ topology conventions, and MT-Fault-* headers on dead-lettered messages.
    • system.amqp.* scripting: connection info, publish, MassTransit publish, encode and decode, topology declaration, and queue inspection. Failures raise Python exceptions, so a script's "except Exception:" catches a failed call.
    • The Direct endpoint style has an Error Queue, so On Failure = DEAD_LETTER keeps failed messages there instead of discarding them. With no error endpoint configured, the discard is logged at startup and per message rather than happening silently.
    • Designer editors for the source and the handler, with hover help on every field and a live topology preview.

    Known issues

    • There is no store-and-forward outbox. A publish attempted while the broker is unreachable fails immediately instead of being buffered.
    • Static handler headers cannot be edited in the Designer. Opening and saving a file-provisioned event stream there drops any headers configured in its config.json.
    • Confirm Mode PER_BATCH and PER_MESSAGE currently behave the same way. Every message is confirmed individually.
    • A config edit made immediately after another one can be missed by a single configuration scan. This is Ignition platform behaviour and it is silent, so re-scan until the Gateway's view agrees.