DEV Community: JhonLiu

I Pointed My Industrial IoT Platform at My Dog — Here Is What Happened

JhonLiu — Sat, 15 Aug 2026 01:42:00 +0000

I Pointed My Industrial IoT Platform at My Dog — Here's What Happened

Dog Days Challenge Entry 🐶

My company builds industrial IoT infrastructure — 928 gateways monitoring oil wells, UAV testing lines producing 60 drones a day, maritime safety platforms with 99.9999% uptime.

This weekend, I pointed that entire stack at a Golden Retriever.

The Stack

Meet PawTrack — a dog health monitoring demo built on DGIOT, our open-source industrial IoT platform:

Smart Collar (PawCollar-V2)
    │  MQTT · 2-second sampling
    ▼
DGIOT Platform (Erlang/OTP)
    │  300+ protocol adapters · Shadow devices · Rule engine
    ├── TDengine (time-series storage)
    ├── DLAS Ontology Engine (OWL reasoning)
    └── Dashboard (real-time vitals)

The collar streams four metrics every 2 seconds:

Heart rate (bpm)
Body temperature (°C)
Activity level (%)
Battery + RSSI

Why Industrial IoT Makes Sense for Pets

Here's the part that surprised me: a dog is just another telemetry source.

The industrial world has spent decades solving problems that pet tech startups are rediscovering:

Industrial Problem	Pet Equivalent
Gateway goes offline in a remote oil field	Dog runs out of Wi-Fi range
Sensor drift on a pressure gauge	Collar temperature calibration
False alarms flooding operators	"Your dog is dying" notification at 3am
928 gateways to manage	Multiple pets, multiple collars

We already solved all of these for oil fields. A Golden Retriever is just a smaller, fluffier oil well.

The Ontology Layer — Why It Matters

The interesting part is our DLAS ontology engine. Instead of hard-coded thresholds ("if temp > 39.5, alert"), we model knowledge:

GoldenRetriever ⊑ Dog ⊓ ∃hasRisk.HipDysplasia
ActivityDrop(dog, 40%) ∧ BreedRisk(dog, High) → Alert(medium)

This means the system knows that a Golden Retriever's activity drop is more concerning than a Border Collie's — hip dysplasia is breed-specific. The ontology compiles to Erlang pattern matches, so reasoning happens at runtime speed.

The Shadow Device

Every physical device gets a digital twin — a gen_statem process that mirrors its lifecycle:

init → auth → online → {active, inactive, alert}

When the collar drops offline, the shadow holds state and retries silently. The dashboard doesn't scream "DOG IS GONE" — it waits, because shadows absorb network chaos. This is the same mechanism that keeps oil field gateways calm during sandstorms.

The Demo

The live demo simulates the MQTT stream with real-time vitals, ontology inference, and the alert closed-loop (discover → confirm → handle → verify):

dgiot/pets/wanCai/telemetry → {"temp":38.6,"hr":88,"activity":62}
dgiot/pets/wanCai/shadow → {"state":"active","battery":87,"rssi":-62}

Watch for the activity-drop alert — when activity falls below 35%, the ontology fires a hip dysplasia risk warning for the Golden Retriever, generates a work order, and closes the loop when activity recovers.

What's Real vs. What's Demo

Real: DGIOT platform, DLAS ontology engine, shadow device architecture, MQTT pipeline, alert closed-loop — all production code from our industrial deployments.

Demo: The collar hardware (simulated), the dog (borrowed), the vitals (synthetic values).

The point: the platform is production-grade. Building pet monitoring on it took one afternoon, because the hard parts — protocol handling, shadow state, ontology reasoning — were already done for 300+ industrial use cases.

The Code

Platform: github.com/dgiot/dgiot — Apache 2.0, 4.8K stars
Demo: Single HTML file simulating the MQTT stream

Want to build your own? The platform deploys in 6 minutes:

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

Built for the Dev.to Dog Days Challenge. If your dog's activity drops below 35%, take them to the vet — the ontology says so.

🐾 Dog Days Pack: Three Zero-Dependency Dog Projects in One Weekend

JhonLiu — Fri, 14 Aug 2026 23:30:21 +0000

This is a submission for Weekend Challenge: Dog Days Edition

What I Built

Three small dog-themed projects, all built from scratch within the challenge window — each one is a single self-contained HTML file with zero dependencies, zero build steps, and zero CDNs. Open the file (or the links below) and it just works, the way software for dogs should.

