System Requirements Document for smartthermo-iot

1. Introduction

SmartThermo is an IoT web dashboard for monitoring room temperature and humidity and industrial-machine temperature. It receives sensor and actuator data from an ATmega328P/ESP32 hardware path, presents current readings and historical trends, and lets an administrator configure remote temperature set points. The application includes a backend API and frontend intended for deployment to Cloud Panel environments such as cPanel, AaPanel, CyberPanel, VPS, or PaaS.

The intended users are a SmartThermo dashboard operator who monitors readings and logs, and a SmartThermo administrator who configures thresholds. The interface is named SmartThermo and uses the slogan “Smart Industrial Temperature & Humidity Monitoring System.”

2. System Overview

SmartThermo comprises a login-protected web interface, backend API, and persistent storage for sensor history and the admin login account. The ATmega328P reads the DHT22 and PT100 sensors and controls the relays/fans and buzzer automatically. The ESP32 receives ATmega328P data over RS485 Modbus RTU and sends it to the cloud server over Wi-Fi/HTTP REST API. The web application accepts periodic ESP32 submissions at POST /api/update-data.

The current interface covers room and machine readings, actuator and connection status, sensor trends, remote threshold settings, and historical logs with search, date filtering, pagination, and CSV/Excel export. The dashboard is protected by login and session/token handling. The accepted active human personas are the SmartThermo dashboard operator and SmartThermo administrator.

The requested visual identity includes a dark glassmorphism interface, the supplied industrial background image, two supplied logo assets, responsive layout, and smooth widget animations. The application is intended to be organized for Cloud Panel deployment and accompanied by a short upload-and-run guide.

2a. Product Interpretation and Delivery Boundary

SmartThermo is a first-party web application with an anonymous entry and login surface, followed by protected monitoring and administration destinations. First-use enrollment establishes an account before returning username/password verification; the source specifies an admin account but does not establish an invitation or provisioning boundary. The application must not expose protected dashboard state before a valid session or token is established.

The hardware performs sensor acquisition and automatic actuator control. The web application receives the reported readings and statuses, persists sensor history, displays the data, and stores the administrator’s threshold settings. The source does not specify how stored remote thresholds are delivered to or applied by the hardware; this document does not assume an additional control protocol or claim that saving a threshold changes hardware behavior.

The current scope does not add user-management functions, additional roles, manual actuator controls, or other adjacent IoT capabilities. No future requirements were specified.

2b. Page Content and Component Coverage

Landing

• Information and state: Anonymous first impression introducing SmartThermo’s industrial temperature and humidity monitoring purpose. Uses the industrial background image as a darkened, blurred ground layer; it is decorative and must not obscure readable content.
• Primary action: Continue to Halaman Login.
• Supporting content: SmartThermo name and specified slogan.
• Components: Entry content and login navigation.
• States: Loading is limited to rendering the entry surface. If the page cannot render, show a recoverable error and allow retry or navigation to Halaman Login. No sensor or protected account data is shown here.

Halaman Login

• Information and state: Anonymous username/password form; first-use account establishment and returning verification. A successful verification establishes a protected session/token before protected destinations are available.
• Primary actions: Establish the initial admin account when no account exists; submit username and password to verify a returning account.
• Supporting actions: Correct invalid or incomplete form input and retry after a failed verification.
• Entities: Admin login account and session/token.
• Components: Centered glassmorphic login card, username and password inputs, interactive validation, submit action, and feedback.
• States: Show validation feedback for invalid input, a clear failure state for unsuccessful verification, and a retry path. On success, continue to Dashboard Utama. Protected state remains unavailable until identity is verified.

Dashboard Utama

• Information and state: Current room temperature and humidity from DHT22; machine temperature from PT100; fan and buzzer states; RS485/ATmega328P–ESP32–cloud connection status; and last-data timestamp.
• Primary actions: Review current readings and system status; navigate to Trends, Thresholds, or History.
• Supporting content: Machine-temperature gauge with Normal/Warning/Danger zones; room temperature and humidity displayed side by side; live indicators for Kipas 1, Kipas 2, and Buzzer.
• Entities: Sensor readings, actuator states, Modbus status, network status, and last-data timestamp.
• Components: Machine gauge, room readouts, actuator/status instrument row, and signal-flow strip showing ATmega328P → RS485 Modbus → ESP32 → Cloud.
• States: Loading while current data is retrieved; empty/unavailable state when no readings have arrived; success state with current values and timestamp; error/stale state when data cannot be retrieved or is no longer fresh. Provide a visible retry/refresh path. A Modbus status other than OK is shown as a connection problem; the signal-flow segment reflects that status.

Trends

• Information and state: Interactive real-time multi-axis line chart for machine temperature, room temperature, and room humidity.
• Primary actions: Select one of the exact duration filters: Live, 1 Jam, 12 Jam, or Hari Ini.
• Entities: Timestamped sensor readings for the three chart series.
• Components: Chart with explicitly styled axes, gridlines, and series colors; duration selector.
• States: Loading while the selected range is retrieved; empty state when no readings exist for that range; success state with the selected series and range; error state with retry. Changing the duration updates the displayed range; the operator can continue monitoring or navigate to another destination.

Thresholds

• Information and state: Administrator’s stored set points for Kipas 1, Kipas 2, and Buzzer Alarm.
• Primary actions: Enter and save the room-fan, machine-fan, and buzzer alarm temperature thresholds.
• Entities: Threshold settings stored on the database/server.
• Components: Interactive threshold form with a distinct field for each of the three set points and save feedback.
• States: Load the stored settings; show validation feedback for invalid input; show save success when settings are persisted; show a recoverable error and retain the ability to retry if saving fails. The administrator can revisit the page to review stored settings. The source does not define threshold ranges or hardware application behavior.

History

• Information and state: Historical sensor log table containing temperature, humidity, and fan status.
• Primary actions: Search logs, filter by date, paginate results, and export data to CSV or Excel.
• Entities: Historical sensor records, including temperature, humidity, fan status, and timestamps where available for the requested date filtering and history.
• Components: Search input, date filter, paginated table, and CSV/Excel export controls.
• States: Loading while records are retrieved; empty state when no records match; success state with matching records; error state with retry. Search and date filtering update the displayed records; pagination moves through the result set; export produces the selected log data in the chosen format or reports a recoverable failure.

3. Functional Requirements

1. As a SmartThermo dashboard operator, I should be able to reach the anonymous SmartThermo entry and continue to login.
   Provenance: required_inference for the Landing page; product name and purpose are explicit.
   Lifecycle and acceptance: The operator opens Landing without an authenticated session, sees the SmartThermo name and slogan, and can continue to Halaman Login. If the entry surface fails to load, the operator can retry or navigate to login. The next step is account verification.

2. As a SmartThermo administrator, I should be able to establish the initial admin login account and verify my username and password on return.
   Provenance: Initial account establishment is required_inference; username/password login and admin account persistence are explicit.
   Lifecycle and acceptance: On first use, the administrator establishes the account before returning verification is available. On return, the administrator submits username and password on Halaman Login. Valid credentials establish a session/token; invalid or incomplete credentials produce feedback and allow correction and retry. Successful verification continues to protected destinations. The account is persisted using the selected lightweight storage approach.

3. As a SmartThermo dashboard operator, I should be able to access the dashboard only after login and see current room, machine, actuator, and connection status.
   Provenance: Dashboard content and login protection are explicit; session continuity is required_inference.
   Lifecycle and acceptance: With a valid session/token, the operator opens Dashboard Utama and sees DHT22 room temperature and humidity, PT100 machine temperature, Kipas 1 and Kipas 2 ON/OFF, Buzzer Active/Mute, RS485/ATmega328P–ESP32–cloud status, and the last-data timestamp. Without a valid session/token, direct URL access to protected state is denied and the operator is directed to Halaman Login. If data is unavailable or stale, the dashboard communicates that state and allows retry/refresh; after recovery, the operator can continue monitoring or navigate to another destination.

4. As a SmartThermo dashboard operator, I should be able to interpret the machine temperature using a gauge with Normal, Warning, and Danger zones.
   Provenance: explicit.
   Lifecycle and acceptance: On Dashboard Utama, the operator views the PT100 reading on an interactive gauge with the three named zones. The gauge transitions smoothly as readings change. If the reading is unavailable, the gauge communicates unavailable data rather than presenting a false current value; the operator can retry or continue to other available dashboard information.

5. As a SmartThermo dashboard operator, I should be able to see the reported automatic actuator states and overheat alarm state.
   Provenance: Hardware behavior and dashboard indicators are explicit.
   Lifecycle and acceptance: The ATmega328P automatically turns Kipas 1 on when DHT22 room temperature exceeds the safe room-temperature limit, turns Kipas 2 on when PT100 machine temperature exceeds the safe machine-temperature limit, and activates the buzzer when machine or room temperature reaches the critical danger limit. The operator sees reported fan ON/OFF and buzzer Active/Mute states. The buzzer indicator uses a red overheat animation when overheat is reported. If status data is unavailable, the interface indicates that it is unavailable rather than implying a current state; the operator can retry or continue monitoring other readings.

6. As a SmartThermo dashboard operator, I should be able to see the specified hardware data path and its reported connection health.
   Provenance: Hardware path and status indicator are explicit; backend acceptance and persistence of periodic submissions are required_inference.
   Lifecycle and acceptance: The ATmega328P reads DHT22 room temperature/humidity and PT100 machine temperature and controls the fans and buzzer automatically. The ESP32 receives ATmega328P data over RS485 Modbus RTU and sends it to the cloud server over Wi-Fi/HTTP REST API. Dashboard Utama shows RS485/Modbus and network status and the last-data timestamp. A non-OK Modbus status or stale data is visibly distinguishable; after data resumes, the displayed status and timestamp update.

7. As a SmartThermo dashboard operator, I should be able to review real-time trends for machine temperature, room temperature, and room humidity over a selected duration.
   Provenance: explicit.
   Lifecycle and acceptance: On Trends, the operator selects Live, 1 Jam, 12 Jam, or Hari Ini. The multi-axis line chart displays the three requested series for the selected duration. If no records exist, the page shows an empty state; if retrieval fails, it shows an error and retry path. The operator can select another duration or continue to another destination.

8. As a SmartThermo administrator, I should be able to configure and save the three remote temperature set points.
   Provenance: explicit.
   Lifecycle and acceptance: On Thresholds, the administrator enters set points for Kipas 1, Kipas 2, and Buzzer Alarm and saves them to the database/server. Invalid input is identified for correction; a successful save is confirmed; a failed save is reported with a retry path. The administrator can revisit the page to review stored settings. The source does not specify threshold values, ranges, or how settings are applied by hardware.

9. As a SmartThermo dashboard operator, I should be able to search, date-filter, paginate, and export historical sensor logs.
   Provenance: explicit.
   Lifecycle and acceptance: On History, the operator views historical temperature, humidity, and fan-status records, searches, filters by date, and navigates pages. The operator can export data to CSV or Excel. No matching records produce an empty state; retrieval or export failure is reported with a retry path. The operator can revise the search/filter or continue to another destination.

10. As an ESP32 device, I should be able to submit periodic sensor data to the specified REST endpoint.
    Provenance: Endpoint and payload fields are explicit; backend acceptance and persistence are required_inference.
    Lifecycle and acceptance: The ESP32 sends JSON to POST /api/update-data. The backend accepts valid submissions and persists sensor history for dashboard, trend, and history use. Invalid or unavailable submissions do not appear as successful current data; the sender can retry. The example payload is:

    {
      "temp_mesin": 45.2,
      "temp_ruangan": 28.5,
      "hum_ruangan": 65.0,
      "kipas_ruangan": 1,
      "kipas_mesin": 0,
      "buzzer": 0,
      "modbus_status": "OK"
    }
    

11. As a SmartThermo project deployer, I should be able to deploy the organized application to a supported Cloud Panel environment.
    Provenance: explicit.
    Lifecycle and acceptance: The deliverable includes complete backend server code, organized frontend files, separate configuration variables URL_BG_PABRIK, URL_LOGO_SEKOLAH, and URL_LOGO_JURUSAN, and a short step-by-step upload-and-run guide for Cloud Panel/cPanel/VPS. The application includes a lightweight SQLite/MySQL database or JSON storage handler for sensor history and the admin login account. Deployment failure must be diagnosable through the guide and deployment/runtime feedback; the deployer can correct configuration and retry.

4. User Personas

SmartThermo dashboard operator

