IoT Message Encoders and Decoders

A broker moves message payloads without interpreting them, so the format of a message must be consistently used by both publisher and subscriber. An encoder turns GENESIS data into the payload a publisher connection sends; a decoder turns an arriving payload into points, datasets, or events that the rest of GENESIS can use.

Every publisher connection selects one encoder and every subscriber connection selects one decoder, in the General Settings section of the connection. This works the same way for MQTT and AMQP connections alike, because the format of a payload is independent of the transport that carries it.

Built-in Encoders and Decoders

The following formats are installed with the Internet of Things Encoders component and appear in the Encoder and Decoder lists without any configuration.

Format	Description
JSON	The native GENESIS message format, in JSON. Carries point names, values, timestamps, quality, and address space information, so GENESIS clients can browse the far end and call methods on it.
JSON Gzip	The native JSON format, compressed.
Binary	The native GENESIS message format, in a compact binary encoding. Carries the same information as JSON in a smaller, non-human-readable form.
Binary Gzip	The native binary format, compressed.
Mitsubishi FX5-ENET JSON	Available as a decoder only. Decodes the telemetry JSON published by Mitsubishi Electric MELSEC iQ-F devices through an FX5-ENET module, in which the topic identifies the device and the payload is a flat object of tag name and value pairs. Select it to read these devices directly, with no custom format to define. The Mitsubishi FX5-ENET JSON decoder reads its options from C:\ProgramData\ICONICS\11\Data\IoT\MitsubishiFX5-ENET.config.json. By default it exposes the data type and access rights of each decoded tag.
OPC UA PUBSUB	Handles messages in the OPC UA PubSub JSON format, for interoperating with OPC UA publishers that use a broker rather than a client-server session.

Additionally, you can create your own custom encoder or decoder and use it with a connection.

Subscribing Without a Decoder

A subscriber connection does not have to name a decoder. When the Decoder field is left as No Decoder, arriving messages are not interpreted at all: each one is forwarded as an event carrying the raw payload and its topic.

This is useful in two situations. It is the quickest way to confirm that a broker connection works and to see what a device is actually sending before you write a decoder for it. It is also a legitimate end state, because an event carrying a raw JSON payload can be picked up by an Alarm Viewer or used to trigger a Bridging transaction that parses the payload with a JSON Content Reader activity.

Custom Formats

Where none of the built-in formats matches a device, the CustomJson plug-in lets you describe that device's message layout in Workbench rather than in code. You select a message type for the overall shape of the payload, then write format templates in which keywords such as %VALUE% and %PUBLISHNAME% mark each piece of information GENESIS reads or writes. Learn more

Decoders Written in Code

Where a device's messages are not JSON at all, or the transformation needed is more than a template can express, a decoder can be implemented as a .NET plug-in and registered with the Internet of Things Subscriber. It then appears in the Decoder list alongside the built-in formats. Learn more