Diagram Overview

These diagrams provide visual representations of the ESL MQTT API system architecture, including network topology, message flows, timing sequences, and queue structures.

Interactive Diagrams: The diagrams below are rendered using Mermaid.js. You can zoom in/out and pan for better viewing of complex diagrams.

Sleep/Wake Protocol Architecture

This diagram illustrates the complete sleep/wake protocol system, showing how messages flow from the server through gateways to sleeping ESL devices.

graph TB subgraph "Cloud Infrastructure" SERVER[Central Server
MQTT Broker] CLOUD[Cloud Services
Web Dashboard] end subgraph "Store Network" ROUTER[Store Router
Internet Gateway] subgraph "WiFi ESL Devices" WIFI1[WiFi ESL 001
ESP32-S3] WIFI2[WiFi ESL 002
ESP32-S3] WIFI3[WiFi ESL 003
ESP32-S3] end subgraph "Gateway Network" MGW[Main Gateway
ESP32-S3] MESH1[Mesh Gateway 1
ESP32-C3] MESH2[Mesh Gateway 2
ESP32-C3] end subgraph "BLE ESL Devices" BLE1[BLE ESL 001
nRF52832] BLE2[BLE ESL 002
nRF52832] BLE3[BLE ESL 003
nRF52832] BLE4[BLE ESL 004
nRF52832] BLE5[BLE ESL 005
nRF52832] BLE6[BLE ESL 006
nRF52832] end end CLOUD --> SERVER SERVER --> ROUTER ROUTER --> MGW SERVER -.->|Direct WiFi| WIFI1 SERVER -.->|Direct WiFi| WIFI2 SERVER -.->|Direct WiFi| WIFI3 MGW -->|WiFi Mesh| MESH1 MGW -->|WiFi Mesh| MESH2 MGW -.->|BLE 5.0| BLE1 MGW -.->|BLE 5.0| BLE2 MESH1 -.->|BLE 5.0| BLE3 MESH1 -.->|BLE 5.0| BLE4 MESH2 -.->|BLE 5.0| BLE5 MESH2 -.->|BLE 5.0| BLE6 classDef serverClass fill:#667eea,stroke:#764ba2,stroke-width:2px,color:#fff classDef gatewayClass fill:#f093fb,stroke:#c084fc,stroke-width:2px,color:#000 classDef wifiClass fill:#10b981,stroke:#059669,stroke-width:2px,color:#fff classDef bleClass fill:#f59e0b,stroke:#d97706,stroke-width:2px,color:#fff class SERVER,CLOUD serverClass class MGW,MESH1,MESH2 gatewayClass class WIFI1,WIFI2,WIFI3 wifiClass class BLE1,BLE2,BLE3,BLE4,BLE5,BLE6 bleClass

Architecture Components

🖥️ Central Server

MQTT broker with global scheduling and queue management for all ESL devices

🌉 Main Gateway

ESP32-S3 powered coordination hub with load balancing and mesh network management

📡 Mesh Gateways

ESP32-C3 zone controllers with local BLE management and wake scheduling

📱 ESL Devices

nRF52832 ultra-low power devices with 4+ year battery life and scheduled wake cycles

Sleep/Wake Protocol Flow

1️⃣ Schedule Coordination

Central server calculates optimal wake times and distributes schedules to all gateways

2️⃣ Message Queuing

Messages are queued per device with priority handling and distributed to zone gateways

3️⃣ Zone Management

Each mesh gateway manages 4 ESL devices with staggered wake slots to prevent collisions

4️⃣ Device Wake Cycle

ESL devices wake on schedule, check for messages, update if needed, then return to deep sleep

Power Management Benefits

Key Advantages:
  • Ultra-Low Power: ESL devices consume <1µA in sleep mode
  • Coordinated Wakes: Staggered timing prevents network congestion
  • Message Buffering: Gateways queue messages during sleep periods
  • Scalable Architecture: Support for hundreds of devices per gateway

Sleep/Wake Protocol Flow

This detailed flowchart shows the complete step-by-step process of the sleep/wake protocol from message initiation to device sleep.

