SmartDB Logo

SmartDB v2

  • SmartDB Firebase API and team integration
    • Run locally
    • Frontend handoff
    • Ownership and device installation
    • Delivery, configuration and commands
    • Firebase deployment
    • Source and verification
  • Current v2 system architecture
    • Responsibilities and data flow
    • Hardware and firmware boundary
    • Local control and fusion
      • Fusion data flow
      • Local protection state machine
    • Cloud and frontend boundary
      • Telemetry and preview delivery
      • Cloud command application
    • Validation and remaining production work
  • SmartDB developer console
  • SmartDB v2 system firmware
    • Easy setup — one terminal menu
      • What each menu item does
      • Where configuration lives
      • Setup troubleshooting
    • Manual build and flash (optional)
    • Local sensing and protection
    • RGB–thermal fusion
    • Firebase integration
    • Postman and telemetry
    • Verification and source layout
  • SmartDB v2 — permanent compact project
    • Current revision
    • Firmware and setup
    • Files and previews
    • Previous revision
  • SmartDB compact redesign — board routing complete
    • Saved work
    • Connector access and routing
    • STEP export
    • Two-camera connections
    • Validation status and remaining work
    • Resuming the editing scripts
  • SmartDB Postman Collection Guide
    • Protocol boundary
      • Implemented v2 bench firmware
    • Import and environment setup
    • Recommended workflow
    • Collection coverage
      • Authentication
      • Users and notifications
      • Devices and configuration
      • Telemetry, alerts, and commands
    • Status and error conventions
    • Maintaining the collection
  • SmartDB Device Ingestion Gateway
    • Status and security boundary
    • Quick start
    • Resources
    • Configuration
    • Development state model
    • Production checklist
  • SmartDB
    • Household Electrical Fault Detection & Protection System
      • Full Engineering Development Specification
    • Document Control
      • Current v2 bench implementation — 10 October 2026
      • Revision History
      • Normative Language
    • Contents
    • Executive Summary
      • Release 1 Product Decisions
      • Primary Deliverables
    • Product Definition and Scope
      • Core Use Case
      • Actors
      • In Scope for Release 1
      • Explicitly Out of Scope (Release 1)
      • Functional Requirements
      • Non-Functional Targets
    • Reference Architecture
      • Ownership Boundary
      • Data Classification
      • Shared Engineering Rules
    • PART A — Embedded/Edge Engineering Specification
      • ESP32 sensing, signal processing, rule-based safety layer, relay control, and security
    • Embedded/Edge Team Scope
      • Team Responsibilities
      • Edge Team Does Not Own
    • Firmware Architecture
      • Repository Layout
      • Edge Processing Pipeline
      • Rule-Based Threshold Engine (Independent Safety Layer)
      • Relay Control
      • Security
      • Offline/Battery-Backed Behavior
      • Power Subsystem
    • Mandatory Edge Test Cases
    • PART B — Cloud AI Inference Engineering Specification
      • Isolation Forest, YOLO RGB detection, thermal anomaly analysis, and decision fusion
    • AI Inference Team Scope
      • Responsibilities
      • AI Pipeline
      • RGB and thermal fusion design — 2026-10-10
      • Fusion and Decision Rules
      • Model Governance
    • AI/Vision Verification and Acceptance
    • PART C — Cloud Backend Engineering Specification
      • Firebase: ingestion, storage, alert routing, device registry
    • Cloud Backend Team Scope
      • Responsibilities
      • Cloud Team Does Not Own
    • Core Cloud Data Model
    • Cloud API/Event Contract
      • Illustrative backend-enriched event
      • Cloud Function Responsibilities
    • Cloud Security and Reliability
    • Cloud Verification and Acceptance
    • PART D — Mobile Application Engineering Specification
      • Flutter app
    • Mobile App Scope
      • Responsibilities
      • Key Screens
      • Alert UX Rules
    • Mobile Verification and Acceptance
    • PART E — Shared Interface, Delivery, and Program Management
    • Ownership Matrix (RACI)
    • Hardware Procurement Summary
      • Hardware Bill of Materials
      • Software Costs
      • Software Stack
    • Project Plan and Timeline
    • End-to-End Acceptance Tests
    • Evaluation Plan
      • Success Criteria
      • Data Collection
    • Risk Register
      • Mitigation Strategy (High-Priority Risks)
    • Stakeholders
      • Primary Beneficiaries
      • Secondary Beneficiaries
      • Stakeholder Engagement
    • Open Decisions Before Field Pilot
    • Device Ingestion API — Production CoAP/DTLS Contract
      • Versioned Resources and Methods
      • Common Envelope and Origin Boundary
      • Examples (JSON Rendering of the CBOR Model)
      • Delivery, ACKs, Retry, and Reconnect
      • Offline Queue, Ordering, and Datagram Size
      • Idempotency, Replay, Reboot, and Time
      • Responses and Errors
      • PSK Lifecycle, Configuration Trust, and Rate Limits
      • Observability and Safety Invariant
    • Repository Implementation, API Tooling, and Operations
      • Repository Map and Sources of Truth
      • Implemented Device Gateway
      • Gateway Runbook
      • HTTP API and Postman Collection Rules
      • Verification Matrix
      • Known Production Gaps and Required Closure
    • Conclusion
      • Immediate Next Steps
    • References
  • SmartDB
    • Project links
    • Repository map
    • Run the backend locally
    • Set up the two boards
    • Current hardware
    • Project maturity
    • Code style
    • Related projects

