How tcrakn/islamic-prayer-times-display-esp32 works
<explanation>
To create a clear, detailed system‐design diagram for the Islamic Prayer Times Display (ESP32 + TTGO T‑Display), follow these steps:
1. Identify the project type and purpose
• This is an embedded IoT application running on an ESP32‐based TTGO T‑Display board.
• It fetches geolocation and prayer‐time data over WiFi, renders maps and schedules on a small TFT, and manages deep‐sleep/WAKE cycles.
2. Analyze the (implied) file structure
• Top‐level sketch folder (“Islamic Prayer Times Display‑TTGO”) containing:
– The main .ino/Arduino sketch
– Library includes (WiFiManager, ArduinoJson, TFT_eSPI)
– Configuration files (User_Setup_Select.h modifications)
• Ancillary docs: ChangeLog.md, LICENSE, README.md
3. Examine README insights
• Uses muwaqqit.com JSON API for prayer times
• Uses Google Maps/Geocoding API for location and static map images
• Incorporates NTP time‑sync, captive‐portal WiFiManager, deep‑sleep, OTA update via portal
• Handles button inputs for UI navigation (map zoom, view toggle, config portal, WAKE)
4. Main components and relationships
A. Hardware (draw at bottom layer)
1. ESP32 SoC + peripherals
• SPI bus → ST7789 TFT display
• GPIO → buttons (top, bottom, wake)
• Li‑Po battery & power‐management IC
2. Persistent storage
• Flash (stores WiFi credentials & firmware bin)
B. Software modules (middle layer)
1. Boot & Wake Manager
• Handles reset, deep‐sleep entry/exit based on button or timer
2. WiFi Manager
• Auto‐connect to stored SSID/PW or launch captive‐portal (SSID “Muwaqqit-AP”)
• Handles OTA binary upload via HTTP
3. Time Sync (NTP Client)
• Queries NTP server to set RTC
4. Geolocation Module
• HTTP GET → Google Geocoding API for address & static map
• Parses image URL or JPEG/PNG response
5. Prayer Times Module
• HTTP GET → muwaqqit.com API
• ArduinoJson to parse Fajr, Dhuhr, etc.
6. Display & Graphics (TFT_eSPI)
• Renders: address text, static map + Qibla overlay, prayer timetable + clock + battery icon
• UI state machine with timeout transitions
7. Button Handler
• Maps button presses to zoom in/out, view toggle, skip to timetable, enter config
8. Deep‐Sleep & Power Manager
• After inactivity or display cycle completion → ESP32 deep‐sleep
C. External Services (top layer)
• NTP Pool (time)
• Google Maps/Geocoding API (address + map)
• muwaqqit.com Prayer Times API
5. Diagram layout and visual guidelines
• Group components into three horizontal layers:
[External Services]
[Embedded Software Modules]
[Hardware / Device]
• Use distinct shapes/colors:
– Blue rectangles for software modules
– Green cylinders for persistent storage (flash)
– Orange parallelograms for external APIs
– Gray box for hardware board
• Draw directional arrows:
– Label arrows with protocols (HTTP GET/POST, SPI, GPIO, I²C if used)
– Show flow: Wake → WiFi → TimeSync → Geolocation → PrayerFetch → Render → Sleep
• Annotate each arrow with latency or timeout info if needed (e.g., “30 sec timeout → deep‐sleep”)
• Highlight key design patterns:
– Event/state‐machine for UI
– Layered network → parser → rendering pipeline
– Power‐management loop
6. Tailoring to this embedded IoT project
• Emphasize power cycle: clearly mark the “Deep‐Sleep” loop.
• Show captive‐portal branching when no WiFi credentials present.
• Call out the OTA update path through the WiFiManager portal.
• Illustrate button‐driven state transitions in the UI subcomponent (e.g., zoom, toggle view, skip screens).
7. Final checklist for the diagram
• Clear, human‐readable labels on all boxes and arrows
• Consistent color coding for categories (software, hardware, external)
• Arrowheads indicating request/response or data flow direction
• A legend/key explaining shapes and colors
• Group boxes or dashed boundaries to show module containment (e.g., network stack vs. UI stack)
By following these guidelines and mapping the specific modules above into your diagram, you’ll produce an accurate, detailed architecture view of the Islamic Prayer Times Display project that captures its embedded‐IoT nature, external dependencies, and power‐sensitive design.
</explanation>