Low-Power Edge Camera External Trigger Guide : PIR, GPIO, MQTT, and Battery Life – NE101 & NE301 Guide

Trigger Architecture: How Triggers Work

A low-power camera node spends almost all its time in deep sleep — drawing microamps, waiting for a reason to wake. The trigger is that reason. When a trigger fires, the device goes through a fixed sequence: wake → stabilise → capture → infer (if applicable) → upload over MQTT → return to sleep. The entire active window is short — typically under 15 seconds for both NE101 and NE301 on WiFi, depending on network conditions. This sleep-first design is what enables years of battery life — the camera only draws power when it has a reason to be awake.

Every trigger ultimately produces the same output: an MQTT message containing device metadata, battery status, capture type, and the encoded image. The trigger type is recorded in the snapType field (NE101) or equivalent field in the NE301 payload, so your downstream system always knows why the camera fired. This consistency simplifies integration — whether the trigger is PIR, scheduled, or remote command, your backend receives the same predictable payload format.

The split between hardware triggers and software triggers matters for your deployment strategy. Hardware triggers (PIR, door sensors, alarm inputs) can wake the camera from deep sleep instantly — they’re the most power-efficient option for battery-powered deployments. Software triggers (scheduled capture, remote MQTT commands) give you more control and flexibility, but require the camera to wake periodically, which uses more battery. This trade-off is covered in detail in the sleep/wake section. The key insight: choose hardware triggers when battery life is critical, and add software triggers when you need scheduled or on-demand capture capabilities.

6 Core Trigger Types — When to Use Each

Both NE101 and NE301 support the following trigger categories. NE301 adds AI detection and MQTT remote command as additional modes (covered separately). All trigger modes are configured in the Web UI — no coding required. The trigger type you choose affects battery life, response time, and deployment complexity, so it’s worth matching the trigger to your use case from the start. Below is a quick reference guide to help you choose the right option for your project.

IO Interfaces & Integration Boundary

Both NE101 and NE301 expose a 16-pin IO connector that determines what external sensors you can integrate. This matters because it affects whether you can connect your existing infrastructure directly (door sensors, industrial PLCs, smart meters) or if you’ll need custom integration work. The table below summarizes what’s available on each device — use it to check compatibility before you commit to a hardware platform.

Integration boundary

The standard interface covers most deployment scenarios without custom firmware. The boundary where customisation begins: if you need to change the MQTT payload format, implement a non-standard protocol on the IO pins, or integrate a sensor type not covered by the expansion board ecosystem, that requires firmware modification. The good news: Both firmware codebases are fully open-source on GitHub — NE101 firmware (ESP-IDF based) and NE301 firmware are available for cloning, modification, and custom builds. Standard deployments — PIR trigger, scheduled capture (NE101/NE301), MQTT remote command (NE301) — require no firmware changes. If you’re unsure whether your use case requires custom development, reach out to our team — we can help you assess the effort and suggest the fastest path to deployment.

Camera Node vs Gateway: Which Architecture Fits Your Project?

CamThink products serve two distinct architectural roles. Choosing the right one matters because they solve different problems: camera nodes (NE101, NE301) capture and transmit images, while gateways (NG4500) receive and process images from multiple cameras. Understanding this distinction upfront helps you design a system that fits your needs without over- or under-specifying hardware.

MQTT Payload Structure: NE101 vs NE301

After capture, the device encodes the JPEG image as Base64 and embeds it directly in a JSON MQTT payload. There is no separate HTTP file transfer — everything travels in a single MQTT message on the configured topic. This simplifies integration — your backend only needs an MQTT subscriber, no separate file server or multipart parsing. Understanding the payload format upfront helps you plan your bandwidth requirements and integration effort.

NE101 payload structure

The NE101 sends a compact JSON payload with device metadata, battery status, and the image. All the information your backend needs is in one message — timestamp, device ID, trigger type, battery level, and the image itself.

{
  "ts": 1740640441620,          // Unix timestamp, milliseconds
  "values": {
    "devName":  "NE101 Sensing Camera",
    "devMac":   "D8:3B:DA:4D:10:2C",
    "battery":  84,                 // Battery % — monitor for replacement planning
    "snapType": "PIR",              // Button | Scheduled | PIR | Alarm
    "localtime":"2026-04-22 08:30:00",
    "imageSize":74371,              // bytes
    "image":    "data:image/jpeg;base64,..."
  }
}

NE301 payload structure

The NE301 payload is richer by design — it bundles the AI inference result with the image in a single message. This eliminates a separate inference step on your server — the camera tells you exactly what it detected (person, vehicle, etc.) with confidence scores and bounding box coordinates. Your downstream system can act directly on this data without re-processing the image.

{
  "metadata": {
    "image_id":  "cam01_1766132582",
    "timestamp": 1766132582,
    "width": 1280, "height": 720, "size": 61880
  },
  "device_info": {
    "device_name":       "NE301-2A207D",
    "battery_percent":   41,
    "power_supply_type": "battery",
    "communication_type":"wifi"
  },
  "ai_result": {
    "model_name":       "YOLOv8 Nano Object Detection (Int8)",
    "inference_time_ms":50,          // On-device inference, pre-upload
    "ai_result": {
      "type_name":       "object_detection",
      "detection_count": 1,
      "detections": [
        {
          "class_name":  "person",
          "confidence":  0.876,
          "x": 0.45, "y": 0.30,
          "width": 0.18, "height": 0.62
        }
      ]
    }
  },
  "image_data": "data:image/jpeg;base64,..."
}

For NE301, configure the Data Reporting Topic (uplink) and Data Receiving Topic (downlink for remote control) separately in the Web UI under Application Management → MQTT/MQTTS. Tip: Use the MQTTX client tool during development to inspect payloads in real-time — this helps you verify integration before writing backend code.

Battery Life: How Trigger Frequency Affects Power Consumption

Battery life is determined almost entirely by how often the camera wakes up, not how deep it sleeps. Both NE101 and NE301 spend most of their time in deep sleep drawing microamps — the power drain during active cycles is what adds up. The key insight: Reducing captures from 20/day to 5/day roughly quadruples battery life. This section gives you the power figures you need to plan deployments that last years, not months.

NE301 power figures

• Deep sleep: 6.1 µA (managed by the U0 power controller — the STM32U073Kx monitors sensors and wakes the STM32N6 only when needed)
• Active (WiFi mode): 170–180 mA
• Wake-up latency: milliseconds from deep sleep to active
• Battery baseline: 4× AA alkaline, ~13 years at 1 capture/day in WiFi mode
• LTE Cat.1: active current and cycle time vary by network conditions and module configuration (EG912U-GL global / EG915Q-NA North America)

NE101 power figures

• Deep sleep: ≤1 W standby (system level)
• Battery baseline: 3+ years in WiFi mode at 10 captures/day (4× AA)
• LTE Cat.1: shorter battery life than WiFi at equivalent capture frequency.

The key design principle: the active window is short and fixed — it is the number of active windows per day that you control. Reducing captures from 20/day to 5/day roughly quadruples battery life. Choosing WiFi over LTE at equivalent capture frequency roughly doubles it (lower TX current, shorter TX window).

Frequently Asked Questions

Quick answers to common questions about triggers, integration, and battery life.