Engineering Log #002 — Multi-Zone Occupancy and the Digital Twin
How room-level occupancy is derived from person detection, and how it feeds a live digital twin.
Mehdi (Masoud) Variji
8/1/20263 min read
Multi-Zone Occupancy and the Digital Twin
From Detection to Occupancy
The previous engineering log introduced the platform and the hardware it runs on. This log moves one layer higher and explains how a person detected by the camera becomes meaningful information about room occupancy.
Detecting a person inside an image is only the beginning. A bounding box represents a location in pixel coordinates, but it does not indicate which room the person occupies, how long they have remained there, or whether they have just entered or are leaving the space.
Bridging that gap is the responsibility of the Occupancy Engine.
⸻
The Zone Model
Rather than treating the apartment as one large open space, the platform divides it into logical occupancy zones.
The current zones are:
Entry
Kitchen
Center
Living
Dining
TV Area
Each detected person is assigned to exactly one active zone at any given time.
This is an intentional design decision. Allowing a person to belong to multiple zones simultaneously would make occupancy duration, room transitions and historical analysis unreliable.
The zones describe functional spaces rather than architectural boundaries. They represent how the building is actually used.
⸻
The Processing Pipeline
The perception pipeline follows a fixed sequence:
Tracking is intentionally positioned between person detection and zone assignment.
Without tracking, a temporary missed detection could cause the system to incorrectly report that someone left a room and immediately returned. Occupancy duration would become fragmented, movement history would lose meaning and room utilization statistics would become unreliable.
The Occupancy Engine continuously maintains:
Current occupied zone
Occupancy duration
Zone transitions
Movement history
Presence state
Every state change is recorded as an event inside the local SQLite database, creating a complete timeline of occupancy throughout the day.
⸻
The Digital Twin
The Digital Twin is not another camera view.
Instead, it is a live abstraction of the apartment that represents room occupancy, room status and contextual information independently from the perception pipeline.
This architectural separation is intentional.
The camera is responsible for observing the environment.
The Digital Twin is responsible for representing the current state of the building.
Future automation systems will read information from the Digital Twin rather than directly from camera frames. This separation reduces coupling between perception and automation while allowing additional sensors to contribute information without changing the vision pipeline.
As the platform evolves, the Digital Twin will become the central representation of the building, combining occupancy, environmental sensing, connected devices and future energy intelligence into a single real-time model.
⸻
Perception and Ground Truth Are Stored Separately
Model predictions are intentionally stored separately from manually verified observations.
The platform maintains two independent datasets:
Raw AI perception output
Human-validated ground truth
These datasets are never mixed.
Maintaining this separation allows the system to measure detection quality objectively instead of reinforcing its own assumptions.
Ground truth is collected through a local Flask annotation interface that allows occupancy observations to be validated against recorded frames and later compared with AI predictions.
This evaluation process provides the foundation for improving occupancy accuracy over time using real engineering data rather than assumptions.
⸻
Current Development Stage
The platform currently operates on real hardware inside an occupied residential environment.
During this phase the system continuously observes occupancy, records events and evaluates internal decisions while collecting engineering data for future learning.
Building automation remains intentionally conservative.
The platform is designed to understand the building before attempting to control it.
This observation-first approach allows new algorithms to be validated safely before any automated decision affects the building.
⸻
Current Limitations
Zone assignment accuracy has not yet been formally measured.
Although the annotation infrastructure has been completed, the current dataset is not yet large enough to produce statistically meaningful evaluation results.
The Learning Engine remains partially implemented.
Long-term occupancy modelling is a future objective, and no behavioural conclusions should be made beyond the evidence collected so far.
Energy values displayed by the dashboard are currently simulated.
Smart-meter integration has not yet been implemented.
Zone boundaries are manually configured and currently require manual calibration.
⸻
Technology Stack
Hardware
Raspberry Pi 5
OAK-D Stereo Camera
ESP32
Software
Python
YOLOv8
OpenCV
PyQt6
SQLite
MQTT
Flask
⸻
What’s Next
The next Engineering Log will explore the database architecture that supports the platform.
It will explain how the sixteen-table SQLite schema separates perception output, occupancy states, Digital Twin data, environmental sensors, device actions, ground truth annotations and decision evaluation to create a reliable foundation for future learning and explainable AI.
The database is the backbone of the platform, enabling every observation, decision and future learning model to be traceable and reproducible.
⸻
Status: runningf
TechnovaMind
Independent engineering practice focused on Edge AI, Computer Vision, Robotics and AI Building Intelligence..
Contact
© 2025. All rights reserved.
Solutions
AI Building Intelligence
Assistive Robotics
Edge AI & Embedded Systems
AI Workflow Automation
Telegram Commerce Automation
Available for international AI engineering opportunities, technical collaborations and pilot projects.