Monthly Archives: September 2016

So long, Kraków! – justinpoland edition

Egy márciusi napon gondoltam egyet és lefotóztam az aznapi ebédet:

justinpoland-1st-image

Aztán nrg kitalálta, hogy ebből lehetne sorozat, angelday meg nevet adott neki - így lett dokumentálva 407 ebéd a justinpoland névre keresztelt tematikus blogon. Mivel ezek a képek csak az itt készült kajákról szóltak, a justinpoland tumbli ezennel véget ér.

Ez egy bő két perces summary a +2 évnyi ebédről:

Mac workflow: textfile to Reminders items

Rövid, de annál szárazabb, scriptelős post lesz. Mivel bármilyen unalmas contentet jótékonyan meg tud támogatni akár egy irreleváns kép is, ezért itt egy panoráma a Tátrából, mielőtt scriptet kéne olvasnod:

Tatra panorama

Erától kaptam szép hosszú szerelmetes levelet to-do listát emailben, amit nekem kényelmesebb lenne kipipálgatni egy Reminders listában. Szerencsére van egy kis eszünk, AppleScriptünk, meg a Remindersnek AppleScript supportja, úgyhogy csak bemásoljuk az emailből a hosszú listát a clipboardba, aztán ráeresztjük ezt a scriptet és voila:

tell application "System Events"
	set myText to paragraphs of (the clipboard as text)
end tell
repeat with myLine in myText
	if length of myLine is greater than 0 then
		tell application "Reminders"
			tell list q
				make new reminder with properties {name:myLine}
			end tell
		end tell
	end if
end repeat

Home automation: építsünk detektívet!

Preface

2012 márciusában lecseréltük a hagyományos kazánt kondenzációsra és ha már lúd legyen kövér alapon telepítettünk mellé 5 m² váklumcsöves napkollektort is a hozzá való köcölékekkel (hőtároló puffer, hőcserélő, frissvíz modul, vezérlés, etc.) egyetemben. A választás némi kutatás után a Vaillant termékére esett.
2016 augusztus közepén egy meleg nyári napon forró etilénglikol szaga áradt a kazánházból. Elég volt egy pillantás a szabályzóra, hogy észrevegyük: a kinti hőség ellenére a kollektorokból egy csepp meleget sem szed le a rendszer. Ráadásul ekkor tűnt csak fel, hogy a baj már 2016 júniusában bekövetkezett, csak akkor nem vettük észre.

Melegcsináló HOWTO

Mielőtt a lényegre térnék, muszáj dióhéjban ideMórickázom, hogy működik a fűtésünk:

r9-heating

Gondolom rájössz magadtól, de azért: a rajzon a zöld az áramlási irányokat jelöli, a piros a meleg közeget, a kék a hideget.

Az 1. napkollektoroktól a 2. szivattyú behúzza a hőszállító etilén-glikolt a 3. hőcserélőbe, aki a glikol melegét beletolja a 4. puffertartályba. Ha a háznak melegre van szüksége, akkor az 5. hőcserélővel a 6. szivattyú csinál a csapvízből meleget, vagy a 7. szivattyú a fűtési körökben levő folyadékokra melegít rá egy kicsit. Az egészhez persze csatlakozik még egy kazán is, de azzal most semmi dolgunk, úgyhogy ezért lehagytam a Mórickáról.

A solar körön a 3. hőcserélő után van egy nyomásmérővel ellátott biztonsági szelep, amiből egy hosszú rézcső megy be egy nyitott puffertartályba. Erre azért van szükség, hogy ha valami hiba folytán a nyomás alatt levő solar kör belső nyomása elérné az 5 bar-t, akkor ez a biztonsági szelep egyszerűen leengedi a glikolt ahelyett, hogy hagyná felrobbanni a csöveket.

Nyomozás v1.0