Provenance: required_inference from Planning Scope.
The operator uses the protected dashboard to monitor DHT22 room temperature and humidity, PT100 machine temperature, fan and buzzer states, connection health, and the last-data timestamp. The operator also reviews the three sensor trends and historical logs, including search, date filtering, pagination, and CSV/Excel export. Their work is focused on observing and reviewing system data rather than changing thresholds. Success is observable when current readings and status are available, selected trends and historical records can be reviewed, and requested log data can be exported. The operator interacts with the hardware data path through the reported data and status; no direct hardware control action is specified for this persona.

SmartThermo administrator

Provenance: explicit for the admin account and threshold configuration.
The administrator establishes the initial admin login account, returns to verify with username and password, and configures the room-fan, machine-fan, and buzzer alarm temperature set points. The administrator’s distinct responsibility is changing and saving server-stored threshold settings, unlike the operator’s monitoring and log-review work. Success is observable when the administrator can authenticate and the three settings are confirmed as stored. The source does not specify additional account-management or permission functions.

5. Core User Flows

5.1 Dashboard operator: enter and monitor current conditions

1. The operator opens Landing, sees SmartThermo and its specified monitoring purpose, and continues to Halaman Login.
2. On first use, the admin account is established; on return, the operator enters username and password and submits them.
3. If verification fails, the operator receives feedback, corrects the input, and retries. If it succeeds, a session/token is established.
4. The operator opens Dashboard Utama. Direct access without a valid session/token remains blocked.
5. The operator reviews room temperature and humidity, the PT100 machine gauge and its Normal/Warning/Danger zones, fan and buzzer indicators, connection status, and last-data timestamp.
6. If readings are unavailable or stale, the operator sees that condition and retries/refreshes. When data resumes, the readings and timestamp update.
7. The operator continues monitoring or independently navigates to Trends or History.

5.2 Dashboard operator: review sensor trends

1. From an authenticated session, the operator opens Trends.
2. The operator selects Live, 1 Jam, 12 Jam, or Hari Ini.
3. The chart displays machine temperature, room temperature, and room humidity for the selected duration.
4. If no data exists for the range, the operator sees an empty state. If retrieval fails, the operator retries.
5. The operator selects another duration or leaves Trends for another protected destination.

5.3 Dashboard operator: review and export history

1. From an authenticated session, the operator opens History.
2. The operator reviews historical temperature, humidity, and fan-status records.
3. The operator enters a search term and/or selects a date filter; the displayed records update.
4. The operator uses pagination to move through matching results.
5. The operator selects CSV or Excel export. Successful export produces the requested format; a failure is reported and can be retried.
6. The operator can revise the search/date filter or continue to another destination.

5.4 Administrator: establish identity and configure thresholds

1. The administrator opens Landing and continues to Halaman Login.
2. On first use, the administrator establishes the initial admin account. On return, the administrator submits username and password.
3. Invalid input or failed verification produces feedback and a retry path. Successful verification establishes a protected session/token.
4. The administrator opens Thresholds and reviews the stored set points.
5. The administrator enters the Kipas 1, Kipas 2, and Buzzer Alarm temperature thresholds and saves.
6. Invalid input is identified for correction. A successful save confirms database/server persistence; a failed save is reported and can be retried.
7. The administrator can revisit Thresholds to review the stored values. No hardware application or acknowledgement step is specified.

5.5 Hardware-to-cloud data delivery and monitoring result

1. The ATmega328P reads DHT22 room temperature/humidity and PT100 machine temperature.
2. The ATmega328P automatically controls Kipas 1 when room temperature exceeds its safe limit, Kipas 2 when machine temperature exceeds its safe limit, and the buzzer when room or machine temperature reaches the critical danger limit.
3. The ESP32 receives the ATmega328P data over RS485 Modbus RTU.
4. The ESP32 periodically sends the specified JSON fields to POST /api/update-data over Wi-Fi/HTTP REST API.
5. The backend accepts and persists sensor history. If submission or persistence fails, the data is not represented as a successful current update; the sender can retry.
6. The operator sees the reported readings, actuator states, Modbus/network status, and last-data timestamp on Dashboard Utama, and can review the resulting records on Trends and History.

6. Visuals Colors and Theme

The visual direction is “Data made physical: the plant's own heat signature as a living, generative instrument panel.” The muse is Refik Anadol. The interface should balance instrument-grade seriousness and calibrated trustworthiness with the requested modern, animated glassmorphism showcase quality. The supplied industrial factory photograph is the only background photograph; the two supplied logos occupy their requested top-navigation positions.

