cd /news/artificial-intelligence/build-an-edge-ai-people-counter-with… · home › topics › artificial-intelligence › article
[ARTICLE · art-166771] src=hackster.io ↗ pub= topic=artificial-intelligence verified=true sentiment=↑ positive

Build an Edge AI People Counter with NE301

Camthink-ai published a walkthrough for turning the NeoEyes NE301 edge AI camera into a bidirectional people counter using the line-crossing v1.0.2 .neapp package on NE301 firmware v4.3.1 App Host Beta, a pairing the company says it validated on a real NE301. In the Wiki demo capture, the OUT count moves from 7 to 8 and the event list shows "#8 person OUT," which Camthink-ai describes as a functional example of the UI path rather than a count-accuracy benchmark. The app can package counts into periodic JSON reports for the device's MQTT or Webhook transport, and the package declares Host capabilities 0x7ff with unsigned NEAPP05 packaging.

by read8 min views4 publishedNov 10, 2026
Build an Edge AI People Counter with NE301
Image: Hackster (auto-discovered)

This build turns a NeoEyes NE301 edge AI camera into a bidirectional people counter. The line-crossing app detects and tracks people on the camera, then records an IN or OUT event when a track crosses the line you draw in the live view.

In the Wiki demo capture, the OUT count changes from 7 to 8 and the recent-event list shows #8 person OUT. That is a functional example of the UI path, not a count-accuracy benchmark.

The app can also package counts into periodic JSON reports for the device's MQTT or Webhook transport. A broker or HTTP receiver is needed only if you want those reports delivered to another system.

What You Will Build

  • A camera-side people counter with separate IN and OUT totals.

  • A configurable line and direction setting in the NE301 live view.

  • A simple test that matches a real walk-through to an on-screen event.

  • An optional reporting path that forwards count summaries to MQTT or a Webhook endpoint.

  • One NeoEyes NE301 camera with a connected image sensor and a stable power source.