Az augusztus közepén detektált problémát a szerelő úgy korrigálta, hogy újratöltötte a glikolt a nyomás alatt üzemelő rendszerben. A szakember arra tippelt, hogy valószínűleg hosszabb ideig nem voltunk otthon, így nem volt hőelvétel a pufferből és a termelődött meleget a vezérlés már nem tudta hova rakni, így ennek megfelelően a túlmelegedő glikol nyomása elérte az 5 bar-t, a biztonsági szelep leeresztett és onnantól nem volt ami lehozza a meleget a tetőről.

Ezt el is fogadtam, viszont nagyon nem hagyott nyugodni, hogy a problémáról a rendszer semmiféle módon nem tájékoztat. A dolgot úgy veszed észre, hogy a kinti hőség ellenére azt látod a vezérlő kijelzőin, hogy aznap semmi hőt nem termelt a solar kör, illetve a hosszabb időtartamú kiesés is megfigyelhető egy buta havi bontású oszlopdiagrammon.

Nekem ez kevés. Én tudni akarom, hogy pontosan mi történik a solar körben, illetve elektronikusan akarom detektálni azt, amikor ismét előáll a probléma és erről push notificationt akarok küldeni a fiúknak, akik majd riasztják a szervizest. Persze az igazi az lenne, ha a solar kör nem hibázna, ám mint pár óra telefonálgatás után megtudtam, erre a nyomás alatt levő solar rendszerek nem alkalmasak, csak a mostanában gyártott, önmagukat leereszteni és újratölteni képes kollektoros installációk. A sajátom természetesen ezekkel nem kompatibilis.

Azt találtam ki, hogy a glikolt szállító csőre hőcserélő bemeneténél és a biztonsági szelepnél is teszek fel egy-egy PT-1000-es hőmérőt, 10 percenként mérek velük egyet és a mért értékeket naplózom egy sql táblába. Ezen felül azt gondoltam, hogy talán jó indikátor lesz a meghibásodásra, ha a bizontsági szelepnél mért hőmérséklet elér egy határértéket (70 ℃-ra saccoltam), aminek hatására már küldhetem is a figyelmeztetést a gyerekeknek.

Felszereltem a hőmérőket, beállítottam a homeaut serverben a naplózást, megcsináltam a vizualizáló interfészt, körbeteszteltem szépen mindent és úgy gondoltam kész vagyok, de persze tévedtem.

A következő meghibásodás kb. 2 héttel az előző hiba kijavítása után következett be. Sajnos a biztonsági szelep utáni hőmérséklet teszt nem bizonyult hatásosnak: a cső nem melegedett 45 ℃ fölé. Ennek ellenére a hőmérő naplózás nem bizonyult hiábavalónak - mindjárt meg is mutatom! A biztonsági szelepnél levő hőmérővel most nem foglalkozunk, elég tanulságos lesz a solar kör hőcserélőjének bemeneti hőmérséklete.

Az első grafikonon azt látod, amikor a rendszer normálisan működik két egymást követő, kb. egyformán meleg napon:
solar-temp-log-OK

Ezen pedig jól látszik, hogy a 2. napon 9:30 tájban pusztul meg ismét a rendszer:
solar-temp-log-FAILURE

Két egymást követő kb. egyforma napon a normál működést tanulmányozva nagyon jól látszik, hogy mi történik a rendszerben:

  • 6:10: az éjszaka után beindul a solar szivattyú. Az ezt követő 10 percben ~10 ℃-t esik a hőmérséklet, mivel az éjszaka során meghűlt a kollektorban levő glikol és a szivattyú épp ezt a hidegebb folyadékot hozza le a hőcserélőbe.
    A kollektor és a hőcserélő közti csőszakasz valamint a padlástér is vastagon szigetelt, ezért abban csak nagyon lassan hűl ki a hőszállító folyadék - ez láthatod az éjféltől kezdődő első szakaszon.
  • 7:20: felkel a nap, a kollektorok elkezdik termelni a meleget.
  • 15:00: a hőtermelés csúcsa, kb. ekkor süti optimális szögben a nap a kollektorokat. Innentől kezdve lassan csökken a glikol hőmérséklete, de még mindig van bőven hőmermelés.
  • 20:00: lemegy a nap, a hőmermelés megszűnik. A hőtároló pufferben már legalább 60 ℃ hőmérsékletű víz van, így az ennél hűvösebb glikolból a hőcserélő már nem vesz el meleget. A görbe simulása egyenletesebbé válik, ami azt is jelzi, hogy a szivattyú már nem keringtet, a csőben levő hőszállító folyadék magától hűl le lassan.

