De ale UPS-urilor

Eaton folosesc unii (Baker Hughes) in medii industriale de ceva vreme (prin 2012 aveau sigur, poate si mai devreme). Ma gandesc ca nu pot fi chiar atat de nasoale.
 
Parcă Eaton i-au înghițit pe cei de la Best Power. Sau s-or fi rebrănduit... Oricum respect tancurile celor de la Best Power. :notworthy:
 
Prima mică problemă, crănțăne enervant o sursă în comutație când e alimentată din UPS-ul ăsta (pe baterie). Că nu e sinus :(. UPS-uri sinus n-am găsit de dimensiunile astea.
 
Luat un Legrand în ideea că are soft de management ce rulează pe Linux. Ce n-au specificat e că soft-ul e pe 32 de biți și n-am reușit să-l fac să vadă UPS-ul decât dintr-un Debian 7 pe 32 de biți. Așa că acuma rulez pe router un VM dedicat exclusiv pentru asta, iar script-ul de shutdown face ssh către vreo 4 alte device-uri (unul dintre ele fiind chiar host-ul de sub el) unde rulează un alt script de shutdown... :damn:

Din ce-am testat, merge decent (ținând cont că soluția e făcută pe genunchi). Mă interesa în primul rând să nu alimenteze device-urile imediat după ce revine curentul pentru a da ceva timp bateriilor să se încarce. Probabil mai există șansa unor race conditions, da' cred (sper!) că am reușit să reduc semnificativ șansele să pierd date din cauză de pană de curent. Să vedem.
 
Da, ce simplu ar fi dacă ar folosi producătorii standardul USB de HID Power Devices (făcut special pentru UPS and stuff). Da' nu, fiecare cu porcăria lor de interfață, drivere și aplicație, că doar așa ținem utilizatorii captivi.
 
Last edited:
Dacă aș fi avut mai mult timp, aș fi încercat. Cu Cyberpower-ul anterior am folosit NUT, dar a trebuit să trimit debug logs pe mailing list pentru a găsi o anumită setare de driver pentru că altfel, după o pană de curent, repornea automat după un anumit interval de timp, indiferent că avea sau nu curent.
 
După un nr. variabil de săptămâni văd mesajul ăsta în logul aplicației:
Communications between UPS and Server lost
Click to expand...
și asta în logul sistemului de operare:
Jul 25 16:56:53 e3845 kernel: usb 1-1: reset low-speed USB device number 2 using xhci_hcd
Jul 25 16:56:52 e3845 kernel: usb 1-1: reset low-speed USB device number 2 using xhci_hcd
Jul 25 16:56:51 e3845 kernel: usb 1-1: reset low-speed USB device number 2 using xhci_hcd
Jul 25 16:56:49 e3845 kernel: usb 1-1: reset low-speed USB device number 2 using xhci_hcd
Click to expand...
Singurul mod de a restabili comunicarea e de a scoate cablul USB din router, lăsat deconectat câteva minute și apoi băgat cablul înapoi. Problema e că eu sunt remote și nu prea am cum să fac asta. Am încercat cu restart la router, dar fără succes.
Am încercat
echo -n "0000:00:14.0" | tee /sys/bus/pci/drivers/xhci_hcd/unbind
Click to expand...
si apoi
echo -n "0000:00:14.0" | tee /sys/bus/pci/drivers/xhci_hcd/bind
Click to expand...
în ideea că va tăia alimentarea, dar tot nu vrea.

Aveți vreo idee cum aș putea simula unplug/plug back? Sau eventual există ceva gadget pe care aș putea să-l inserez pe firul cablului USB și să întrerup alimentarea remote?
 
Până la urmă am intercalat o priză ocoșă (pe care am pus Tasmota) pe alimentarea UPS-ului și voi face periodic power off; delay 10m; power on. E o soluție demnă de Marius95, dar ar trebui să meargă cât timp inițiez manual power off înainte să pierd comunicarea cu UPS-ul.
 
O sa-ti fu*i bateriile.
Mai bine vezi daca iti merge uhubctrl pe portul UPS-ului. Dar cel mai bine, RS232 in loc de USB. Ala n-are moarte.
 
You must log in or register to reply here.
Back
Top