Protocol Support

MQTT / MQTTS

The dominant IoT messaging protocol. Publish/subscribe model, persistent sessions, QoS levels (0 = fire-and-forget, 1 = at-least-once, 2 = exactly-once), last-will messages, retained messages. MQTTS adds TLS encryption — mandatory for any production deployment.

Used by AWS IoT Core, Azure IoT Hub, Google Cloud IoT, TTN (LoRaWAN), and the majority of FIWARE IoT deployments today (via the iotagent-json and iotagent-ul agents). MQTT 5.0 adds shared subscriptions, message expiry, topic aliases, and user properties.

MQTT is the #1 protocol for FiWorks Multi-Agent. A native fw-lib means zero external dependencies, full integration with fwAlloc/fwHttp event loops, and the ability to handle MQTT and HTTP in the same thread without context switching.

CoAP / CoAPS

The Constrained Application Protocol — essentially HTTP semantics (GET, PUT, POST, DELETE) over UDP, designed for constrained devices with limited RAM, CPU, and battery. CoAP adds observe (server-push notifications), block transfer (chunked messages for constrained links), and resource discovery (.well-known/core).

CoAPS uses DTLS (TLS over UDP) for encryption. CoAP is the IETF's answer to "HTTP is too heavy for IoT" — and it's the wire protocol for LwM2M (OMA Lightweight M2M), used in cellular IoT, smart metering, and asset tracking.

Critical for LwM2M device management and constrained sensor networks. CoAP's 4-byte header vs HTTP's ~300 bytes makes it feasible for devices with 10 KB of RAM.

AMQP 1.0

The Advanced Message Queuing Protocol — enterprise-grade messaging with guaranteed delivery, transactional messaging, flow control, and sophisticated routing. Used by Azure Service Bus, Azure IoT Hub (AMQP mode), RabbitMQ, Apache ActiveMQ.

AMQP 1.0 is significantly more complex than MQTT: connection multiplexing (sessions and links), flow control (credit-based), message settlements (accepted, rejected, released, modified), and a rich type system (composite types, described types, arrays). Not worth building from scratch.

WebSockets

Full-duplex bidirectional communication over a single TCP connection, initiated via HTTP Upgrade. The standard for real-time web applications — live dashboards, real-time notifications, chat, collaborative editing. Also used as a transport layer for MQTT-over-WebSocket (browser MQTT clients) and STOMP.

For FIWARE 2.0, WebSockets enable live entity subscriptions from browsers — instead of the FiWorks Broker pushing notifications via HTTP POST to a callback URL, a web dashboard can open a WebSocket and receive entity updates in real time. This eliminates the need for a separate notification receiver service.

WebSockets are essential for modern FIWARE deployments. Every smart city dashboard, every real-time monitoring application, every browser-based IoT console needs them. Also serves as the transport for MQTT-over-WebSocket, enabling browser-based MQTT clients.

OPC-UA

The Open Platform Communications Unified Architecture — the modern standard for industrial communication. OPC-UA provides a rich information model (nodes, references, data types), discovery, security (X.509 certificates, encrypted channels), subscriptions (monitored items with sampling intervals), and historical data access.

OPC-UA is the lingua franca of Industry 4.0. Every major PLC vendor (Siemens, Beckhoff, Rockwell, ABB) exposes OPC-UA servers. FIWARE's current IoT Agent for OPC-UA (Node.js) uses the node-opcua library and is one of the most requested agents for industrial deployments.

OPC-UA is the #1 protocol for industrial FIWARE. Wrapping open62541 rather than reimplementing ensures compliance with the massive spec while keeping the fw-libs integration clean.

Modbus TCP

The oldest and simplest industrial protocol still in active use. Modbus TCP wraps the original Modbus RTU (serial) protocol in TCP frames. It reads/writes registers (16-bit words) and coils (bits) from PLCs, sensors, and actuators. No discovery, no security, no subscriptions — just raw register access. Simple, universal, everywhere.

Used in power meters, VFDs (variable frequency drives), water treatment, HVAC controllers, solar inverters — anywhere there's an industrial device older than 10 years or cheaper than $100.

BACnet

Building Automation and Control Networks — the standard for building management systems (BMS). HVAC, lighting, fire alarms, elevators, access control. BACnet defines object types (analog-input, binary-output, schedule, trend-log, etc.) and services (ReadProperty, WriteProperty, SubscribeCOV, WhoIs/IAm).

