System Requirements Document for mars-ems

1. Introduction

mars-ems is a Smart Micro-Grid monitoring and control dashboard for a small solar micro-grid built around an ESP32 controller, a Random Forest power-prediction model, and an EMS (Energy Management System) that performs predictive load shedding. The product presents live telemetry from the solar panel, battery state-of-charge, and environmental sensors; surfaces the AI engine's power-supply prediction and its EMS decision; shows the state of the two relays (primary LED load and secondary DC fan load); and streams a system activity log — all inside a single dark, instrument-grade dashboard that reads correctly on a 390px phone (Mobile PWA) and on a 1280px desktop.

The audience is the Micro-Grid Operator: a maker, student, technician, or energy hobbyist who runs this micro-grid and needs to trust the numbers instantly, see grid state at a glance, and confirm that the machine is reporting in. The dashboard is a precision tool, not a marketing surface — it opens like a panel that was already running before the operator arrived.

2. System Overview

mars-ems is delivered as a first-party web dashboard (custom UI) with a responsive layout that adapts between desktop and a 390px Mobile PWA viewport. The current product consists of two first-party surfaces:

• Landing — an anonymous public entry surface that introduces the Smart Micro-Grid dashboard, its telemetry monitoring, EMS decisions, and relay status before the operator enters the monitoring workspace.
• Dashboard — the main monitoring workspace: header with connection and mode badges, three real-time telemetry cards, the AI/EMS decision banner, the relay control panel, and the system activity log, with the specified responsive stacking.

Actors. The only active human persona is the Micro-Grid Operator. The ESP32 device, the Random Forest prediction model, and the EMS decision engine are typed non-persona actors: they supply telemetry, predictions, and decisions that the dashboard displays, and they are not human users of the product.

Accepted behavior. The dashboard displays live telemetry (solar panel power/voltage/current, battery SoC and voltage, environmental irradiance and temperature), the ESP32 connection status and AUTO (AI) mode, the AI engine's 2-hour power-supply prediction and its predictive load-shedding decision, the ON/OFF state of Relay 1 (Lampu LED, primary) and Relay 2 (Kipas DC, secondary), and a scrolling activity log of system events. The layout is fixed by the design system: three telemetry columns on desktop, one stacked column on 390px; relay panel above activity log on 390px.

Ownership and exclusions. All current behavior is owned by the two first-party pages above. No account, login, role, or permission system is part of the current product — both surfaces are reachable without identity, and no differentiated visibility over shared state is established by the source. No adjacent capabilities (historical analytics, alerting/notification delivery, multi-site management, user administration, manual mode switching beyond what the source states) are in scope. The ESP32, Random Forest model, and EMS engine are external/system actors whose outputs the dashboard consumes; their internal implementation is not a product surface.

2a. Product Interpretation and Delivery Boundary

mars-ems is a read-and-observe instrument with a live control-state display. The operator's job is to watch the grid: confirm the ESP32 is online, read the three telemetry cards, understand what the AI engine predicts and what the EMS has decided, verify which relays are on or off, and follow the activity log as events arrive. The dashboard is the product; there is no separate admin console, no settings area, and no account lifecycle in the current scope.

Access. Both the Landing and Dashboard surfaces are reachable without identity (access_requirement: none). The source establishes no login, no user accounts, and no differentiated permissions; the operator opens the dashboard and it reports. This is a deliberate boundary, not an omission — no identity establishment, verification, or account management is added.

Delivery. The product is a responsive web dashboard delivered as a Mobile PWA at 390px and as a desktop layout at 1280px, with the exact stacking rules the source specifies. The ESP32, Random Forest model, and EMS engine are external/system actors; the dashboard consumes their telemetry, predictions, and decisions and does not own their execution.

Current vs. future. Everything in this document is current. No future-horizon requirements were stated by the user; nothing is deferred.

2b. Source Content Inventory

Not applicable — no reference directive in this request declares content_source. All product facts come from the user-authored requirement thread and the accepted Planning Scope.

2c. Page Content and Component Coverage

Landing

• Purpose and information. Anonymous public entry that introduces the Smart Micro-Grid dashboard — its telemetry monitoring, EMS decisions, and relay status — before the operator enters the monitoring workspace. It presents the product identity and the value of the instrument, then hands off to the Dashboard.
• Primary actions. Enter the Dashboard (open the monitoring workspace).
• Supporting actions. Read the product framing (what the dashboard monitors and decides).
• Domain entities. Product identity (Smart Micro-Grid Dashboard), the monitored subjects (solar panel, battery, environmental sensors), the AI/EMS decision concept, relay state concept.
• Component responsibilities. Wordmark \xe2\x9a\xa1 Smart Micro-Grid Dashboard; a concise framing of the instrument; a single entry control into the Dashboard. No telemetry values, no live badges, no relay controls on this surface.
• States. Loading: minimal — static framing renders immediately. Empty: not applicable (no data collections). Success: operator proceeds to Dashboard. Error/recovery: if the entry control cannot proceed, present a retry affordance; the framing remains readable.

Dashboard