Ha ránézel a 2. ábrára, akkor arról a fentiek alapján a meghibásodás napján (=kék diagram) ugyanígy leolvasható a történet:

  • 9:00: A lassan hűlő glikolt 6:10 helyett 9:00-kor mozdítja meg a keringtető szivattyú. A hőcserélő visszahűlése jóval kevesebb ideig tart, mivel a kollektor ilyenkor már baromi meleg.
  • 9:30: a hőmérséklet ezerrel emelkedik.
  • 9:50: az utolsó mért meleg érték - a nyomás alatt levő csőrendszer itt éri el az 5 bar határértéket, a biztonsági szelep leereszti a glikolt. Innentől már csak a lassú kihűlés marad, mivel nincs hőszállító közeg.

A fentieket megmutattam a szerelőnek, aki a rendszert ismét átnézve arra jutott, hogy a hőcserélő szivattyúja adta meg magát. Én továbbra is azt látom a diagrammokon, hogy az eltelt 2 hétben a szivattyú minden nap 6:10-kor indul, kivéve a meghibásodás napját, amikor 9:00-kor mozdította meg először a folyadékot. Szerintem inkább a vezérléssel nem stimmel valami.

A második hiba után szeptember 5-én a csöveket trisóval átmosták, a hibásnak gondolt szivattyút kicserélték, majd 2 nappal ezután a következőt rajzolta nekem reggelire a log:

solar-temp-log-WARNING

A kék vonal megint azt mutatja, hogy a szivattyú egy órával később kapcsol. A vezérlésnek nincs internetkapcsolata, tehát nem tud az időjárásról, mindössze annyit ismer a környezetéből, hogy Magyarországra telepítették és hogy épp mennyi a pontos idő.

Nyomozás v2.0

A fentiek alapján azt feltételezem, hogy a rendszer hamarosan ismét megadja magát. A logok nekem már most is egyértelműek, viszont ettől lehetnének egy picit még precízebbek is, ezért a következő tuningot eszeltem ki:

  • A biztonsági szelepen levő hőmérő átkerül a hőcserélő kimeneti oldalára, így a két mért értékből jól látszik majd, hogy a puffer felvette-e a tetőről lehozott hőt.
  • A szivattyú tápellátására párhuzamosan rákötök egy 230 V AC-re kapcsoló relét, aminek a kapcsolt NO lábát odaadom egy digitális bemenetnek a homeaut buszon. Ezzel értesülni fogok arról, hogy mikor indult és mikor állt le a szivattyú.
  • Ha már tudom, hogy mikor megy a solar szivattyú, akkor elég lesz akkor megmérnem a két hőmérsékletet - illetve egész pontosan mondjuk 30 másodperccel a szivattyú indulása után, hogy biztosan a lehozott hőszállító folyadékot mérjem.

Amióta ern0vel összeraktuk a dataflow alapú homeaut servert, nincs az a probléma, aminek a megoldását ne lenne élvezetes implementálni homeaut oldalon egy kis dataflow script módosítással. Lényegében az egész terjengős posztot azért kellett végigrágnod, hogy meg tudjam mutatni neked, hogy csináltam!-)