Code and API reference

  • Firmware code guide
    • Build structure
    • Where to change behavior
    • Startup and task boundaries
    • Fusion and measurement
    • Configuration ownership
    • Source interfaces and verification
  • C interfaces
    • Fusion core
    • Protection core
    • System control
    • Connection settings
    • Telemetry publisher
  • Protocol implementation
    • USB dispatcher
    • HTTPS telemetry worker
  • Local HTTP API
    • Routes and responses
    • Read status
    • Replace control configuration
    • Open the relay
    • Retrieve images
    • Contract and examples
  • USB setup protocol
    • Framing
    • Operations
    • Read and update control limits
    • Connection settings
  • Telemetry and central API
    • Configure delivery
    • Payload
    • Queue, retry and server responsibilities
    • Other central routes

Related projects

  • SmartDB project directory
  • ByteLab
    • Browser edition
    • Available features and SmartDB fit
    • Install and open the project
    • Inspect a SmartDB board over USB
    • Telemetry integration boundary
    • ByteLab source map

Development reference

  • PlatformIO setup for SmartDB v2
    • Interactive setup
    • Build targets
    • Configuration and recovery
  • Workflow for ESP-IDF
    • Enter your project
    • Load ESP-IDF environment (if not already loaded)
    • Configure project (optional)
    • Build
    • Find ESP32 serial port
    • Flash firmware
    • Monitor serial output
    • Normal development loop
    • CMake errors
    • Before committing to Git
  • Blink LED: ESP-IDF Edition
    • Purpose
    • Development Environment
      • Host Machine
    • ESP-IDF Environment Setup
    • Load ESP-IDF
    • Creating ESP-IDF Project
    • Code
      • Explanation
    • Overall execution flow
      • Why using Preprocessor
      • Why use pointers
      • Why use struct
      • How they work together
    • Project Migration to main.c
    • Build System Verification
    • Issue: Missing app_main
      • Error
      • Cause
      • Solution
    • Issue: Missing Source File
      • Error
      • Cause
      • Solution
    • LED Blink Implementation
    • Issue: Unsupported LED Type
      • Error
      • Cause
      • Solution: Simplify GPIO Control
    • Final Firmware Structure
    • Build Workflow
      • Development cycle
    • Hardware Connection
    • Clean Build
  • LED Blink API Reference: ESP-IDF edition
    • GPIO: General Purpose Input Output
      • esp_err_t gpio_reset_pin(gpio_num_t gpio_num)
      • esp_err_t gpio_set_level(gpio_num_t gpio_num, uint32_t level)
      • esp_err_t gpio_set_direction(gpio_num_t gpio_num, gpio_mode_t mode)
    • LED Strip (led_strip)
      • Allocate LED Strip Object with RMT Backend
      • Allocate LED Strip Object with SPI Backend
      • function led_strip_clear
      • function led_strip_refresh
      • function led_strip_set_pixel
      • struct led_strip_rmt_config_t
      • function led_strip_new_rmt_device
      • struct led_strip_spi_config_t
      • function led_strip_new_spi_device
  • Preprocessor
    • File Inclusion
    • Macro Substitution
    • Conditional Inclusion
  • Pointer and Smart Pointer
    • Pointer
    • Pointer as Arguments
    • Pointers and Arrays
  • YOLOv26 – Architectural Overview
    • Convolutional Neural Network (CNN)
      • Layers of a CNN
      • How a CNN Works
      • Feature Extraction
    • CV: Computer Vision
      • Image Classification
      • Object Localization
      • Object Detection
      • Image Segmentation
      • Relationship Between Tasks
    • Object Detection
      • Detection pipeline
      • Bounding Box
      • Confidence score and objectness
      • Class Probability
      • Intersection over Union (IoU)
      • Non-Maximum Suppression (NMS)
    • YOLO Architecture
      • One-Stage Detection
      • Backbone Network
      • Neck (Feature Aggregation Module)
      • Detection Head
      • Multi-scale Predition
    • YOLOv26
      • Architectural Improvement
      • New Modules
      • Loss Function
      • Training Strategy
  • Jetson Orin Nano Configuration
    • System Requirements
      • Host Machine (for SDK Manager)
      • Target Device
    • Installation
      • Prepare Host Machine
      • Install SDK Manager
      • Flash JetPack SDK
      • Verify Installation
    • Environment Configuration
      • First boot
      • Install Jetson Monitoring tools
      • Install NVIDIA container runtime
      • Install NVIDIA container runtime:
      • Install NVIDIA container toolkit
      • Create YOLO workspace
      • Test YOLO
      • Optimize for Jetson
      • Camera setup
      • SmartDB recommended architecture
  • SmartDB ESP32-CAM diagnostic firmware
    • Current status
    • Hardware assumptions
    • Build, flash, and monitor
    • Configuration
    • How to use it
    • Expected serial output
    • Latest monitor log explained
    • Code explanation
      • Headers and SCCB declarations
      • Compile-time options and pin definitions
      • camera_config
      • SD state: sd_card and sd_mounted
      • sd_init()
      • wifi_init_softap()
      • gpio_level_check()
      • sccb_debug_scan()
      • camera_init()
      • capture_frame()
      • app_main() and complete control flow
    • Troubleshooting
    • Project layout
  • Documentation website
    • Publish to Vercel
    • Architecture diagrams
