Restaurant QSC Automation with Edge AI Camera:
Deploying a MQTT-Based Monitoring System (NE301 + YOLOv8)

The Hidden Cost of "Scheduled Cleaning" in QSC

In the world of global fast-food chains, QSC — Quality, Service, Cleanliness — is the operational standard that determines brand trust, franchise compliance scores, and in serious cases, operating licenses. Of the three pillars, Cleanliness is the one most vulnerable to silent failure: problems accumulate invisibly between audit windows.

Insect trap management sits squarely in this blind spot. Every restaurant in a network maintains sticky-paper trap boxes — typically checked and replaced on a fixed weekly or bi-weekly schedule. The logic is simple: show up on Tuesday, swap the paper, log the visit, move on. The problem is that the schedule is decoupled from reality. A high-traffic summer week might saturate a trap in three days. A slow February week might leave a perfectly good trap being replaced unnecessarily.

For a system integrator or developer building a monitoring solution for a chain restaurant client, the ask is straightforward: automate the decision of when to replace, not just log that replacement happened. This is the shift from scheduled maintenance to demand-driven maintenance — and it's the core problem this deployment guide addresses.

Why Edge AI — Not Cloud AI — for This Use Case

Before selecting hardware, the architectural decision that most affects system design is where inference runs. Cloud-based AI vision workflows route images to a remote API for processing and return a result. Edge AI runs the model directly on the camera device, with no round-trip. For restaurant back-of-house deployments, this distinction has real operational consequences.

The restaurant kitchen environment adds further constraints that favor on-device processing. Back-of-house areas frequently sit at the edge of WiFi coverage. Condensation from cooking and refrigeration affects connectivity. And in multi-franchise scenarios, sending raw video offsite creates a compliance surface that legal and IT teams at the franchise operator level are increasingly reluctant to accept.

System Architecture: End-to-End Data Flow

The full deployment stack for this use case involves five components, each with a clear responsibility. Understanding the data flow at this level helps integrators plan network topology, server requirements, and alert logic before hardware arrives on site.

The camera captures an image of the insect trap box on a configured schedule (every N minutes, or event-triggered). The on-device YOLOv8 model classifies the trap as either Effective or Critical-Replacement. The result — a JSON payload including class name, confidence score, battery level, and timestamp — is pushed via MQTT to a broker. Home Assistant (or any MQTT-compatible platform) consumes this topic and drives dashboard displays, history logging, and automated alerts to cleaning staff.

No image data leaves the device in steady-state operation. Only the structured inference result is transmitted. This architecture can be extended: multiple NE301 units across locations all push to the same broker, with device MAC addresses used as unique identifiers in the topic path (device/<mac>/uplink).

Step-by-Step: Training and Deploying a Custom Detection Model

This section walks through the full model lifecycle — from image collection through production deployment. The CamThink AI Tool Stack handles data management, training, and quantization in a single pipeline.

MQTT Integration: Connecting NE301 to Home Assistant

Once the model is deployed and the camera is publishing results, the MQTT integration is what makes the data operationally useful. Home Assistant is used here for its open-source status, broad hardware support, and flexible automation engine — but any MQTT-compatible platform (Node-RED, custom backend) works identically with the same topic structure.

1. Configure MQTT Forwarding on NE301

In the NE301 Web UI, navigate to Application Management and set your MQTT broker address, port (default 1883), uplink topic, and credentials. The device MAC address makes each device's topic path unique by default: device/<last-6-mac>/uplink.

2. NE301 MQTT Payload Structure

Every detection event publishes a JSON payload. Understanding the schema is necessary for building sensors and automation rules in any downstream platform:

// Abbreviated payload — key fields for integration
{
  "metadata": {
    "image_id":   "cam01_1767603614",
    "timestamp":  1770084900,         // Unix epoch
    "width":      1280,
    "height":     720
  },
  "device_info": {
    "device_name":     "NE301-2A38A5",
    "battery_percent": 100,
    "communication_type": "wifi"      // or "lte"
  },
  "ai_result": {
    "model_name":      "YOLOv8 Nano Object Detection",
    "inference_time_ms": 50,
    "ai_result": {
      "detections": [
        {
          "class_name":  "Effective",       // or "Critical-Replacement"
          "confidence":  0.87,
          "x": 0.004, "y": 0.053,
          "width": 0.999, "height": 0.804
        }
      ],
      "detection_count": 1
    }
  }
}

3. Home Assistant Configuration

Add the following sensor definitions to /homeassistant/configuration.yaml. Replace 76b2fc32 with your device's MAC-derived topic segment, and update class names if you used different labels during training.

mqtt:
  sensor:
    # 1. Trap status — driven by model class_name output
    - name: "Trap Monitoring Status"
      unique_id: "ne301_trap_status"
      state_topic: "device/76b2fc32/uplink"
      value_template: >-
        {% if value_json.ai_result.ai_result.detections | length > 0 %}
          {{ value_json.ai_result.ai_result.detections[0].class_name }}
        {% else %}
          None
        {% endif %}
      icon: "mdi:bug-check"

    # 2. Battery level
    - name: "NE301 Battery"
      unique_id: "ne301_battery"
      state_topic: "device/76b2fc32/uplink"
      value_template: "{{ value_json.device_info.battery_percent }}"
      device_class: battery
      unit_of_measurement: "%"

    # 3. Last detection timestamp
    - name: "Last Detection Event"
      unique_id: "ne301_last_event"
      state_topic: "device/76b2fc32/uplink"
      value_template: "{{ (value_json.metadata.timestamp | int) | timestamp_local }}"
      device_class: timestamp

After saving, apply changes in Home Assistant's Developer Tools → MQTT → Manually configured MQTT entities. The sensors will appear immediately in the Devices list. From here, standard Home Assistant automations can trigger notifications to cleaning staff when the Trap Monitoring Status sensor reads Critical-Replacement.

Hardware Selection for This Deployment

For insect trap monitoring in chain restaurant environments, hardware selection depends primarily on whether the deployment is a single-location PoC or a multi-site rollout, and whether mains power is accessible at the mounting point.

Recommended for This Use Case

NeoEyes NE301

Primary Node · On-Device AI

• STM32N6, Cortex-M55 + Neural-ART NPU
• 0.6 TOPS on-device inference
• 4MP MIPI CSI sensor (51°/88°/137° FOV)
• Wi-Fi · LTE Cat-1 · PoE variants
• Deep sleep: 7–8µA · IP67 weatherproof
• YOLOv8 native · Open firmware · Web UI

$199.90 – $258.00

Best for this use case: Single-location PoC, battery-powered mounting inside kitchen areas, LTE variant for locations with weak WiFi, PoE variant for always-on fixed installations.

View Details →

For Multi-Site Scale-Out

NeoEdge NG4500

Edge Server · Multi-Camera Hub

• NVIDIA Jetson Orin NX/Nano
• Up to 157 TOPS compute
• JetPack 6.0+ · supports VLM/LLM
• Multi-camera aggregation
• CAN · RS232 · RS485 · multi I/O
• Fanless · 12–36V DC

$899.00 – $1599.00

Best for: Enterprise chain rollouts where a single hub aggregates feeds from 10+ NE301 cameras across a large kitchen or multiple locations managed from one on-site server.

View Details →

For most initial deployments — a single restaurant location or a pilot across 3–5 sites — the NE301 operating standalone is the right architecture. The NG4500 becomes relevant when the client requires centralized inference management, model versioning across a camera fleet, or integration with heavier VLM-based analytics on the same edge node.

Deployment Roadmap: From PoC to Production

A realistic PoC for this use case runs 4–6 weeks from hardware receipt to a validated, alert-generating system. The timeline below assumes one system integrator or developer with access to the restaurant site for initial setup.

FAQ

Developer Resources