Era doar in handoff (care se sterge) si in mesajul commit-ului 03d3045. Acum e
la vedere, langa celelalte: un NEINREGISTRAT de la -Mode Status poate fi o
eroare tranzitorie de interogare, nu un task disparut.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RRyaDj39hPQ89SZS6URRpS
Al doilea test cu scoaterea din priza (16:08:03 -> 16:23:04, 15,0 min).
Autonomia tot nu e masurata - gauge-ul a coborat doar 90% -> 80% - dar testul
raspunde la intrebarea "pe ce criteriu se opreste serverul".
Trei constatari, toate cu date in document:
(a) Procentul nu are panta pe care sa se poata extrapola: imobil la 90% timp de
patru minute, apoi 0,8, apoi 2 puncte/minut. Extrapolarea de la minutul 8
dadea 220 de minute pana la pragul de 35%, cea de la minutul 14 dadea 22.
(b) Saltul de la revenirea curentului se reproduce la aceeasi valoare (65%) in
ambele teste, dar NU poate opri serverul: blocul de decizie e inauntrul
ramurii if ($r.OnBattery), iar saltul se produce dupa revenire. Corectez
aici ce scrisesem in commit-ul anterior - riscul nu e oprirea inutila, ci
opusul: gauge-ul ramane optimist cat timp bateria chiar se descarca.
(c) BatteryLifeTime e numaratoare inversa, nu masuratoare: 901 secunde scurse,
872 scazute din estimare (raport 0,97, verificat la trei puncte). Nu aduce
nimic peste cronometrul propriu al scriptului, deci shutdownAtRuntimeSeconds
ramane dezactivat - contrar directiei propuse dupa primul test.
Concluzie: timpul pe baterie ramane criteriul principal, procentul ramane plasa
secundara grosiera.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RRyaDj39hPQ89SZS6URRpS
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
Lantul de protectie are doua jumatati. Prima - "UPS-ul chiar raporteaza trecerea
pe baterie?" - e deja dovedita de perechile de evenimente Kernel-Power 105 de la
panele reale din 2026. A doua - decizie, alerta, oprirea curata a Oracle - nu
avea cum sa fie exercitata decat asteptand o pana.
Acum monitorul accepta un SIMULARE.json care suprascrie citirea de alimentare.
Doua garzi, ca un fisier uitat sa nu opreasca serverul pe date inventate:
"expira" e obligatoriu si e sters automat la depasire, iar oprirea e in gol daca
nu se cere explicit "dryRun": false. Cat e activa, fiecare ciclu scrie WARN in
log si -Mode Status o afiseaza.
test-battery.ps1 conduce simularea si urmareste logul; sterge fisierul si daca e
intrerupt. Cu -ConfirmReal 'DA-OPRESTE-SERVERUL' devine repetitie reala pentru o
fereastra de mentenanta - singurul mod de a masura cat dureaza shutdown immediate
pe baza de productie, informatie de care depinde alegerea pragurilor.
Validat in gol pe 27.08.2026: detectie la 15:36:09 + email de pana, apoi exact
trei cicluri de confirmare, declansare pe pragul de 35% la 15:36:40 si secventa
parcursa integral. Oracle a ramas Running.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RRyaDj39hPQ89SZS6URRpS
ViewPower nu putea dialoga cu acest UPS: 5777 de "QPI return(NAK" si zero
citiri reusite in fereastra 6-10 august, pentru ca UPS-ul vorbeste HID Power
Device standard, nu dialectul text Voltronic. Serviciile au fost dezactivate
pe 10.08.2026 la 22:34, lasand serverul fara nicio alertare 17 zile. Nici
inainte nu exista: emailReceivers = 0, iar excuteProgram era gol, deci Oracle
nu era oprit curat oricum.
UPS-ul comunica insa perfect cu Windows pe canalul HID - dovedit de perechile
de evenimente Kernel-Power 105 la panele reale din 2026.
Monitorul nou citeste GetSystemPowerStatus, acelasi semnal pe care il foloseste
Windows pentru propria actiune la baterie critica. Alerteaza pe email la
trecerea pe baterie, la revenirea curentului si cand UPS-ul nu mai comunica -
cazul care a trecut neobservat. Opreste curat listenerul, apoi instanta cu
shutdown immediate, apoi Windows-ul, inaintea pragului brutal de 20% al
Windows-ului.
Ruleaza ca task programat sub SYSTEM, cu AllowStartIfOnBatteries si
DontStopIfGoingOnBatteries - fara ele Windows ar fi oprit taskul exact cand
serverul trece pe baterie.
Validat pe 27.08.2026: citire, email, secventa de oprire in dry-run si
pierderea comunicatiei (alerta la exact 8 cicluri, apoi revenire). Pragurile
de 10 min / 35% sunt conservatoare, nu masurate - testul de autonomie reala
ramane de facut.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RRyaDj39hPQ89SZS6URRpS