A fizikai adatbuszról a fenti probléma megoldásához kétféle adatra van szükségünk: egy digitális bemenetére (amire a keringtető szivattyú tápjával vezérelt 230 V AC-s relét kötöm) és a PT-1000-es hőmérők által mért analóg értékekre. A digitális inputokat 100 msec-enként lekérdezem egyben, úgyhogy az már kész, viszont a házban levő 8 darab PT-1000-es hőmérőt csak 10 percenként kérdeztem le eddig, mert a többit bőven elég ilyen lépesközzel naplózni, a két solar hőmérő naplózását viszont a szivattyú bekapcsolásának kellene vezérelni mostantól. A dolog azért problémás, mert a 8 darab hőmérőből 4-et csak egyszerre tudok lekérdezni a Wago MODBUS interface-en. Szerencsére itt van a kezem alatt a dataflow nevű rágógumi, amit a végtelenségig lehet nyújtani - nézzük meg, hogy hogyan csinálom!

Dataflow gyorstalpaló

Ha tudod, mi az a dataflow, akkor menni fog az is, ami lejjebb következik - ha viszont nem, akkor ern0 barátom eldarálja neked elképesztő sebességgel 10 percben (amiből a második ~5 perc már csak a kérdésekre adott válasz):

Dataflow from Budapest New Tech Meetup on Vimeo.

ern0 közben feltöltötte youtube-ra a tavalyi hosszabb dataflow meetup videót is - hardcore rajongóknak kötelező ez is:

Megoldunk

Ezek után lássuk, hogy raktam mindezt össze:

log_df_visualized

Ha inkább a scriptet olvasnád, mint a vizualizált ábrát, az így néz ki (btw a fenti rajzot ern0 kódja generálja graphvizzel a lenti dataflow scriptből :)):

component Main {
	implementation {
		carpet log {

			// create pulsars
			p100ms: RTCPulsar
			p100ms.freq = 100000

			p1s: RTCPulsar
			p1s.freq = 1000000

			// create 10 min scheduler
			p100ms.out >> sched10min.clock
			sched10min: Scheduler
			sched10min.mask := "schedule={mi=0,10,20,30,40,50 se=0}"

			// feed Wago digital poll
			p100ms.out >> wdp.digipoll
			wdp: WagoPoll
			wdp.digibase = 0
			wdp.digipollsize = 96
			wdp.anabase = 0
			wdp.anapollsize = 4
			wdp.serout >> s1.in

			s1: Serial
			s1.device := "wago_ip:502"

			s1.out >> di4_1.serin
			di4_1: WagoDigiIn
			di4_1.base = 48

			// feed Wago analog poll
			p1s: RTCPulsar
			p1s.freq = 1000000
			p1s.out >> wap.anapoll

			wap: WagoPoll
			wap.anabase = 0
			wap.anapollsize = 4
			wap.serout >> s2.in

			// Wago bus
			s2: Serial
			s2.device := "wago_ip:502"

			// split Wago analog input msg
			s2.out >> ai1.serin
			ai1: WagoAnaIn
			ai1.base = 0
			ai1.size = 8 // 4 input, 2 byte/input

			// store temps in Value components
			ai1.out1 >> temp1.setvalue
			ai1.out2 >> temp2.setvalue
			ai1.out3 >> temp3.setvalue
			ai1.out4 >> temp4.setvalue

			temp1: Value
			temp2: Value
			temp3: Value
			temp4: Value

			// send measured temps to sql loggers from the first 3 thermometers
			sched10min.out >> temp1.in
			sched10min.out >> temp2.in
			sched10min.out >> temp3.in

			temp1.out >> sql1_1.in
			temp2.out >> sql1_2.in 
			temp3.out >> sql1_3.in
			temp4.out >> sql1_4.in

			// define sql loggers for all 4 thermometers
			sql1_1: Shell
			sql1_1.command := "./log_temp.py r9_nagyhaz_nappali"
			sql1_2: Shell
			sql1_2.command := "./log_temp.py r9_solar_test"
			sql1_3: Shell
			sql1_3.command := "./log_temp.py r9_utca"
			sql1_4: Shell
			sql1_4.command := "./log_temp.py r9_napkollektor"

			// di4_1.out1 = solar pump power state change
			di4_1.out1 >> change4_1.value
			change4_1: Change
			change4_1.last = 0
			change4_1.zero >> log_solar_pump.in = 0    // log pump OFF state
			change4_1.nonzero >> log_solar_pump.in = 1 // log pump ON state
			change4_1.nonzero >> d30s_4_1.in           // log temp with delay after pump switched on

			// log solar pump state
			log_solar_pump: Shell
			log_solar_pump.command := "./log_di.py r9_solar_pump"

			// log thermometer wiuth a 30 sec delay
			p100ms.out >> d30s_4_1.clock
			d30s_4_1: Delay
			d30s_4_1.delay = 300
			d30s_4_1.out >> temp4.in // log temp with 30s delay after pump has started
		}
	}
}