flowchart TD Start([Protocol Start]) --> CheckTime{Is it Wake Time?} CheckTime -->|No| DeepSleep[Deep Sleep Mode
~1µA Power] DeepSleep --> RTC[RTC Timer Active
Check every second] RTC --> CheckTime CheckTime -->|Yes| WakeUp[Wake Up Sequence
~5mA Power] WakeUp --> InitRadio[Initialize BLE Radio
~12mA Power] InitRadio --> ScanGW[Scan for Gateway
Advertising] ScanGW --> GWFound{Gateway Found?} GWFound -->|No| Timeout1{Timeout
30 seconds?} Timeout1 -->|No| ScanGW Timeout1 -->|Yes| EmergencySleep[Emergency Sleep
Try next cycle] EmergencySleep --> DeepSleep GWFound -->|Yes| Connect[Establish BLE
Connection] Connect --> Auth[Device Authentication
Send Device ID] Auth --> AuthSuccess{Auth OK?} AuthSuccess -->|No| AuthRetry{Retry < 3?} AuthRetry -->|Yes| Auth AuthRetry -->|No| EmergencySleep AuthSuccess -->|Yes| CheckQueue[Request Queued
Messages] CheckQueue --> HasMessages{Messages
Available?} HasMessages -->|No| SendStatus[Send Status Update
Battery, Signal] SendStatus --> CalcNext[Calculate Next
Wake Time] CalcNext --> SendAck[Send ACK to Gateway] SendAck --> Disconnect[Disconnect BLE] Disconnect --> DeepSleep HasMessages -->|Yes| ReceiveMsg[Receive Messages
~15mA Power] ReceiveMsg --> ValidateMsg{Message
Valid?} ValidateMsg -->|No| SendNack[Send NACK
Request Retransmit] SendNack --> ReceiveMsg ValidateMsg -->|Yes| ParseMsg[Parse Message
Type & Priority] ParseMsg --> MsgType{Message Type?} MsgType -->|Display Update| UpdateDisplay[Update E-ink Display
~20mA Power, 2-5 sec] MsgType -->|Config Update| UpdateConfig[Update Device Config
Save to Flash] MsgType -->|Status Request| CollectStatus[Collect Device Status
Battery, Temperature] MsgType -->|Firmware Update| FWUpdate[Firmware Update Process
~25mA Power] UpdateDisplay --> SendSuccess[Send Success ACK] UpdateConfig --> SendSuccess CollectStatus --> SendStatus FWUpdate --> SendSuccess SendSuccess --> MoreMessages{More Messages
in Queue?} MoreMessages -->|Yes| ReceiveMsg MoreMessages -->|No| CalcNext classDef sleepState fill:#e8f5e8,stroke:#10b981,stroke-width:2px classDef activeState fill:#fef3c7,stroke:#f59e0b,stroke-width:2px classDef commsState fill:#e0e7ff,stroke:#667eea,stroke-width:2px classDef errorState fill:#fef2f2,stroke:#ef4444,stroke-width:2px classDef processState fill:#f3e8ff,stroke:#8b5cf6,stroke-width:2px class DeepSleep,RTC,EmergencySleep sleepState class WakeUp,InitRadio,ScanGW,Connect,Disconnect activeState class Auth,CheckQueue,ReceiveMsg,SendStatus,SendAck,SendNack,SendSuccess commsState class Timeout1,AuthRetry errorState class ParseMsg,UpdateDisplay,UpdateConfig,CollectStatus,FWUpdate,CalcNext processState

Protocol Phases

🛌 Sleep Phase

Power: ~1µA
Duration: Hours to days
Activity: RTC timer monitoring, ultra-low power mode

⚡ Wake Phase

Power: ~5-12mA
Duration: 100-500ms
Activity: MCU startup, radio initialization, gateway scanning

📡 Communication Phase

Power: ~15mA
Duration: 2-30 seconds
Activity: BLE connection, authentication, data exchange

🔄 Processing Phase

Power: ~20-25mA
Duration: 2-10 seconds
Activity: Display updates, config changes, status collection

Error Handling & Recovery

Error Condition Detection Method Recovery Action Retry Policy
Gateway Not Found 30-second scan timeout Emergency sleep, try next cycle Progressive backoff: 1min, 5min, 15min
Authentication Failed Server rejection response Retry with fresh credentials 3 attempts, then emergency sleep
Message Corruption CRC/checksum validation Send NACK, request retransmit 5 attempts per message
Display Update Failed Display driver error Log error, continue with other messages 1 retry, then skip to next message
Low Battery Voltage monitoring (<3.0V) Extend sleep cycles, minimal updates Gradual degradation to preserve data

Power Consumption Analysis

