dgiot: an Erlang/OTP industrial IoT platform built around device shadows and an ontology layer

The problem dgiot solves: one model across many field protocols

A factory floor rarely speaks one protocol. A PLC exposes Modbus registers, a newer controller answers OPC UA, and a gateway publishes MQTT. The usual answer is a pile of per-site scripts that each translate one device into one dashboard, and the translation logic lives nowhere in particular. dgiot's stated goal is to collapse that into a single pipeline. The README describes an FDE pipeline with six stages: Model, Ontology, Device Access, TimeSeries, Rules, Dashboard. The audience is an integration engineer or platform team who already knows the protocols and wants the modeling layer handled once rather than per deployment.

The repository is primarily Erlang, and the README's architecture diagram is explicit about the split between an edge component and the platform. The edge is iotStudio, described as Python plus Vue, with its own DeviceAccess, pipeline, stream engine and alert stages. The platform below it receives data over MQTT or HTTP. That division matters: dgiot is not trying to run the field collector itself, it expects an edge agent to publish into it.

How the DLAS layers and the shadow process actually fit together

The architecture is named DLAS and is drawn as four stacked layers: Data, Logic, Action, Security. The Data layer holds 23 Parse classes, TDengine, and Mnesia or ETS. The Logic layer is the ontology engine plus a model registry backed by three ETS tables, with a lifecycle the README lists as load_model, compile, spawn, evaluate, reason. The Action layer is where the interesting part sits: a Shadow process per device, implemented as an Erlang gen_statem, plus Bridge, MQTT and a rule engine. Security covers auth, a role tree, ACL and CLP, hooks, and JWT.

The state machine is spelled out in the diagram as init, auth, online, then a set of normal, alarm and offline states. Because each device gets a one-to-one process, device state is a live Erlang process rather than a row someone polls. The README's data flow example shows a Modbus register 40300 becoming an MQTT message on a topic shaped like dgiot/{site}/{gw}/{dev}/{pt}/data, which is routed to a shadow PID, evaluated against rules, transitioned, then parsed and inserted into TDengine. That is a coherent design and it is the reason the project is written in Erlang: one process per device is cheap in the BEAM, and gen_statem gives the state transitions a formal home.

Storage is split by purpose. TDengine holds telemetry, with the README noting a _{ProductId} naming convention and a devaddr column typed NCHAR(50). PostgreSQL, exposed on port 7432 in the Compose file, holds business data. Mnesia and ETS hold the model registry. The trade-off is real: you are now operating three storage systems, and the ontology docs are the place to check before assuming a query spans all of them.

Installing dgiot with Docker Compose and a first MQTT publish

The README calls Docker the recommended path for evaluation. Clone the repository and bring the stack up:

git clone https://github.com/dgiot/dgiot.git
cd dgiot
docker compose up -d

The Compose file defines postgres on host port 7432 with user dgiot, password dgiot_pass and database dgiot, redis on 16379, tdengine on 6030 and 6041, and a Parse Server container. The healthchecks use pg_isready and redis-cli ping, so you can watch the stack settle before touching it.

If you would rather build from source, the README gives a second path. The bootstrap script installs Erlang/OTP 24.3 and build tools on Ubuntu, Debian, CentOS, openEuler and macOS:

git clone https://github.com/dgiot/dgiot.git
cd dgiot
bash scripts/bootstrap.sh
make

The Makefile resolves rebar3 through scripts/ensure-rebar3.sh and runs scripts/fail-on-old-otp-version.escript first, so an old OTP fails early rather than mid-build. Once the stack is up, the data flow in the README tells you what a first message looks like: publish to a topic of the form dgiot/{site}/{gw}/{dev}/{pt}/data over MQTT, and the platform routes it to that device's shadow process. The README does not document a rollback or uninstall procedure, and it does not list default credentials for the Parse Server container in the excerpt available, so check the Compose file and docs directory before exposing anything.

Where dgiot is the wrong tool, and what the documentation leaves open

The first limitation is operational weight. A working deployment means PostgreSQL, Redis, TDengine, Parse Server and the Erlang release, each with its own backup story and upgrade cadence. If your requirement is to read twenty Modbus registers into a spreadsheet, this is several orders of magnitude more machinery than the job needs. A single Python script and a time-series file would be the honest choice.

The second is the documentation boundary. The README links an ontology document, a storage architecture document, a station simulation note, and a comparison page, but the top-level README itself is a diagram plus a module table. Several claims in the project's own description, such as the protocol count and the deploy time, are marketing framing rather than something the repository files substantiate. Treat the architecture diagram as the reliable part and verify the rest against docs/ before you quote it internally.

The third is the edge. Because iotStudio is a separate repository, the platform alone does not talk to a PLC. You need the edge agent or your own publisher. Anyone expecting a single clone to reach out and poll a device will be disappointed. Finally, the README does not document rollback, and the maintenance picture should be read from the dates: the last push was on 2026-09-11, with v4.9.3 released on 2026-08-11 and the previous release v4.9.2 back on 2025-03-21. The gap between those two releases is worth noting if you depend on a predictable upgrade rhythm.

dgiot against a general-purpose broker plus a hand-rolled collector

The obvious alternative is EMQX or Mosquitto as the broker, plus your own service that subscribes, parses and writes to a database. That approach is smaller and you understand every line. The difference in dgiot is the modeling layer: a model registry in ETS, an ontology compile step, and a per-device gen_statem that holds state between messages. With a plain broker you get message delivery and nothing else; device state, alarm transitions and the mapping from a register address to a named point are yours to build. dgiot's README also notes it runs EMQX 4.9 underneath, so the broker is not replaced, it is wrapped.

A second comparison the project itself draws is against Palantir, in docs/comparison.md, framed as "the brain and the limbs, complementary by design." That is positioning rather than a technical comparison, and the same docs directory contains a survey of open-source Palantir alternatives that the README describes as reality-checked. If you are evaluating this category, read that survey before the comparison page. The practical distinction to hold onto is that dgiot owns the device-to-model path and leaves analytics and BI to whatever you connect downstream, which the pragmatic enhancement architecture document sketches as Kafka plus TimescaleDB plus rules plus BI in four phases.

Editorial conclusion

Adopt dgiot if you have industrial devices speaking Modbus, OPC UA or MQTT and you want them modeled once, then read through a shadow process and a rule engine rather than writing a bespoke collector per site. Skip it if you want a mobile app for consumer gear: the repository is an Erlang platform, and the search traffic around a similarly named phone app and Wi-Fi camera does not describe this codebase. Before committing, verify two things yourself: that docker compose up -d brings up postgres, redis, tdengine and parse cleanly on your host, and that the version of EMQX and Erlang/OTP you plan to run matches what the README badges state, because the build path and the Compose path are not the same artifact.

Frequently asked questions

Official sources

1. dgiot/dgiot on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases