Koko EnergyHub-sarjan ajan on ollut yksi hiljainen oletus, jota ei ole kunnolla testattu: mitä tapahtuu, kun sähkö menee poikki? Palvelin, joka ohjaa ja valvoo koko talon energiaa, on itse kiinni samassa verkkosähkössä. Jos se kaatuu hallitsemattomasti keskellä latausta tai lämmönohjausta, menetetään paitsi käyttöaika myös se, mikä tässä projektissa on aina ollut tärkeintä: hallittu tila, jäljitettävyys ja varma palautuminen.
Tämä osa kertoo UPS:n käyttöönotosta. Se on tarina siitä, miten yritin varmistaa, että lyhyt katko ei kaada mitään, pitkä katko sammuttaa palvelimen siististi, ja sähkön palatessa kaikki nousee itsestään takaisin pystyyn. Ja kuten näissä jutuissa yleensä, se on samalla tarina siitä, missä kohtaa oletukset pettivät — myös aivan lopussa, kun luulin olevani jo valmis.
Lopputulos etukäteen: sähköinen pohja, NUT-valvonta, BIOS-palautuminen ja sammutuslogiikka toimivat. Automaattinen sammutuspolku on toteutettu tilanteeseen, jossa guardilla on käytettävissään tuore ja yhtenäinen UPS-telemetria. USB/NUT-yhteyden häiriötilanteessa järjestelmä toimii tarkoituksella konservatiivisemmin eikä vielä sammuta konetta automaattisesti. Yksi tärkeä asia puuttuu edelleen: koko ketjua ei ole vielä todistettu yhdellä hallitulla päästä päähän -sähkökatkotestillä.
Miksi käyttöaika ei ole se tärkein asia
Kun kuluttaja ostaa UPS:n, myyntipuhe on yleensä käyttöaika: kuinka monta minuuttia kone pysyy pystyssä akun varassa. EnergyHubin tapauksessa se on toissijaista. Nykyinen kuorma on pieni — tilapäinen pistorasiamittaus näytti noin 30 wattia — ja valitun UPS:n akku riittäisi sillä kuormalla tunneiksi. NUT raportoi täydellä akulla arviolta reilut kolme ja puoli tuntia käyttöaikaa.
Tärkeämpää on, mitä tapahtuu katkon lopussa. Kun akku alkaa oikeasti tyhjentyä, palvelin pitää sammuttaa hallitusti ennen kuin virta loppuu kesken. Ja kun verkkosähkö palaa, koneen pitää käynnistyä itsestään ilman että kukaan on paikalla painamassa nappia.
Nämä kaksi asiaa — siisti sammutus ja automaattinen palautuminen — ratkaisevat sen, kestääkö järjestelmä pitkän katkon ilman ihmistä.
Valitsin selvästi ylimitoitetun laitteen tarkoituksella. UPS ei käy lähellä tehorajojaan, akkua jää runsaasti, ja myöhempiä verkkolaitteita voi lisätä ilman välitöntä uudelleenmitoitusta. Mitoituksen kanssa ei kannata kitsastella, kun kyse on koko järjestelmän selkärangasta.
Sähköinen pohja ensin, automaatio vasta sitten
Ensimmäinen sääntö, jonka opin nopeasti: testaa sähköinen perustoiminta ilman mitään ohjelmistoa.
Latasin UPS:n täyteen, kytkin palvelimen sen lähtöön ja katkaisin verkkosähkön noin minuutiksi. Kone pysyi käynnissä, UPS käyttäytyi odotetusti, ja verkkosähkön palatessa kaikki normalisoitui.
Tämä kuulostaa itsestäänselvältä, mutta se on tärkeä vaihe: se erottaa laiteviat ohjelmistovioista. Kun myöhemmin tuli ongelmia, tiesin että sähköinen pohja oli kunnossa ja saatoin keskittyä ohjelmistoon.
Samalla lyötiin lukkoon fyysinen periaate, josta ei jousteta: UPS:n tulo suoraan verkkosähköön, lähtö palvelimelle ja verkkolaitteille, USB palvelimeen.
Testien aikana käytin verkkosähkön hallittuun katkaisuun Shelly-pistorasiaa — ja siitä lisää alempana, koska juuri se opetti yhden tämän osan tärkeimmistä läksyistä.
Sivujuoni, joka olikin oikea vika: boottijärjestys
UPS-projektin kontrolloiduissa uudelleenkäynnistyksissä paljastui erillinen mutta kriittinen ongelma, jolla ei ollut mitään tekemistä UPS:n kanssa.
Docker saattoi käynnistyä ennen kuin verkolla oli toimiva reitti ja nimipalvelu kunnossa. Silloin kontit perivät puutteellisen resolver-tilan, ja Home Assistantissa näkyi DNS-virheitä esimerkiksi auton, sääaseman ja pörssisähkön rajapinnoissa.
Tämä on juuri sellainen vika, joka ei näy normaalikäytössä mutta iskee juuri silloin kun kone käynnistyy katkon jälkeen — eli pahimpaan mahdolliseen aikaan.
Korjaus oli laittaa boot odottamaan toimivaa reittiä ennen kuin verkkoriippuvaiset palvelut ja Docker käynnistyvät. Kontrolloitu uudelleenkäynnistys korjauksen jälkeen: reitti pystyssä ennen Dockeria, nimipalvelu käytettävissä konteille heti, ja palveluiden DNS-kyselyt kunnossa.
Ilman UPS-projektia en olisi käynnistänyt palvelinta kontrolloidusti niin monta kertaa, enkä olisi löytänyt tätä.
Joskus tärkein löytö on se, jota ei etsinyt.
NUT ja laite, joka valehtelee nimestään
Sähkötilan saa Linuxiin Network UPS Tools -ohjelmistolla eli NUTilla. UPS tunnistui USB-HID-laitteena ja NUT saatiin toimimaan standalone-tilassa niin, että se kuuntelee vain localhostia — UPS-ohjausta ei avata verkkoon.
Pieni mutta opettavainen yksityiskohta: lsusb:n oma laitetietokanta näytti laitteelle aivan väärän mallinimen.
Se ei ollut vika, vaan muistutus siitä, että työkalun tietokantanimi ei ole sama kuin laitteen itsensä kertoma malli. Todellinen malli varmistui HID-tuotetiedosta ja NUTin skannauksesta, ei lsusb:n arvauksesta.
Detaljit tästä ja kaikesta muusta NUT-asennuksesta ovat erillisessä teknisessä ohjeessa, johon viittaan tämän osan lopussa.
Perustilan muutos testattiin fyysisesti katkaisemalla verkkosähkö: UPS siirtyi nopeasti akulle ja NUT raportoi on battery -tilan, ja palautuksen jälkeen tila palasi normaaliksi.
Opetus oli myös käytännöllinen: UPS:n OL/OB-tilatieto on luotettava ensisijainen signaali, kun taas esimerkiksi jännitelukema voi päivittyä hitaammin eikä sitä kannata yksin käyttää sähkökatkon tilan määrittämiseen.
Kaksi kertaa, kun laite ei tehnyt mitä käskettiin
Tässä kohtaa alkoi mielenkiintoinen osuus. Testaus paljasti kaksi laite- ja ohjelmistopoikkeamaa, jotka muuttivat koko lähestymistapaani.
Ensin yritin asettaa UPS:n natiiveja kynnysarvoja — sitä rajaa, jolla laite itse ilmoittaa akun olevan lopussa.
Kirjoitus epäonnistui hiljaisesti.
Kun yritin asettaa raja-ajaksi 600 sekuntia, laitteeseen jäi luku 88. Se vastaa 8-bittistä käärimistä: 600 jaettuna 256:lla jättää jäännökseksi 88.
Toinen kynnys, akun varausprosentti, ei muuttunut lainkaan — yritin arvoa 5, mutta se pysyi kymmenessä. Eikä ”turvallinen palautus” johonkin muuhun arvoon olisi auttanut: sama muunnos voisi tehdä 300:sta arvon 44.
Johtopäätös oli selvä: tämän UPS/NUT-yhdistelmän kirjoitettavia natiivikynnyksiä ei käytetä ohjaussignaalina. Laitteen oma ”akku loppu” -raja toimii korkeintaan neuvoa-antavana varoituksena. Varsinainen sammutuspäätös tehdään omassa testattavassa logiikassa.
Toinen poikkeama liittyi viiveisiin. NUT raportoi aluksi hyvin pieniä sammutus- ja käynnistysviiveitä. CyberPowerin kanssa nämä pitää auditoida mallikohtaisesti, koska liian pienet arvot voivat johtaa siihen, että UPS katkaisee lähdön ennen kuin kone ehtii varmasti sammua.
Viiveet määritettiin siksi turvallisesti konfiguraation kautta eikä samassa laitteen kirjoituspolussa, jonka epäluotettavuus oli juuri havaittu.
Molemmista opeista syntyi sama periaate:
turvallisuuden kannalta kriittinen päätös pitää perustaa sellaiseen logiikkaan, jonka käyttäytyminen voidaan itse lukea, testata ja todentaa.
Host guard — ensin tarkkailija, sitten rajattu sammutusvalta
Koska laitteen omiin rajoihin ei voinut luottaa, tein erillisen valvontakomponentin, host guardin.
Se lukee NUTia viiden sekunnin välein ja tekee sammutuspäätöksen omilla kriteereillään. Alkuperäinen perusmalli oli yksinkertainen: jos ollaan akulla ja jäljellä oleva käyttöaika alittaa kymmenen minuuttia tai akun varaus laskee alle viiteen prosenttiin, ja tämä toistuu kolmella peräkkäisellä mittauksella, päätös laukeaa.
Yksittäinen piikki ei siis riitä, ja verkkosähkön palautuminen nollaa tilan.
Ensimmäisessä vaiheessa guard oli tarkoituksella vain havaitsija. Se kirjasi olisin sammuttanut -päätöksiä mutta ei saanut tehdä mitään fyysistä. Näin kynnyslogiikka voitiin testata positiivisilla ja negatiivisilla kokeilla ilman riskiä siitä, että väärä päätös sammuttaisi palvelimen.
Sen jälkeen toteutusta vietiin pidemmälle.
Nykyisessä tuotantoversiossa automaattinen sammutuspolku on sallittu vain silloin, kun guardilla on käytössään tuore ja yhtenäinen NUT-telemetria. Ennen sammutuspäätöstä guard revalidoi UPS:n tilan, syöttöjännitteen, akun jäljellä olevan käyttöajan ja varauksen sekä oman sammutusketjunsa kriittisiä komponentteja.
Vasta tämän jälkeen se muodostaa sammutusluvan ja johtaa hallittuun hostin alasajoon. Myöhäinen shutdown-hook huolehtii UPS:n oman lähtötoiminnon käynnistämisestä vasta hostin sammutusketjun loppuvaiheessa.
Tärkein suunnitteluperiaate ei kuitenkaan muuttunut:
fail-safe on tärkeämpää kuin aggressiivinen sammutus.
Jos USB/NUT-yhteys katoaa kesken sähkökatkon, guard pystyy jatkamaan tilanteen arviointia viimeisestä varmasta akkutilasta, mutta tämä communication-loss-haara ei vielä saa käynnistää varsinaista sammutusta automaattisesti.
Tämä on tietoinen turvallisuusraja. Pitkä USB-häiriö juuri pitkän sähkökatkon aikana on edelleen avoin vikatilanne, eikä sitä peitetä väittämällä kokonaisuutta valmiiksi.
BIOS, joka ei käynnistänyt konetta
Recovery-ketju kaatuu, jos kone ei käynnisty itsestään kun UPS palauttaa lähdön.
Testasin tämän fyysisesti — ja ensimmäinen koe epäonnistui.
Sammutin koneen hallitusti, irrotin ja palautin virran, eikä kone käynnistynyt itsestään.
Vika oli BIOS-asetuksessa.
Muutin sen tilaan, jossa kone käynnistyy automaattisesti virran palatessa, ja toistin kokeen. Nyt kone nousi heti pystyyn AC-syötön palautuessa.
Tämä on juuri sellainen asia, jota ei voi olettaa toimivaksi. Oletusasetus tässä koneessa ei käynnistänyt sitä uudelleen, ja ilman fyysistä koetta olisin luullut recovery-ketjun olevan kunnossa, kun se ei ollut.
BIOS-asetus on myös hyvä esimerkki tiedosta, jota tavallinen tiedostovarmistus ei voi palauttaa. Se elää koneen firmware-asetuksissa ja pitää siksi dokumentoida sekä testata erikseen.
Shelly, joka jätti pulaan
Muistatko sen Shelly-pistorasian, jolla katkaisin verkkosähköä testeissä?
Se osoittautui erinomaiseksi testivälineeksi mutta paljasti samalla, miksi se on huono tuotannon riippuvuus.
Sammutustestissä ideana oli katkaista UPS:n tulo Shellyllä, antaa UPS:n katkaista lähtönsä, ja sitten palauttaa verkkosähkö Shellyn kautta nähdäkseni käynnistyykö kaikki.
Lähdön katkaisu onnistui odotetusti. Verkkosähkö palasi noin minuutin kohdalla — mutta Shelly itse jäi tavoittamattomaksi juuri silloin kun sitä olisi tarvittu ohjaamaan.
Verkkosähkö palautettiin lopulta fyysisesti ilman Shellyä, ja kaikki laitteet palautuivat normaalisti katkon jälkeen.
Opetus on kirkas:
älä koskaan rakenna UPS:n palautumista verkkoriippuvaisen älypistorasian varaan.
Shelly sopii testiin, ei kriittiseksi sarjaelementiksi UPS:n syöttöketjuun. Verkkokatkon jälkeen sellainen laite voi olla juuri se osa, joka ei vastaa.
Vika, jonka virheilmoitus valehteli
Sammutustestin jälkeen tuli tämän osan hankalin ongelma, ja se ansaitsee tulla kerrotuksi, koska sen virheilmoitus johti täysin harhaan.
Kun UPS oli katkaissut lähtönsä ja verkkosähkö palautettu, UPS:n oma sähköinen lähtö palasi normaaliksi — näyttö vahvisti verkkosähkön ja jännitteet olivat kunnossa.
Mutta NUTin USB-yhteys laitteeseen jäi jumiin.
Lokin yhteenveto sanoi, että oikeudet eivät riitä ”mihinkään laitteeseen”.
Se oli väärä johtolanka.
Tarkistin oikeudet: laite näkyi USB-väylässä, laitesolmun omistaja ja oikeudet olivat kunnossa, ja NUT-käyttäjä pystyi lukemaan sen. Ajuripalvelun uudelleenkäynnistys ei auttanut — joka kierroksella tuli ilmoitus, ettei sopivaa HID-UPS-laitetta löydy.
Ratkaisu löytyi ajamalla ajuri debug-tilassa.
Silloin näkyi todellinen syy: NUT ei saanut luettua laitteen USB-tuotetietoja lainkaan, vaikka muut työkalut lukivat ne normaalisti. Valmistaja, tuote ja sarjanumero näkyivät NUTille tyhjinä.
Koska konfiguraatiossa oli sarjanumerosuodatin, tyhjä sarjanumero johti siihen, että laite hylättiin. Ongelma ei siis liittynyt Unix-oikeuksiin lainkaan.
Lopun oikeusviesti oli vain harhaanjohtava yhteenveto.
Korjaus oli fyysinen: irrotin UPS:n USB-kaapelin noin kymmeneksi sekunniksi ja kytkin sen takaisin.
Laite enumeroitui uudelleen, tuotetiedot palautuivat, ja NUT löysi UPS:n normaalisti.
Tämä oli diagnostisesti ratkaisevaa. Se todisti, että kyse oli USB/HID-tilasta, ei rikkoutuneesta UPS:stä. Pelkkä ohjelmiston uudelleenkäynnistys ei palauttanut tilaa — tarvittiin fyysinen USB-uudelleenenumerointi.
Tämä havainto ei lopulta estänyt koko automaattisen sammutuspolun toteuttamista, mutta se määritti sille tärkeän turvallisuusrajan.
Tuoreella ja varmennetulla UPS-telemetrialla automaattinen sammutus voidaan sallia. Jos USB/NUT-yhteys katoaa kesken sähkökatkon, järjestelmä ei vielä saa tehdä samaa päätöstä automaattisesti.
Ja lopuksi vika, jota en osannut odottaa: varmuuskopio ei aluksi kattanut mitään tästä
Kun tuotantotila oli ensimmäisen testikierroksen jälkeen kunnossa — NUT pystyssä, guard ensimmäisessä tarkkailutilassaan ja BIOS testattu — halusin varmistaa vielä yhden asian: jos Lenovo pitäisi asentaa tyhjästä, palautuisiko tämä koko UPS-ketju?
Aiemmissa osissa oli rakennettu palautuspaketti ja testattu koko järjestelmän palautusta tyhjälle levylle, joten oletin UPS-osan kulkevan siinä mukana.
Ei kulkenut.
Kävin läpi oikean varmuuskopion sisällysluettelon ja tarkistin UPS:n kriittisiä tiedostoja. Guard, sen systemd-yksikkö, NUT-konfiguraatiot ja sammutukseen liittyvät host-tason tiedostot olivat kokonaan poissa.
Itse varmuuskopio oli täysin terve. Se ajautui ajastetusti, paketti syntyi ja tarkistussumma täsmäsi.
Ongelma ei ollut mekanismissa vaan kattavuudessa.
Joka öinen-backup oli alun perin suunniteltu varmuuskopioimaan EnergyHubin sovellustason data — Home Assistant, Node-RED, tietokannat ja Grafana. UPS ja NUT taas elivät koneen ja käyttöjärjestelmän tasolla, esimerkiksi /etc-, /usr/local– ja systemd-rakenteissa.
Looginenkin raja on puute, jos se huomataan vasta palautustilanteessa.
Silloin muu järjestelmä olisi voinut nousta pystyyn ja UPS-suojaus jäädä rakentamatta — huomaamatta, kunnes seuraava sähkökatko muistuttaisi siitä.
Havainto ei jäänyt korjauslistalle. EnergyHubin nykyinen V3B-varmistus ottaa mukaan myös UPS/NUT-kokoonpanon ja sen palautumiseen tarvittavaa host-tason tilaa.
Myöhemmässä oikeassa varmistusajossa mukanaolo myös validoitiin. Arkistosta löytyivät muun muassa host guard, UPS:n shutdowniin liittyvä hook, guardin systemd-yksikkö sekä NUTin keskeiset konfiguraatiot kuten nut.conf, ups.conf, upsd.conf, upsd.users ja upsmon.conf.
Tämä ei silti tee dokumentaatiosta tarpeetonta.
Kirjoitin UPS:n koko kokoonpanon, toimintaperiaatteet, tiedostopolut ja palautusvaiheet myös erilliseen tekniseen ohjeeseen. Se toimii toisena palautusreferenssinä tilanteessa, jossa asetukset pitää rakentaa tyhjälle koneelle tai tarkistaa, mitä backupista kuuluu palauttaa.
Ja ainakin yksi asia jää aina tiedostovarmistuksen ulkopuolelle: BIOSin After Power Loss = Power On -asetus.
Backup ja palautusohje eivät siis kilpaile keskenään. Molempia tarvitaan.
Mitä on valmiina ja mitä ei
Tutkimuksen jälkeen palvelin ja verkkolaitteet jäivät UPS:n taakse, UPS:n tulo suoraan verkkosähköön ilman Shellyä. NUT, verkkoyhteys, kontit ja nimipalvelu ovat normaalissa tuotantokäytössä.
Rehellinen tilanne on nyt tämä.
Valmiina ovat UPS:n sähköinen perustoiminta, NUT-valvonta ja telemetria, akkukäytön tunnistus, BIOSin automaattinen käynnistyminen, boottijärjestyksen korjaus sekä host guardin automaattinen sammutuspolku silloin, kun käytössä on tuore ja yhtenäinen UPS-telemetria.
Myös UPS/NUT-kokoonpano kuuluu nykyiseen EnergyHubin V3B-varmistukseen.
Kaikki ei silti ole suljettu.
USB/NUT-kommunikaation katoamisen aikana guard ei vielä saa käynnistää automaattista sammutusta. Lisäksi ennen kuin koko UPS-ketjua voi kutsua päästä päähän todennetuksi, tarvitaan yksi hallittu tuotantotason koe:
- verkkosähkö katoaa
- UPS siirtyy akulle
- akku tai käyttöaika saavuttaa sammutusrajan
- host sammuu hallitusti
- UPS:n lähtö katkeaa vasta sammutuksen jälkeen
- verkkosähkö palaa
- UPS:n lähtö palautuu
- Lenovo käynnistyy BIOS-asetuksen perusteella
- verkko ja Docker-palvelut nousevat oikeassa järjestyksessä
- NUT ja EnergyHub palaavat terveeseen tuotantotilaan.
Toteutettu ei tarkoita samaa kuin päästä päähän todennettu.
Tämä ero on tärkeä. Automaattinen sammutuspolku on olemassa, mutta koko sähkökatko–sammutus–UPS–palautuminen-ketju ei ole vielä CLOSED.
Opit tästä osasta
Tämän projektin tärkeimmät opit eivät lopulta liity akun kapasiteettiin.
- Testaa sähköinen pohja ennen automaatiota, jotta laite- ja ohjelmistoviat eivät sekoitu toisiinsa.
- Älä tee turvallisuuspäätöstä kirjoitettavan UPS-kynnysarvon perusteella ennen kuin olet todentanut sen käyttäytymisen omalla laitteellasi.
- Fail-safe on tärkeämpää kuin aggressiivinen sammutus.
- Testaa BIOSin virranpalautuskäyttäytyminen fyysisesti.
- Älä rakenna recovery-ketjua verkkoriippuvaisen älylaitteen varaan.
- Kun virheilmoitus tuntuu oudolta, mene yksi kerros syvemmälle — tässä ”oikeudet eivät riitä” oli täysin väärä johtolanka.
- Varmuuskopio ei kata sitä, mitä sitä ei ole suunniteltu kattamaan. Tarkista arkiston sisältö, älä pelkkää onnistumisviestiä.
- Ja ennen kaikkea: toteutettu, testattu osittain ja päästä päähän todennettu ovat kolme eri tilaa.
Kirjoitin NUT + CyberPower -asennuksesta erillisen teknisen ohjeen, jossa käyn läpi vaihe vaiheelta USB-tunnistuksen, konfiguraation, viiveiden auditoinnin, host guardin fail-safe-periaatteet sekä kinkkisen USB/HID-descriptorivian diagnostiikan ja korjauksen.
Ohje toimii samalla palautusreferenssinä, vaikka UPS/NUT-tiedostot kuuluvat nykyisin myös EnergyHubin V3B-varmistukseen. Backup kertoo, mitä palautetaan; ohje kertoo, miten kokonaisuuden pitäisi toimia ja mitä pitää todentaa käsin.
Kun UPS-ketju oli tässä tilassa — merkittävä osa toteutettuna mutta yksi päästä päähän -todiste edelleen puuttuvana — huomasin miettiväni samaa kysymystä laajemmin. Tämän osan jokainen yllätys, boottijärjestyksestä siihen ettei varmuuskopio aluksi kattanutkaan UPS-tiedostoja, oli sama oivallus pienoiskoossa: se mitä luulin valmiiksi, ei aina ollut sitä, ja se mitä en ollut testannut loppuun asti, saattoi olla juuri se kohta joka pettäisi katkon hetkellä.
Kuinka moni muu järjestelmän osa mahtoi olla tuollaisessa tilassa — muistiini merkitty valmiiksi, mutta todistamatta? Ennen lämmityskautta halusin siihen rehellisen vastauksen. Seuraavassa osassa teetän koko EnergyHubille puhtaan auditoinnin, joka ei saa muuttaa mitään, ja selvitän mikä on todella valmis, mikä vain näyttää siltä ja mikä on kriittistä juuri nyt.