• Purpose and information. The main monitoring workspace. Displays, top to bottom: the header bar; the three real-time telemetry cards; the full-width AI/EMS decision banner; and the bottom area with the relay control panel and the activity log.
• Header / Top Navigation Bar.
  • Left: \xe2\x9a\xa1 Smart Micro-Grid Dashboard — bold, 18px, white (#F8FAFC).
  • Right: two status pills — Badge Status 1 ESP32: ONLINE (pill, fill green #16A34A, white text 11px bold) and Badge Status 2 MODE: AUTO (AI) (pill, fill blue #0284C7, white text 11px bold).
  • Separated from content by a 1px #334155 rule.
• Telemetry row (3 columns on desktop, 1 stacked column at 390px).
  • Card 1 — PANEL SURYA. Title muted #94A3B8, 12px bold. Primary metric 0.91 W in blue #38BDF8, 28px bold. Detail line 5.10 V | 180 mA in #CBD5E1, 12px.
  • Card 2 — KONDISI BATERAI (SOC). Title muted #94A3B8, 12px bold. Primary metric 78% in green #4ADE80, 28px bold. Detail line Tegangan: 3.95 V (Aman) in #CBD5E1, 12px.
  • Card 3 — SENSOR LINGKUNGAN. Title muted #94A3B8, 12px bold. Primary metric 650 W/m² in yellow #FACC15, 28px bold. Detail line Suhu: 31.5 °C (Terik) in #CBD5E1, 12px.
  • Each card: #1E293B surface, 1px #334155 stroke, 3px full-height state rail on the left inner edge (green #22C55E / amber #FACC15 / red #EF4444).
• AI/EMS decision banner (full-width container).
  • Background purple/indigo #312E81 with indigo border #6366F1.
  • Left header: \xf0\x9f\xa4\x96 SMART ENGINE (Random Forest & EMS) in light indigo #A5B4FC, 14px bold.
  • Right badge: ⚠️ PREDIKSI PENURUNAN DAYA (pill red #EF4444, white text 11px bold).
  • Info line 1: Prediksi Pasokan Daya (2 Jam Ke Depan): 0.25 Watt — white text, metric number in blue #38BDF8 bold.
  • Info line 2: Status Keputusan: Predictive Load Shedding Active in yellow #FBBF24 bold.
  • Action note: Aksi Sistem: Mematikan Beban Sekunder (Kipas DC) secara proaktif agar Beban Utama (LED) tetap mendapat pasokan daya. in light gray #CBD5E1, 12px.
• Bottom area (2 columns on desktop, 1 column at 390px with relay panel above log).
  • Left — Relay Control Panel. Title \xf0\x9f\x8e\x9b️ PANEL KONTROL SAKELAR (RELAY) (13px bold). Mode status ● Mode Otomatis (AI Engine Active) (blue, 12px). Horizontal divider. Relay 1 row: Relay 1: Lampu LED (Utama) + badge button ON (green #22C55E, white bold). Relay 2 row: Relay 2: Kipas DC (Sekunder) + badge button OFF (AI) (red #EF4444, white bold).
  • Right — System Activity Log (Terminal Box). Title \xf0\x9f\x93\x8b LOG AKTIVITAS SISTEM (13px bold). Terminal box: background deep black #020617, monospace font 11px. Log lines:
    • [14:10:05] ESP32 kirim telemetri: V=5.1V, I=180mA (gray)
    • [14:10:07] RF prediksi daya turun 40% (gray)
    • [14:10:08] EMS Load Shedding: Relay 2 OFF (red #F87171)
    • [14:10:10] Relay 1 tetap dijaga ON (green #4ADE80)
• Domain entities. Telemetry reading (solar power/voltage/current; battery SoC/voltage; irradiance/temperature), device connection status, operating mode, AI prediction (2-hour power supply), EMS decision state, relay state (Relay 1 / Relay 2), activity log entry (timestamp, source, message, severity color).
• Component responsibilities. Header bar (wordmark + two status pills); telemetry card ×3 (title, primary metric, detail line, state rail); AI/EMS banner (header, prediction badge, two info lines, action note); relay control panel (panel title, mode status, divider, two relay rows with status chips); activity log terminal (panel title, scrollable monospace bay with color-coded lines).
• States.
  • Loading: telemetry cards and banner show their structure with values pending; the log bay shows its frame.
  • Empty: if no log entries have arrived, the terminal bay shows an empty recessed frame; telemetry cards retain their labels.
  • Success: live values render in their specified colors; badges show ESP32: ONLINE and MODE: AUTO (AI); relay chips show ON / OFF (AI); log lines stream in.
  • Error/recovery: if the ESP32 connection drops, the ESP32: ONLINE badge reflects the non-online state and the dashboard continues to display the last known values and log; when the connection returns, live values resume. If the AI/EMS output is unavailable, the banner retains its structure and the dashboard continues to show telemetry and relay state.
  • Responsive: at 390px the three telemetry cards stack into one vertical column (Panel Surya → Kondisi Baterai → Sensor Lingkungan) and the bottom area becomes one column with the Relay Control Panel above the Activity Log.

3. Functional Requirements

Each requirement is a distinct story point with provenance, lifecycle facts, and observable acceptance.

FR-1 — Dark Mode / Slate Dark base theme (explicit) As a Micro-Grid Operator, I should see the dashboard on a Dark Mode / Slate Dark (#0F172A) background so that the instrument reads as a dark, low-glare panel.

• Trigger/input: opening the dashboard.
• Observable result: page ground is #0F172A.
• Access state: none required.
• Failure/recovery: not applicable (static presentation).
• Continuation: operator reads telemetry.

FR-2 — Slate container surfaces with hairline strokes (explicit) As a Micro-Grid Operator, I should see cards and containers on Slate Container (#1E293B) with a #334155 stroke border so that surfaces are separated by hairlines rather than shadows.

• Trigger/input: rendering of any card/panel/banner.
• Observable result: #1E293B fill with 1px #334155 stroke.
• Access state: none required.
• Failure/recovery: not applicable.
• Continuation: operator distinguishes panels at a glance.

FR-3 — Text and metric color roles (explicit) As a Micro-Grid Operator, I should see primary text in white (#F8FAFC), secondary/muted text in #94A3B8, and metric numbers in #38BDF8 so that hierarchy is legible without decoration.

• Trigger/input: rendering of labels, detail lines, and metric values.
• Observable result: each text role uses its specified color.
• Access state: none required.
• Failure/recovery: not applicable.
• Continuation: operator reads values and labels.

FR-4 — Status indicator colors (explicit) As a Micro-Grid Operator, I should see status indicators in green active/safe (#16A34A), yellow warning (#FACC15), and red critical/load-shedding (#EF4444) so that grid state is coded consistently.

• Trigger/input: any status display (badges, rails, chips, log lines).
• Observable result: each status uses its specified color.
• Access state: none required.
• Failure/recovery: not applicable.
• Continuation: operator reads state at a glance.

FR-5 — Sans-serif typography (Inter or Roboto) (explicit) As a Micro-Grid Operator, I should see the product set in a sans-serif typeface (Inter or Roboto) so that the interface reads as a clean technical tool.

• Trigger/input: rendering of all text.
• Observable result: sans-serif family applied throughout.
• Access state: none required.
• Failure/recovery: not applicable.
• Continuation: operator reads the interface.

FR-6 — Header / Top Navigation Bar (explicit) As a Micro-Grid Operator, I should see a header bar with \xe2\x9a\xa1 Smart Micro-Grid Dashboard on the left (bold, 18px, white) and two status pills on the right — ESP32: ONLINE (pill, fill green #16A34A, white text 11px bold) and MODE: AUTO (AI) (pill, fill blue #0284C7, white text 11px bold) — so that I can confirm the device connection and operating mode immediately.

• Trigger/input: opening the dashboard; ESP32 connection state; operating mode.
• Observable result: wordmark and both pills render with their specified fills and text.
• Access state: none required.
• Failure/recovery: if the ESP32 is not online, the connection pill reflects the non-online state; the mode pill continues to show the current mode.
• Continuation: operator proceeds to read telemetry.

FR-7 — Real-time telemetry card: Panel Surya (explicit) As a Micro-Grid Operator, I should see a PANEL SURYA card with primary metric 0.91 W (blue #38BDF8, 28px bold) and detail line 5.10 V | 180 mA (gray #CBD5E1, 12px) so that I can read solar output at a glance.

• Trigger/input: live solar telemetry from the ESP32.
• Observable result: card renders title (muted #94A3B8, 12px bold), metric, and detail line.
• Access state: none required.
• Failure/recovery: if solar telemetry is unavailable, the card retains its structure and shows the last known reading.
• Continuation: operator reads the next card.

FR-8 — Real-time telemetry card: Kondisi Baterai (SoC) (explicit) As a Micro-Grid Operator, I should see a KONDISI BATERAI (SOC) card with primary metric 78% (green #4ADE80, 28px bold) and detail line Tegangan: 3.95 V (Aman) (gray #CBD5E1, 12px) so that I can read battery state-of-charge and voltage.

• Trigger/input: live battery telemetry from the ESP32.
• Observable result: card renders title, metric, and detail line.
• Access state: none required.
• Failure/recovery: if battery telemetry is unavailable, the card retains its structure and shows the last known reading.
• Continuation: operator reads the next card.

FR-9 — Real-time telemetry card: Sensor Lingkungan (explicit) As a Micro-Grid Operator, I should see a SENSOR LINGKUNGAN card with primary metric 650 W/m² (yellow #FACC15, 28px bold) and detail line Suhu: 31.5 °C (Terik) (gray #CBD5E1, 12px) so that I can read irradiance and temperature.

• Trigger/input: live environmental telemetry from the ESP32.
• Observable result: card renders title, metric, and detail line.
• Access state: none required.
• Failure/recovery: if environmental telemetry is unavailable, the card retains its structure and shows the last known reading.
• Continuation: operator reads the AI/EMS banner.

FR-10 — AI/EMS decision banner (explicit) As a Micro-Grid Operator, I should see a full-width AI/EMS banner with background #312E81 and border #6366F1, header \xf0\x9f\xa4\x96 SMART ENGINE (Random Forest & EMS) (light indigo #A5B4FC, 14px bold), right badge ⚠️ PREDIKSI PENURUNAN DAYA (pill red #EF4444, white text 11px bold), info line Prediksi Pasokan Daya (2 Jam Ke Depan): 0.25 Watt (white text, metric number blue #38BDF8 bold), info line Status Keputusan: Predictive Load Shedding Active (yellow #FBBF24 bold), and action note Aksi Sistem: Mematikan Beban Sekunder (Kipas DC) secara proaktif agar Beban Utama (LED) tetap mendapat pasokan daya. (light gray #CBD5E1, 12px) so that I can see the machine's prediction and its decision.

• Trigger/input: Random Forest prediction and EMS decision output.
• Observable result: banner renders with its specified fill, border, header, badge, two info lines, and action note.
• Access state: none required.
• Failure/recovery: if the prediction or decision output is unavailable, the banner retains its structure and the dashboard continues to show telemetry and relay state.
• Continuation: operator reads the relay panel.

FR-11 — Relay control panel (explicit) As a Micro-Grid Operator, I should see a \xf0\x9f\x8e\x9b️ PANEL KONTROL SAKELAR (RELAY) panel with mode status ● Mode Otomatis (AI Engine Active) (blue, 12px), a horizontal divider, a Relay 1: Lampu LED (Utama) row with badge button ON (green #22C55E, white bold), and a Relay 2: Kipas DC (Sekunder) row with badge button OFF (AI) (red #EF4444, white bold) so that I can see which loads are energized.

• Trigger/input: relay state from the ESP32/EMS.
• Observable result: panel renders title, mode status, divider, and both relay rows with their chips.
• Access state: none required.
• Failure/recovery: if relay state is unavailable, the panel retains its structure and shows the last known state.
• Continuation: operator reads the activity log.

FR-12 — System activity log (terminal box) (explicit) As a Micro-Grid Operator, I should see a \xf0\x9f\x93\x8b LOG AKTIVITAS SISTEM panel with a terminal box on background #020617 in monospace 11px, containing lines such as [14:10:05] ESP32 kirim telemetri: V=5.1V, I=180mA (gray), [14:10:07] RF prediksi daya turun 40% (gray), [14:10:08] EMS Load Shedding: Relay 2 OFF (red #F87171), and [14:10:10] Relay 1 tetap dijaga ON (green #4ADE80), so that I can follow system events as they occur.

• Trigger/input: system events (telemetry receipt, RF prediction, EMS load shedding, relay maintenance).
• Observable result: log lines render in the terminal bay with their specified colors.
• Access state: none required.
• Failure/recovery: if no events have arrived, the bay shows an empty recessed frame; when events resume, lines continue to append.
• Continuation: operator continues monitoring.

FR-13 — Mobile PWA 390px responsive layout (explicit) As a Micro-Grid Operator, I should see the three telemetry cards stacked into one vertical column and the bottom area collapsed to one column with the Relay Control Panel above the Activity Log when viewing at 390px, so that the dashboard is usable on a phone.

• Trigger/input: viewport width at 390px.
• Observable result: telemetry cards stack in the order Panel Surya → Kondisi Baterai → Sensor Lingkungan; Relay Control Panel appears above Activity Log.
• Access state: none required.
• Failure/recovery: not applicable (layout rule).
• Continuation: operator monitors from the phone.

FR-14 — ESP32 connection status and real-time telemetry supply (required_inference) As a Micro-Grid Operator, I should have the ESP32 device provide connection status and real-time telemetry so that the telemetry cards, connection badge, EMS decision, relay status, and log can be displayed.

• Trigger/input: ESP32 reporting.
• Observable result: telemetry values and connection state populate the dashboard.
• Access state: none required.
• Failure/recovery: if the ESP32 stops reporting, the connection badge reflects the non-online state and the dashboard retains the last known values.
• Continuation: operator continues monitoring; live values resume when reporting resumes.

FR-15 — Random Forest prediction and EMS decision availability (required_inference) As a Micro-Grid Operator, I should have the Random Forest prediction and EMS decision data available so that the predictive load-shedding status can be shown on the dashboard.

• Trigger/input: model prediction and EMS decision output.
• Observable result: the AI/EMS banner displays the 2-hour prediction and the decision status.
• Access state: none required.
• Failure/recovery: if the output is unavailable, the banner retains its structure and the dashboard continues to show telemetry and relay state.
• Continuation: operator continues monitoring.

FR-16 — Responsive order preservation at 390px (required_inference) As a Micro-Grid Operator, I should have the responsive layout preserve the Relay Control Panel above the Activity Log at 390px so that the control state is read before the event history.

• Trigger/input: viewport width at 390px.
• Observable result: relay panel renders above the log.
• Access state: none required.
• Failure/recovery: not applicable.
• Continuation: operator reads control state, then history.

4. User Personas

Micro-Grid Operator

Product context. The operator runs a small solar micro-grid built around an ESP32 controller, a Random Forest power-prediction model, and an EMS that performs predictive load shedding. They are a maker, student, technician, or energy hobbyist — someone who built or maintains the rig and needs to know, at a glance, whether the grid is healthy and what the machine has decided. They read the dashboard on a phone at 390px while standing near the rig and on a laptop at 1280px when reviewing.

Primary goal. To trust the numbers instantly: confirm the ESP32 is online, read solar/battery/environmental telemetry, understand the AI engine's power-supply prediction and the EMS decision, verify which relays are energized, and follow the activity log — so that the primary LED load keeps receiving power.

Distinct accepted responsibilities.

• Monitor real-time telemetry: solar panel power/voltage/current, battery SoC and voltage, environmental irradiance and temperature.
• Confirm device connection status (ESP32: ONLINE) and operating mode (MODE: AUTO (AI)).
• Read the AI engine's 2-hour power-supply prediction and the EMS decision state (Predictive Load Shedding Active).
• Verify relay state: Relay 1 (Lampu LED, primary) and Relay 2 (Kipas DC, secondary).
• Review the system activity log to understand what the machine has done and why.

Relevant inputs and decisions. The operator reads values and states; the source does not establish a manual override, mode switch, or configuration decision for the operator. The operator's decision is observational: whether the grid is in a safe state and whether the primary load is protected.

Interactions with other accepted participants. The operator interacts with the dashboard surfaces. The ESP32, Random Forest model, and EMS engine are non-persona actors that supply the data the operator reads; the operator does not converse with them, but their outputs are the substance of the operator's monitoring.

Observable success. The operator can see grid condition, the power-drop prediction, and relay status clearly on both desktop and the 390px Mobile PWA viewport, and can confirm that the primary LED load remains supplied.

5. Core User Flows

Flow 1 — Operator opens the dashboard and confirms the grid is reporting

1. Starting context. The operator opens mars-ems on a phone (390px) or laptop (1280px). The Landing surface is the anonymous public entry.
2. Action. The operator reads the product framing on Landing and selects the entry control to open the monitoring workspace.
3. Observable result. The Dashboard opens on the #0F172A ground with the header bar visible.
4. Action. The operator reads the header: \xe2\x9a\xa1 Smart Micro-Grid Dashboard on the left, and the two status pills on the right.
5. Observable result. ESP32: ONLINE renders as a green (#16A34A) pill and MODE: AUTO (AI) renders as a blue (#0284C7) pill. The operator confirms the device is reporting and the system is in automatic AI mode.
6. Failure/recovery. If the ESP32 is not reporting, the connection pill reflects the non-online state; the operator can still read the last known telemetry and log, and live values resume when reporting resumes.
7. Next step. The operator proceeds to read telemetry (Flow 2).

Flow 2 — Operator reads real-time telemetry

1. Starting context. The operator is on the Dashboard with the header confirming the device is online.
2. Action. The operator reads the three telemetry cards in order.
3. Observable result. PANEL SURYA shows 0.91 W in blue (#38BDF8) with detail 5.10 V | 180 mA; KONDISI BATERAI (SOC) shows 78% in green (#4ADE80) with detail Tegangan: 3.95 V (Aman); SENSOR LINGKUNGAN shows 650 W/m² in yellow (#FACC15) with detail Suhu: 31.5 °C (Terik). Each card carries its 3px state rail on the left inner edge.
4. Action (mobile). At 390px, the operator scrolls through the three cards stacked in one vertical column in the order Panel Surya → Kondisi Baterai → Sensor Lingkungan.
5. Observable result. All three readings are legible without horizontal scrolling.
6. Failure/recovery. If a telemetry value is unavailable, the affected card retains its structure and shows the last known reading; the operator continues reading the other cards.
7. Next step. The operator reads the AI/EMS banner (Flow 3).

Flow 3 — Operator reads the AI prediction and EMS decision

1. Starting context. The operator has read telemetry and continues down the dashboard.
2. Action. The operator reads the full-width AI/EMS banner.
3. Observable result. The banner renders on #312E81 with a #6366F1 border; the header \xf0\x9f\xa4\x96 SMART ENGINE (Random Forest & EMS) appears in light indigo (#A5B4FC); the right badge ⚠️ PREDIKSI PENURUNAN DAYA appears as a red (#EF4444) pill; info line 1 shows Prediksi Pasokan Daya (2 Jam Ke Depan): 0.25 Watt with the metric number in blue (#38BDF8); info line 2 shows Status Keputusan: Predictive Load Shedding Active in yellow (#FBBF24); the action note explains that the system is proactively shutting off the secondary load (DC fan) so the primary load (LED) keeps receiving power.
4. Action. The operator interprets the decision: the machine predicts a power drop and has already acted on the secondary load.
5. Observable result. The operator understands the machine's reasoning without needing to inspect the log.
6. Failure/recovery. If the prediction or decision output is unavailable, the banner retains its structure and the dashboard continues to show telemetry and relay state.
7. Next step. The operator verifies relay state (Flow 4).

Flow 4 — Operator verifies relay state

1. Starting context. The operator has read the AI/EMS decision and wants to confirm which loads are energized.
2. Action. The operator reads the \xf0\x9f\x8e\x9b️ PANEL KONTROL SAKELAR (RELAY) panel.
3. Observable result. The mode status reads ● Mode Otomatis (AI Engine Active) in blue; below the divider, Relay 1: Lampu LED (Utama) shows the ON chip in green (#22C55E) and Relay 2: Kipas DC (Sekunder) shows the OFF (AI) chip in red (#EF4444).
4. Action (mobile). At 390px, the operator reads the relay panel above the activity log in the single-column bottom area.
5. Observable result. The operator confirms the primary LED load is on and the secondary DC fan has been shed by the AI.
6. Failure/recovery. If relay state is unavailable, the panel retains its structure and shows the last known state.
7. Next step. The operator reviews the activity log (Flow 5).

Flow 5 — Operator reviews the system activity log

1. Starting context. The operator wants to understand the sequence of events that led to the current state.
2. Action. The operator reads the \xf0\x9f\x93\x8b LOG AKTIVITAS SISTEM terminal box.
3. Observable result. The bay renders on #020617 in monospace 11px with color-coded lines: [14:10:05] ESP32 kirim telemetri: V=5.1V, I=180mA (gray), [14:10:07] RF prediksi daya turun 40% (gray), [14:10:08] EMS Load Shedding: Relay 2 OFF (red #F87171), [14:10:10] Relay 1 tetap dijaga ON (green #4ADE80).
4. Action. The operator follows the sequence: telemetry received → RF predicted a 40% power drop → EMS shed Relay 2 → Relay 1 was kept on.
5. Observable result. The operator can reconstruct what the machine did and why, matching the banner's decision to the log's events.
6. Failure/recovery. If no events have arrived, the bay shows an empty recessed frame; when events resume, lines continue to append.
7. Next step. The operator continues monitoring; the dashboard updates as new telemetry, predictions, and events arrive.

6. Visuals Colors and Theme

Muse and headline. Rasmus Andersson — instrument-grade product craft: graphite ground, tabular numerals as ornament, one hot signal accent. The user's mandated design system is already a dark, dense, data-first instrument; the muse contribution is craft, density, and numeral typography, not colour. The user's explicit palette is honoured exactly.

Colour tokens (dark mode).

Proportion. ~85% dark neutrals, ~10% status colour, ~5% metric cyan. The AI banner is the only container that leaves the slate system for a second hue family — that makes the machine's decision the loudest object on the page.

Typography. Inter Tight (the user's requested Inter, taken in its tighter, more characterful cut) across the whole product: 600–700 weights for headings and card titles, uppercase with +0.08em tracking for micro-labels (PANEL SURYA, KONDISI BATERAI (SOC), SENSOR LINGKUNGAN, RELAY 1), tabular-nums and slashed-zero on every number so digits never jitter as telemetry updates. Metrics are set large and tight (-0.02em) in 700; body/detail copy is 400–500 at 12–13px with 1.5 line-height. No display serif, no rounded font.

Type scale (1.25 modular on a 4px baseline grid).

• Mobile 390px: metric 28px / panel title 13px / card title 11px / body 12px / micro-label 10px.
• Tablet 768px: metric 36px / panel title 14px / body 13px.
• Desktop 1280px: metric 44px / page title 20px / panel title 14px / body 13px / micro-label 11px.
• Every size written as clamp(), e.g. metric: clamp(28px, 4.2vw, 44px).

Shape language. Hairline engineering geometry. 4px/8px spacing scale throughout; 10px radius on cards and panels, 6px on pills and badges, 4px on the relay status chips, 0px radius on the terminal box and on the left status rails so the log reads as a machined recess. Separation is achieved with 1px #334155 strokes and 1px internal dividers, never with shadows or glows. A 3px full-height colour rail (green/amber/red) runs down the left inner edge of each telemetry card to encode its state as structure rather than as an icon.

Layout. A single 12-column grid, max-width 1280px, 24px gutters, 16px page padding at 390px. Order top-to-bottom: (1) header bar — wordmark flush left, the two status pills flush right, separated from content by a 1px #334155 rule; (2) telemetry row — three equal columns at 768px+ and desktop, stacking to one full-width column at 390px in the order Panel Surya → Kondisi Baterai → Sensor Lingkungan; (3) the full-bleed AI/EMS banner, indigo, the only container that breaks the slate system; (4) bottom area — Relay Control panel left and Activity Log right at 768px+, stacking to Relay Control above Activity Log at 390px exactly as specified. Dense but ordered: label/value pairs align on a common right edge across all three cards, and the log is a fixed-height scrollable bay rather than a growing block.

Imagery. The interface is the imagery. No photography, no illustration, no 3D. The only graphic elements are: the live status dot, the 3px state rails on cards, a hairline sparkline drawn in #38BDF8 under the solar metric, and the emoji already specified in the copy (\xe2\x9a\xa1\x20\xf0\x9f\xa4\x96\x20\xe2\x9a\xa0️\x20\xf0\x9f\x8e\x9b️\x20\xf0\x9f\x93\x8b) used at 1em inline. The AI banner may carry one faint 1px-stroked radial grid in #6366F1 at 12% opacity behind its text as a nod to the Random Forest model — diagrammatic, never a gradient blob.

7. Signature Design Concept

The instrument that was already running. The first screen is not a marketing hero — it is the instrument itself, and it must read that way in the first 400ms. Full-bleed #0F172A ground. A 56px-tall header bar with a 1px #334155 baseline rule: \xe2\x9a\xa1 Smart Micro-Grid Dashboard at 18–20px/700 in #F8FAFC on the left, and on the right two pills — ESP32: ONLINE filled #16A34A and MODE: AUTO (AI) filled #0284C7, both 11px/700 white, 6px radius, with a 6px slow-pulsing white dot inside the first. Immediately below, the dominant element: the three telemetry cards, each #1E293B with a 1px #334155 stroke and a 3px state rail on its left inner edge, each carrying an uppercase 11px/700 #94A3B8 title, a clamp(28px, 4.2vw, 44px)/700 tabular numeral (0.91 W in #38BDF8, 78% in #4ADE80, 650 W/m² in #FACC15) and a 12px #CBD5E1 detail line beneath a hairline divider. At 1280px they sit as three equal columns spanning the grid; at 390px they become three stacked full-width cards. The banner is deliberately NOT in the first viewport at mobile — it sits just below the fold as the next discovery. No centred headline, no subtext, no gradient, no hero image, no button: the page opens like a panel that was already running before you arrived.

Signature moves.

• Tabular numerals as the hero type. Every metric is set in Inter Tight 700 with tabular-nums and slashed zero at clamp(28px, 4.2vw, 44px), and the values roll to new readings in 180ms without the layout shifting a single pixel — the numbers are the most designed object on the page.
• A 3px full-height state rail on the left inner edge of each telemetry card (green #22C55E / amber #FACC15 / red #EF4444) that encodes status as architecture, so the page can be read at a glance from the far side of a room without reading a single word.
• The AI/EMS banner as a deliberate palette rupture. The only container in the product that leaves the slate system for #312E81 with a #6366F1 border, #A5B4FC header, a #EF4444 prediction pill pushed flush right, and a faint 1px #6366F1 radial grid at 12% behind the text — the machine's decision is visibly a different kind of object from the sensor readings.
• The Activity Log as a machined recess. A #020617 bay, 0px radius, 11px monospace, fixed height with its own scroll, where each new line slides in from the left in 150ms and older lines fade to #94A3B8 — a terminal you watch, not a list you read.
• Relay rows as label/value pairs aligned on a shared right edge across the whole panel, each ending in a 4px-radius status chip (ON #22C55E, OFF (AI) #EF4444) that flips fill instantly on toggle with a one-frame 1px border flash — no switch chrome, no shadow, just a state that changes.

8. Interaction Model & Motion Direction

Interaction Model: Static Motion Tempo: restrained Hero Dimensionality: flat

Landing Hero Motion Brief. The public entry is the instrument itself, not a marketing hero. Focal subject: the three telemetry cards with their tabular numerals and 3px state rails, framed by the header bar with its two status pills. Input → transformation → outcome thesis: the operator arrives at the dashboard; the live status dot pulses once every 2s at low amplitude to signal the machine is reporting; telemetry numbers roll/count to their new values in 180ms with tabular-nums so the layout never shifts; status pills crossfade their fill when state changes; a new log line slides in from the left in 150ms and older lines dim to #94A3B8; relay chips flip fill instantly on toggle with a 1px border flash. The outcome is a panel that reads as already running — the operator trusts the numbers instantly. Motion vocabulary: fast and functional, 120–200ms, cubic-bezier(0.2, 0, 0, 1) — state changes, not performances. Composed first frame: full-bleed #0F172A ground, 56px header bar with the wordmark left and the two pills right, three telemetry cards below with their state rails and tabular numerals, the AI/EMS banner just below the fold at mobile. Reduced-motion state: all counting, pulsing, and slide-ins are replaced by instant value swaps and a static dot; the layout is unchanged and every value remains readable.

9. Non-Functional Requirements

NFR-1 — Responsive layout at 390px and 1280px (explicit) The dashboard must render correctly at a 390px Mobile PWA viewport and at a 1280px desktop viewport, with the specified stacking rules (three telemetry cards → one column; bottom area → one column with relay panel above log). Rationale: the source explicitly specifies the 390px Mobile PWA layout.

NFR-2 — Readable text and controls at every viewport (explicit, from creative direction) Headlines, wordmarks, labels, numbers, card text, and controls must stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling (e.g. font-size: clamp(...) with its mobile size) to fit; no other element may cover any part of them. Rationale: the creative direction's readability rule.

NFR-3 — Tabular numerals and slashed zero (explicit, from creative direction) Every numeric metric must use tabular-nums and slashed zero so digits do not jitter as telemetry updates. Rationale: the creative direction's typography rule; supports the operator's need to trust the numbers.

NFR-4 — No shadows, glows, or elevation (explicit, from creative direction) Separation must be achieved with 1px #334155 strokes and 1px internal dividers only; no card shadows, glows, glassmorphism, blur, or elevation. Rationale: the creative direction's shape language.

NFR-5 — Metric cyan is a data colour only (explicit, from creative direction) #38BDF8 must be used only for live numeric telemetry and the mode indicator dot — never as a button fill or accent on the page ground. Rationale: the creative direction's palette rule.

NFR-6 — Reduced-motion support (explicit, from creative direction) With prefers-reduced-motion, all counting, pulsing, and slide-ins must be replaced by instant value swaps and a static dot. Rationale: the creative direction's motion rule.

NFR-7 — No generic indigo/blue-on-white SaaS template (explicit, from creative direction) The generic indigo/blue-on-white SaaS template is forbidden for this project. Rationale: the creative direction's explicit prohibition.

NFR-8 — Backend integration for telemetry, prediction, and EMS (required_inference) The dashboard must integrate with a backend that supplies ESP32 telemetry, Random Forest predictions, and EMS decisions. Rationale: required to make the accepted monitoring journey executable; the source establishes these data flows as the substance of the dashboard.

10. Tech Stack

• Frontend: React (web dashboard, responsive, Mobile PWA at 390px). (Default — not specified by user; the source specifies a web dashboard with a Mobile PWA viewport.)
• Backend: Python / FastAPI to receive ESP32 telemetry, serve Random Forest predictions, and expose EMS decision state. (Default — not specified by user; required_inference to support the accepted data flows.)
• Storage: appropriate storage for telemetry readings, predictions, EMS decisions, and activity log entries. (Default — not specified by user.)
• Containerization: Docker / docker-compose for local and deployment packaging. (Default — not specified by user.)
• Typography: Inter Tight (the user's requested Inter, taken in its tighter cut), with Roboto as the source-permitted alternative. (Explicit — user specified Inter or Roboto.)
• Device: ESP32 controller supplying connection status and real-time telemetry. (Explicit — user specified ESP32.)
• Model: Random Forest power-prediction model. (Explicit — user specified Random Forest.)
• EMS: Energy Management System performing predictive load shedding. (Explicit — user specified EMS.)

11. Assumptions and Constraints

Assumptions.

• A1: The ESP32, Random Forest model, and EMS engine are external/system actors whose outputs the dashboard consumes; their internal implementation is not a product surface. (required_inference)
• A2: The dashboard is a read-and-observe instrument with a live control-state display; the source does not establish a manual override, mode switch, or configuration decision for the operator. (explicit — no such capability is stated)
• A3: Both Landing and Dashboard are reachable without identity; no account, login, role, or permission system is part of the current product. (explicit — access_requirement: none on both surfaces)
• A4: The dashboard continues to display the last known values and log when the ESP32 connection drops, and resumes live values when reporting resumes. (required_inference — needed for a usable monitoring lifecycle)
• A5: The AI/EMS banner retains its structure when prediction or decision output is unavailable, and the dashboard continues to show telemetry and relay state. (required_inference)
• A6: The activity log is a fixed-height scrollable bay rather than a growing block. (explicit, from creative direction)

Constraints.

• C1: Dark Mode / Slate Dark (#0F172A) is the mandatory page ground. (explicit)
• C2: Cards/containers use Slate Container (#1E293B) with a #334155 stroke border. (explicit)
• C3: Text roles: primary #F8FAFC, secondary/muted #94A3B8, metric #38BDF8. (explicit)
• C4: Status colors: green active/safe #16A34A, yellow warning #FACC15, red critical/load-shedding #EF4444. (explicit)
• C5: Font must be sans-serif (Inter or Roboto). (explicit)
• C6: The terminal log box uses background #020617 with monospace 11px. (explicit)
• C7: At 390px, the three telemetry cards must stack into one vertical column and the bottom area must become one column with the Relay Control Panel above the Activity Log. (explicit)
• C8: The AI/EMS banner uses #312E81 fill with #6366F1 border and #A5B4FC header text. (explicit)
• C9: The MODE: AUTO (AI) pill uses fill #0284C7. (explicit)
• C10: The ESP32: ONLINE pill uses fill #16A34A. (explicit)
• C11: Relay 1 chip ON uses #22C55E; Relay 2 chip OFF (AI) uses #EF4444. (explicit)
• C12: The generic indigo/blue-on-white SaaS template is forbidden. (explicit, from creative direction)

12. Glossary

• EMS (Energy Management System): The system that decides how to allocate power across loads; in mars-ems it performs predictive load shedding.
• Predictive Load Shedding: Proactively shutting off a secondary load (the DC fan) so that the primary load (the LED) keeps receiving power, based on a predicted power drop.
• Random Forest (RF): The machine-learning model that predicts power supply for the next 2 hours.
• SoC (State of Charge): The battery's remaining charge, expressed as a percentage.
• ESP32: The microcontroller that reports connection status and real-time telemetry from the micro-grid.
• Relay 1 — Lampu LED (Utama): The primary load; the LED lamp that must keep receiving power.
• Relay 2 — Kipas DC (Sekunder): The secondary load; the DC fan that the EMS sheds proactively.
• Micro-Grid: The small solar-powered grid monitored and managed by mars-ems.
• Mobile PWA: The 390px mobile viewport layout of the dashboard.
• State Rail: The 3px full-height colour bar on the left inner edge of each telemetry card that encodes its status (green/amber/red).
• Tabular Numerals: Numerals with fixed advance width (tabular-nums) so digits do not shift as telemetry updates.