docs(ups): uneltele testului de autonomie si ce s-a aflat despre gauge

Cele trei unelte adaugate la ultimul commit (set-praguri, trace-baterie,
start-trace) nu aparaeu in documentatie. Adaugate in tabelul de fisiere si
descrise ca procedura in sectiunea de operare, in ordinea reala de folosire:
largeste praguri -> porneste trace -> scoate din priza -> opreste trace ->
restaureaza praguri.

Sectiunea 6 punctul 1 primeste rezultatul scoaterii din priza de pe 27.08:
autonomia tot nu e masurata (trei minute sunt prea putine), dar s-a vazut ca
gauge-ul de procent al acestui UPS nu e de incredere - 96% -> 65% -> 90% in
100 de secunde la revenirea curentului. Pragul de 35% se sprijina exact pe
cifra asta, iar confirmPolls=3 (45 s) e mai scurt decat fereastra de zgomot.
ACLineStatus, in schimb, a fost impecabil - de aici directia pentru pragurile
definitive: timpul pe baterie devine criteriul principal.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RRyaDj39hPQ89SZS6URRpS

docs/ups-server36-monitorizare.md

@@ -98,8 +98,13 @@ canal care să se strice separat.
 | `scripts/ups-monitor/install-ups-monitor.ps1` | instalare: copiere, `config.json`, ACL, task programat |
 | `scripts/ups-monitor/test-battery.ps1` | test: simulează „pe baterie" fără scoaterea din priză |
 | `scripts/ups-monitor/test-comms-loss.ps1` | test: dezactivează temporar bateria HID și verifică alerta de comunicație |
+| `scripts/ups-monitor/set-praguri.ps1` | schimbă pragurile din `config.json` fără a atinge parola SMTP, și repornește taskul |
+| `scripts/ups-monitor/trace-baterie.ps1` | înregistrează curba de descărcare într-un CSV (rulează ca task, sub SYSTEM) |
+| `scripts/ups-monitor/start-trace.ps1` | pornește / oprește (`-Stop`) taskul de înregistrare |
 | `scripts/ups-monitor/config.example.json` | șablon; **fișierul real nu se comite** (conține parola SMTP) |
 
+Ultimele trei sunt uneltele testului de autonomie — se folosesc împreună, vezi secțiunea 3.
+
 Pe server:
 
 ```
@@ -170,6 +175,11 @@ powershell -ExecutionPolicy Bypass -File C:\ROMFAST\ups-monitor\ups-monitor.ps1
 | `-Mode TestShutdown` (dry-run) | secvența parcursă integral; Oracle a rămas `Running` |
 | Pierderea comunicației (`test-comms-loss.ps1`) | dispozitiv oprit 15:24:44 → alertă **15:26:44** (exact 8 cicluri × 15 s) + email; reactivare → „comunicația a revenit" + email; `Win32_Battery` înapoi la 1 instanță |
 | Taskul rulează ca SYSTEM | proces `ups-monitor.ps1 -Mode Run`, `state.json` actualizat la fiecare ciclu |
+| **Trecerea reală pe baterie** (scos din priză, 15:47:45 → 15:50:46) | tranziția s-a văzut instantaneu în ambele sensuri; email de pană la 15:47:55, email de revenire la 15:50:56 |
+
+Toate cele patru ramuri de alertare au emis email. Testul cu scoaterea din priză a durat doar
+trei minute — prea puțin pentru autonomie, dar suficient cât să valideze semnalul de sursă și
+să descopere problema gauge-ului (secțiunea 6, punctul 1).
 
 ### Testul „pe baterie", fără scoaterea din priză
 
@@ -209,7 +219,35 @@ Asta e singurul mod de a verifica de-adevăratelea cât durează `shutdown immed
 producție — informația de care depinde alegerea pragurilor.
 
 **Rămâne netestabilă prin simulare** doar autonomia reală a UPS-ului: câte minute ține sub
