Node-RED – ovládaní rekuperace ATREA přes ModBus

Asi jako každý začátečník jsem v Node-REDu začal kreslením chobotnic. Není to špatný začátek a funguje to. Funkčními nody se dělá to samé, ale je možné si ušetřit místo na ploše a mít flow trochu přehlednější. Inu opásejme svá bedra mečem trpělivosti a vydejmež se na pouť.

Začátek

Výchozím impulzem bylo zjištění, že přes Node-RED lze pomocí rozhraní ModBus velmi snadno řídit parametry rekuperační jednotky ATREA. Od instalace až do tohoto zjištění jsme větrání řešili pouze nastavením ve vestavěném webovém rozhraní – spínání podle předdefinovaných časů, což se po pořízení čidel Netatmo a kontrole naměřených hodnot ukázalo jako naprosto nedostatečné a jen se potvrdila poučka:

Nereguluj, co neměříš.

Samotné řízení je triviální, přes plugin ModBus se na správnou adresu pošle ta správná hodnota jako číslo, jednotka zareaguje okamžitě. Nevýhodou je, že samotný ModBus není ani náznakem blbuvzdorný a provede, co se mu řekne, je tedy třeba vzít v potaz mezní hodnoty, které se do jednotky mohou v daném domě poslat.

První verze

Postupný vznik přiložené chobotnice nemůžu úplně do detailu komentovat, dopustil jsem se začátečnické chyby, nedokumentoval jsem. Tenhle postup vřele NEDOPORUČUJU, reverse engeneeringem řešení, které jste jednou vymysleli sice strávíte pár hezkých večerů, ale ty nervy za to opravdu, ale opravdu nestojí.

Ve stručnosti – jednou za 5 minut (častěji to nemá smysl, Netatmo také měří v pětiminutových intervalech) se příslušným pluginem zeptám serveru Netatmo (ano, tahám to z cloudu) na naměřené hodnoty, funkčním nodem si vytáhnu patřičnou hodnotu CO2 (celkem 4, měříme ve 4 pokojích), ty si potom srovnám do [array] ze kterého dalším nodem vytáhnu nejvyšší hodnotu. V další části flow se pak rozhoduju, jestli je přes 1000 ppm, nebo pod 900 ppm, což jsou prahové hodnoty nastavené pro spuštění a zastavení větrání.

Původní verze tohoto flow neobsahovala další dotaz na vlhkost, čímž jsem si v domě v mrazech způsobil pokles vlhkosti až na hodnoty kolem 25% (moje verze jednotky větráním vzduch bohužel také vysušuje), takže dalším krokem bylo zesložitění chobotnice další podmínkou – dotazem na nejnižší vlhkost, momentálně 35%, pod kterou jednotka nevětrá. Minimální vlhkost v domě si pro kontrolu také posílám pro kontrolu do HomeKitu. Prostě jsem to tam potom flákal, jak se dalo, aby to nějak fungovalo a jak píšu výše, kdybych měl zrekonstruovat proč jsem co udělal, dám to dohromady horko těžko.

Druhá verze

Automatika chobotnicí nefunguje špatně, dělá, co se po ní chce – při překročení hodnoty 1000 ppm CO2 začne větrat, při poklesu pod 900 ppm větrat přestane a nevětrá, když je vlhkost pod 35%. Nevýhodou je, že parametry jsou nastavené napevno a měnit je lze jen přes Node-RED. Flow působí zmateně a neuspořádaně.

Při hledání elegantnějšího řešení nezbylo nic jiného, než se pustit do funkčních nodů a seznámit se se světem globálních proměnných. Node-RED umožňuje ukládat hodnoty jako globální proměnné a pracovat s nimi ve všech flows na serveru, což je praktické. Ovšem při restartu serveru se smažou.

Řešení je dvojí. Buď si nastavit Inject node s výchozí hodnotou a jej proběhnout jednou při startu, nebo hodnoty v nějakém časovém intervalu ukládat na disk (záměrně říkám na disk a ne SD kartu) a při startu serveru je načíst.

Takže začínáme, nejprve definicí parametrů. Pro jejich zadání v HomeKitu jsem použil dva vstupy: HeaterCooler a FanV2. Nejprve to jednodušší, požadovaný výkon rekuperace:

Konfigurace tlačítka v HomeKitu:

Proč takto? Můj model větrací jednotky nepřijme nižší hodnotu, než 12% výkonu a systém je navržený na nejvýše 70%. Je to maličko nešikovné, protože posuvník v HomeKitu ukazuje hodnoty 0-100%, takže 0% v Homekitu znamená výkon jednotky 12% a 100% v HK znamená 70%, dá se na to zvyknout.

