Open source digital twin tools let you build a capable twin without licensing a proprietary platform, but no single project does everything. This guide compares the most useful options by the layer they cover (modeling, data integration, visualization and history) and explains how each one consumes MQTT data. By the end you will be able to assemble a stack that fits your use case instead of forcing your use case into one tool.
If you are still getting oriented, read the digital twin technology guide first.
Think in Layers, Not Platforms
A working twin needs four things:
- A model: what the asset is, its properties and relationships.
- Live data: current values flowing in from the field, and commands flowing out.
- Visualization: dashboards, 3D scenes or both.
- History: stored time series for trends, analysis and machine learning.
Open-source projects usually specialize in one or two of these. MQTT is the glue that lets them share one live data stream: gateways publish once, and every tool subscribes to what it needs. That is why the "how does it consume MQTT" column below matters as much as the feature list.
The Tools at a Glance
| Tool | Main layer | Model format | How it consumes MQTT | Good for |
|---|---|---|---|---|
| Eclipse Ditto | Model and twin state API | Things with attributes and features (JSON) | Built-in MQTT 3.1.1 and 5 connections with payload mapping | Device twins with REST/WebSocket APIs and search |
| Eclipse BaSyx | Model (Industry 4.0) | Asset Administration Shell submodels | Data bridge component subscribes to MQTT and updates submodels | AAS-based interoperability in manufacturing |
| FIWARE Orion-LD | Context model | NGSI-LD entities | IoT Agent for JSON or UltraLight over MQTT | Smart city and cross-domain context data |
| Node-RED | Integration and logic | Flows, any JSON | Native MQTT in and out nodes | Glue, transformations, quick dashboards |
| Three.js | 3D visualization | glTF scenes | MQTT.js over Secure WebSocket in the browser | Custom web 3D twins |
| Babylon.js | 3D visualization | glTF and Babylon scenes | MQTT.js over Secure WebSocket | Web 3D with built-in inspector and GUI |
| Telegraf + InfluxDB | History | Time-series measurements | Telegraf mqtt_consumer input plugin |
Storing telemetry for trends |
| Grafana | Dashboards | Panels over data sources | Via a database, or MQTT data source plugin | Operations dashboards and alerting |
Eclipse Ditto
Ditto is the most complete open-source "twin state" service. Each twin is a Thing with attributes (mostly static) and features (changing state). Ditto stores the current state, exposes it through REST and WebSocket APIs, supports search across things, and enforces fine-grained policies on who can read or write what.
Ditto connects to MQTT brokers through its connectivity service: you define a connection with source addresses (topics to subscribe), target addresses (topics to publish changes to) and a payload mapping that turns your device JSON into Ditto protocol messages. It works well when other applications want to query twin state over HTTP rather than subscribe to MQTT. Our Eclipse Ditto with MQTT guide walks through a full connection setup.
Watch out for: operational weight. Ditto runs as several services plus a database, so it suits teams comfortable with containers and Kubernetes.
Eclipse BaSyx
BaSyx implements the Asset Administration Shell (AAS), the standardized digital twin model from the Industry 4.0 community. An AAS describes an asset through submodels such as nameplate, technical data and operational data, with semantic IDs that make them understandable across vendors.
For live data, BaSyx's data bridge subscribes to sources such as MQTT topics and writes values into submodel elements. If your customers or partners expect AAS, BaSyx is the obvious open-source choice. The Asset Administration Shell guide explains the model.
Watch out for: the learning curve of AAS metamodels and semantic IDs. Start with standard submodel templates rather than designing your own.
FIWARE Orion-LD
FIWARE's context broker stores entities in NGSI-LD, a linked-data format well suited to cities, utilities and agriculture where data from many domains must be combined. IoT Agents translate device protocols, including JSON over MQTT, into entity updates. Choose it when you need cross-organization data sharing and a standard API, less so for a single factory cell.
Node-RED
Node-RED is not a twin platform, but it shows up in nearly every open-source twin stack because it makes integration fast. MQTT in and out nodes, function nodes for transformations and a dashboard add-on cover a surprising amount of a first twin. Typical jobs: normalizing vendor payloads into your schema, computing derived values, and bridging into a database or a twin service. See the official Node-RED documentation for installation and the MQTT nodes.
Watch out for: large flows becoming hard to version and review. Keep logic small and push complex models into proper services.
Three.js and Babylon.js
For 3D, the two leading open-source web libraries are Three.js and Babylon.js. Both load glTF models exported from CAD or Blender, and both run anywhere a browser does. Pair either with MQTT.js over Secure WebSocket and the browser subscribes directly to live state, no backend relay required.
Three.js is a lean rendering library with a huge community; you assemble controls, loaders and UI yourself. Babylon.js is more of a complete engine with a built-in inspector, GUI system and physics. The Three.js digital twin tutorial and Babylon.js digital twin guide show each in action.
Telegraf, InfluxDB and Grafana
The history layer is the least glamorous and most often forgotten. Telegraf's MQTT consumer plugin subscribes to topics and writes measurements into InfluxDB or another time-series store; Grafana then charts them. Here is a working Telegraf configuration against the public MQTT test broker, using a unique prefix:
[[inputs.mqtt_consumer]]
servers = ["tcp://broker.connectmq.com:1883"]
topics = ["connectmq/demo/ostw-3c9/site1/+/+/state"]
client_id = "ostw-3c9-telegraf"
qos = 0
data_format = "json"
topic_tag = "topic"
[[inputs.mqtt_consumer.topic_parsing]]
topic = "connectmq/demo/ostw-3c9/site1/+/+/state"
tags = "_/_/_/site/line/asset/_"
[[outputs.influxdb_v2]]
urls = ["http://localhost:8086"]
token = "$INFLUX_TOKEN"
organization = "plant"
bucket = "twin"
The topic_parsing block turns topic levels into tags, so Grafana can filter by line and asset without parsing strings. Publish a test message and it appears in the bucket:
mosquitto_pub -h broker.connectmq.com -p 1883 -i ostw-3c9-pub \
-t "connectmq/demo/ostw-3c9/site1/line2/oven1/state" -m '{"temp_c":212.4,"door_open":0}'
For production, switch the server to ssl://YOUR_BROKER_HOST:8883 and add username = "YOUR_USERNAME" and password = "YOUR_PASSWORD" from your broker portal.
Recommended Stacks
| Use case | Suggested combination |
|---|---|
| First asset twin with dashboards | MQTT broker + Node-RED + Telegraf/InfluxDB + Grafana |
| Interactive 3D operations twin | MQTT broker + Three.js or Babylon.js + Telegraf/InfluxDB |
| API-driven device twins for applications | MQTT broker + Eclipse Ditto + Grafana |
| Industry 4.0 interoperability | MQTT broker + Eclipse BaSyx + your visualization of choice |
| Cross-domain smart city data | MQTT broker + FIWARE Orion-LD and IoT Agent |
Notice the common element. Whichever tools you choose, one MQTT namespace feeds them all, so you can add or swap tools later without touching devices.
Selection Checklist
- Which layer is your biggest gap today: model, live data, visualization or history?
- Do partners or customers require a standard model such as AAS or NGSI-LD?
- Who will operate it? Multi-service platforms need container skills; Node-RED and Telegraf do not.
- How will each tool authenticate to the broker, and can you give each its own credentials?
- Does the tool support MQTT 5 if you rely on features like message expiry or shared subscriptions?
- Can you run a proof of concept in a day with your real topic structure?
The Piece Not to Self-Host
Open-source twin tools are easy to run in containers, but the broker that all of them depend on deserves extra care: it must stay up, accept TLS, authenticate dozens of clients and survive reconnect storms. Many teams keep the tools self-hosted and use a fully managed MQTT service for the backbone, or run a cloud MQTT broker close to their analytics.
ConnectMQ fits this pattern: Ditto, BaSyx's data bridge, Node-RED, Telegraf and browser viewers all connect to it as ordinary MQTT clients over TCP, TLS or Secure WebSocket. Its portal adds a live topic explorer and ISA-95 device view that help you verify data before wiring up each tool, and Sparkplug B decoding if your edge devices speak it.
Connect Your Open-Source Stack to ConnectMQ
Pick the tools for your gaps and give them one reliable backbone. Create a free ConnectMQ Serverless broker, no credit card required, then point Node-RED, Telegraf or Ditto at it in minutes.
Frequently Asked Questions
What is the best open source digital twin platform?
There is no single best one. Eclipse Ditto is strongest for twin state APIs, Eclipse BaSyx for Asset Administration Shell models, and Three.js or Babylon.js for 3D. Most real stacks combine several tools around an MQTT broker.
Does Eclipse Ditto support MQTT 5?
Yes, Ditto's connectivity service supports MQTT 3.1.1 and MQTT 5 connections, with configurable sources, targets and payload mapping.
Can Node-RED be a digital twin on its own?
For simple asset twins with dashboards, Node-RED can go a long way. As the twin grows, move models and history into dedicated tools and keep Node-RED for integration.
Do open-source twin tools need their own broker?
They need access to an MQTT broker, not necessarily their own. A shared, managed broker lets every tool consume the same namespace.