1. 🎴 Paw Match — Dog Breed Memory Game
A card-memory game where you flip cards to match dog breed pairs. Match a pair and a real breed fact pops up — did you know Dalmatians are born pure white and only develop spots after 3–4 weeks? Three difficulties (6/8/10 pairs), move counter, timer, star ratings, CSS 3D flip animations and confetti.

2. 📓 Paw Log — Dog Training & Care Journal
A practical training log (the brief literally suggested this one 🎯). Log walks, feedings, training sessions, vet visits, baths and playtime. Everything persists in localStorage, with daily stats (walks today, training minutes, day streak), per-activity totals with progress bars, and JSON export/import backups.

3. 🎨 Dog-o-matic — Generative Dog Art
A tiny procedural dog factory. Every click generates a unique dog face — head shape, ear type (flop/point/round/fold), coat color, chest blaze, Dalmatian spots, tongue, freckles — all random. It "identifies" the breed and always concludes the dog is a very good boy. Pure Canvas 2D, and you can save any dog as PNG or auto-breed a dozen in a row.

Demo

All three run right in your browser — no install, no login:

🎴 Paw Match: play it here
📓 Paw Log: use it here
🎨 Dog-o-matic: generate dogs here

Code

The entire codebase is the demos themselves: each project is one self-contained HTML file — right-click → View Source in any browser and you have the full code. No frameworks, no lockfiles, no node_modules to explain.

A GitHub repository with the full pack (plus this README) is being published and I'll link it here before submissions close.

How I Built It

The one-file constraint was the fun part. I decided each project had to be a single HTML file that works over file:// — double-click and play, anywhere, even offline. That forced some genuinely nice engineering:

Paw Match uses CSS 3D transforms for the flip animation (perspective + rotateY), a tiny state machine for the flip/lock/match flow, and a hand-picked fact table of 10 real breed facts.
Paw Log is a full CRUD app in ~130 lines of vanilla JS: a single localStorage JSON document, day-keyed aggregation for the "today" view, streak calculation walking back through calendar days, and JSON backup export/import for the "data stays on your machine" promise.
Dog-o-matic draws every dog procedurally on a <canvas>: a parameter object (coat, ear, head, muzzle, patches, spots, tongue, freckles) drives an ordered paint pass — ears behind the head, muzzle overlay, white blaze, then face details. The "breed guess" is a tiny rules engine over those parameters (ears === 'round' → "Corgi (all loaf, no legs)").

The whole pack is responsive, works on mobile, and was built in one weekend sitting — because that's the challenge.

Made for fun. No dogs were harmed (or trained) in the making. 🦴

Why We Built an Ontology Engine Instead of Another Rules System

JhonLiu — Thu, 13 Aug 2026 19:11:50 +0000

Why We Built an Ontology Engine Instead of Another Rules System

Every IoT platform has a rules engine. We built something different: a 252-entity OWL ontology that understands what equipment is, not just what values it reports.

The Problem with Rules

Traditional industrial alarm systems work like this:

IF temperature > 80°C THEN alert

This works until it doesn't:

False alarms: A pump starting up briefly spikes to 82°C. Is it failing, or just warming up? The rule doesn't know.
Rule explosion: 100 equipment types × 20 parameters × 5 thresholds = 10,000 rules to maintain
No context: "Pressure low" means different things for a water pump (cavitation) vs an oil well (depletion)
Fragile thresholds: Each plant tunes its own thresholds. Nothing transfers between sites.

At Daqing Oil Field, false alarm rates exceeded 20% with the old rules-based system. Operators learned to ignore alarms — which defeats the entire purpose.

The Ontology Approach

An ontology models the structure of industrial equipment:

Pump ⊑ Equipment ⊓ ∃hasPart.Bearing ⊓ ∃measures.Pressure
Bearing ⊑ Component ⊓ ∃hasFailureMode.Overheat
Overheat → triggers(Alert) ∧ reduces(RemainingLife, 0.8)

When our platform reads a pressure value of 2.35 MPa, it doesn't just compare against a threshold. It knows:

This is a pump (not a valve, not a compressor)
The pump has a bearing
Bearings fail by overheating
Combined with vibration data, this pattern matches "bearing wear stage 2"
The recommended action is "schedule maintenance within 14 days" — not "sound alarm now"

