Skip to main content

NE101 Camera: The Most Complex Device-Bound Component in the NeoMind Ecosystem

One-sentence positioning: the flagship component that brings the CamThink NE101 sensing camera into the Dashboard β€” it is the first component in the NeoMind marketplace to combine device binding + image canvas + AI processing pipeline + ROI overlay in a single bundle, extending the entry-level metric_card "show a number" story into a full "device β†’ inference β†’ visual overlay" chain.

This is the "flagship deep-dive case" of the NeoMind component marketplace. The previous six cases (with 6 metric_card as the direct prerequisite) teach you "how to write a component"; this case's eight subpages answer "how to write a complex component that wires hardware + AI + visual effects together". After reading it you will understand why NeoMind's "IIFE + window.React injection" pattern (instead of ESM bundling) scales to 1972 lines of hand-written code, and why the manifest combination has_data_source: false + has_device_binding: true is the canonical signature of any device-bound component.

The flagship case has eight subpages organized by dependency. Read them in the order below; pages marked β˜… are MVP core (required reading for the v1 release), the rest are v1.1 increments.

1 Background β†’ 2 Architecture β†’ 3 Extension Side β†’ 4 Data Contract β˜… β†’ 5 Frontend Consume β˜… β†’ 6 Component Build β˜… β†’ 7 Integration Test β†’ 8 Deep Dive

If you are short on time and only want to understand "how this component works", read 1 + 2 + 4 + 5 + 6. If you plan to fork the component or retarget it to another camera device, also read 3 (the extension-side contract) and 7 (ROI rendering).

Eight-Subpage Index​

#TitleRoleStatus
1Business BackgroundNE101 device capabilities + why a dedicated component is needed + ecosystem positioningMVP
22-architecture.md (v1.1)Module breakdown of the 1972-line IIFE, component tree, data flowv1.1
33-extension-side.md (v1.1)The processingExtensionId generic contract + how extensions consume imagesv1.1
44-data-contract.md β˜…MQTT topics, WebSocket deltas, the detections field schemaMVP
55-frontend-consume.md β˜…How the component fetches detections, parses JSON strings, colors per classMVP
66-component-build.md β˜…The NE101CameraPanel named export, IIFE injection, React-hooks-in-IIFE pitfallsMVP
77-integration-test.md (v1.1)End-to-end integration tests, ROI overlay verification, multi-extension switching matrixv1.1
88-deep-dive.md (v1.1)Version evolution (133 commits), debug traces, performance tuning, source hygiene recapv1.1

Relationship to 6 metric card: From Starter to Flagship​

This case is a direct continuation of 6 metric_card, but an order of magnitude more complex. The table below maps the two cases so you can build a "starter β†’ flagship" cognitive ladder.

Dimensionmetric_card (starter)ne101_camera (flagship)
bundle.js lines3521972 (5.6Γ—)
Component typeDisplay (category: "display")Device (category: "device")
Data accessBinds a data source (has_data_source: true)Binds a device (has_device_binding: true + device_type_filter)
Renders imagesNo (scalars only)Yes (JPEG capture + Canvas ROI overlay)
Triggers AI inferenceNoYes (via processingExtensionId)
Named exportNeoMind_MetricCardNE101CameraPanel (note: not default)
Hardest topicOKLCH + CSS variable glassROI normalized coords + processingRoiOverlap threshold + React-in-IIFE hooks pitfalls

Recommendation: if you have not read the metric_card case yet, read its 1-3 first. metric_card teaches the triple "IIFE injection + manifest contract + fetchData pull"; that triple remains the underlying skeleton of ne101_camera, with two additional layers (device binding and AI processing) stacked on top.

What You Will Learn​

Reading all eight sections will give you five key capabilities:

  1. The essential difference between device binding and data source β€” why NE101 uses has_device_binding: true + device_type_filter: ["ne101_camera"] instead of has_data_source: true. This determines whether the dashboard editor shows a "bind device" panel and whether the component receives device telemetry deltas (e.g. image_url change push). See 1 Business Background.

  2. How a 1972-line IIFE stays maintainable β€” bundle.js has no build step at all; it is entirely hand-written IIFE. We break down its module layers (helper / template / sub-component / main / export) and explain why NeoMind chose this pattern over ESM. See 6 Component Build (v1.1).

  3. The processingExtensionId generic AI processing contract β€” the most important design innovation in this case: the component does not run AI itself; instead, the processingExtensionId: "" field lets the user pick an installed extension (object_detection / ocr / describe / any locate-anything-v2-compatible extension) to "outsource" the image to. This "component + pluggable extension" contract is the template for AI reuse across the NeoMind ecosystem. See 3 Extension Side (v1.1).

  4. Engineering details of ROI overlay rendering β€” from single-rectangle ROI (processingRoiX/Y/W/H, normalized 0-1) to multi-ROI arrays (processingRois: []), from center-point detection (deprecated) to the processingRoiOverlap: 0.6 IoU-threshold detection. This involves Canvas coordinate mapping, the non-linear scaling of object-cover, and the async setup of ResizeObserver. See 5 Frontend Consume and 7 Integration Test.

  5. The React-in-IIFE pattern and its pitfalls β€” writing React hooks inside a 1972-line IIFE has surprising traps: for example, b060a25 fixes React error #310 (a useEffect that used hooks depending on uninitialized state), and 0601cd4 moves a conditional useState to the top level to keep hook order stable. These traps do not arise in bundled React projects but must be handled explicitly in the IIFE pattern. See 6 Component Build (v1.1).

Reading Dependency Graph​

The diagram below shows the knowledge dependencies among the eight subpages. Solid arrows mean "must read prerequisite first"; dashed arrows mean "recommended but skippable". β˜… marks MVP core (required for v1).

Shortest learning path (MVP only): 1 Background β†’ 4 Data Contract β†’ 5 Frontend Consume β†’ 6 Component Build. These four sections are enough to understand the full "NE101 capture β†’ MQTT β†’ NeoMind β†’ extension inference β†’ component render" chain.

Full learning path (all eight): read in order 1 β†’ 2 β†’ 3 β†’ 4 β†’ 5 β†’ 6 β†’ 7 β†’ 8. Best for developers planning to fork the component or retarget it to another camera device.

Case Info Card​

FieldValue
Component IDne101_camera
Version2.14.9 (as of this writing)
AuthorCamThink Team
bundle.js lines1972 (hand-written IIFE, not a build artifact)
manifest.json lines40
Frontend component repocamthink-ai/NeoMind-Dashboard-Components β€” bundle.js + manifest.json
Device type definitioncamthink-ai/NeoMind-DeviceTypes β€” ne101_camera device type JSON (metrics / commands)
Git commits (component dir)133
Prerequisite case6 metric_card (starter component case)
Successor casenone (this is currently the most complex case in the marketplace)

Next​

  • Want to understand "why NE101 needs a dedicated component" β†’ 1 Business Background
  • Want to jump straight to code structure β†’ 2 Architecture (v1.1)
  • Want to understand the AI processing contract β†’ 3 Extension Side (v1.1) + 4 Data Contract (MVP)
  • Want React implementation details β†’ 5 Frontend Consume (MVP) + 6 Component Build (MVP)

Last updated: 2026-06-23