SmartDB
  • LED Blink API Reference: ESP-IDF edition

LED Blink API Reference: ESP-IDF edition

GPIO: General Purpose Input Output

esp_err_t gpio_reset_pin(gpio_num_t gpio_num)

Reset a GPIO to a certain state (select gpio function, enable pullup and disable input and output).

  • Parameters:

    • gpio_num – GPIO number.

  • Returns:

    • ESP_OK Success

    • ESP_ERR_INVALID_ARG Parameter error

esp_err_t gpio_set_level(gpio_num_t gpio_num, uint32_t level)

GPIO set output level.

Note: This function is allowed to be executed when Cache is disabled within ISR context, by enabling CONFIG_GPIO_CTRL_FUNC_IN_IRAM

  • Parameters:

    • gpio_num – GPIO number. If you want to set the output level of e.g. GPIO16, gpio_num should be GPIO_NUM_16 (16);

    • level – Output level. 0: low ; 1: high

  • Returns:

    • ESP_OK Success

    • ESP_ERR_INVALID_ARG GPIO number error

esp_err_t gpio_set_direction(gpio_num_t gpio_num, gpio_mode_t mode)

GPIO set direction. Configure GPIO mode,such as output_only,input_only,output_and_input

Note: This function always overwrite all the current modes that have applied on the IO pin

  • Parameters:

    • gpio_num – Configure GPIO pins number, it should be GPIO number. If you want to set direction of e.g. GPIO16, gpio_num should be GPIO_NUM_16 (16);

    • mode – GPIO direction

  • Returns:

    • ESP_OK Success

    • ESP_ERR_INVALID_ARG GPIO error

LED Strip (led_strip)

Allocate LED Strip Object with RMT Backend

#define BLINK_GPIO 0

/// LED strip common configuration
led_strip_config_t strip_config = {
    .strip_gpio_num = BLINK_GPIO,  // The GPIO that connected to the LED strip's data line
    .max_leds = 1,                 // The number of LEDs in the strip,
    .led_model = LED_MODEL_WS2812, // LED strip model, it determines the bit timing
    .color_component_format = LED_STRIP_COLOR_COMPONENT_FMT_GRB, // The color component format is G-R-B
    .flags = {
        .invert_out = false, // don't invert the output signal
    }
};

/// RMT backend specific configuration
led_strip_rmt_config_t rmt_config = {
    .clk_src = RMT_CLK_SRC_DEFAULT,    // different clock source can lead to different power consumption
    .resolution_hz = 10 * 1000 * 1000, // RMT counter clock frequency: 10MHz
    .mem_block_symbols = 64,           // the memory size of each RMT channel, in words (4 bytes)
    .flags = {
        .with_dma = false, // DMA feature is available on chips like ESP32-S3/P4
    }
};

/// Create the LED strip object
led_strip_handle_t led_strip = NULL;
ESP_ERROR_CHECK(led_strip_new_rmt_device(&strip_config, &rmt_config, &led_strip));

Allocate LED Strip Object with SPI Backend

#define BLINK_GPIO 0

/// LED strip common configuration
led_strip_config_t strip_config = {
    .strip_gpio_num = BLINK_GPIO,  // The GPIO that connected to the LED strip's data line
    .max_leds = 1,                 // The number of LEDs in the strip,
    .led_model = LED_MODEL_WS2812, // LED strip model, it determines the bit timing
    .color_component_format = LED_STRIP_COLOR_COMPONENT_FMT_GRB, // The color component format is G-R-B
    .flags = {
        .invert_out = false, // don't invert the output signal
    }
};

