GenesisNode IoT Simulation Demo
The core claim: by running GenesisNode inference directly on the microcontroller, you eliminate the need to stream raw sensor data to the cloud. The device only transmits detected events (anomalies, state changes), reducing network bandwidth by 97%+, cutting inference latency from 60ms (cloud round-trip) to 24 microseconds (on-device graph walk), and dropping power consumption from 175mW to 30mW.
What This Demo Shows
The IoT Simulation demonstrates GenesisNode performing industrial anomaly detection on edge devices. It simulates a complete IoT pipeline -- from raw sensor data streaming off an ESP32-class device, through on-device tokenization and inference, to fleet-wide deployment -- and compares the result against traditional cloud-centric IoT architectures in real time.
The demo has three tabs: Single Device (train and deploy a model), Fleet Simulation (scale to 200 devices with topology visualization), and Edge Scenarios (offline resilience, cloud cost projections, battery life estimates).
Single Device Mode
The left panel streams three sensor channels in real time:
- Temperature (C) -- baseline oscillates around 20C with a slow sinusoidal drift (5-minute period) and Gaussian noise. Range: 10-35C.
- Vibration (g) -- baseline at ~0.2g with a 60-second oscillation. Range: 0-2.0g.
- Humidity (%) -- baseline at ~50% with a 10-minute period drift. Range: 20-80%.
The stream runs at a configurable sample rate (1, 5, 10, or 50 Hz). At 10 Hz, the simulation generates 10 readings per second, each containing all three sensor values plus a timestamp.
Event Injection
Four industrial events can be injected by clicking toggle buttons. Each event modifies the sensor readings in a physically plausible way:
| Event | Temperature Effect | Vibration Effect | Humidity Effect |
|---|---|---|---|
| Compressor Failing | +8C (ramping) | +0.6g with noise | -- |
| Door Opened | -5C (sudden) | -- | +20% |
| Motor Start | -- | +0.5-1.5g (random burst) | -- |
| Motor Running | -- | +0.6g with 2Hz oscillation | -- |
Events toggle on/off. When toggled off (or when a timed event expires), the affected time range is automatically labeled and added to the training set. The corresponding button pulses red while an event is active.
Token Extraction
Raw sensor readings are converted into discrete tokens through a deterministic tokenization pipeline. For any window of readings, the system extracts:
Level tokens (current state)
- Temperature:
temp_very_low,temp_low,temp_normal,temp_high,temp_very_high - Vibration:
vib_none,vib_low,vib_medium,vib_high,vib_extreme - Humidity:
humid_very_low,humid_low,humid_normal,humid_high,humid_very_high
Trend tokens (computed from first-half vs. second-half comparison)
temp_rising,temp_falling,temp_stablevib_rising,vib_falling,vib_stablehumid_rising,humid_falling,humid_stable
Burst tokens (statistical anomalies)
vib_burst-- vibration standard deviation exceeds 0.3temp_spike-- temperature range exceeds 5C within the window
Key architectural insight: instead of transmitting raw floating-point sensor data, the device converts continuous signals into a small set of categorical tokens that GenesisNode can reason over using its graph-based inference.
The Training Workflow
Training follows a four-step pipeline:
- Collect labeled data -- Either inject events (which auto-label when toggled off) or manually select a range on the charts by click-dragging, choose a label from the dropdown (or enter a custom label), and click "Label Range." Each labeled range produces a
LabeledEventcontaining the start/end indices, the event label, and the extracted tokens. - Review extracted tokens -- The center panel shows extracted tokens for each labeled event as colored tags. Verify that the token signatures differ between event types. For example, a compressor failure should produce tokens like
temp_high,temp_rising,vib_high,vib_burst, while a door opening should producetemp_falling,humid_very_high,humid_rising. - Train the model -- Set the number of epochs (default: 100, range: 10-500) and click "Train Model." Training uses contrastive learning with the parameters described below.
- Deploy to device -- Click "Deploy to Device" to simulate flashing the trained model to an ESP32. The deployment step counts the
liot-scaler nodes and estimates the model size at ~650 bytes per node.
Training Details
- For each labeled event, the system creates or strengthens connections from sensor-token scaler nodes (prefixed
liot) to the event label node, tagged withiot:<label>context. - Connections to the correct label are strengthened (up to a cap of 0.6).
- Connections to incorrect labels are weakened (contrastive signal at 0.3x the learning rate).
- The learning rate starts at 0.10 and decays by 0.5% per epoch (floor: 0.02).
- Accuracy is evaluated every 10 epochs by running inference on all labeled events and reporting to the UI.
The progress bar shows epoch count and current accuracy. Training typically reaches 100% accuracy on the training set within 30-50 epochs for 4 event types.
Deployment
A typical 4-event-type model uses 20-40 nodes and fits in 13-26 KB -- well within the constraints of an ESP32 with 520 KB SRAM and 4 MB flash.
Edge Deployment and Inference
After deploying, click "Start Edge Inference" (the sensor stream must be running). The device now runs inference inline with the stream:
- Accumulate window -- A sliding window of 10 readings accumulates.
- Extract tokens -- When the window fills, tokens are extracted using the same tokenization pipeline.
- Graph walk -- Tokens are fed to
process_iot_state, which performs a BFS graph walk through the GenesisNode network followingiot:*context-tagged connections. - Classify -- The label node with the highest activation wins. If the result is not
normal_operation, it is classified as a detected event. - Transmit events only -- Only detected events are transmitted -- not the raw readings.
Detected events appear in the "Device Events" panel on the right, showing the label, confidence percentage, and timestamp.
Comparison Metrics
The right panel runs a continuous side-by-side comparison between traditional IoT and GenesisNode edge inference. Metrics update every 2 seconds.
Traditional IoT
Represents the standard architecture where every sensor reading is uploaded to the cloud for processing:
| Metric | Value | Basis |
|---|---|---|
| Throughput | 74 bytes/reading x sample rate | Raw upload of 3 floats + timestamp + overhead |
| Latency | 60 ms | Cloud round-trip (device → gateway → cloud → response) |
| Power | 175 mW | WiFi radio active for continuous streaming |
GenesisNode Edge
Represents on-device inference where only anomaly events are transmitted:
| Metric | Value | Basis |
|---|---|---|
| Throughput | 82 bytes/event (only when events occur) | Label + confidence + timestamp |
| Latency | 24 us | On-device graph walk (no network hop) |
| Power | 30 mW | WiFi radio mostly idle; inference is dict lookups |
Savings Dashboard
The savings panel shows four key metrics:
- Data Ingestion Reduction -- Side-by-side KB counters with a percentage bar. Typically 97-99%+ reduction because events are rare compared to total readings.
- Network Bandwidth Reduction -- Real-time bytes/sec comparison, usually showing 97%+ savings.
- Latency Improvement -- 2,500x (60ms / 24us). This is the ratio of cloud round-trip to on-device graph walk.
- Power Reduction -- 82.9% (1 - 30mW / 175mW). Less radio usage means dramatically lower power draw.
Why the Savings Are So Large
The fundamental difference is data filtering at the source. Traditional IoT sends every reading regardless of whether anything interesting happened. GenesisNode only sends events. At 10 Hz with ~5 events per hour, you are sending 5 event packets vs. 36,000 raw readings -- a 7,200:1 ratio. The savings scale linearly with sample rate and inversely with event frequency.
Fleet Simulation
The Fleet tab scales the simulation to multiple devices running in parallel.
Configuration
- Number of Devices -- 1 to 200 simulated ESP32 devices, each with independent sensor streams and random phase offsets.
- Tick Rate -- 1, 2, or 5 Hz (lower than single-device to keep simulation manageable at scale).
- Network Type -- Selectable network link speed that affects utilization calculations:
| Network | Bandwidth | Latency |
|---|---|---|
| SCADA/Modbus | 9.6 Kbps | 200 ms |
| LoRa WAN | 50 Kbps | 150 ms |
| Wi-Fi | 50 Mbps | 5 ms |
| 100 Mbps Ethernet | 100 Mbps | 1 ms |
| Cat 6 / 1 GbE | 1 Gbps | 0.5 ms |
| Fiber Optic 10G | 10 Gbps | 0.1 ms |
- Event Types -- Checkboxes to enable/disable which events are randomly injected across the fleet.
How It Works
Each device runs independently: it generates sensor readings at the tick rate, accumulates a 10-reading window, runs tokenization and inference, and reports detected events. Random events are injected with ~0.2% probability per tick per device, lasting 3-8 seconds each. Devices are grouped into clusters of 12 for topology visualization.
Aggregate Metrics
The fleet dashboard shows:
- Total Readings / Events Detected -- across all devices
- Active Events -- how many devices currently have an injected event
- Readings/sec and Events/min -- fleet-wide throughput
- Bandwidth at Scale -- traditional vs. GenesisNode throughput using the same unit (auto-scaled from B/hr to GB/hr)
- Fleet Bandwidth Savings -- percentage bar showing aggregate reduction
- Network Utilization -- what percentage of the selected link capacity is consumed by each approach, with a red warning when traditional IoT exceeds the link
Network Impact Comparison
A side-by-side panel lets you click through different network types (SCADA, LoRa, Wi-Fi, Ethernet, Cat6, Fiber) and see how traditional IoT vs. GenesisNode performs on each:
- Throughput (same unit for fair comparison)
- Link utilization percentage
- Per-hop latency
- Maximum devices supportable on that link
- Verdict: "Within capacity," "Heavy load," or "EXCEEDS CAPACITY"
This is where the GenesisNode advantage becomes dramatic on constrained networks. On a SCADA/Modbus link (9.6 Kbps), traditional IoT may exceed link capacity with just a handful of devices. GenesisNode, sending only events, can support orders of magnitude more devices on the same link.
Topology Visualization
Switch to the Topology view for a visual representation of the fleet. Two canvas-rendered maps are displayed side by side -- one for Traditional IoT, one for GenesisNode Edge -- showing:
- Devices as colored circles grouped into clusters around cluster heads
- Gateway at the top receiving data from all clusters
- Data flow particles animated along the connections, with particle density proportional to bandwidth
- Link color indicating congestion level (green < 30%, orange 30-70%, red > 70%)
Seven visualization dimensions can be selected:
| Dimension | What It Shows |
|---|---|
| Congestion | Network load per link -- red means overloaded |
| Latency | Response time -- traditional adds cloud hop, GenesisNode is local |
| Privacy | Data exposure -- traditional exposes raw data, GenesisNode keeps data on-device |
| Cost | Per-device monthly cost based on AWS IoT Core pricing |
| Power | Simulated battery drain over time |
| Offline | What happens when links go down -- traditional goes blind, GenesisNode keeps detecting |
| Adaptability | Model freshness -- GenesisNode can evolve locally, traditional requires OTA reflash |
Click any device node to inspect its individual metrics in the Device Inspector panel.
Edge Scenarios
The third tab provides calculators for three real-world deployment concerns.
Offline Resilience
Simulates network outages and compares how each approach handles them:
| Scenario | Duration | Behavior |
|---|---|---|
| 30s network blip | 30 seconds | Brief disconnection |
| 5 min outage | 5 minutes | Typical infrastructure failure |
| 30 min extended outage | 30 minutes | Major incident |
| Intermittent | 10s on / 20s off | Flaky connection |
| 30% packet loss | Continuous | Degraded link |
For each scenario, the calculator shows data queued, queue overflow risk, reconnect burst size, flush time, events missed, and detection capability during the outage. The key difference: traditional IoT goes blind during an outage (no cloud inference), while GenesisNode continues detecting events locally and only queues the small event packets for later transmission.
Cloud Cost Projection
Estimates monthly cloud costs at scale using real AWS IoT Core pricing ($1.00 per million messages, $0.09/GB egress). Azure IoT Hub and Google Cloud IoT pricing are also available for comparison.
Configurable parameters:
- Fleet size: 10 to 100,000 devices (logarithmic slider)
- Sample rate: 1, 2, 10, or 50 Hz
- Cloud provider
The calculator breaks down messaging costs, data transfer costs, and compute costs for both approaches, showing monthly and annual savings. At 10,000 devices and 2 Hz:
| Approach | Monthly Cost |
|---|---|
| Traditional IoT | ~$52,877 |
| GenesisNode Edge | ~$295 |
| Savings | ~$52,582/month ($631K/year) |
Battery Life and ESP32 Model Fit
Estimates battery life for four ESP32 variants:
| Variant | SRAM | Flash | PSRAM |
|---|---|---|---|
| ESP32 | 520 KB | 4 MB | -- |
| ESP32-S3 | 512 KB | 16 MB | 8 MB |
| ESP32-C3 | 400 KB | 4 MB | -- |
| ESP32-C6 | 512 KB | 4 MB | -- |
The calculator compares battery life at different sample rates and battery capacities. Traditional IoT (continuous WiFi streaming) drains batteries significantly faster than GenesisNode (mostly sleeping, WiFi only for sporadic event reports).
The ESP32 Model Fit section estimates how many GenesisNode nodes can fit in each variant's RAM and flash at ~650 bytes per node, whether the current trained model fits, RAM/flash utilization bars, and OTA update size estimates (including over LoRa).
Why This Matters
The Business Case
Traditional IoT architectures stream all raw sensor data to the cloud for processing. This creates three scaling problems:
- Bandwidth costs grow linearly with device count and sample rate. At 10,000 devices streaming at 2 Hz, you are pushing ~2.5 GB/hour to the cloud.
- Latency is bounded by the network. Cloud round-trip of 60ms+ means you cannot respond to safety-critical events in real time.
- Offline means blind. If the network drops, traditional devices have no local intelligence -- they just queue raw data and hope the connection comes back before the buffer overflows.
GenesisNode inverts this architecture. The $5 ESP32 runs inference locally using a sparse graph walk that completes in microseconds. Only meaningful events traverse the network. The result:
- 97%+ bandwidth reduction -- send 5 event packets per hour instead of 36,000 raw readings
- 2,500x latency improvement -- 24 microseconds on-device vs. 60ms cloud round-trip
- 83% power reduction -- WiFi radio sleeps most of the time
- Full offline capability -- detection continues without any network connection
- $52K/month savings at 10K devices -- verified against AWS IoT Core pricing
Integration Points
GenesisNode edge inference is designed to be compatible with existing IoT infrastructure:
- AWS IoT Core -- event-only MQTT messages instead of raw data streams
- Azure IoT Hub -- same event-driven pattern, compatible with IoT Edge modules
- MQTT -- standard protocol for event transmission; GenesisNode reduces message volume, not message format
- LoRa WAN -- sparse event traffic fits within LoRa's bandwidth constraints, enabling deployments where continuous streaming is physically impossible
What Makes GenesisNode Different from Other Edge AI
Unlike TensorFlow Lite Micro or Edge Impulse, GenesisNode does not deploy a frozen model that requires cloud retraining and full OTA reflash when conditions change. The graph-based architecture enables:
- On-device incremental learning -- the model can adapt to sensor drift without cloud connectivity
- Differential updates -- push individual node changes instead of reflashing the entire firmware
- Multi-task inference in a single model -- the same graph that handles anomaly detection can handle other tasks via context-tagged routing
The IoT simulation demonstrates these properties with a complete train-deploy-infer pipeline running in your browser.