truth()One semantic source
Final Athan, Iqama, Jumuah, Ramadan, event stage and operator policy belong to Core — not scattered helpers, pages or device automations.
visitor@sultaning:~/work$ open masjid-platform-v2
CASE STUDY / LOCAL-FIRST PLATFORM
Masjid
Platform V2
A mosque should keep working even when the internet does not. Masjid Platform V2 is a local operating layer for prayer truth, schedules, devices, displays and trusted operator control — built to outlive the hardware beneath it.
OWNERSHIP, NOT A MONOLITH
Masjid CoreWHAT · WHEN · WHY
↓ intent / ↑ evidence
Home AssistantPHYSICAL HOW · vendor integrations · actual state
Masjid Displaypresentation
Operator Appsauthorized control
DevicesHVAC · Zigbee · IR
01 / THE PROBLEM
Automation was useful. Ownership had to become durable.
The first mosque system proved that prayer-aware automation could run a real building. But as HVAC, microphones, displays, presence sensors, Ramadan behavior and more were added, one question became more important than another automation: where should mosque truth live so the system still makes sense five years later?
replace(device)Hardware can change
Policy references logical identities. Replacing a Gree unit with another vendor changes the mapping, not every prayer schedule that used it.
offline()The mosque stays local
Cloud services can add distribution, but local prayer operations, device control and signage do not depend on the public internet.
02 / THE MODEL
Separate mosque meaning from physical execution.
The architectural rule is intentionally simple: Core knows what the mosque wants, when it should happen and why. Home Assistant knows how a real device does it. The Display renders truth; it does not invent it.
01
Prayer + event truthfinal times, stages, Ramadan, Jumuah02
Operator policylead times, zones, target settings03
Logical intentstable device IDs, idempotent actions04
Physical HOWHA integrations, REST services, vendor details05
Observed truthWebSocket state, confirmation, reconciliation03 / PRAYER RUNTIME
The system understands a prayer as a lifecycle, not a timer.
Prayer preparation, Athan, waiting for Iqama, the prayer itself and the post-prayer period are distinct semantic states. Device preparation can start earlier without inventing a fake religious stage.
scheduledfuture event exists
athanprayer window begins
waiting_iqamacountdown + readiness
prayingruntime evidence confirms transition
post_prayercompletion flows + next state
04 / REALTIME
Events for immediacy. Snapshots for truth.
Core begins with an authoritative Home Assistant state sync, then consumes live state changes over WebSocket. Commands are event-confirmed when possible and reconciled with REST when needed. Display clients use the same principle: snapshot first, ordered realtime after.
HA → CoreLive evidence
Relevant device, microphone, presence, temperature and availability state arrives as normalized Home Assistant events.
Core → HASafe intent
Core issues physical service requests through a single integration boundary, then observes the result instead of assuming success.
Core → DisplayVersioned push
Display receives an authoritative snapshot followed by ordered state updates; a version gap causes reconciliation, not guesswork.
05 / SECURITY
Roles describe people. Capabilities decide access.
An Imam, Muezzin, facilities operator or volunteer can use the same operator contract while receiving different effective permissions. The server remains authoritative, explicit deny wins, and device scopes reference logical mosque resources rather than Home Assistant entity IDs.
Identityhuman or trusted service
Role templatesreusable permission bundles
Capabilities + scopefine-grained domain actions
Audit + safetyauthorization never bypasses physical policy
06 / FAILURE DESIGN
Recovery is part of the product, not an afterthought.
The platform was deliberately tested across backup, restore, host reboot, candidate upgrade, rollback, authorization recovery, realtime compatibility and interrupted restore. A valid request still cannot bypass the physical execution gate or a post-restore safety lock.
Backup / RestoreCore state, security and semantic state version recover together as one validated checkpoint.
Upgrade / RollbackCandidate compatibility is checked before mutation; rollback strategy depends on schema compatibility rather than hope.
Realtime gapsWebSocket disconnects degrade gracefully; REST snapshot reconciliation restores trust.
Physical safetyAuthorization and operational safety are separate. Permission to request an action does not guarantee unsafe execution.
07 / EVOLUTION
From one smart mosque to a platform that can fit many.
The current system keeps what the first installation taught us, but changes the unit of customization. A new mosque should mostly be configuration, logical device mapping and policy — not a copied forest of automations.
FIRST GENERATION
Behavior lived close to devices.
- Prayer-aware HA automations
- Hard-linked physical entities
- Display/navigation logic inside HA
- Excellent at proving real requirements
→
PLATFORM V2
Meaning lives above devices.
- Core-owned mosque semantics
- Stable logical device identities
- Realtime contracts and recovery
- Same product, different mosque configuration
08 / MY ROLE
Product thinking, architecture and the operational details between them.
This project is not only an interface or an automation set. The work spans product boundaries, domain modeling, physical-device orchestration, Home Assistant integration, reliability, authorization, release safety, responsive management UX and the discipline required to keep a live mosque safe while the system evolves.
Productreal mosque tasks → durable capabilities
Architectureclear ownership + stable contracts
Engineeringruntime, realtime, devices, recovery
Operationssafe upgrades, rollback and validation
platform.status / local · resilient · evolving