Olen kirjoittanut tässä sarjassa yli kahdenkymmenen osan verran siitä, miten kotini energianhallintajärjestelmä on rakentunut pala palalta: aurinkosähkön ohjaus, lämpöpumppu, sähköauton lataus, seinäpaneeli, datan laatu, palautustesti. Jokainen osa on kuvannut yhden asian sillä hetkellä kun se oli valmis — tai ainakin kun luulin sen olevan valmis.
Ja juuri se on tämän osan aihe. Ennen kuin lämmityskausi alkaa toden teolla, halusin tietää yhden asian mahdollisimman rehellisesti: missä järjestelmä oikeasti menee juuri nyt? Ei mitä muistan, ei mitä olen blogiin kirjoittanut, vaan mitä koneella todella pyörii — ja voinko luottaa siihen dataan, jonka perusteella seuraava kehitysvaihe pitäisi rakentaa.
Vastaus yllätti minut monin tavoin.
Miksi en voinut vain katsoa muistiinpanojani
Kun projekti kasvaa tarpeeksi suureksi, muistiinpanot alkavat elää omaa elämäänsä. Minulla on TODO-listoja, blogiluonnoksia, keskusteluhistoriaa ja arkkitehtuuridokumentteja — ja ne kaikki kuvaavat jotain hetkeä menneisyydessä. Osa on kuukausien takaa. Kun sama asia mainitaan kolmessa eri paikassa hieman eri sanoin, on aivan liian helppo uskoa, että jokin on yhä kesken, vaikka se olisi tehty jo viikkoja sitten. Tai päinvastoin: uskoa jonkin olevan kunnossa, koska ”muistan tehneeni sen”.
Ohjelmistopuolella tälle on nimi: muisti ajautuu erilleen todellisuudesta. Dokumentaatio vanhenee hiljaa, koska koodi muuttuu nopeammin kuin sitä kuvaavat tekstit.
Siksi tein jotain, mitä suosittelen kenelle tahansa, jonka kotiautomaatio on kasvanut yksittäisistä skripteistä kokonaiseksi järjestelmäksi: teetin puhtaan tila-auditoinnin, joka ei saanut muuttaa mitään.
”Read-only” — katso, älä koske
Auditointi ajettiin tarkoituksella niin, ettei se koskenut mihinkään. Ei muutettu tiedostoja, ei ajettu tilaa muuttavia testejä, ei käynnistetty palveluita uudelleen. Pelkkää lukemista: mitä koodia repositoriossa on, mitä versiota siitä oikeasti pyörii muistissa, mitkä palvelut ovat käynnissä ja mitä lokit kertovat.
Tämä kuulostaa itsestäänselvältä, mutta ero on tärkeä. Jos alat ”vähän vain korjata” samalla kun kartoitat tilannetta, et enää tiedä, mikä oli rikki ennen sinua ja mikä sinun jäljiltäsi. Tilannekuvan ottaminen ja korjaaminen ovat kaksi eri työtä, eikä niitä pidä sekoittaa.
Auditoinnin tärkein periaate oli tämä:
”Koodi löytyy” ei tarkoita samaa kuin ”valmis”.
Tästä tuli koko harjoituksen selkäranka. On iso ero sillä, että jokin on kirjoitettu, että se on otettu käyttöön, ja että sen on todistettu toimivan oikeasti. Aivan liian usein olin merkinnyt asian valmiiksi heti kun koodi oli olemassa — testaamatta sitä loppuun asti oikeassa tilanteessa.
Otin käyttöön karkean todistusasteikon. Vahvin todiste on live-testi tuotannossa. Sitä seuraa tilanne, jossa ajossa oleva versio ja repositorio täsmäävät. Sitten pelkkä käyttöönotto, sitten pelkkä committi, sitten dokumentoitu suunnitelma — ja heikoimpana pelkkä muisti tai blogimerkintä. Kun ristiriita tuli, vahvempi todiste voitti aina heikomman.
Ensimmäinen yllätys: olin jäljessä omasta työstäni
Suurin löydös oli, että moni asia oli valmiimpi kuin muistin.
Iso osa datan tallennuksen ja auditoinnin putkesta oli jo otettu käyttöön, vaikka listoillani se näytti keskeneräiseltä. Sähköauton latauksen määräaikatoiminto — se, josta kirjoitin osassa 21 — oli auton pilvipalvelun katkoksen aikana jo elävästi todennettu toimivaksi. Varasähköjärjestelmän valvontaa oli rakennettu tuotantoon. Seinäpaneelin mobiiliversio oli uudempaa versiota kuin blogissa väitin. Kotona/poissa-perustila oli käytössä.
Kävin läpi listan vanhoja ”auki”-väitteitä, ja rivi toisensa jälkeen todellisuus oli: tehty, otettu käyttöön, toimii. Se on tietysti mukava ongelma. Mutta se on silti ongelma — koska jos et tiedä olevasi valmis, saatat tehdä saman työn toiseen kertaan tai jättää seuraavan askeleen ottamatta.
Tämä on kotiprojektien hiljainen ansa. Kun teet kaiken itse iltaisin ja viikonloppuisin, tekemisen tahti on nopeampi kuin ehdit kirjata. Blogi laahaa väistämättä perässä.
Toinen yllätys: kriittisin puute löytyi datan merkityksestä
Kolikon toinen puoli oli epämukavampi. Kun kymmenet vanhat kohdat paljastuivat jo tehdyiksi, ne peittivät alleen ne harvat asiat, jotka olivat oikeasti kesken ja tärkeitä. Kohina piilotti signaalin.
Ja lämmityksen kohdalla kysymys osoittautui vielä perustavammaksi kuin ensin ajattelin.
Datan pitää olla paitsi teknisesti ehjää myös merkitykseltään oikeaa. Aiemmassa auditoinnissa löytyi vanhasta tallennuspolusta aikaleimavirhe, jossa luku kasvoi liian suureksi esitettäväksi tarkasti. Uudempi datapolku ei kärsi samasta ongelmasta, mutta löydös oli hyvä muistutus siitä, ettei pitkä historia ole automaattisesti käyttökelpoista historiaa.
Nyt Thermian kohdalla auditointi on mennyt vielä yhtä tasoa syvemmälle. Käyn Modbus-tietoja rekisteri rekisteriltä valmistajan dokumentaatiota vasten. Osa aiemmin kerätyistä arvoista on voinut olla teknisesti aivan oikeita numeroita mutta väärin tulkittuja. Esimerkiksi pumpun tila ei välttämättä kerrokaan siitä kiertovesipumpusta, jonka ensin kuvittelin sen kertovan, vaan lämpöpumpun sisäisestä toiminnosta.
Tämä muuttaa periaatteen hyvin selväksi: vanhaa lämmitysdataa ei käytetä mallin opettamiseen vain siksi, että sitä on paljon. Jokaisen mallille tärkeän suureen lähde, rekisteri, yksikkö ja merkitys pitää ensin todentaa. Vanhat m_hp_*-nimet eivät itsessään ole todiste siitä, että tieto tarkoittaa sitä mitä nimi väittää.
Tämä on ehkä koko auditoinnin tärkein löydös. Virheellinen datapiste näyttää Grafanassa aivan yhtä uskottavalta kuin oikea. Jos sen päälle rakentaa hienon optimointialgoritmin, lopputulos voi olla matemaattisesti täsmällinen ja silti fyysisesti väärä.
Varasähkö: valvonta ei vielä ole sama asia kuin todistettu palautuminen
Varasähköjärjestelmän valvonta on pitkällä, mutta yhtä asiaa ei pidä kuitata pelkillä tilatiedoilla: koko fyysinen ketju pitää todistaa sähkökatkosta hallittuun alasajoon, siitä sähkön palaamiseen ja järjestelmän itsenäiseen käynnistymiseen.
Juuri tällaisessa testissä kiinnostavaa ei ole se, näkyykö UPS ohjelmistolle, vaan mitä tapahtuu koko talon ohjausketjulle silloin kun verkkosähkö oikeasti katoaa. Nousevatko palvelut takaisin oikeassa järjestyksessä? Jääkö jokin ohjaus epäselvään tilaan? Palaako järjestelmä turvalliseen lähtötilaan ilman käsin tehtäviä temppuja?
Kaikki palaset voivat näyttää erikseen toimivilta ja kokonaisuus silti epäonnistua. Siksi fyysinen testi on tässä vahvempi todiste kuin yksikään vihreä statusruutu.
Varmuuskopiointi eteni — mutta palautus ratkaisee edelleen
Kirjoitin osassa 23 siitä, ettei varmuuskopio ole varmuuskopio ennen palautustestiä. Auditoinnin jälkeen tämä osa järjestelmästä on edennyt selvästi.
EnergyHubista syntyy salattu varmistusartefakti, jonka eheys tarkistetaan. Kodin ulkopuolella on salattu kopio Google Drivessa, ja sen rinnalle on rakennettu erillinen paikallinen kopio omalle USB-levylle. Varmistusketjun onnistumista seurataan myös erillisellä markerilla, joka päivittyy vasta kun koko normaali ketju on todella onnistunut.
Se on paljon vahvempi tilanne kuin auditointia aloittaessa. Mutta yksi lause ei muutu:
Tarkistussumma todistaa, että tiedosto on sama. Palautus todistaa, että sillä voi rakentaa järjestelmän takaisin.
Siksi salatun varmistuksen purku ja oikea palautusharjoitus ovat edelleen oma todennettava kokonaisuutensa.
Mitä ”valmis” oikeastaan tarkoittaa
Auditoinnin hyödyllisin sivutuote oli, että jouduin määrittelemään täsmällisesti, mitä eri tilat tarkoittavat. Aiemmin merkitsin asioita valmiiksi vähän fiiliksen mukaan. Nyt erottelen:
Jokin on valmis vasta kun se on toteutettu, otettu käyttöön ja riittävästi todennettu nykyisestä ajopolusta. Se voi olla toteutettu mutta todentamatta, jolloin koodi ja käyttöönotto ovat kunnossa, mutta kohdennettu tosielämän testi puuttuu. Se voi olla osittainen, jolloin osa ketjusta on tehty mutta luvattu kokonaisuus ei ole valmis. Se voi olla auki, jolloin toteutusta ei ole tai tunnettu bugi on aktiivinen. Ja lopulta jokin voi olla tuntematon — auditoinnin lukuoikeus ei yksin riittänyt sanomaan, tarvitaan lisätesti.
Datan kohdalle tarvitsen käytännössä vielä yhden kysymyksen: onko merkitys varmennettu? Arvo voi tulla moitteettomasti Modbusista, tallentua InfluxDB:hen ja piirtyä Grafanaan, mutta olla silti käyttökelvoton ohjaukselle, jos en tiedä varmasti mitä rekisteri fyysisesti tarkoittaa.
Tämä kuulostaa byrokratialta, mutta se on käytännössä hyödyllisin muutos koko projektin hallinnassa. ”Toteutettu mutta todentamatta” on rehellisempi ja hyödyllisempi tila kuin joko ”tehty” tai ”kesken”. Se kertoo tarkalleen mitä puuttuu: ei välttämättä koodia, vaan todiste.
Roadmap: ensin totuus datasta, sitten optimointi
Auditoinnin jälkeen työjärjestys on selkiytynyt paljon.
Ensimmäinen tehtävä on Thermian datapolku. Modbus-rekisterit käydään läpi yksi kerrallaan, väärin tulkitut tiedot poistetaan käytöstä tai nimetään uudelleen ja keräys korjataan vastaamaan todellista merkitystä. Vasta tämän jälkeen voidaan päättää, mitä historiasta voidaan käyttää ja mistä aloitetaan uusi luotettava mittausjakso.
Lämmityskauden alussa kerätään ensin perustaso. Tarvitsen puhtaan vertailujakson, jossa taloa ei yritetä vielä tehdä ”älykkäämmäksi”. Lämmityksen tila, ulkolämpötila, sisälämpötila, energiankulutus ja muut mallille tarvittavat suureet kerätään vain varmennetuista lähteistä. Samalla jokaisella mittauksella pitää olla käsitys laadusta: onko tieto tuoretta, uskottavaa ja mallille kelpaavaa.
Sen jälkeen alkaa talon käyttäytymisen mittaaminen. Kuinka nopeasti raskas rakennus reagoi muutokseen? Kuinka kauan lämpö pysyy rakenteissa? Mitä tapahtuu, kun lämmitystä vähennetään yhdellä asteella tai palautetaan takaisin? Millainen viive on ulkolämpötilan muutoksen ja sisätilojen reaktion välillä?
Vasta tämän aineiston päälle kannattaa rakentaa hinta-, aurinko- ja lämmitystarve-ennusteisiin nojaava suunnittelija.
Ja silloinkin se aloittaa varjossa.
Se saa laskea mitä tekisi, mutta ei vielä tehdä sitä. Malli saa ensin katsoa ja ehdottaa. Sen päätöksiä verrataan todelliseen taloon ja nykyiseen ohjaukseen. Vasta kun tiedän riittävän hyvin sekä datan että mallin käyttäytymisen, voidaan puhua varsinaisista ohjausvaltuuksista.
Loput — talouslaskennan laajennukset, käyttöliittymän säästönäkymät ja muu hienosäätö — voivat odottaa. Ne ovat kehitystä. Väärä lähtödata sen sijaan voisi pilata koko seuraavan vaiheen.
Periaate, jota en anna hämärtyä
Yksi asia on auditoinnin läpi kirkkaana: palautuminen on deterministinen, ja lopullinen valta on ihmisellä.
Rakennan mielelläni järjestelmää, joka osaa havaita ongelmia, yhdistellä havaintoja ja myöhemmin jopa hyödyntää aiemmista häiriöistä opittua tietoa. Mutta ohjausvaltaa ei avata epäselvän datan tai keskeneräisen palautumislogiikan päälle.
Kun kone käynnistyy sähkökatkon jälkeen, sen on tiedettävä varmasti mitä tehdä — ei arvattava. Kun mittaus kertoo lämpöpumpun tilasta, minun pitää tietää varmasti mitä se mittaa — ei päätellä nimestä. Ja kun kaksi järjestelmää voisi periaatteessa ohjata samaa laitetta, vain yhden pitää olla vallassa kerrallaan.
Tämä on koko projektin punainen lanka pienoiskoossa: automaatio saa olla fiksu, mutta sen on oltava ennustettava, ja ihmisen on voitava aina ottaa ohjat.
Mitä opin
Kotiautomaatio ei ole valmis silloin kun se toimii. Se on valmis silloin kun tiedät miksi se toimii, tiedät mihin sen käyttämä tieto perustuu ja tiedät mitä tapahtuu kun jokin menee rikki.
Ero näiden välillä on juuri se työ, joka ei näy käyttäjälle — ja jonka helpoiten jättää tekemättä.
Tämän auditoinnin suurin anti ei ollut yksittäinen korjaus. Se oli rehellinen tilannekuva: lista siitä, mikä on todella valmis, mikä vain näyttää valmiilta, mitä dataa voidaan oikeasti käyttää ja mikä on kriittistä juuri nyt.
Sellaista kuvaa ei saa muistista. Sen saa vain katsomalla, mitä koneella oikeasti pyörii — ja sen jälkeen vielä kysymällä, tarkoittaako koneen näyttämä tieto todella sitä mitä kuvittelet sen tarkoittavan.
Seuraavaksi: levy, jonka pitää saada hajota
Auditoinnissa nousi esiin myös paljon arkisempi ongelma: EnergyHub tuottaa jatkuvasti lisää dataa, eikä Lenovon nopeaa järjestelmälevyä ole järkeä käyttää vuosien mittaisena arkistona. Samalla varmistukselle halusin Google Driven rinnalle toisen, fyysisesti erillisen paikallisen kohteen.
Ratkaisuksi tuli viiden teratavun USB-kiintolevy.
Seuraavassa osassa kiinnostavaa ei kuitenkaan ole itse levy vaan se, miten tällainen uusi komponentti lisätään järjestelmään niin, että sen saa irrottaa, sen saa kadottaa ja se saa lopulta hajota ilman että EnergyHub lakkaa toimimasta.
Miten estetään varmistusta kirjoittamasta vahingossa järjestelmälevylle, jos USB-levy puuttuu? Miksi levylle ei tallenneta selväkielistä varmistusta? Miten tarkistetaan sekä oikea fyysinen levy että kopioidun tiedoston eheys? Entä miten mekaanista levyä valvotaan herättämättä sitä viiden minuutin välein vain siksi, että halutaan tarkistaa nukkuuko se edelleen?