Elmagyarázom a rajzot - a legjobb, ha kinyitod teljes méretben :)

Start

Kezdetben azt csináltam, hogy egy 10 perces scheduler (=sched10min) lökdöste meg az analog inputokat pollozó wap komponenst és az abból kiálló ai1 analóg poll értelmező meghívott négy darab, sql insertet elvégző scriptet (sql1_1..sql1_4), akik megcsinálták a naplózást. Ezzel az a baj, hogy a 4. hőmérőt csak akkor akarom naplózni, amikor a szivattyú beindul, a többi meg maradhat 10 percenként.

Flow detection

Első körben detektálni kellett a szivattyú indulását. Ehhez csak a solar vezérlőből a szivattyúnak adott 230 V AC tápra kell párhuzamosan rákötni egy 230 V AC által kapcsolt relét, aminek a másik végébe jön a 24 V DC kimenetünk, akit a buszon a di4_1 modul out1 lábára kötünk.
Nekem akkor kell naplóznom a solar folyadék hőmérsékletét, ha a szivattyú megindul (egész pontosan kicsivel utána), így a di4_1.out1 láb 0-ról 1-re történő állapotváltozása kell, hogy kiváltsa a naplózást. Az állapotváltozás detektálására ott van a change4_1 komponensünk, aminek a zero illetve nonzero lábain csak akkor jelenik meg trigger, ha a bemenetén az előző inputhoz képest más adat jelenik meg.

Logging

Innentől már nincs nehéz dolgunk, csak be kell kötni a change4_1.nonzero kimenetet a d30s_4_1 30 másodpercre állított delay komponensbe, akinek az out kimenetével indíthatjuk a naplózást.

Analog poll

Az analóg input olvasásán is változtatni kellett. Egyrészt a 10 perces kérések helyett másodpercenként kérdezzük le a modult (ezért bökdösi a p1s 1 másodperces Pulsar komponens a wap analóg input poll generátort a korábbi sched10min 10 perces trigger helyett), másrészt az ai1 analóg input választ feldolgozó komponens lábait a közvetlen naplózás helyett a temp1..temp4 Value komponensekbe kötögettem. A temp1..temp4 value komponensek tárolják a mért értékeket, a kimenetük indítja meg a bennük levő érték naplózását, amit az sql1_1..sql1_4 Shell komponensek végeznek el. A temp1..temp4 komponensekből az első hármat a sched10min 10 perces időzítő triggereli, míg a negyediket (amiben a solar folyadék hőmérsékletét tároljuk) a di4_1.out1 komponens kimeneten megjelenő 0->1 érték változás indítja.

Extras

Ha már egyszer detektálom a szivattyú indulását (és leállását is, hiszen a change4_1 komponens mindkét állapotváltozást megadja), akkor ezt is simán lehet naplózni - erre való a change4_1 zero és nonzero lábaira kötött log_solar_pump komponens. Innentől a következő hibánál nincs vita, hogy mikor indította el a solar vezérlés a szivattyút.

Szummárium

Hétvégén megcsinálom a hardveres részt is, aztán még készül hozzá egy olyan diagram, ami a solar kör hőmérő által mért értékeket együtt mutatja a keringtető szivattyú állapotváltozásával és onnantól már kellőképpen felvegyverkezve várom a következő hibát.