Battery Life Calculation:
With a 2000mAh battery and optimized protocol:
  • Sleep Mode (99.9% of time): 1µA × 8760 hours = 8.76mAh/year
  • Wake Cycles (4 times/day): 15mA × 30sec × 1460 cycles = 182.5mAh/year
  • Display Updates (2 times/day): 20mA × 5sec × 730 cycles = 20.3mAh/year
  • Total Annual Usage: ~211mAh/year → 9.5 year battery life

Gateway Queue Structure

This diagram shows how messages are queued and prioritized at the gateway level for delivery to ESL devices.

graph LR S1[Message 1 HIGH] S2[Message 2 NORMAL] S3[Message 3 LOW] S4[Message 4 URGENT] QM[Queue Manager] UQ[URGENT Queue] HQ[HIGH Queue] NQ[NORMAL Queue] LQ[LOW Queue] D1Q[ESL 001 Queue] D2Q[ESL 002 Queue] D3Q[ESL 003 Queue] D4Q[ESL 004 Queue] DM[Delivery Manager] WS[Wake Schedule] E1[ESL 001] E2[ESL 002] E3[ESL 003] E4[ESL 004] S1 --> QM S2 --> QM S3 --> QM S4 --> QM QM --> UQ QM --> HQ QM --> NQ QM --> LQ UQ --> D1Q HQ --> D2Q NQ --> D3Q LQ --> D4Q D1Q --> DM D2Q --> DM D3Q --> DM D4Q --> DM DM --> WS DM --> E1 DM --> E2 DM --> E3 DM --> E4

Queue Management Features

Priority Level Use Case Delivery Time Retry Policy
URGENT Critical updates, emergencies Immediate (trigger wake) 5 attempts, 1 min interval
HIGH Price changes, important updates Next wake cycle 3 attempts, 5 min interval
NORMAL Regular updates, content refresh Scheduled wake time 3 attempts, standard
LOW Maintenance, logs, metrics Best effort 1 attempt only

Wake Timing Sequence

This diagram illustrates the precise timing of device wake cycles and how they are staggered to prevent network congestion.

sequenceDiagram participant S as Server participant MG as Main Gateway participant G1 as Mesh Gateway 1 participant G2 as Mesh Gateway 2 participant E1 as ESL_001 participant E2 as ESL_002 participant E5 as ESL_005 participant E6 as ESL_006 Note over S,E6: Wake Cycle at 08:00:00 rect rgb(200, 230, 255) Note over E1,E2: Slot 1: 08:00:00-08:00:15 E1->>G1: Check-in (08:00:00) G1->>E1: Queued messages E1->>G1: ACK + Sleep E5->>G2: Check-in (08:00:05) G2->>E5: Queued messages E5->>G2: ACK + Sleep end rect rgb(255, 230, 200) Note over E1,E2: Slot 2: 08:00:15-08:00:30 E2->>G1: Check-in (08:00:15) G1->>E2: Queued messages E2->>G1: ACK + Sleep E6->>G2: Check-in (08:00:20) G2->>E6: Queued messages E6->>G2: ACK + Sleep end Note over G1,G2: Status Report to Main Gateway G1->>MG: Batch status update G2->>MG: Batch status update Note over MG,S: Consolidated Report MG->>S: Wake cycle complete (8 devices)

Timing Considerations

⏱️ Slot Duration

15 seconds per device allows for connection setup, data transfer, and acknowledgment

🔄 Overlap Strategy

20% overlap between slots enables efficient use of gateway resources

📊 Load Distribution

Devices are distributed across gateways to balance network load

🎯 Synchronization

All devices sync to gateway time during check-in for accurate scheduling

Complete Network Flow

This comprehensive diagram shows all possible message routing paths in the ESL MQTT system with our specific hardware architecture.

graph TB CLOUD[Cloud Services] SERVER[Central Server] ROUTER[Store Router] WIFI1[WiFi ESL 001] WIFI2[WiFi ESL 002] WIFI3[WiFi ESL 003] MG[Main Gateway] BLE1[BLE ESL 001] BLE2[BLE ESL 002] MESH1[Mesh Gateway 1] BLE3[BLE ESL 003] BLE4[BLE ESL 004] BLE5[BLE ESL 005] MESH2[Mesh Gateway 2] BLE6[BLE ESL 006] BLE7[BLE ESL 007] BLE8[BLE ESL 008] CLOUD --> SERVER SERVER --> ROUTER ROUTER --> MG SERVER --> WIFI1 SERVER --> WIFI2 SERVER --> WIFI3 MG --> MESH1 MG --> MESH2 MG --> BLE1 MG --> BLE2 MESH1 --> BLE3 MESH1 --> BLE4 MESH1 --> BLE5 MESH2 --> BLE6 MESH2 --> BLE7 MESH2 --> BLE8