-sarcina actuală. Aceea cere scoaterea din priză (secțiunea 6, punctul 1).
+sarcina actuală. Aceea cere scoaterea din priză — procedura e mai jos.
+
+### Testul de autonomie, cu scoaterea din priză
+
+Trei unelte, în ordinea asta. Toate rulează **pe server**, prin `ssh -p 22122`.
+
+```powershell
+# 1. lărgește pragurile, ca monitorul să nu oprească serverul în timpul testului
+#    (scriptul repornește singur taskul - configurația se citește doar la pornirea buclei)
+powershell -ExecutionPolicy Bypass -File C:\ROMFAST\ups-monitor\set-praguri.ps1 -Minute 60 -Procent 15
+
+# 2. pornește înregistrarea curbei de descărcare
+powershell -ExecutionPolicy Bypass -File C:\ROMFAST\ups-monitor\start-trace.ps1 -IntervalSecunde 15
+
+#    --- abia acum se scoate din priză; minimum 15-20 de minute, ca să se vadă panta ---
+
+# 3. după ce s-a băgat înapoi: oprește înregistrarea și restaurează pragurile de producție
+powershell -ExecutionPolicy Bypass -File C:\ROMFAST\ups-monitor\start-trace.ps1 -Stop
+powershell -ExecutionPolicy Bypass -File C:\ROMFAST\ups-monitor\set-praguri.ps1 -Minute 10 -Procent 35
+```
+
+Înregistrarea rulează ca **task programat sub SYSTEM**, nu în sesiunea SSH — dacă în pană
+cade switch-ul și conexiunea moare, măsurătoarea continuă. Datele rămân în
+`C:\ROMFAST\ups-monitor\log\trace-baterie.csv`; scriptul **adaugă** la fișierul existent, deci
+CSV-ul unui test anterior se arhivează întâi sub alt nume, altfel se amestecă rulările.
+
+Două lucruri de verificat înainte de a scoate ștecherul: pragul de procent lărgit sub 20 %
+înseamnă că **plasa de siguranță rămâne Windows-ul**, nu scriptul; și e util ca gauge-ul să
+fie la 100 %, nu abia revenit dintr-un test anterior.
 
 **Dezarmare de urgență** (monitorul rămâne pornit, dar nu mai ia nicio decizie):
 
@@ -294,11 +332,45 @@ nu are constrângerea asta.
    - *cât durează oprirea curată* (`shutdown immediate` + închiderea Windows-ului) — se află
      dintr-o **repetiție reală** cu `test-battery.ps1 -ConfirmReal ...`, într-o fereastră de
      mentenanță, cu UPS-ul în priză;
-   - *cât ține UPS-ul sub sarcina actuală* — asta chiar cere scoaterea din priză, cu monitorul
+   - *cât ține UPS-ul sub sarcina actuală* — asta chiar cere scoaterea din priză, după
-     **dezarmat** (`DEZACTIVAT`) și cu cineva care urmărește `-Mode Status`.
+     procedura din secțiunea 3.
 
    Pragul corect e „autonomia măsurată minus durata opririi, cu marjă". Până când ambele sunt
    măsurate, pragurile rămân o presupunere rezonabilă, nu o garanție.
+
+   **Ce s-a aflat pe 27.08.2026, dintr-o scoatere din priză de trei minute:** autonomia n-a
+   fost măsurată — trei minute sunt prea puține, iar singura cifră existentă rămâne estimarea
+   proprie a UPS-ului, ~70 de minute, nevalidată. S-a aflat însă altceva, mai important.
+
+   **Gauge-ul de procent al acestui UPS nu e de încredere.** Pe baterie a scăzut lent și
+   monoton (100 % → 96 % în trei minute), dar la revenirea curentului a sărit haotic:
+
+   ```
+   15:50:26  baterie 96%
+   15:50:46  rețea   65%     <- revine curentul
+   15:51:06  rețea   75%
+   15:51:46  rețea   90%
+   ```
+
+   96 → 65 → 90 în 100 de secunde. Nicio baterie nu se încarcă 25 de puncte în 80 de secunde,
+   deci nu e încărcare — e recalibrare, sau zgomot în jurul tranziției. (La 12 minute după test
+   gauge-ul era tot la 90 %.)
+
+   **Consecința pentru configurația actuală:** pragul de **35 %** se sprijină exact pe numărul
+   ăsta nesigur, iar garda de confirmare (`confirmPolls = 3`, adică 45 s) e **mai scurtă decât
+   fereastra de zgomot observată (~80–100 s)**. Riscul e în ambele sensuri: o citire aberantă
+   sub 35 % ar putea opri inutil baza de producție, iar una optimistă ar putea întârzia
+   oprirea.
+
+   Semnalul de **sursă** (`ACLineStatus`) a fost, în schimb, impecabil — tranzițiile s-au văzut
+   instantaneu în ambele sensuri. De aici, direcția pentru pragurile definitive:
+
+   - **timpul pe baterie devine criteriul principal**, fiindcă se sprijină pe `ACLineStatus`;
+   - procentul rămâne doar plasă secundară, cu valoare mai mică și cu `confirmPolls` crescut
+     peste fereastra de zgomot (≥ 8 cicluri = 2 min);
+   - de evaluat `BatteryLifeTime` ca al treilea criteriu — în acest test a scăzut lin și
+     monoton, spre deosebire de procent. Există deja `shutdownAtRuntimeSeconds` în
+     `config.json`, momentan `0` = dezactivat.
 2. **Vârsta acumulatorilor.** Necunoscută. Pe cluster există deja criteriul de vârstă în
    testul lunar (`proxmox/cluster/ups/`); aici nu există nimic echivalent.
 3. **BIOS: *Restore on AC power loss*.** De verificat la prima intervenție fizică — altfel