before(prayer)Prepare the building
Climate could begin before a prayer, with different lead times by prayer and a staged startup across physical areas rather than switching everything at once.
visitor@sultaning:~/work$ open smart-mosque-v1
CASE STUDY / FIRST GENERATION
Smart Mosque
System
Before the platform, there was a working mosque. This first-generation system connected prayer time to climate, microphones, presence, screens, lighting, media and notifications — and ran those ideas against real daily operation.
MASJID / AUTOMATION BOARDoperational
HVAC9×front · left · right · back
MICROPHONES2×prayer-stage evidence
PRESENCEFP2mihrab occupancy
ZIGBEE↯lights · switches · buttons
DISPLAYTVkiosk + power sequence
MEDIA / IR⌁Cast + Broadlink
PRAYER-AWARE RUNTIME
maghrib → ishaclimate transition · display · mic evidence
01 / WHY BUILD IT
A mosque has a rhythm. The building should understand it.
Most smart-building systems understand clocks, rooms and devices. A mosque also has Athan, Iqama, prayer, Friday, Ramadan and changing occupancy. The first system explored what happens when those religious and operational rhythms become automation inputs.
during(prayer)Use real-world evidence
Microphone state near Iqama and presence around the mihrab became useful signals for understanding whether the planned schedule matched what was actually happening.
after(prayer)Transition gracefully
Post-prayer climate, display and notification behavior could change without someone manually operating every subsystem.
special(days)Not every day is normal
Friday, Ramadan, Qiyam and Eid introduced different timing and presentation needs that a fixed daily automation model could not ignore.
02 / A PRAYER IN MOTION
The automation began before Athan and kept listening afterward.
A typical flow was not a single “turn on AC” command. It combined prayer timestamps, staged device actions, microphone evidence, screen behavior and post-prayer transitions.
EXAMPLE / DAILY PRAYERrelative to Athan + Iqama
PREPClimate startsareas start gradually with target cooling
ATHANPrayer contextdisplay and countdown enter the active window
WAITIqama countdownArabic countdown adapts minute by minute
EVIDENCEMic turns onsignal can confirm the prayer transition
POSTSystems settleclimate, screen and alerts move on
03 / HARDWARE
Different protocols. One operational experience.
The installation mixed Wi‑Fi climate, Zigbee devices, MQTT infrastructure, IR, presence, media and kiosk hardware. Home Assistant made those different physical worlds usable together.
Climatenine Wi‑Fi AC units across four mosque areas, with staged start/stop and temperature behavior
ZigbeeZigbee2MQTT, local broker, lighting/microphone switches and scene buttons
PresenceAqara FP2 sensors around the mihrab as contextual evidence rather than a simple motion trigger
Display + IRkiosk navigation, screen power, Raspberry Pi sequencing and Broadlink infrared control
AudioGoogle Cast and semantic media behavior for selected mosque flows
Notificationslocal mobile and Telegram messages for HVAC, microphone and prayer-related events
Environmenttemperature aggregation and operational status derived from physical device readings
Auxiliarywater/pump and other building devices proved the system would keep expanding beyond one category
04 / SMART COUNTDOWN
The screen did more than show prayer times.
The Iqama display reacted to the actual prayer window. It produced human Arabic countdown language, shifted to second-level urgency near Iqama, and could change from a planned countdown to “the prayer has begun” when microphone evidence appeared.
SCHEDULEAthan + Iqamaknown prayer timestamps define the expected window
→
LIVE EVIDENCEMicrophone statea physical signal near Iqama changes the interpretation
→
PRESENTATIONUseful Arabic stateminutes, seconds, “أقم الصلاة”, or “أقيمت الصلاة”
05 / WHAT IT PROVED
The prototype answered the questions a diagram could not.
Running real devices through daily prayers revealed which ideas were genuinely valuable — and where a Home Assistant-centered architecture would eventually become difficult to scale.
01
Prayer context is a domain.
Friday, Ramadan, Iqama, prayer stages and special nights are not just collections of timers. They need consistent semantics shared across devices and screens.
02
Physical evidence matters.
Schedules are plans; microphones, presence and actual device state tell you what is happening. Good automation needs both.
03
Hardware changes faster than policy.
When prayer policy and physical entity IDs live too close together, replacing devices becomes expensive. That lesson directly shaped the next architecture.
04
Special periods are first-class.
Ramadan, Qiyam and Eid were not edge cases. They proved the system needed an explicit event/calendar model rather than endless one-off branches.
05
Presentation needs its own home.
Kiosk navigation and prayer-page logic worked, but the screen deserved to become a dedicated presentation client consuming one mosque truth.
06
Real operation beats assumptions.
The most important output was not the YAML. It was a tested requirements map for what a mosque platform actually needs.
06 / MY ROLE
Connect the religious rhythm, physical building and user experience.
The work crossed software and hardware: discovering the operational problem, connecting different device ecosystems, writing prayer-aware logic, testing it against a live mosque, shaping screen behavior and turning repeated friction into the architecture requirements for the next generation.
SystemsHome Assistant + device ecosystems
Automationprayer-aware physical behavior
Experiencedisplay, countdown and notifications
Product learningoperational lessons → V2 requirements
prototype.result / requirements discovered in production