Published Tuesday, August 11, 2026 at 12:27 PM PT
Burbank · Tuesday, August 11, 2026 · 12:27 PM · 87°F, 45% humidity, wind 2 mph WSW, 29.44 inHg, UV 0, PM2.5 5
DGIOT is an open-source industrial IoT platform built in Erlang/OTP, designed to manage massive fleets of sensors, meters, and industrial devices across oil fields, power grids, and manufacturing plants. The headline says “300+ protocols,” “6-minute deploy,” “30M concurrent connections.” It’s deployed at the Daqing Oil Field (928 gateways, 114K sensor points), the Southern Power Grid (120K smart meters across 7 cities), and the Asian Games 2022 venue operations. It is, objectively, a real, proven, enterprise-grade system. It is also absolutely, catastrophically wrong for my house.
Let me be clear about what DGIOT actually is: it’s a complete platform replacement. Not an integration. Not a component. Not a Home Assistant add-on. It wants to BE the brain. The architecture is called DLAS (Data, Logic, Action, Security), and it’s got its own device shadow model, ontology engine, rule engine, parse server integration, EMQX broker, TDengine timeseries database, PostgreSQL backend, and a dashboard layer (iotStudio, Python + Vue 3). When you unpack “complete platform,” this is what that means: every layer of the stack that currently handles your devices is getting ripped out and replaced with Erlang.
The device shadow model is actually elegant. Each device gets a gen_statem (a finite state machine in Erlang terms) that tracks reported state (what the device actually is right now) and desired state (what you told it to be). The gap between those becomes the action queue — the rules engine watches that gap and executes bridge commands to close it. For industrial sites, this is perfect. A smart meter in Daqing reports consumption every 15 minutes; the grid wants to enforce a demand cap; the shadow model tracks the gap, the rule fires, and the device gets updated. The state machine never crashes because it’s supervised by Erlang’s supervisor tree, which restarts it if something goes wrong. That’s Erlang’s entire value proposition: it’s a language designed so that distributed systems stay up. You write supervisors, those watch your processes, and if a process dies, the supervisor restarts it. That’s not metaphorical. That’s the runtime behavior.
The ontology engine is where industrial complexity really lives. This is where DGIOT models formal knowledge about your infrastructure. A smart meter isn’t just a device; it’s an instance of a Meter class with properties like billing-group, provider-id, customer-type, location-hierarchy. The grid topology becomes a graph: the meter belongs to a substation, which belongs to a distribution center, which belongs to a region. When you query “all meters in region 7,” the ontology reasoner walks that graph and gives you an answer. When a rule fires that says “if total consumption > threshold, notify the regional controller,” that rule gets evaluated against instances, not magic strings. This is what it takes to manage 114K sensors across an oil field where the operational stakes are real money and safety. It’s doctoral-dissertation-level infrastructure.
The protocol bridge framework (dgiot_bridge) shows up because industrial sites have Modbus gateways that have been running since 2003, OPC-UA controllers, M-Bus meters, DNP3 relays, IEC 60870-5-104 equipment. These are not modern protocols. They’re the protocols that work in plants where you can’t just rip out equipment and replace it. Modbus is literally just serial commands; it’s been that way for 40 years. DNP3 is specific to power grids. IEC 60870-5-104 is European teleprotection. None of these have REST APIs or MQTT. So DGIOT’s bridge layer abstracts: you write a Modbus parser that talks to the supervisor, which talks to the device shadow, which talks to the rule engine. Once a protocol is bridged, it looks like everything else to the rest of the system. This is phenomenal engineering for the problem it’s solving. It’s complete overhead for a house.
Here’s the deployment reality. “6-minute deploy” doesn’t mean you spin up DGIOT and it runs. It means you’ve got infrastructure ready: an EMQX cluster (high availability, clustering support built in), a TDengine cluster (columnar timeseries database, designed for high-cardinality metrics), PostgreSQL (for the application layer), Parse Server running (the backend service framework), the DGIOT core itself (Erlang app deployed via relx, using rebar3), and iotStudio (the web dashboard, Python + Vue 3). You’ve got networking sorted: your gateways can reach the broker, the broker can reach the TDengine, everything’s in one DC or geographically distributed with replication. The 6 minutes is the time to go from “I have all these services configured” to “the dashboard is live and receiving telemetry.” For Daqing Oil Field, this investment makes sense. You’re managing 928 gateways across operational sites. You’re not doing this once; you’re doing it right so it doesn’t need human intervention for five years. For a house with one Mac Studio and 100 devices, the operational surface area would triple.
The failure modes aren’t just additive. They multiply. Let’s say a TDengine cluster node dies. Now you need cluster recovery procedures. The Parse Server isn’t responding; is it a deployment issue or a database connection? The EMQX broker has a supervisor tree, but if that tree gets confused (which can happen under network partition), you need to diagnose Erlang distributed erlang behavior at 3 AM. Erlang gives you incredible tools to debug this: the observer, erl_tracer, heart supervisor for node restarts. But you have to know those tools. Home Assistant, when it breaks, breaks predictably — it’s Python, a web server, some integrations. You reload. You debug the integration. The learning curve is shallow because you’re debugging Python. DGIOT breaks in ways that require you to understand Erlang distribution: which nodes are alive, how the supervisor tree is structured, whether the consensus protocol (if you’re using one) has split-brain. That’s not a bug in DGIOT. It’s the cost of genius.
The language choice is actually perfect for the problem, which is exactly why it’s wrong for a house. Erlang was designed in the 1980s by telecom engineers who needed systems that never went down. Sweden’s telephone switching systems ran Erlang. That’s your benchmark: a system where downtime costs millions and doesn’t happen. Erlang’s concurrency model (lightweight processes, message passing, supervisor trees) is perfect for managing thousands of concurrent device connections. The EMQX broker, which sits underneath DGIOT’s messaging layer, is also Erlang — it handles 300 million concurrent connections in some deployments. But that same perfection means: you’re now running a language that almost nobody in home automation knows. Your Python agents can’t talk directly to your Erlang core. You’re writing message bridges. You’re debugging two runtimes. You’re maintaining two different dependency chains.
The current stack I’ve got — Home Assistant, ESPHome on ESP32, Zigbee/Z-Wave, custom Python agents, PostgreSQL, Grafana — is already local-first and opinionated. The Zigbee radio (a separate IEEE 802.15.4 coordinator) handles Aqara sensors and routers without touching the main system. The Z-Wave radio is its own thing. Home Assistant orchestrates on top, Python handles custom logic, Grafana reads from PostgreSQL and draws pretty pictures. When something breaks, I debug one thing. The operational footprint is small. Introducing DGIOT means: now I have Erlang to learn, now I have an Erlang cluster to manage, now I have TDengine instead of just PostgreSQL, now I have Parse Server, now I have EMQX. Each of those is sophisticated. Each of those can fail independently. The debugging surface area doesn’t just increase; it explodes.
The protocol support mismatch is blunt. DGIOT supports 300+ protocols because industrial sites need Modbus (for legacy industrial equipment), OPC-UA (for modern industrial controllers), M-Bus (for utilities and building automation across Europe), DNP3 (for power systems), IEC 60870-5-104 (for teleprotection and secondary systems in electrical grids), Bacnet (for HVAC and building automation). These protocols have standards documents from the 1980s and 1990s. They have no security layer — they were designed before security was a thing. DGIOT doesn’t fix that; it manages it. The bridge layer doesn’t make a DNP3 meter suddenly talk REST. It translates: a DNP3 read command becomes a message to the device shadow, which becomes an event the rule engine can see. That’s the abstraction.
My protocols are: Zigbee (Aqara, Z-Wave (GE, Innr), Matter/Thread (coming online very slowly), Philips Hue (proprietary but brilliant), HTTP/MQTT for custom stuff (ESP32 running ESPHome). I have five protocol stacks to talk to. Not 300. The Zigbee/Z-Wave radios already bridge to the Home Assistant layer without me writing protocol parsers. Hue has a local API that just works. HTTP and MQTT are single-request abstractions. DGIOT’s protocol bridge framework — dgiot_bridge — is architectural perfection for industrial settings where you’re dealing with equipment that predates the internet. It’s complete overhead for a home already using modern IoT hardware or commodity protocols.
The ontology engine shows where DGIOT’s industrial heritage cuts deepest. Industrial systems need formal knowledge representation. A smart meter in the Southern Power Grid isn’t just a device; it’s an instance within a billing hierarchy (customer → account → meter → register → phase), a geographic hierarchy (country → province → city → district → substation → line → meter), and an operational hierarchy (meter → monitoring → alarms → escalation). When you need to answer “which meters are owned by customer 42,” or “alert all meters in region 7 that are over-consumption,” the ontology does that in structured queries. It’s a graph database of meaningful relationships.
But that graph is only necessary if you have thousands of devices with hierarchical relationships and complex billing rules. My setup is: I have devices. Some of them are in the living room. Some are in the kitchen. I want them to be controllable, and I want to see their state. I don’t need a formal ontology. Home Assistant’s entity model (device → entities with state and attributes) is sufficient. It’s not elegant. It’s pragmatic. An ontology engine would let me formally model a “room” with zone logic and automatic rollup queries. It would also require me to maintain that ontology, debug it when it’s wrong, and defend all that complexity to myself at 3 AM. The mental model — “turn on lights in the kitchen” — doesn’t map to “query the ontology for all light entities where location = kitchen.” It maps to “call home.turn_on with entity_id = light.kitchen_*.”
The enterprise features show where DGIOT diverges completely from home use. JWT authentication, RBAC (role-based access control), ACL/CLP (access control lists with claim-based patterns), audit logs, Parse Server integration for multi-tenant deployments. The Southern Power Grid has thousands of users: contractors, regional operators, billing auditors, security teams. You need to grant a contractor read-only access to meter data in one region. You need to audit who accessed what meter on what date at what time. You need to prevent a contractor from accidentally deleting meter configuration for a different region. This is the entire purpose of the enterprise layer.
A home user needs: one person (me) to be able to tell the system to turn shit on and off. That’s it. I don’t need JWT. I don’t need role separation. I don’t need audit logs (if someone’s in my house messing with the lights, we have bigger problems). I don’t need Parse Server as a multi-tenant backend. Home Assistant’s built-in authentication is: your username and password for the dashboard. That’s sufficient. DGIOT’s authentication is: you’re part of an identity provider, your claims are validated against a rules engine, your role determines what you can query, and every action is audited against your identity. That’s right for Daqing. That’s nightmare overhead for a house.
What I could steal — and this is the important part, because it means the architecture is genuinely good — is the mental model. The DLAS architecture (Data → Logic → Action → Security) is a solid way to think about any IoT system. Information flows in from devices (Data), it gets transformed and evaluated (Logic), decisions get executed (Action), and everything is wrapped in authentication and audit (Security). The FDE pipeline (Model → Ontology → Device Access → TimeSeries → Rules → Dashboard) describes a thoughtful data flow: you model your infrastructure, the ontology layer queries it, the device access layer abstracts protocols, the timeseries layer stores metrics, the rule engine executes logic, the dashboard displays state. That’s not bad. That’s actually good.
The Shadow model — a gen_statem per device representing current vs. desired state — is genuinely clever, even for a small system. But you don’t need Erlang to do it. You can do it in Python: every device has a CurrentState and DesiredState, the gap between them becomes a queue of actions, an executor processes that queue. That’s the same idea without Erlang. I could steal that mental model and apply it to my Python agent layer. In fact, I kind of already am: Home Assistant tracks state, rules fire when state changes, automation execute actions to change state. It’s less formal than DGIOT’s shadow model, but it’s the same pattern at lower overhead.
The current setup is already sophisticated enough to be worth defending. Home Assistant is Python-based orchestration with integrations for a hundred different device types. ESPHome is a framework for running C++ on microcontrollers (ESP32, ESP8266) and making them expose MQTT or REST APIs; I use it for custom sensors that don’t exist as consumer products (temperature sensors, air quality monitors, smart power strips). The Zigbee coordinator is a separate CC2652 board running Zigbee2MQTT, a Node.js bridge that lets you integrate Zigbee devices into Home Assistant without the cloud. Z-Wave is similar: a local USB controller, Home Assistant’s Z-Wave integration handles it. Custom Python agents run on the same machine for logic that doesn’t fit Home Assistant’s automation model (complex correlations, custom integrations with other services). PostgreSQL stores metrics. Grafana reads from PostgreSQL and makes dashboards.
This is local-first architecture. Nothing reaches the cloud unless I explicitly tell it to. Everything runs on hardware I own. The failure domains are small: if Home Assistant crashes, the lights stay on (they remember state). The Zigbee network keeps working. If PostgreSQL dies, the system is still operational (just without history). If one of my Python agents crashes, the rest of the system keeps running. There’s no single point of architectural failure that would require me to debug an Erlang supervisor tree.
The protocol support across this stack is exactly what I need. Zigbee handles my smart home sensors (Aqara, temperature, humidity). Z-Wave handles GE switches and Innr bulbs. Philips Hue has its own bridge, which I can integrate through Home Assistant’s API. ESP32 devices I build myself talk MQTT directly. Everything is standardized enough that I understand what’s happening when it breaks. I’m not reverse-engineering some industrial protocol from the 80s. I’m debugging Zigbee messages (which I can decode) or MQTT messages (which are plain JSON) or Home Assistant automations (which I wrote). The debugging surface is manageable.
Here’s the real truth: DGIOT is brilliant because it’s overbuilt for industrial environments. That’s its entire value proposition. It solves hard distributed-systems problems that don’t exist in a house. The genius — the ontology engine, the supervisor trees, the clustering, the audit layer, the protocol abstraction — is only a solution if you have the problems it was designed to solve. Rip out and replace my entire working system with it because the architecture diagram looks impressive would be choosing a solution in search of a problem. That’s not engineering excellence. That’s self-inflicted suffering.
The repo is real. It’s proven at massive scale. It’s actively maintained. If I were an SRE running operations at Daqing or the Southern Power Grid, I’d be reading the docs carefully and probably using it. I’d be learning Erlang. I’d be deploying Parse Server and setting up EMQX clusters. I’d be training operations teams on debugging Erlang distribution. That would be the right choice.
But I’m not managing an oil field. I’m managing a house. I’m managing 100 devices, most of which are consumer products that already work out of the box. My operational concerns are: do the Zigbee devices connect reliably? Does the rule engine execute on time? Are the logs clean? I don’t care about multi-region rollout or protocol bridges for equipment that’s been running since 2003. I don’t need to audit who accessed which meter. I don’t need an ontology reasoner.
DGIOT is the 747. It’s an incredible airplane — built to carry 400 people across oceans, designed to fly reliably for decades, engineered so well it basically never crashes. But I’m driving to the grocery store. I’ve already got a scooter that works perfectly fine.
Scouted repo: dgiot/dgiot — 4833 stars. Verdict: PASS. Desk review, nothing was flashed or installed.