Color tokens

Use approximately 70% dark ground, 20% glass surfaces, and 10% amber/teal signal. Do not use blue/indigo as primary or accent, amber on white, or rainbow/violet washes. Danger red is reserved for buzzer-overheat and the Danger gauge zone.

Typography

• Headings and wordmark: Space Grotesk 500/700, tight -0.02em tracking, sentence case.
• Body: IBM Plex Sans.
• Numeric readouts, timestamps, and counters: IBM Plex Mono 500 with tabular figures.
• Micro-labels: IBM Plex Sans 600, 11px, uppercase, +0.14em tracking, muted color.
• Type scale: 14 / 16 / 20 / 25 / 31 / 39 / 49 / 61px.
• Display readouts: clamp(44px, 9vw, 88px), line-height 1.05.
• Page title: clamp(26px, 4.2vw, 40px).
• Widget titles: 16px.
• Body: 16px / 1.6.

Shape, surfaces, and layout

Use soft-edged glass slabs with 20px radii, a luminous 1px top-left edge, and 24px backdrop blur. Buttons and inputs use 12px-radius rectangles, not pills. The factory photo is darkened to approximately 22% brightness, blurred 22px, and given a radial vignette so it remains a faint industrial texture rather than readable content. Place the school and department logos on glass chips.

The dashboard uses a sticky 72px top bar with school logo at left, SmartThermo wordmark and slogan centered, and department logo at right. Below it, use an asymmetric 12-column composition: machine gauge in a 5-column hero area; room DHT22 readouts and actuator/status row in a 4-column area; threshold form in a 3-column rail. Trends and History occupy the full width below. At 768px, the gauge becomes full-width above two stacked columns. At 375px, use one column, wrap the actuator strip into two rows, and make the history table horizontally scrollable with the timestamp column pinned. Keep all readable text and controls fully within their viewport and containers at 375px, 768px, and 1280px.

Imagery and chart styling

Use the supplied industrial background image as the darkened, blurred ground layer. Use the supplied school and department logo images in their respective top-navigation slots. Do not add unrelated photographs. Generate the gauge, trend chart, heat-haze field, and signal-flow strip as interface graphics. Chart axes, gridlines, and series must be styled to the palette rather than left at library defaults.

7. Signature Design Concept

The first protected screen is a live instrument rather than a conventional headline hero. The PT100 machine-temperature dial is the dominant visual: a large circular gauge with a 14px arc, 10°C tick marks, and three concentric Normal/Warning/Danger zones that remain dim until entered by the needle. The current value sits inside the dial in large IBM Plex Mono numerals, with the micro-label “PT100 · SUHU MESIN” beneath it.

The room temperature and humidity readouts sit alongside the gauge as oversized amber and teal figures. Beneath them, the actuator and connection indicators form a ruled instrument row. A signal-flow strip shows the accepted hardware path—ATmega328P → RS485 Modbus → ESP32 → Cloud—with small data packets moving along the line and the relevant segment turning red when modbus_status is not OK.

Behind the glass, a restrained heat-haze particle field is driven by the actual PT100 reading: it visibly warms and quickens as the machine heats. The factory photo remains a subdued background texture, never competing with the readings or controls. The login screen uses the same ground and particle field behind a centered glass card. This concept recomposes only accepted readings, statuses, and controls.

8. Interaction Model & Motion Direction

Interaction Model: Animated
Motion Tempo: cinematic
Hero Dimensionality: flat

Landing Hero Motion Brief

• Focal subject: The live PT100 machine-temperature dial and its current reading, supported by the room DHT22 values and actuator/status row.
• Input → transformation → outcome thesis: Sensor values arriving through the accepted ATmega328P → RS485 Modbus → ESP32 → Cloud path update the displayed readings and status; the PT100 value drives the heat-haze field and gauge state, while the room values and actuator states remain directly readable.
• Motion vocabulary: A slow-drifting heat-haze/particle field whose drift speed and color temperature respond to PT100 readings; numeric readouts count-tick over 600ms with ease-out; gauge needle sweeps over 900ms using cubic-bezier(.22,1,.36,1); cards fade upward 12px with 60ms stagger on first paint and scroll-in. Fresh Modbus/network status uses a 2s teal ping ring and greys after 30 seconds of silence. The buzzer-overheat state alone uses a 1.1s red glow pulse on its badge and the machine-gauge card border.
• Composed first frame: Near-black industrial ground with the subdued factory texture, sticky logo/wordmark bar, large machine dial, paired room readouts, and ruled status indicators. The dial and values are the visual focus, not a centered marketing headline.
• Reduced-motion state: Freeze the particle field to a static gradient; snap count-ups instantly; remove pulses and use a solid red border for overheat while retaining the text “OVERHEAT.” Ensure moving or scrollable content remains fully reachable and readable.

