Occupancy counting sensor

A practical, privacy‑first guide to municipal-grade occupancy (people) counting sensors — technology options (ToF, thermal, mmWave, optical), accuracy, deployment checklist, standards, and real-world references.

occupancy counting
people counting sensor
time-of-flight sensor
ToF people counter
END-to-END smart parking

From sensors in the ground to apps in your hand — so you don't have to piece it together

Hardware, software, connectivity and turnkey solutions. One partner for your entire parking stack.

71k

sensors live

50+

countries

99,96%

accuracy

10-year

battery life

Occupancy counting sensor

At a Glance

A municipal-grade occupancy counting sensor is an overhead or zone sensor that quantifies pedestrian flows and live utilization with accuracy typically between 85% and 98% depending on technology and scene.

Attribute Value
Primary Use Footfall and utilization analytics for garages, transit hubs, stairwells, and municipal buildings
Typical Accuracy 85–98% (scene- and tech-dependent) with MOTA-based validation for entrance monitoring
Coverage per Device ~172–389 sq ft at 8–12 ft installation height; wider with multi-sensor stitching
Power / Protocol PoE 802.3af/at/bt (3–60 W) or 9–24 VDC; Ethernet/HTTP, MQTT; LoRaWAN/NB‑IoT/BLE for aggregated counters
Installation Height 8–16 ft common indoors; 12–20 ft in covered garages with narrow FOV optics
Standards FCC/CE, IEC 60529 (IP65–IP68), IEC 62368‑1, GDPR/EDPB/ICO privacy guidance

This guide pulls practical device and test detail from Fleximodo technical materials and public standards/guidance to help procurement and deployment teams reach predictable, privacy‑respecting results. See Fleximodo product and test details for example sensor capabilities and test reports. ylic garages A privacy-first occupancy sensor avoids personally identifiable imaging while still delivering high-quality counts and heatmaps for operations. Use modes that export only anonymized vectors, depth maps, or thermal blobs and disable all raw-frame export by default (on-device redaction + strict retention policies). European guidance for video devices and surveillance (GDPR context) explicitly requires Data Protection by Design and appropriate lawful bases for footage or derived metrics; follow EDPB and ICO advice when you design count‑grade systems. (edpb.europa.eu)

Why an occupancy counting sensor matters in smart parking

An occupancy counting sensor turns raw movement into operational signals—guiding cleaning, staffing, wayfinding, curbside planning, and safety actions that raise revenue and cut OPEX. In parking facilities, people flow correlates strongly with payment kiosk demand, elevator load, and night-time risk, enabling smarter signage, targeted patrols, and better service levels across smart-city parking sensor and parking guidance system deployments.

  • Measurable gains: 10–25% HVAC savings in attached facilities via schedule trimming; 15–30% cleaning labour reallocation by servicing only used floors; and 2–5% revenue lift where footfall-driven messaging improves pay compliance.
  • Rich use cases: real-time queue management, restroom “clean-on-50-entries” triggers, stairwell safety, and pedestrian routing at event ingress/egress.
  • For city campuses, link people counts with garage space telemetry to balance demand across zones and reduce circling around curbs.

For procurement and privacy templates, reference Fleximodo’s DPIA-ready product materials and test reports for example implementations.

For a deeper dive on privacy and anonymization controls, see our GDPR guide: GDPR-compliant parking sensor.

Standards and regulatory context (what to require in tenders)

Public-sector deployments must meet radio, safety, ingress, and privacy baselines while documenting test evidence for procurement. Below are the minimum items to call out in RFP language and acceptance tests:

Domain Standard / Guidance Scope Why it matters
Electrical safety IEC 62368‑1 IT/AV equipment safety Ensures safe operation for PoE and DC-powered counters in public spaces.
Ingress / impact IEC 60529 (IP ratings) / IK08–IK10 Dust/water ingress; vandal resistance Required in garages or exposed curbside sites; IK10 deters tampering. See IP68 ingress protection and IK10 impact resistance.
Radio / EMC FCC Part 15 (US); ETSI EN 300/301; EN 301 489 Unlicensed RF, EMC Covers Wi‑Fi/BLE, mmWave, and sub‑GHz radios in dense urban RF.
Networking / power IEEE 802.3af/at/bt (PoE) Power over Ethernet for edge devices PoE is the pragmatic default where cabling is available — it simplifies uptime and backhaul. See vendor PoE overviews for port planning. (cisco.com)
Interop / BMS ONVIF / BACnet/IP / DALI (as applicable) Device discovery & BMS linkage Simplifies integration with building systems and signage.
Privacy / data protection GDPR / EDPB guidance; ICO guidance (UK) Data minimisation; DPIAs; lawful basis Requires PIA/DPIA, redaction methods, retention controls and signage for public deployments. (edpb.europa.eu)
Metrics / validation MOTA / confusion matrices / standardised test clips People counting accuracy methods Require vendor-supplied annotated test clips and quarterly revalidation.