The DLAS Architecture

We formalized this as a four-layer stack:

DATA     Parse (23 classes) · PostgreSQL · TDengine · EMQX
LOGIC    Ontology Engine · Model Registry · 3 ETS Tables
ACTION   Shadow (gen_statem) · MQTT · Rule Engine  
SECURITY JWT · RBAC · ACL/CLP · Audit Log

The key innovation: the ontology compiles to Erlang pattern matches. Each OWL axiom becomes native code. Reasoning happens at runtime speed — not query speed.

% OWL: Overheat → triggers(Alert)
handle_event(#event{type = overheat, device = Pid}, State) ->
    case ontology:class_of(Pid) of
        bearing ->
            {next_state, alert, schedule_maintenance(State)};
        _ ->
            {next_state, normal, State}
    end.

Shadow Devices: The State Machine Layer

Every physical device has a digital twin — a gen_statem process that mirrors its lifecycle:

init → auth → online → {normal, alarm, offline}

The shadow absorbs network chaos:

Gateway drops offline for 30 seconds? Shadow holds state, retries silently.
Device sends contradictory readings? Shadow evaluates against the ontology before propagating.
Firmware updates? Shadow freezes state, swaps, resumes — no downtime.

This is why we run 928 gateways with 99.9999% uptime on a 10-person team.

Real Results

Metric	Rules-Based	Ontology-Based
False alarm rate	22%	4.7%
Rules to maintain	10,000+	252 entities + 15 SWRL rules
New equipment onboarding	2 weeks	2 hours (just describe the type)
Cross-site transfer	Manual re-tuning	Automatic (ontology is generic)

The false alarm reduction alone saved an estimated $2.3M in year one at Daqing.

When to Use Which

	Rules Engine	Ontology Engine
Simple thresholds	✅	Overkill
Complex equipment hierarchies	❌	✅
Cross-industry reuse	❌	✅
Explainable decisions	Partial	✅ (inference chain)

We still ship a rules engine. But for anything with mechanical structure — pumps, turbines, compressors, breakers — the ontology wins.

Try It

The full platform is open source (Apache 2.0):

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

The ontology engine is in apps/dgiot_ontology/. Docs at docs/DGAIOT_ONTOLOGY.md.

Liu Shouxin is the founder of DGIOT. He's spent 20 years on industrial IoT, previously at EMQ and Huawei. The ontology approach came from his master's thesis at Zhejiang University — 22 years before it shipped in production.

How One Open-Source IoT Platform Unified China Largest Oil Field — 928 Gateways, 114K Sensors, 600x Faster

JhonLiu — Tue, 11 Aug 2026 03:25:37 +0000

How One Open-Source IoT Platform Unified China's Largest Oil Field — 928 Gateways, 114K Sensors, 600× Faster

Daqing Oil Field produces 30 million tons of crude annually. When they needed to modernize their sensor network, they chose an open-source platform built by a 10-person team. Here's the story.

The Scale of the Problem

Daqing Oil Field spans 6,000 square kilometers — roughly the size of Delaware. It has:

16 oil extraction plants
928 industrial gateways (mostly Modbus RTU/TCP and a proprietary CNPC protocol called A11)
114,809 sensor points measuring pressure, temperature, flow rate, vibration, and 20 other parameters
30+ years of accumulated legacy equipment

When we first visited in 2020, the data infrastructure looked like this:

Field Operator checks gauge → writes value on clipboard
  → enters into Excel at end of shift
  → supervisor reviews next morning
  → alarm triggered 4 hours after anomaly occurred

Collection frequency: every 10 minutes on a good day. End-to-end latency: 15-30 minutes. False alarm rate: over 20%. Storage: data older than 10 days was purged.

An oil pump failure caught 4 hours late costs $50,000-200,000 in lost production.

The Approach: Protocol-First

We didn't try to replace the gateways. Instead, we built protocol adapters that spoke their language:

Siemens S7-1200 (Modbus TCP)  ──┐
ABB AC500 (Modbus RTU)         ──┤
A11 CNPC Gateways (proprietary) ──┼──→ DGIOT Unified Pipeline
OPC UA Servers (newer units)   ──┤
Manual Input (legacy gauges)   ──┘

Each protocol adapter is an Erlang gen_statem process. A single gateway's Modbus connection is one lightweight process consuming ~2KB of memory. 928 gateways = <2MB RAM for the entire protocol layer.

The A11 Protocol Challenge

The hardest part was A11 — a proprietary CNPC protocol with almost no documentation. We had to reverse-engineer it from packet captures and conversations with retired engineers. The protocol uses a unique 4-byte magic number (0x6A6A5A5A) and variable-length frames with custom CRC. It took three weeks of on-site work, but once we cracked it, we could talk to 60% of Daqing's legacy gateways natively.

The Architecture in Production

928 Gateways
    │  Modbus RTU/TCP, A11 CNPC, OPC UA
    ↓
DGIOT Edge (Runs on existing gateway hardware)
    │  Protocol adaptation + stream computation + 7-day offline buffer
    ↓
MQTT Broker (EMQX) — 1M+ msg/sec
    │
    ├──→ TDengine (time-series, 10:1 compression, 652M data points)
    ├──→ Parse Server (device metadata, auth, tenant isolation)
    └──→ Stream Engine (15 algorithms, real-time alerting)
    │
    ↓
Vue 3 Dashboard (operator view, maintenance view, director view)

The Results

Metric	Before	After	Improvement
Collection frequency	10 min	1 sec	600×
End-to-end latency	15-30 min	<3 sec	600×
Storage retention	10 days	2 years	73×
False alarm rate	22%	4.7%	4.7× better
Gateways managed	1 per system	928 unified	—
Protocols supported	3	15 at Daqing, 300+ globally	—
Uptime	~95%	99.9999%	—

The Real Impact

$2.3 million saved in the first year — not from license fees (DGIOT is free), but from:

Reduced downtime: Pumps caught at first sign of bearing wear, not after failure
Eliminated manual rounds: Operators stopped driving 2 hours to check a gauge
Optimized maintenance: Predictive instead of scheduled — 40% fewer truck rolls

Why Open Source Won

Daqing initially wanted a commercial SCADA system. Three vendors quoted:

Vendor A: $1.2M license + $200K/year maintenance
Vendor B: $850K + $180K/year
Vendor C: $3M for a "full digital transformation"

All three required replacing the existing gateways — a $15M hardware project. DGIOT ran on the existing hardware. The software was free. The only cost was integration and training.

When the project lead asked "What if your company goes out of business?", we pointed to the GitHub repo: "The code is Apache 2.0. It outlives us."

That closed the deal.

Lessons for Industrial IoT Founders

Don't compete on features. Compete on protocols. Every protocol you support removes a reason to say no.
Open source is a trust mechanism for hardware companies. They've been burned by vendor lock-in. Apache 2.0 is the ultimate guarantee.
Edge computing is non-negotiable. Oil fields have terrible connectivity. Your platform must work offline for days.
The hard part isn't the tech — it's the protocol reverse-engineering. Budget 2-4 weeks per proprietary protocol. It's worth it.
Pricing: free software, paid integration. The software is open source. The 3-week on-site integration, training, and custom protocol work is what you charge for.

DGIOT is open source (Apache 2.0) at github.com/dgiot/dgiot. The Daqing deployment has been running in production since 2021.

Liu Shouxin is the founder of DGIOT. He previously architected IoT platforms at EMQ, Huawei, and TCL.

How We Built an IoT Platform That Handles 30 Million Concurrent Connections — With a Team of 10

JhonLiu — Tue, 11 Aug 2026 03:25:00 +0000

How We Built an IoT Platform That Handles 30 Million Concurrent Connections — With a Team of 10

DGIOT is an open-source industrial IoT platform. We run 928 gateways across 16 oil fields, process 652 million data points, and maintain 99.9999% uptime. Here's the architecture that makes it possible.

The Problem

In 2021, we got a call from Daqing Oil Field — China's largest oil producer. They had a problem:

928 industrial gateways from different vendors
114,809 sensor points speaking 15 different protocols
Data collection every 10 minutes (they needed seconds)
15-30 minute end-to-end latency (they needed <3 seconds)
False alarm rate above 20%

The existing system was a patchwork of vendor-specific tools, each with its own database, UI, and authentication. Operators had to log into 8 different systems just to check if a pump was overheating.

They asked: "Can you unify this?"

What We Built

DGIOT is an Erlang/OTP-based platform that acts as a universal translator for industrial protocols. Think of it as a Rosetta Stone for machines.

Modbus ─┐
OPC UA ─┤
MQTT  ──┼──→ Unified Pipeline ──→ TDengine ──→ Dashboard
IEC104 ─┤
A11   ──┘

The key insight: industrial protocols are just state machines. Once you model each protocol as a gen_statem FSM in Erlang, you can handle hundreds of them concurrently with almost zero overhead.

The Architecture: DLAS

We designed a four-layer architecture that separates concerns cleanly:

Layer 1: DATA — Ingestion

Parse Server (23 classes) handles device metadata, user auth, tenant isolation
TDengine stores 652M time-series data points with 10:1 compression
EMQX handles MQTT message routing at 1M+ msg/sec
Mnesia/ETS provides in-memory caching for hot data

Layer 2: LOGIC — Ontology Engine

This is our secret weapon. We built a 252-entity OWL ontology that models industrial equipment:

Pump ⊑ Equipment ⊓ ∃hasPart.Bearing ⊓ ∃measures.Pressure
Bearing ⊑ Component ⊓ ∃hasFailureMode.Overheat
Overheat → triggers(Alert) ∧ reduces(RemainingLife, 0.8)

These rules are compiled to Erlang pattern matches. When a pressure sensor reads 2.35 MPa, the platform doesn't just display a number — it knows that pump P-103's bearing is trending toward failure, cross-references the maintenance schedule, and generates a work order.

Layer 3: ACTION — Shadow State Machines

Every physical device has a "shadow" in software — a gen_statem process that mirrors its real-world state:

init()    → auth → online → {normal, alarm, offline}
normal()  → evaluate(Rules) → publish(MQTT)
alarm()   → escalate → notify → acknowledge
offline() → retry(5) → alert

The shadow absorbs network interruptions. If a gateway goes offline for 30 seconds, the shadow holds the last known state and retries. The dashboard never shows "disconnected" unless the device has been unreachable for 2+ minutes.

Layer 4: EDGE — iotStudio

A Python + Vue 3 edge agent that runs on ARM gateways. It does:

Protocol adaptation: Modbus RTU → MQTT bridge
Stream computation: Moving average, anomaly detection, deadband filtering — 15 algorithms
Offline autonomy: 7-day buffer if cloud connection drops
OTA updates: Rolling firmware deployment to 928 gateways

The Numbers

Metric	Before DGIOT	After DGIOT
Collection frequency	10 min	1 second (600×)
End-to-end latency	15-30 min	<3 seconds
Storage retention	10 days	2 years
False alarm rate	>20%	<5%
Concurrent connections	~1,000	30M verified
Protocols supported	3	300+

Why Erlang?

We get this question a lot. The answer is simple: Erlang was built for this.

Preemptive scheduling: A slow Modbus device can't block a fast MQTT stream
Hot code reloading: We deploy updates without shutting down 928 gateways
Let-it-crash philosophy: A failing protocol adapter restarts in milliseconds without affecting others
Built-in distribution: Adding a new node to the cluster is one command

The same reasons WhatsApp used Erlang for 2 billion users. Industrial IoT has the same requirements: massive concurrency, high availability, and soft real-time.

Open Source

DGIOT is Apache 2.0 licensed. Full source at github.com/dgiot/dgiot.

We made this choice deliberately. Industrial IoT is too fragmented for any single company to solve. The only way to cover 300+ protocols is to let the community add them. Every new protocol adapter benefits everyone.

git clone https://github.com/dgiot/dgiot.git
cd dgiot && docker-compose up -d
# Open http://localhost:5080

Lessons Learned

Protocols are the moat. Every new protocol adapter opens a new industry. We went from 3 to 300 in 4 years — each one brought new customers.
Ontology beats rules. Hard-coded alarm thresholds break. An ontology that understands "pump→bearing→overheat" generalizes across equipment types.
Open source is the distribution. We don't have a sales team. Our customers find us through GitHub, then ask for enterprise support.
Erlang is a competitive advantage. In a world of Node.js and Python IoT platforms, Erlang's concurrency model lets us handle 100x the load with the same hardware.
Community > code. The 70K developers in our community have built integrations we never would have thought of.

Liu Shouxin is the founder of DGIOT, an open-source industrial IoT platform. He previously worked at EMQ, Huawei, and Kaspersky. He lives in Hangzhou and Dallas.