Olin tyytymätön ilmanvaihdon ohjaukseen (koneellinen poisto ja liesikupu) ja päätin rakentaa paremman. Kielenä on MicroPython, alustana on Raspberry Pi Pico W ja läjä itse kasattua elektroniikkaa.
Koodi ja kytkentäkaavio on GitHubissa: https://github.com/Metabolix/
Projektista on myös kuvia.
Ominaisuudet:
- Lukee alkuperäisten ohjainten ohjausjännitteet.
- Tunnistaa jänniteestä alkuperäisen ohjaimen asetuksen.
- Sallii omat säädöt ohjaimen asetuksista puhaltimen nopeuteen.
- Lukee lieden lähettämät infrapunakoodit (Hob2Hood).
- Sallii omat säädöt infrapunaohjauksesta puhaltimen nopeuteen.
- Lukee kummankin poistopuhaltimen todellisen nopeuden.
- Muuntaa kierrokset (RPM) prosenteiksi puhaltimen mallin mukaan.
- Ohjaa puhaltimia PWM:llä tavoitteen ja toteutuneen nopeuden mukaan.
- Lukee lämpötilan ja kosteuden DHT22-anturilta.
- Wi-Fi-rajapinta (HTTP ja UDP) seurantaan ja ohjaukseen.
- Wi-Fi-ohjaus: muunnoskäyrä, jonka mukaan tavoitenopeutta korjataan.
- Home Assistant -integraatio.
Fyysisillä kytkimillä voi valita, onko puhaltimet kytketty omaan ohjaukseen, alkuperäiseen ohjausjännitteeseen (esimerkiksi vikatilanteessa) vai ovatko kokonaan irti ohjauksesta (eli pysäytettynä).
Koska nopeutta voi säätää verkon yli, lisäominaisuudet (kuten varsinaisen ajastuksen ja lämpötilan mukaan säädön) voi ohjelmoida erikseen.
Tausta:
Asunnon ilmanvaihtona on koneellinen poisto eli yksi huippuimuri yleisilmanvaihtoon ja toinen liesikuvulle. Alkuperäisen ilmanvaihdon puute on se, että sitä ei voi oman automatiikan ohi ajastaa tai tehostaa järkevästi, vaan ainoa ”tehostus” on välitön täysteho ja ”ajastus” on täystehon kesto, tai sitten pitää vaihtaa täysin manuaaliseen ohjaukseen. Liesikuvun vikoja ovat täysin sopimattomat asetukset, Hob2Hood-infrapunaohjauksen puute ja bugi automaattisessa palautumisessa perustilaan. Nämä kaikki on nyt tällä projektilla korjattu.
Aika upea tuotos!
Oletko miettinyt jotain HomeAssistant -integraatiota? Eli saisi luotua erilaisia sääntöjä ja fyysisiä painikkeita, joilla tuota voisi ohjata.
Projekti oli sikäli hyvin mielenkiintoinen, että en ole aikaisemmin suunnitellut varsinaista elektroniikkaa. Juotosjälki on aivan kammottavaa...
Lebe80 kirjoitti:
Oletko miettinyt jotain HomeAssistant -integraatiota?
En ole miettinyt. Pitää seuraavaksi tutustua johonkin tuollaiseen alustaan, kun alkaa olla kotona palasia, joita tuolla voisi ohjata.
Mulla HomeAssistant tällä hetkellä vain kerää tietoa, ja ilmoittelee lasten huoneen alhaisesta lämpötilasta.
Tarkoituksena on ollut tilata ilmalämpöpumppuun wifi-moduli, jonka avulla saisin automatiikalla ohjailtua sen toimintaa, esim. lämpömittari huomaa, että takka on päällä ja pistäisi lämmityksen sijaan ilpin vain oskiloimaan ilmaa ympäri asuntoa yms.
Ilmanvaihtoprojektin ohjausjännitteiden osalta jäi ihmetyttämään, onko sähkölaitteet yleensäkin suunniteltu ja koottu näin suurpiirteisesti vai onko tässä jotain huonoa tuuria. Seuraa teknistä nipotusta:
Speksin mukaan puhaltimelle pitää olla 1–10 voltin ohjausjännite, ja alle 1 voltin jännitteellä puhallin on pois päältä. Puhaltimen datalehdellä tosiaan 1 V tuottaa 360 RPM. Lähes lineaarinen kuvaaja saavuttaisi huipun 9 V kohdalla, mutta tämä on ovelasti jätetty merkkaamatta, eli 8 V:n jälkeen tuleekin jo 10 V ja – tadaa – maksimijännitteellä maksimikierrokset 3069 RPM. Että näin jo virallisissa papereissa, kuka nyt yhtä volttia kaipaisi.
Omalla katolla jo 8 V tuottaa maksimikierrokset. Sama tulos kahdella puhaltimella eri putkissa, joten ei liene yksittäisen laitteen tai putken aiheuttama sattuma.
Saman valmistajan ”hieno” ohjain tuottaa 1–10 voltin ohjausjännitteet mutta laskettuna väärin, kuin 1 voltti olisi nolla. Näin ollen ohjaimen antama ”10 %” onkin sitten jo 1,9 volttia eli 19 % maksimista. Mitä ihmettä, insinöörit? Kun huomioidaan vielä nuo yllä mainitut 8 voltin huippukierrokset, ensimmäinen porras on peräti 24 %. – Toki voidaan ajatella, että asunnon säännölliseen ilmanvaihtoon ei kuitenkaan käytetä ihan alimpia puhaltimen nopeuksia, mutta tämä kyllä näyttää enemmän laskuvirheeltä.
Liesikuvun ohjain taas tuottaa PWM-signaalia 12 voltin jännitteellä. Puhaltimen kytkentäesimerkin mukaan tämä on sentään siedetty jännite, mutta 10 volttia vastaava lopputulos tulee sitten jo noin 83 % PWM-syklillä, mitä ei ole kuitenkaan huomioitu ohjaimen suunnittelussa. Asetus 7/8 tuottaa yli 10 volttia vastaavan PWM-signaalin, joten 8/8 jää täysin tarpeettomaksi. Asetus 6/8 tuottaa yli 8 volttia vastaavan signaalin ja näillä puhaltimilla siis maksimikierrokset, joten myös 7/8 menee hukkaan. Kaiken huipuksi ohjekirjassa on annettu vielä reilusti korkeammat prosenttilukemat asetuksille alkaen siitä, että asetus 1/8 olisi 25 %; onneksi ohjekirja on väärässä ja asetus 1/8 on todella noin 1/8 kyseisen ohjaimen maksimista.
Metabolix kirjoitti:
Ilmanvaihtoprojektin ohjausjännitteiden osalta jäi ihmetyttämään, onko sähkölaitteet yleensäkin suunniteltu ja koottu näin suurpiirteisesti
Kyllä on. En ole vielä nähnyt virheetöntä datalehteä, ainakaan monisivuista. Tai ainakaan minkään laitteen ensimmäistä, jotkuthan niitä päivittelevät kun virheitä tulee esiin, mutta eivät kaikki.
Ja puhun nyt siis esim. jenkkiyhtiöistä. Kiinalaisillahan datalehden on usein vaan kopio jostain länsimaisen tuotteen datalehdestä ja tuote on vähän sinne päin.
Kaikkihan sitten muistavat myös mitata, että vaadittavat asunnon ilmanvaihdon ilmamäärät toteutuvat, jos askarrellaan omia säätimiä muuhun kuin pelkkään keittiön poistoon.
jalski kirjoitti:
Kaikkihan sitten muistavat myös mitata, että vaadittavat asunnon ilmanvaihdon ilmamäärät toteutuvat,
Tottakai! Kun venttiilit on säädetty ja oikea kiinteä puhaltimen nopeus on tiedossa, omalla ohjaimella saavutetaan tietenkin täysin sama lopputulos. Lisäksi tässä ilmanvaihto oletuksena seuraa alkuperäisen ohjaimen signaalia ja käytännössä käyttötarkoitukseksi tulee automatisoitu tehostus (nostamalla alarajaa, jolloin mikäli alkuperäinen ohjain antaisi vielä korkeamman jännitteen, edelleen noustaisiin sen mukaan).
Toisaalta ilmamäärät saa helposti vaatimusten vastaisiksi myös alkuperäisillä ohjaimilla tai ihan vain pyörittelemällä venttiilejä.
Kun nyt IV-vaatimukset tulivat asiaksi:
Nämä IV-vaatimuksethan on täysin vanhanaikaisesti vakioitu siten, että niissä ei huomioida vaihtelevaa käyttöä eikä varsinkaan nykyisiä mittausmahdollisuuksia. Suunnitelmissa on tietyt litramäärät joka venttiilille, ja lisäksi on se yleisvaatimus, paljonko pitää pystyä tehostamaan – kaikkea kerralla tietenkin, ei esimerkiksi yksittäisen märkätilan poistoa erikseen. Onkohan todella rakennusmääräysten hengen mukaista, että puhallus pyörii samalla teholla arkena ja sunnuntaina ja lomamatkoilla? Kärynpoisto keittiöstä ja kylppärin kuivatus on joka tapauksessa täysin omalla vastuulla.
Jos sitten näitä suunniteltuja ilmamääriä pidetään ehdottomina, niin miten on edes mahdollista, että merkittävä alan toimija myy Suomessakin järjestelmää, joka säätää ilmanvaihtoa automaattisesti (vaikkakin kömpelösti) ilmanlaadun ja -kosteuden mukaan?
Lebe80 kirjoitti:
Oletko miettinyt jotain HomeAssistant -integraatiota?
Nyt olen: harjoitusversio Home Assistant -integraatiosta valmistui puolilta öin, mutta jotain vikaa on vielä sen vikasietoisuudessa.
Home Assistant vaati kyllä minusta kohtuuttomasti perehtymistä oman integraation tekemistä varten. Arkkitehtuuri on aika monimutkainen ja dokumentaatio ei anna konkreettista tietoa, esimerkiksi funktioiden ja luokkien nimiä ei paljon dokumentaatiosta löydy, vaan ainoa ratkaisu on koodin kaivaminen ja kopiointi.
Ilmanvaihdon ohjaus toimi upeat 100 vuorokautta ilman katkoja, ja liesikuvun automaattinen IR-ohjaus on kyllä kiva pieni apu arkeen. Nyt päivitin siihen UDP-rajapinnan kevyempää integraatiota varten.
Metabolix kirjoitti:
Lebe80 kirjoitti:
Oletko miettinyt jotain HomeAssistant -integraatiota?
Nyt olen: harjoitusversio Home Assistant -integraatiosta valmistui puolilta öin, mutta jotain vikaa on vielä sen vikasietoisuudessa.
Home Assistant vaati kyllä minusta kohtuuttomasti perehtymistä oman integraation tekemistä varten. Arkkitehtuuri on aika monimutkainen ja dokumentaatio ei anna konkreettista tietoa, esimerkiksi funktioiden ja luokkien nimiä ei paljon dokumentaatiosta löydy, vaan ainoa ratkaisu on koodin kaivaminen ja kopiointi.
Upeaa! Itsellä myös samanlainen käsitys HomeAssistantista, joten omat integraatiot ovat sen vuoksi jääneet.
Metabolix kirjoitti:
Jotain vikaa on vielä sen vikasietoisuudessa.
Yhteysvirhe johtui siitä, että MicroPythonissa bytes on mahdollista JSON-koodata mutta purkaessa siitä tulee kuitenkin str, minkä jälkeen alkuperäinen ja purettu arvo ovat erisuuret.
Pakkohan tästä on laittaa kuva näytille. :D En vielä järjestänyt ja nimennyt sensoreita tarkemmin, suurin osa joutaisi piiloon. Teen kunnon kuvakoosteen projektista sitten, kun ehdin toteuttaa vielä hallinnan.
Ihan mielenkiinnosta, onko noiden HA:n dashboardien asetuksekset kuinka vaikea saada kohdilleen? Entä miten käyttäytyy vikatilanteessa, näyttääkö viimeisen saadun arvon vai virheen?
Itse piirtelen Nuklear pohjaisen käyttöliittymän itse. Erillinen ohjain välittää mittaus -ja tilatiedot ohjelmalle. Yksinkertainen taulukkopohjainen parseri käsittelee ne, välitttää pää säikeelle mikä sitten hoitaa tietojen ja graafisen käyttöliittymän päivittämisen.
jalski kirjoitti:
Ihan mielenkiinnosta, onko noiden HA:n dashboardien asetuksekset kuinka vaikea saada kohdilleen?
Riippuu varmaan, mitkä asetukset ja miten tarkasti ”kohdilleen”. Itse olen laiskasti käyttänyt asetteluun oletusasetuksia (pl. laitteiden sijoittelu oikeisiin huoneisiin), ja tämä on omalla varsin pienellä laitemäärällä ihan ok.
Automaatioiden (toimintojen) rakentelu vaatii välillä mielikuvitusta. Esimerkiksi en löytänyt valmista välinettä, jolla saisi helposti laitettua muutaman minuutin ajastimeen, vaan ajastimen säätö käyttöliittymässä pitää tehdä tekstimuodossa sen toiselta asetuslehdeltä. Lisäsin sitten erillisen liukupalkin, jonka muuttuessa automaatio siirtää luvun ajastimen minuuteiksi ja käynnistää ajastimen. Tämä purkkaratkaisu tietysti toimii vain 0–59 minuutilla. Oman integraation koodaaminen tähänkin yksinkertaiseen asiaan vaatisi varmaan ainakin 150 riviä copy-paste-Pythonia.
jalski kirjoitti:
Entä miten käyttäytyy vikatilanteessa,
Jos integraatio raportoi virheestä tietojen päivityksessä, käyttöliittymässä laitteiden tilaksi tulee Unavailable. Integraatio voi myös asettaa yksittäisen sensorin arvoksi None eli Unknown.
jalski kirjoitti:
Itse piirtelen Nuklear pohjaisen käyttöliittymän itse.
Se on varmaan ainakin tuhat kertaa nopeampi. Home Assistant käynnistyy Raspberry Pi 2:lla varmaan minuutin. Toisaalta sen jälkeen se toimii kyllä sujuvasti.
Etuna omatekoiseen nähden on valmis tuki monenlaisille laitteille. Esimerkiksi kun sain WiZ-älyvalot valmistajan mobiilisovelluksella käyntiin, ne suoraan ilmestyivät myös Home Assistantiin. Tietysti googlasin ennen hankintaa, että tuki löytyy, mutta helppous ylitti odotukset.
Pitää myöntää myös, että jostain syystä se oma automaatiojärjestelmä ei usean vuoden odottelulla realisoitunut edes insinöörimuodossa (tyylitön HTML-sivu, tekstilaatikko JS- tai Python-skriptille) saati sitten yleisesti käytettävässä muodossa. Tähän nähden Home Assistant on ihan hyvä vaihtoehto.
Metabolix kirjoitti:
Etuna omatekoiseen nähden on valmis tuki monenlaisille laitteille. Esimerkiksi kun sain WiZ-älyvalot valmistajan mobiilisovelluksella käyntiin, ne suoraan ilmestyivät myös Home Assistantiin. Tietysti googlasin ennen hankintaa, että tuki löytyy, mutta helppous ylitti odotukset.
Itse en älylaite villitykseen vielä ole lähtenyt mukaan ja langattomia laitteita pyrin välttämään mikäli mahdollista. Nykyään useimpien laitteiden hallintaan on kaikkiin oma sovelluksensa ja esimerkiksi monissa lämmittimissä ei enää ole mahdollisuutta keskitetysti pudottaa lämpötilaa ylimääräisen ohjausjohtimen avulla. Tämä on harmi koska olisi helppo keino saada sähkölämmitteiseen taloon pientä lisäsäästöä pörssisähköohjauksia toteuttaessa.
Itse käytän Eseran 1-Wire laitteita. Ovat halpoja, toimintavarmoja, asentuvat nätisti din-kiskoon ja lopputuloksesta tulee ammattimaisen näköinen ja viimeistelty. Lisäksi ohjaustietokoneeseen integroitu 1-Wire ohjain hoitaa lähes kaiken ja tekee ohjaus softan toteuttamisesta helppoa. Yhtenä kriteerinä olen pitänyt, että kaiken pitää kuitenkin toimia perinteisesti mikäli ohjaustietokone hajoaisi.
Kyseessä siis tämän näköinen kapistus. Vaatii kuuden johdonsuojakatkaisijan verran tilaa ja tietysti 24 VDC powerin. Kyseinen demo asennus toteuttaa minulla LVV:n pörssisähköohjauksen ja sähkölämmittimien lämpötilan pudotuksen pörssisähkön hintarajan mukaan.
Jossain välissä pitäisi keskittyä graafiseen ulkoasuunkin. Tällä hetkellä olen toteuttanut jokusen yksinkertaisen oman widgetin kuten tämä LVV:n pörssisähköohjaus. Tuossa siis yksikertaisesti kuvattuna vuorokauden tuntikohtaiset hinnat. Punaisella alapuolella merkattuna lämmitettävät tunnit ja mustalla oleva palkki kertoo nykyisen tunnin.
Mielenkiintoinen projekti.
Metabolix kirjoitti:
Jotain vikaa on vielä sen vikasietoisuudessa.
Tuolta Wikipediasta katselin, että muut kodinohjauksen ohjelmat on koodattu Pythonin sijaan Javalla tai C++:lla, joissa on mm. staattinen tyypitys. Se tuntuu loogisemmalta, kun järjestelmä vaatii paljon luotettavuutta.
Nyt kuukauden käytön jälkeen laitoin muutokset GitHubiin ja päivitin kuvausta aloitusviestiin. Uutena ominaisuutena on nyt siis UDP-rajapinta, jonka avulla toimii Home Assistant -integraatio. Lisäsin vihdoin myös kuvia projektista.
Järjestelin koodia hieman matkalla HASS-integraatioon. Projekti on nyt entistä joustavampi. Alkuperäisille ohjaimille on tehty omat luokat, joissa tapahtuu muunnos ohjaimesta valittavan tason ja vastaavan ohjausjännitteen välillä. Myös puhaltimelle on oma luokka, jossa määritellään vastaavuus ohjausjännitteen, toteutuvan RPM:n ja prosenttien välillä. Jos tulisi tarve lisätä erilaisia ohjaimia tai puhaltimia, tarvitsisi vain toteuttaa nuo muunnokset.
Käyttöliittymässä voidaan muutosten myötä näyttää ohjainten tiedot alkuperäisessä muodossa ja puhallinten nopeudet (asetukset, nykyinen tavoite, toteutunut) prosentteina laitteen maksimista. Käyttäjälle merkityksettömät yksiköt mV ja RPM jäävät piiloon.
Home Assistant -integraatiossa piti tehdä kompromissi selkeyden ja tarkkuuden ja hyödyllisyyden kesken, joten prosentteina ilmaistu nopeussäädin (välillä -100% ja +100%) ei säädä prosentteja puhaltimen nopeudesta vaan rajoja, joiden sisään muilla perusteilla laskettu tavoitenopeus skaalataan: Jos säädin on >0%, se säätää minimitason, jolloin esimerkiksi +10% tarkoittaa, että 0–100% nopeus skaalataan välille 10–100%. Jos säädin on <0%, se muuttaa maksimia, jolloin esimerkiksi -10% tarkoittaa, että 0–100% nopeus skaalataan välille 0–90%. Arvioin tämän omassa käytössä toimivaksi ideaksi.
Wi-Fi-ohjaus ottaa mielivaltaisen joukon datapisteitä, joiden perusteella (lineaarisesti interpoloiden) muista tiedoista laskettu tavoitenopeus muutetaan lopulliseksi tavoitteeksi, eli kaikenlaisia ratkaisuja voisi toteuttaa nyt muokkaamalla vain HASS-integraatiota eikä tarvitse koskea enää mikrokontrollerin sisältöön.
Luultavasti tämä projekti on nyt "valmis" ja viimeiset viilaukset tapahtuvat HASSin automaatioiden kautta. Lähinnä tuo salauksen puute vähän kaivelee, mutta saa nähdä, jaksanko tehdä sille mitään.
Mielenkiintoinen projekti ja aika valmis ratkaisu jo! Itsekin innostuin taas jatkamaan omaa projektiani ja toteutin minimaalisen webbi serverin info sivua varten. Myöhemmin tuohon tulee websocket tuki varsinaista ohjauksien hallintaa varten.
Oma nettiohjelmoinnin osaamiseni on heikkoa, niin ajattelinpa kysäistä miten toteuttaisit Javascriptillä, jos haluaisin näyttää ohjauksien tilat kahdelle peräkkäiselle vuorokaudelle siten, että palkeilla piirtäisi tuntikohtaiset hinnat ja nykyisen tunnin palkki olisi erivärinen kuin muut. Näiden alle tulisi ohjauksien tila indikaattorit kahdelle eri kanavalle allekkain, mitkä näyttäisivät onko ohjaus päällä vai pois kyseisenä tuntina?
Ajattelinpa kysyä mielipidettä. Kaverillani ollut nyt askartelemani ohjain ohjaamassa lämminvesivaraajaa päälle halutuksi ajaksi pörssisähkön vuorokauden halvimpia peräkkäisiä tunteja ja lisäksi aurinkovoiman pientuotannon ennusteeseen perustavan asetusrajan mukaan.
Tällä hetkellä ohjauksien tilan ja tiedot voi käydä katsomassa yksinkertaiselta nettisivulta. Älä ihmettele, jos näyttää tutulta. Varastin nimittäin nettisivun ulkoasun sinulta, koska en nettisivuja osaa kirjoitella! ;D
Ohjelmassa olevassa webserverissä on nyt WebSocket tuki ja ajattelin käyttää sitä toteuttamaan Pub/Sub Api:n jonka avulla asiakasohjelman voisi toteuttaa helposti haluamallaan ohjelmointikielellä tai vaikka selainpohjaisena käyttäen JavaScript:iä. Mitä mieltä olet?
jalski kirjoitti:
Ajattelinpa kysyä mielipidettä.
En hahmota nyt kysymystä. Tietysti WebSocketilla voi kaikenlaista toteuttaa. WebSocketin varsinainen etu on jatkuva kaksisuuntainen yhteys. Jos tila muuttuu vain tuntien ja päivien mittakaavassa ja sivua katsotaan ehkä pari kertaa päivässä, luultavasti WebSocketista ei ole varsinaista hyötyä, pikemminkin aiheutuu lisää debuggausta, kun yhteys voi erilaisista syistä katketa. Perinteinen pollaukseen perustuva HTTP-rajapinta on helppo toteuttaa, ja tähän on myös laajempi tuki eri ohjelmointikielissä. Omassa projektissani taas on UDP-rajapinta erityisesti sitä ajatellen, että IP-osoitteen vaihtuminen ei haittaa vaan laitteen tavoittaa aina kotiverkossa broadcast-paketilla.
Metabolix kirjoitti:
En hahmota nyt kysymystä.
Minulla on ohjaintietokoneen yhteyteen siis integroitu erillinen 1-Wire ohjain, jolta saan 1-Wire väylässä olevien laitteiden tiedot ja tapahtumat luettua sarjaväylän kautta sekä tietysti myös ohjattua 1-Wire väylässä olevia laitteita. Yleensä järkevä maksimi määrä laitteita 1-Wire väylässä on n. 22 kpl pinnassa, mutta ohjaimeni tukee niitä aina 30 kpl asti. Ajattelin, että ohjaintietokoneella pyörivä ohjelmani julkaisisi aiheen jokaisesta 1-Wire väylässä olevasta laitteesta. Aiheiden nimet olisi muodostettu siten, että niistä saisi parsittua helposti kaikki tarvittavat tiedot ohjauksista. Asiakasohjelman liittyessä aiheeseen, ohjelmani välittäisi sille samat tiedot aina käytännössä samaan aikaan kuin ohjaintietokone saa ne.
Selvensikö yhtään ajatusta? Lähinnä ajattelin, että asiakasohjelman toteutus olisi yksinkertainen ja helposti toteutettavissa millä tahansa ohjelmointikielellä. Itse ajattelin asiakasohjelman toteuttaa mobiilisovelluksena 8th:lla Nuklear pohjaisella käyttöliittymällä.
Kuulostaa ihan mahdolliselta ratkaisulta. Tee ihmeessä oma projektisivu tuosta projektista.