Procurement tip: require a DPIA, a redaction mode (thermal-only or depth-only), signed SBOM and quarterly accuracy reports. Interop tip: specify MQTT topics and JSON schemas for event messages (see real-time data transmission, MQTT and REST API).

Types of occupancy counting sensor

Count-grade options span optical, depth, thermal, radar, and device-signal methods; choose by accuracy target, privacy posture, power, and budget.

Optical AI (camera-based, edge AI)

  • Typical performance: 95–99% people counting accuracy on single-file entrances; accuracy drops in strong backlight without HDR.
  • Pros: Rich analytics (directionality, dwell, zones), mature VMS/ONVIF support; edge AI models can run on low-power NPUs.
  • Cons: Highest privacy burden; generally PoE; needs periodic revalidation after layout changes.
  • Best for: Event gates, municipal building lobbies, high-precision studies. See edge AI.

3D depth / ToF (time-of-flight)

  • Typical performance: 90–98% in controlled entrance geometries; excellent lighting immunity and strong privacy when only depth maps are used.
  • Pros: Robust in low light; compact; accurate direction detection with one ceiling unit.
  • Cons: Reflective floors and glass can cause holes; range must match installation height coverage.
  • Best for: Garage elevator lobbies and turnstile-free entrances. Academic and industry reviews show ToF/depth sensors are commonly used for vehicle and passenger counting applications and are robust in many indoor scenarios. (mdpi.com)

Thermal array (privacy-first)

  • Typical performance: 85–95% for counting and presence; very strong privacy since no visible images are produced.
  • Pros: Works in darkness; minimal PII risk; stable across seasons.
  • Cons: Lower spatial resolution; needs careful thresholding when large temperature swings occur.
  • Best for: Restrooms, wellness rooms, policy‑sensitive sites.

mmWave radar (radar people counter)

  • Typical performance: 75–99% depending on algorithm and scenario; recent 60 GHz FMCW prototypes report >95% accuracy in controlled tests. mmWave is powerful where vision is limited (smoke, dust, darkness). (mdpi.com)
  • Pros: Penetrates fog/haze; precise range/velocity; good for safety zones and presence detection.
  • Cons: Ghosts from moving doors/metal; tuning required in narrow corridors; algorithm generalization is an active research area.

Device-signal methods (Wi‑Fi/BLE presence)

  • Typical performance: Presence and utilization inference (not headcount); precision limited by device-carry rates (often 60–90%).
  • Pros: Low cost; useful for macro‑trends and zone telemetry.
  • Cons: Not suitable for compliance-grade counts; MAC randomization complicates analytics.

Binary motion (PIR)

  • Typical performance: Detects activity, not counts.
  • Pros: Ultra‑low power, battery‑friendly, and inexpensive.
  • Cons: No directionality; poor in hot garages where ΔT shrinks.

Environmental inference (CO2 / IAQ)

  • Typical performance: Post‑hoc occupancy estimation; good for ventilation control, not live counts.
  • Pros: Uses existing IAQ sensors; strengthens demand‑controlled ventilation.
  • Cons: Slow response; confounded by airflow patterns and doors.

Connectivity note: a PoE people counter or other wired occupancy sensor simplifies uptime and throughput for analytics backends. Where wiring is hard, LoRaWAN or NB‑IoT can carry aggregated counts from gateways — LoRaWAN continues to grow in city deployments and offers a low-power LPWAN option for aggregated telemetry; reference LoRa Alliance evolution and roadmap for network considerations. (resources.lora-alliance.org)

For technical readers: recent mmWave research shows high accuracy in controlled indoor conditions but warns about generalization across environments; fusion (ToF + radar + thermal) often gives the most robust real-world results. (mdpi.com)

System components (what to specify)

A deployable solution combines the sensing head, compute, connectivity, power, enclosure, and a cloud/bus interface set:

  • Sensing front end: choose optical AI, time-of-flight, thermal array, or mmWave front end matched to installation detection range and field of view.
  • Edge compute: MCU/SoC or NPU running edge models, secure boot, and signed OTA firmware; require firmware over the air and intelligent firmware controls. See Fleximodo sensor references for real device packaging and OTA capabilities.
  • Connectivity: Ethernet/PoE for high-throughput; LoRaWAN [/glossary/lorawan-connectivsary/nb-iot-connectivity] for sparse telemetry; BLE/Wi‑Fi for local commissioning; MQTT/REST northbound. (Specify JSON schemas in the ICD.)
  • Power: PoE (802.3af/at/bt) or 9–24 VDC; batteries for ultra‑low‑power devices (define battery‑life policy).
  • Enclosure/mechanics: IP65–IP68, IK08–IK10 anti‑tamper brackets; tilt‑adjustable ceiling plates. See device ingress and impact test reports for examples.
  • Back end: data lake and realtime bus, alert engine, role‑based access control; optional cloud-based parking management and BACnet integration for BMS linkage.