9. Non-Functional Requirements

1. Deployment compatibility — explicit: Organize the backend and frontend for deployment to Cloud Panel environments including cPanel, AaPanel, CyberPanel, VPS, or PaaS, and provide the requested short upload-and-run guide.
2. Authentication boundary — explicit / required_inference: Dashboard access requires login and must be protected against direct URL access without login. Session/token continuity is required for protected destinations.
3. Persistence — explicit: Persist sensor history and the admin login account using a lightweight SQLite/MySQL database or JSON storage handler.
4. Responsive presentation — explicit: The interface is responsive and readable at the specified 375px, 768px, and 1280px widths; text and controls remain whole and unobscured.
5. Motion accessibility — direction-derived: Respect prefers-reduced-motion as specified in the motion brief.
6. Visual legibility — direction-derived: Keep the factory image subdued behind readable content; use the specified palette and chart styling so readings, labels, and status remain distinguishable.
7. Data freshness — direction-derived: Show fresh-data status with the specified teal ping treatment and grey the Modbus/network badge after 30 seconds of silence. Do not represent stale data as current.

10. Tech Stack

• Backend: Node.js/Express, Python/Flask, or PHP Native are source-listed implementation options; no single option is mandated.
• Frontend: Organized HTML/CSS/JavaScript files, separate or integrated, with a clear structure such as public/, views/, and config/.
• Persistence: SQLite, MySQL, or a JSON storage handler, as explicitly allowed by the source.
• Charting: Chart.js or ApexCharts are source-listed options for the interactive multi-axis line chart.
• Deployment: Cloud Panel environments including cPanel, AaPanel, CyberPanel, VPS, or PaaS.
• Configuration: Provide separate variables named URL_BG_PABRIK, URL_LOGO_SEKOLAH, and URL_LOGO_JURUSAN.

11. Assumptions and Constraints

• The source does not select one backend language, database option, or chart library; implementation may choose among the listed alternatives.
• The supplied images are assigned as follows: 5897aef5_backround.jpg is the industrial background, 8b197763_logo_sekolahh.jpg is the school logo, and 933f1938_logo_jurusann.jpg is the department logo.
• First-use enrollment is required to make the accepted admin login journey executable; the source does not define invitations, provisioning, or additional account-management functions.
• The source does not specify threshold values, validation ranges, or how saved thresholds are delivered to or applied by the hardware. Do not invent these details.
• The source does not specify a separate hardware command channel from the web application; the accepted hardware behavior remains automatic at the ATmega328P.
• No additional personas, roles, permissions, manual actuator controls, or future capabilities are included.
• The supplied page contract is the current ordered page inventory: Landing, Halaman Login, Dashboard Utama, Trends, Thresholds, History. Access follows the supplied surfaces: Landing and Halaman Login are anonymous; Dashboard Utama, Trends, Thresholds, and History require the supplied role-restricted access. The source-backed login/session requirement is preserved; no additional differentiated permission behavior is specified.

12. Glossary

• ATmega328P: Master microcontroller that reads the sensors and automatically controls the fans and buzzer.
• DHT22: Sensor for room temperature and humidity.
• ESP32: Slave hardware that receives ATmega328P data over RS485 Modbus RTU and sends it to the cloud server over Wi-Fi/HTTP REST API.
• Modbus RTU: The specified serial communication protocol used over RS485 between the ATmega328P and ESP32.
• PT100: Precision temperature sensor for the industrial machine.
• Set point / threshold: A stored temperature limit configured for Kipas 1, Kipas 2, or the Buzzer Alarm.
• Session/token: The authenticated state required before protected dashboard destinations can be accessed.