set-praguri.ps1 schimba pragurile de oprire fara sa atinga parola SMTP si
reporneste taskul, pentru ca ups-monitor.ps1 citeste configuratia o singura
data, la pornirea buclei.
trace-baterie.ps1 scrie o citire la fiecare 20 s intr-un CSV local, iar
start-trace.ps1 il inregistreaza ca task programat sub SYSTEM. Local si
detasat, pentru ca intr-o pana reala reteaua cade odata cu curentul daca
switch-ul nu e pe UPS: sesiunea SSH devine oarba si emailurile esueaza, deci
CSV-ul de pe server ramane singura sursa de date. Taskul are aceleasi
AllowStartIfOnBatteries / DontStopIfGoingOnBatteries ca monitorul - fara ele
Windows l-ar opri exact cand incepe ce vrem sa masuram.
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