Sample Q&A — commissioning & validation

  • Do we need a gateway for LoRaWAN counters? If sensors publish aggregated counts via LoRa Class A, a nearby gateway is required; PoE/Ethernet devices can publish directly over MQTT/HTTP to the city broker. (Specify gateway redundancy and regional parameters per LoRaWAN regional docs.) (resources.lora-alliance.org)

  • How do we validate people counting accuracy after go‑live? Capture a 2–4 hour annotated clip per entrance once per quarter and recompute MOTA; flag drift >2 percentage points for retuning.

  • Can we operate fully as an anonymized occupancy sensor? Yes—choose thermal-only or depth-only modes, disable raw frame export, and persist only counts/vectors with automated retention.

How occupancy counting sensor is installed / measured / implemented — step-by-step (short)

A staged plan reduces surprises. Full HowTo follows in the JSON‑LD below and in Fleximodo install guides; key steps:

  1. Requirements capture: define KPIs (e.g., ≥95% at turnstiles), privacy posture, and integration points with smart-city parking.
  2. Survey & coverage planning: blueprint traffic lines, occlusion risks and compute FOVs.
  3. Network & power design: prefer PoE for backbones; specify VLANs, QoS, NTP; budget uplink intervals for LPWAN devices.
  4. Mounting plan & height: 8–16 ft indoor; 12–20 ft in covered garages.
  5. Privacy-by-design: enable on-device redaction, TLS 1.2+/1.3, and retention ≤30 days for diagnostic imagery.
  6. Mechanical install: mount brackets, torque fasteners, certify IP sealing.
  7. Calibration & test counts: run 20–50 person walk-tests; compare to manual tallies; tune zones to drift <±2%.
  8. Integration: publish to city broker (MQTT JSON), map topics to cleaning/safety triggers.
  9. Acceptance & handover: freeze ICD, export dashboards, schedule quarterly audits, and document SLA for uptime (≥99.5%).

Detailed install procedures and torque/fastener lists are in Fleximodo installation guides and test reports.

Maintenance and performance considerations

Sustained accuracy and uptime require small, scheduled tasks and an explicit battery and firmware policy:

  • Lens and cover care: clean quarterly in dusty garages; instruct staff to avoid harsh solvents on polycarbonate domes.
  • Revalidation: brief MOTA tests after furniture or queuing changes.
  • Drift sources: seasonal clothing, umbrellas, pushchairs; mmWave false echoes near metal shutters.
  • Network resilience: local buffering for 24–72 hours; design backoff/retention for LPWAN outages.
  • Firmware/OTA: schedule quarterly updates with rollback; export SBOMs for IT review. See firmware over the air and sensor health monitoring.
  • Power strategy: for battery designs, define baseline (e.g., 15‑min uplinks) and keep spares; aim for multi-year life where possible. See example long-life battery accessories and smart battery options in device datasheets.

Q: When should we pick PoE over batteries? A: If you need sub-second events, multi-zone counting, or continuous analytics, PoE wins on TCO; batteries fit low‑duty zones where wiring is infeasible. See PoE typical port power specs and PoE planning guidance. (cisco.com)

Q: Can we deploy at open‑air curbside zones? A: Yes — specify IP66/IK10, sunshades, anti‑corrosion fasteners; prefer radar or thermal where backlight is severe.

Q: How do we avoid double counting across doors? A: Use entrance IDs and direction tagging on the edge; fuse streams at the broker with 2–5 s hysteresis windows.

Current trends and advancements

Cities are shifting to privacy‑first analytics with on‑sensor inference, stronger redaction, and standardized event streams. LoRaWAN remains a popular LPWAN for aggregated telemetry and the LoRa Alliance continues to publish an evolution roadmap for network and protocol improvements; if you plan LPWAN, reference the Alliance materials when specifying regional parameters. (resources.lora-alliance.org)

Edge AI inference and hybrid sensor fusion (ToF + thermal + mmWave) reduce corner cases (luggage occlusion, strong backlight) while preserving privacy. Recent academic and industry work demonstrates mmWave's high accuracy in controlled trials and highlights the benefits and limits of radar-only systems in complex scenes. (mdpi.com)

Summary

Deployed correctly, an occupancy counting sensor gives municipalities precise, privacy‑respecting footfall insights that shasafety coverage, and guidance messaging at a compelling ROI within 8–18 months. Fleximodo can help you choose the right stack, validate accuracy with reproducible tests, and integrate counts with parking and building systems over secure, open protocols. See Fleximodo datasheets and backend docs for product‑level details and examples.