A náhled příslušné funkce:

Dalším krokem je stanovení minimální vlhkosti, kterou chci v domě udržovat:

Opět je použité tlačítko FanV2

Zde žádnou minimální ani maximální vlhkost nedefinuji.

Nastavení prahu zapnutí a vypnutí:

Tohle mě potrápilo asi nejvíc. V HomeKitu není žádná služba na nastavení/měření CO2, musím tedy jako v případě vlhkosti „ohnout“ to, co je dispozici a jako nejvhodnější se ukázala služba HeaterCooler, která umí nastavit dva parametry a navíc z ní lezou čísla, které lze poměrně snadno překlopit na hodnoty, které potřebujeme.

Za tlačítko HeaterCooler jsem původně umístil funkční node, který měl ukládat desetinásobek (nastavujeme hodnoty CO2, které se pohybují ve stovkách – tisících) hodnoty CoolingThresholdTemperature a HeatingThresholdTemperature do globálních proměnných, jako PrahZapnuti a PrahVypnuti (Cooling je horní hranice, tam zapínáme a Heating spodní a tam vypínáme). Bohužel se ukázalo, že message chodí z té služby nějak podivně a v globálních proměnných docházelo k tomu, že se jedna hodnota zapsala a druhá vymazala, to nakonec vyřešily dva RBE nody, které propouští pouze změnu Heating respektive Cooling a teď se už hodnoty do globálních proměnných zapisují korektně. Takže celé flow vypadá takto.

Vysvětlení, proč zapisuji i HeatingThresholdTemperature jako globální proměnnou je prosté – potřebuju si ji uložit pro případ restartu. Rozebereme dále.

Další flow využívá posbírané globální proměnné a na základě porovnání nejvyšší hodnoty CO2 a nejnižší hodnoty vlhkosti pošle do větrací jednotky po protokolu modbus příslušnou nastavenou hodnotu, je-li odlišná od předchozí.

Uchování a obnovení nastavení

Regulaci bychom měli za sebou, teď se musíme podívat na uchování hodnot, po restartu Node-RED by se všechna nastavení smazala a museli bychom vše nastavit znovu.

Nabízí se dvě možnosti:

1. před „nastavovací“ flow výkonu, vlhkosti a prahů zapnutí a vypnutí CO2 dát Inject node, který bude sypat nějakou výchozí hodnotu, anebo
2. nastavit si ukládání vlastního nastavení.

Když už jsme v tom, tak se pustíme do varianty 2) neb o variantě 1) není moc, co psát, žeano.

Takže musíme nejprve v pravidelných intervalech ukládat data někam „mimo“ RAM, tedy do souboru na disk. K tomu slouží „storage“ nody, použijeme nejprve File in kterým si vytvoříme příslušný soubor (jeden pro každou hodnotu, nechceme riskovat, že případným porušením jednoho souboru přijdeme o všechna uložená data). Ukládací operaci opakujeme každou dejme tomu minutu, ale ukládáme s pomocí RBE nodu pouze změněná data, abychom si neodpálili úložiště (i na SSD můžeme být hodní).

A blížíme se finiši, po restartu si chceme vytáhnout uložená data ze souborů, na což použijeme následné flow, jen je potřeba změnit formát vytažené informace ze string na number, což nám v pohodě provede jednoduchý příkaz ve funkčním nodu.

Za timestamp, který „odpálíme“ výchozí 0,1 sekundovou hodnotou a neopakujeme je pro jistotu vložený pětisekundový delay. V Inject nodech, které jsou v „Nastavovacích“ flow zmíněných na začátku je pak delay 10s pro „natažení“ hodnot do tlačítek HomeKitu. A nyní se dostáváme i k vysvětlení, proč 2x ukládám stejnou hodnotu, jednou jako PrahZapnuti/Vypnuti a podruhé, jako Heating/CoolingTargetTemperature – přišlo mi to jednodušší, než vkládat do flow další „přepočítávací“, protože v inject nodu se dělit nedá.

Hodnoty CO2, vlhkosti, teploty a další se do InfluxDB ukládají v jiném flow, ale toto by se samozřejmě dalo použít taky.

No a to je asi tak všechno. Bezpochyby existují vychytanější a elegantnější řešení, tohle je nejlepší, na co jsem byl schopný přijít. Momentálně ještě zvažuji přidání dalšího „teploměru“ který bude v HK zobrazovat aktuální hodnotu výkonu větrání, ono to asi nikdy nekončí…

Pomoc a inspiraci při tvoření poskytli S474N a Michael Vita, kterým tímto srdečně děkuji.