/// SPI backend specific configuration
led_strip_spi_config_t spi_config = {
    .clk_src = SPI_CLK_SRC_DEFAULT, // different clock source can lead to different power consumption
    .spi_bus = SPI2_HOST,           // SPI bus ID
    .flags = {
        .with_dma = true, // Using DMA can improve performance and help drive more LEDs
    }
};

/// Create the LED strip object
led_strip_handle_t led_strip = NULL;
ESP_ERROR_CHECK(led_strip_new_spi_device(&strip_config, &spi_config, &led_strip));

function led_strip_clear

Clear LED strip (turn off all LEDs)

esp_err_t led_strip_clear (
    led_strip_handle_t strip
) 
  • Parameters:

    • strip LED strip

  • Returns:

    • ESP_OK: Clear LEDs successfully

    • ESP_FAIL: Clear LEDs failed because some other error occurred

function led_strip_refresh

Refresh memory colors to LEDs.

esp_err_t led_strip_refresh (
    led_strip_handle_t strip
) 
  • Parameters:

    • strip LED strip

  • Returns:

    • ESP_OK: Refresh successfully

    • ESP_FAIL: Refresh failed because some other error occurred

Note: After updating the LED colors in the memory, a following invocation of this API is needed to flush colors to strip.

function led_strip_set_pixel

Set RGB for a specific pixel.

esp_err_t led_strip_set_pixel (
    led_strip_handle_t strip,
    uint32_t index,
    uint32_t red,
    uint32_t green,
    uint32_t blue
)
  • Parameters:

    • strip LED strip

    • index index of pixel to set

    • red red part of color

    • green green part of color

    • blue blue part of color

  • Returns:

    • ESP_OK: Set RGB for a specific pixel successfully

    • ESP_ERR_INVALID_ARG: Set RGB for a specific pixel failed because of invalid parameters

    • ESP_FAIL: Set RGB for a specific pixel failed because other error occurred

struct led_strip_rmt_config_t

LED Strip RMT specific configuration.

  • Variables:

    • rmt_clock_source_t clk_src RMT clock source

    • struct led_strip_rmt_config_t::led_strip_rmt_extra_config flags Extra driver flags

    • size_t mem_block_symbols How many RMT symbols can one RMT channel hold at one time. Set to 0 will fallback to use the default size. Extra RMT specific driver flags

    • uint32_t resolution_hz RMT tick resolution, if set to zero, a default resolution (10MHz) will be applied

function led_strip_new_rmt_device

Create LED strip based on RMT TX channel.

esp_err_t led_strip_new_rmt_device (
    const led_strip_config_t *led_config,
    const led_strip_rmt_config_t *rmt_config,
    led_strip_handle_t *ret_strip
) 
  • Parameters:

    • led_config LED strip configuration

    • rmt_config RMT specific configuration

    • ret_strip Returned LED strip handle

  • Returns:

    • ESP_OK: create LED strip handle successfully

    • ESP_ERR_INVALID_ARG: create LED strip handle failed because of invalid argument

    • ESP_ERR_NO_MEM: create LED strip handle failed because of out of memory

    • ESP_FAIL: create LED strip handle failed because some other error

struct led_strip_spi_config_t

LED Strip SPI specific configuration.

  • Variables:

    • spi_clock_source_t clk_src SPI clock source

    • struct led_strip_spi_config_t flags Extra driver flags

    • spi_host_device_t spi_bus SPI bus ID. Which buses are available depends on the specific chip

    • uint32_t with_dma Use DMA to transmit data

function led_strip_new_spi_device

Create LED strip based on SPI MOSI channel.

esp_err_t led_strip_new_spi_device (
    const led_strip_config_t *led_config,
    const led_strip_spi_config_t *spi_config,
    led_strip_handle_t *ret_strip
) 

Note: Although only the MOSI line is used for generating the signal, the whole SPI bus can’t be used for other purposes.

  • Parameters:

    • led_config LED strip configuration

    • spi_config SPI specific configuration

    • ret_strip Returned LED strip handle

  • Returns:

    • ESP_OK: create LED strip handle successfully

    • ESP_ERR_INVALID_ARG: create LED strip handle failed because of invalid argument

    • ESP_ERR_NOT_SUPPORTED: create LED strip handle failed because of unsupported configuration

    • ESP_ERR_NO_MEM: create LED strip handle failed because of out of memory

    • ESP_FAIL: create LED strip handle failed because some other error

Previous Next

© Copyright 2026, SmartDB.

Built with Sphinx using a theme provided by Read the Docs.