Frequently Asked Questions

  1. How is an occupancy counting sensor installed in smart parking?

    • Ceiling‑mounted units over entrances and corridors, PoE networking for uptime, and a commissioning walk‑test to validate people counting accuracy before going live. See the installation guide for torque and sealing steps.
  2. Which protocols are best for integrating counts with our city data bus and BMS?

    • Use MQTT for live events and REST for historical pulls; ONVIF/BACnet/DALI interfaces simplify lighting and signage through BMS links. Map topics in the ICD and require JSON schemas. See real-time data transmission and remote configuration.
  3. How do we handle multi‑entrance venues and centralize the truth source?

    • Assign entrance IDs and timestamps on the edge, publish to a central MQTT broker, and reconcile at the data lake with 2–5 s hysteresis to prevent double counts.
  4. What are realistic TCO differences between PoE and wireless designs?

    • PoE requires cabling CAPEX but lowers maintenance and enables higher data rates. Wireless saves initial wiring cost but adds battery management and periodic field visits; quantify with a 5‑7 year TCO model.
  5. How do tenders specify verifiable performance without overfitting vendor demos?

    • Require MOTA-based validation against annotated video or audited manual tallies, publish test datasets, and cap drift at ±2% over a quarter.
  6. What edge cases should we test before scale in garages?

    • Test glare at sunset, umbrellas and carts, metal shutter motion near mmWave sensors, and emergency egress with high-density flows.

Key engineering callouts (practical takeaways)

Key Takeaway — Privacy-first default

Require on-device anonymization modes (thermal/depth-only), disable raw-frame export by default, and set a maximum diagnostic-image retention of 30 days in procurement documents. Reference EDPB/ICO guidance when drafting DPIAs. (edpb.europa.eu)

Key Takeaway — Network & power

If you can run cabling, favour PoE (802.3af/at/bt) for uptime and throughput; plan switch port budgets for 802.3at/802.3bt devices and use LLDP/CDP for power negotiation. (cisco.com)

Field note (pilot example — illustrative)

Key Takeaway from a cold-climate municipal pilot (Graz, Q1 2025): early pilot notes reported robust cold-start behaviour and long battery health in winter trials — useful as a planning reference, but use your own acceptance testing to verify local conditions. (Pilot figures should be verified with the local authority before contractually relying on them.)


References

Below are curated real‑world projects (internal rollout data) showing sensor types, counts and deployment notes. These examples are drawn from project records and are useful comparators during scoping.

Pardubice 2021 — Czech Republic

  • Project: Pardubice 2021
  • Sensors: 3,676 × SPOTXL NB‑IoT
  • Deployment: 2020‑09‑28
  • Notes: Large-scale NB‑IoT deployment suited to city-wide aggregation and parking occupancy studies; good long-term operational telemetry. See NB‑IoT connectivity.

RSM Bus Turistici — Roma Capitale, Italy

  • Project: RSM Bus Turistici
  • Sensors: 606 × SPOTXL NB‑IoT
  • Deployment: 2021‑11‑26
  • Notes: Fleet/large vehicle zone use-case; NB‑IoT backs periodic aggregated counts.

CWAY virtual car park — Famalicão, Portugal

  • Project: CWAY virtual car park no. 5
  • Sensors: 507 × SPOTXL NB‑IoT
  • Deployment: 2023‑10‑19
  • Notes: Virtual car‑park architecture, aggregated counts published to city broker.

Kiel Virtual Parking 1 — Germany

  • Project: Kiel Virtual Parking 1
  • Sensors: 326 × mix (SPOTXL LORA / SPOTXL NB‑IoT)
  • Deployment: 2022‑08LPWAN strategy (LoRa + NB‑IoT) used to balance local gateways and cellular telemetry. See LoRaWAN connectivity.

Chiesi HQ White / Skypark / Henkel (selected indoor deployments)

NOTE: project list above is a selection from internal deployment records; full project metadata and telemetry dashboards are available to authorised customers and integrators for benchmarking and coverage planning. Use internal project insights to calibrate expected uptime, battery schedules and maintenance windows.


Optimize your parking operation with an occupancy counting sensor

Partner with Fleximodo to scope, pilot, and scale a privacy‑first, standards‑compliant counting solution that feeds parking guidance, cleaning, and safety workflows in real time. Our engineers will help you choose the right mix of ToF, thermal, and radar, validate performance with reproducible tests, and integrate data over secure MQTT/REST into your existing platforms—without vendor lock‑in. See product datasheets and backend docs for platform-level examples and installation manuals.


Author Bio

Ing. Peter Kovács, Technical Freelance writer

Ing. Peter Kovács is a senior technical writer specialising in smart‑city infrastructure. He writes for municipal parking engineers, city IoT integrators and procurement teams evaluating large tenders. Peter combines field test protocols, procurement best practices and datasheet analysis to produce practical glossary articles and vendor evaluation templates.