- NE301 firmware: [v4.3.1 App Host Beta.](https://github.com/camthink-ai/ne301/releases#release-v4.3.1-app-host-beta)
- The `line-crossing` v1.0.2`.neapp` package from the[ne30x-app v1.0.2 release.](https://github.com/camthink-ai/ne30x-app/releases/tag/v1.0.2)
  • A browser that can access the camera's local Web interface.
  • Optional: an MQTT broker or HTTP service reachable from the camera, if you want to receive reports elsewhere.

The line-crossing v1.0.2 package and NE301 v4.3.1 App Host Beta listed above have been validated together on a real NE301. The package declares Host capabilities 0x7ff and uses unsigned NEAPP05 packaging; the firmware provides the corresponding capability and admission path. This validates the listed pairing on the tested device. It is not a counting-accuracy benchmark or an end-to-end MQTT/Webhook delivery test. If you use a different firmware build or app package, check that release's requirements before installing; do not assume compatibility across versions.

If the camera needs a firmware upgrade, follow the official [NE301 v4.3.1 OTA Update Guide.](https://github.com/camthink-ai/ne301/blob/main/docs/NE301_v4.3.1_OTA_Update_Guide.md) The required sequence depends on the installed firmware; do not skip or reorder the release's upgrade steps. A firmware source tag is not itself an installed-device record.

For this walkthrough, keep the target class set to `person`. Counting quality depends on camera placement, lighting, target density, and the selected detection model. This project demonstrates directional trend counting; it does not establish billing-grade or safety-compliance accuracy.

Connect the NE301 to a stable power source and bring it onto the network used for setup. Mount or position it so the path is visible and people remain large enough in the frame. For an initial test, use a clear, well-lit passage and leave room on both sides of the planned line.

Open the camera's Web interface in a browser. Confirm that the left navigation includes Application Management and that the device is running the firmware used in the validation described above. If you use a different build, check its compatibility with the app package before proceeding.

Expected result: the device is online, the live camera view is available, and it is running the app/firmware pairing validated for this project.

Download line-crossing-1.0.2.neapp. Read the package compatibility notes before importing it. In the camera interface, open Application Management → Manage App, import the package, and start line-crossing.

Open the app from App Status. The application UI should load alongside the live view. If import is refused, re-check the package's compatibility and signing/admission requirements; do not treat an offline package-verifier PASS as proof that the device accepts it.

Expected result: the app reports Running and its realtime/configuration pages open in the camera interface.

Start with the person-detection path documented for this solution. In the app's Configuration page, confirm that the target class is person and note the model currently bound to the device.

Do not change to a custom model for the first run. Custom-model support is an extension path; this article does not claim a custom target was validated in the demo.

Expected result: the app shows a person target and the live view can display person detections.

On Realtime Data, choose Draw Counting Line. Click once for each endpoint, then drag an endpoint to adjust the line so it spans the part of the passage people actually cross.

The outside reference point defines direction: outside-to-inside is IN, and inside-to-outside is OUT. If the labels are reversed for your camera view, choose Swap IN/OUT Direction. Save the line before testing.

Expected result: the saved line and direction arrow are visible over the live view. A person moving across the passage can be tracked on both sides of the line.

If you need a clean baseline, use Reset Statistics first. This clears cumulative counts, events, and the offline backlog and cannot be undone. Then walk through the line once in the IN direction and once in the OUT direction. Compare the physical walk-through with the current window counters and the Recent Crossing Events list. The Wiki demo screenshot shows one OUT event: the displayed OUT count moves from 7 to 8, and the list records #8 person OUT. Your own starting numbers will differ. The verification is that each deliberate crossing produces a corresponding direction and event in your test scene, not that your totals match the demo screenshot.

Expected result: one matching IN event and one matching OUT event appear for the two controlled crossings. If not, adjust the line placement/direction and inspect framing, lighting, and tracking parameters before drawing a conclusion about accuracy.

In Advanced, choose a statistics window and enable MQTT or Webhook reporting. Configure the receiver in the corresponding application-management tab. Save the two settings groups separately: click Save App settings for the statistics window, then Save Host settings for the MQTT/Webhook channel. Wait at least one complete statistics window before checking delivery. The app creates a line_counting report; the device Host handles the transport.

The report includes window and cumulative counts plus identifiers such as boot_id and report_seq. Use the pair boot_id + report_seq for idempotent processing because retries or backlog delivery can produce duplicates. Inspect the payload produced by the installed app before integrating it; for wall-clock timelines, use the receiver's timestamp unless the payload provides a synchronized event timestamp.

An abbreviated, illustrative payload looks like this:{

  "type": "line_counting",

  "boot_id": 3,

  "report_seq": 128,

  "window": { "in": 12, "out": 9 },

  "total": { "in": 1246, "out": 1180 }

}

These values illustrate the schema; they are not a measurement from the demo screenshot. Confirm delivery in your MQTT subscriber or Webhook logs before connecting the counter to a business workflow.

Expected result: after both settings groups are saved and a window closes, the configured receiver gets a report with type: line_counting and window counts. Confirm receipt in the subscriber or Webhook logs; this article does not include a witnessed receiver log. The inspected count-report payload contains counts and metadata, not image frames; this is not a blanket claim about other device traffic or configurations.

The app keeps short histories for tracked objects. For each track, it compares the object's position on the two sides of the configured line. A side change becomes an IN or OUT event, updates the corresponding window and cumulative counters, and can be included in the event list and report.

This design keeps the example focused: the camera view is used to establish the target and line, while downstream systems receive structured count reports rather than the video frames in those reports.

Source Code and Package

- App source and releases: [camthink-ai/ne30x-app](https://github.com/camthink-ai/ne30x-app) ·[GitHub Releases.](https://github.com/camthink-ai/ne30x-app/releases)
- Device App Host reference: [camthink-ai/ne301 app-host branch.](https://github.com/camthink-ai/ne301/tree/app-host)
- Setup reference: [NE301 People Counting engineering guide.](https://wiki.camthink.ai/docs/edge-ai-solutions/people-counting/engineering-guide/)

The source repository includes the native app, web interface, packaging tools, and tests. The project owner confirms that the listed app/firmware pair was validated on a real NE301. This test applies to the pair used in that validation; check release requirements again if you substitute another package or firmware build. Automated package verification alone does not replace a real-device test.

Limitations

  • No controlled accuracy, latency, or throughput benchmark is included.
  • The displayed counts are a demo capture, not a field-site performance result.
  • Count quality depends on framing, lighting, target density, occlusion, and model behavior; validate at the intended location.
  • Offline report buffering is documented as best effort. Do not rely on it as a lossless event ledger without independent receiver-side reconciliation.
  • Timestamp semantics can vary across releases; use the receiver's timestamp unless the installed app provides a synchronized event timestamp.
  • The listed v1.0.2 app and v4.3.1 App Host Beta firmware pair was validated on a real NE301. This does not establish a controlled accuracy result or a received MQTT/Webhook report. Re-check compatibility when changing either version.

The NE301 line-crossing app provides a compact path from a live camera view to directional events and optional structured reports: install the validated app/firmware pair, select the person target, draw the line, and verify controlled crossings. The real-device validation confirms the tested pairing; the demo screenshot illustrates the event UI but does not establish site accuracy. Before relying on reporting, save both settings groups and verify a received report on your own receiver.

[Read more](<javascript:void(0)>)

── more in #artificial-intelligence 4 stories · sorted by recency
── more on @camthink-ai 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
→ Live at https://your-agent.zahid.host ✓
Get free account → Pricing
from €0/mo · no card required
LIVE [news/build-an-edge-ai-peo…] indexed:0 read:8min 2026-11-10 · —