BACnet/IP runs over UDP with broadcast discovery. It's essential for smart buildings — any FIWARE deployment in a smart campus, hospital, or commercial building will encounter BACnet devices.

PROFINET

Siemens' industrial Ethernet protocol for real-time I/O in factory automation. PROFINET RT (real-time) runs at Layer 2 with cycle times of 1–10ms; PROFINET IRT (isochronous real-time) achieves sub-microsecond jitter for motion control. PROFINET operates at the Ethernet frame level, below TCP/IP.

Relevant only for Siemens-heavy factory floors. Most FIWARE industrial deployments use OPC-UA as the gateway to PROFINET controllers. Direct PROFINET support is a differentiator for edge deployments co-located with the PLC.

EtherNet/IP

Rockwell/Allen-Bradley's industrial protocol, dominant in North American manufacturing. Uses CIP (Common Industrial Protocol) over TCP (explicit messaging) and UDP (implicit I/O). Same CIP layer as DeviceNet and ControlNet.

Like PROFINET, most deployments will access EtherNet/IP controllers via OPC-UA. Direct support is for edge co-location scenarios.

KNX

The European standard for home and building automation. KNX connects light switches, blinds, HVAC valves, presence sensors, and energy meters over twisted pair (TP), powerline (PL), RF, or IP. KNXnet/IP tunnels KNX telegrams over UDP multicast, enabling integration from a standard network.

Essential for European smart building deployments. KNX installations are estimated at 500 million+ devices worldwide.

DDS (Data Distribution Service)

The OMG Data Distribution Service — a middleware for real-time publish/subscribe data distribution. DDS provides automatic discovery (no broker), QoS policies (reliability, durability, deadline, liveliness, ownership), content-based filtering, and deterministic latency. Used in autonomous vehicles, defense, aerospace, robotics (ROS 2), financial trading, and smart grids.

DDS is already part of the FIWARE ecosystem via the FIWARE DDS Enabler (based on eProsima Fast-DDS). FIWARE 2.0 deepens this integration — DDS topics can map directly to NGSI-LD entities, enabling FIWARE to act as a bridge between DDS domains and the NGSI-LD world.

Apache Kafka

The de facto standard for event streaming at scale. Kafka provides persistent, ordered, replayable event logs. In FIWARE, Kafka serves as a notification backbone — instead of the FiWorks Broker pushing HTTP notifications to each subscriber (which fails if the subscriber is down), events are published to Kafka topics. Subscribers consume at their own pace, with replay capability.

Kafka transforms FIWARE from a push-only notification model to a durable event stream. Subscribers can replay history, new subscribers get backfill, and the broker doesn't need to manage notification retry queues.

gRPC

Google's high-performance RPC framework based on HTTP/2 and Protocol Buffers. gRPC provides bidirectional streaming, flow control, connection multiplexing, and automatic code generation from .proto files. Used by Kubernetes, Envoy, gRPC-Web, and many cloud-native services.

For FIWARE 2.0, gRPC offers an alternative API surface for performance-sensitive clients — especially in cloud-native environments where gRPC is the expected wire protocol. NGSI-LD operations could be exposed as gRPC services alongside the REST API.

Server-Sent Events (SSE)

SSE is a simple, browser-native mechanism for server-to-client push over a long-lived HTTP connection. No upgrade handshake, no framing complexity — just text/event-stream with data: fields. The browser's EventSource API handles reconnection, last-event-id replay, and parsing automatically.

SSE is already part of the NGSI-LD API specification for subscription notifications. The FiWorks Broker should support it natively — a client subscribes and receives entity updates as SSE events. Simpler than WebSockets for unidirectional server-push.

SSE is the simplest path to real-time browser notifications. Unlike WebSockets, it works through HTTP proxies, CDNs, and load balancers without special configuration. For the common case (server pushes updates to client), SSE is the right tool.

NATS

NATS is an ultra-lightweight, cloud-native messaging system. Text-based protocol (like Redis), sub-millisecond latency, publish/subscribe + request/reply + queue groups. JetStream adds persistence, exactly-once delivery, and key-value/object stores. Used by Kubernetes (k3s), Synadia, and cloud-native microservices.

NATS is an attractive alternative to Kafka for lightweight deployments — a single NATS server binary (10 MB) vs a Kafka+Zookeeper cluster. For edge deployments where a full Kafka is overkill, NATS provides durable messaging with minimal footprint.