Hardware Specifications

📱 WiFi ESLs (ESP32-S3)

Direct server connection for real-time updates

  • Dual-core Xtensa LX7 @ 240MHz
  • 512KB SRAM + up to 8MB PSRAM
  • 802.11 b/g/n WiFi
  • TLS encryption support

📡 Main Gateway (ESP32-S3)

Primary bridge with BLE coordination

  • Dual-core Xtensa LX7 @ 240MHz
  • 512KB SRAM + 8MB PSRAM
  • WiFi mesh + BLE 5.0
  • PoE+ power supply

📡 Mesh Gateways (ESP32-C3)

Cost-optimized zone coverage

  • Single-core RISC-V @ 160MHz
  • 400KB SRAM
  • WiFi mesh + BLE 5.0
  • PoE power supply

📟 BLE ESLs (nRF52832)

Ultra-low power with 4+ year battery life

  • ARM Cortex-M4F @ 64MHz
  • 64KB RAM, 512KB Flash
  • BLE 5.0 with extended advertising
  • <1µA standby current

Connection Types

Legend:
  • Solid lines (⟷): Always-on connections (Internet, WiFi)
  • Dashed lines (- - →): On-demand connections (BLE, scheduled wake-ups)
  • Double arrows (⟷): Bidirectional communication
  • Direct paths: WiFi ESLs bypass gateways for real-time updates

Hardware Architecture Overview

This diagram shows the specific hardware components and their relationships in our ESL system.

graph TB SERVER[Central Server] WESL1[ESP32-S3 WiFi ESL] WESL2[ESP32-S3 WiFi ESL] MGW[Main Gateway ESP32-S3] MESH1[Mesh Gateway ESP32-C3] MESH2[Mesh Gateway ESP32-C3] BESL1[nRF52832 BLE ESL] BESL2[nRF52832 BLE ESL] BESL3[nRF52832 BLE ESL] SERVER --> WESL1 SERVER --> WESL2 SERVER --> MGW MGW --> MESH1 MGW --> MESH2 MGW --> BESL1 MESH1 --> BESL2 MESH2 --> BESL3

Key Hardware Benefits

🚀 ESP32-S3 Performance

Dual-core 240MHz processor with 8MB PSRAM enables complex applications and real-time processing

💰 ESP32-C3 Cost Efficiency

RISC-V architecture provides excellent price-performance ratio for mesh gateways

🔋 nRF52832 Power Efficiency

Advanced power management achieves 4+ year battery life with scheduled wake cycles

🌐 Direct WiFi Architecture

ESP32-S3 WiFi ESLs bypass gateways for critical real-time updates and high reliability

ESL Device State Machine

This diagram shows the various states an ESL device can be in and the transitions between them.

stateDiagram-v2 [*] --> PowerOn PowerOn --> Initialization PowerOn --> Error Initialization --> DeepSleep DeepSleep --> WakeTransition WakeTransition --> Connecting Connecting --> Connected Connecting --> DeepSleep Connected --> Authenticated Connected --> DeepSleep Authenticated --> ReceivingData Authenticated --> DeepSleep ReceivingData --> ProcessingData ReceivingData --> DeepSleep ProcessingData --> UpdatingDisplay ProcessingData --> DeepSleep UpdatingDisplay --> DeepSleep Error --> [*]

State Descriptions

State Description Power Usage Typical Duration
Deep Sleep Ultra-low power mode, RTC active ~10 µA Hours
Wake Transition MCU startup, radio initialization ~5 mA 100-200 ms
Connecting BLE scanning and connection setup ~12 mA 1-3 seconds
Connected Active BLE connection ~15 mA Variable
Receiving Data Downloading messages/images ~15 mA 2-10 seconds
Updating Display E-ink display refresh ~20 mA 2-5 seconds

Additional Resources

🏗️ System Architecture

Detailed explanation of system components

⚡ Sleep/Wake Protocol

In-depth protocol documentation

📋 API Reference

Complete API specifications

📄 PDF Download

Offline documentation