Azt hittem, nagyon már nem fogok hozzányúlni a fűtéshez. Aztán véletlenül beleolvastam egy mézeskút (Honeywell) termosztát leírásába, ahol arról áradoztak, hogy annyira de annyira takarékos, és annyira menő, mert PI vezérlést használ, ami a legszuperebb.
Mivel én is menő és takarékos termosztátot szerettem volna, kicsit utána olvastam a dolgonak, és rá is találtam a Proportional Integral Derivative Control-ra, ami nem annyira bonyolult, mint amilyennek elsőre tűnik. Mint a neve is mutatja, derivál, integrál, ebből kitalálja (megjósolja), hogy mikor és mennyit kell fűteni, így nagyon precízen tudja tartani a beállított hőmérsékletet. Nagyjából így:
Akit érdekelnek a további részletek, az itt talál egy egész jó leírást, forráskódot, és további problémafelvetéseket (mint pl. tuning, derivative kick / filter, anti reset windup):
A dolog annyira működik, hogy a bevezetés után az első visszajelzés az volt, hogy csináljam vissza az egészet, mert soha nem melegek igazán a radiátorok. Még különösebb tuningolás és különösebb görbeillesztések nélkül is, normál működés során elég észrevehetetlen mikor fűt, és mikor nem. Viszont a tényleges hőmérséklet tized foknál többel nem nagyon tér el az előre beállított értéktől.
A vezérlést egyébként épp a napokban módosítottam tovább, hogy a lenti részt csak akkor fűtse a rendszer ha a fentit amúgy is fűtené. Így önmagában a lenti ág csak végszükség esetén indul el, és sokkal melegebb is van, mintha külön fűteném. A fűtés hatásfoka nem észrevehető módon romlott (a plusz egy radiátor és padlófűtés cső nem sokat vesz el a visszatérő ágból, amit amúgy is felfűt a kazán).
A jövőben ha lesz még egy kis időm, akkor az újonnan érkezett szervómotorokból egyet rákötök a kazán hőmérséklet állító tekerőjére, és megpróbálom kihasználni a D részt a PID vezérlőből. Így majd az eltérés mértéke vezérli a kazán által előállított és keringetett víz hőmérsékletét. Ha csak picit kell fűteni, akkor az majd alacsony hőfokú (pl. 40 fokos) vízzel történik, ha nagyon, akkor pedig melegebb (pl. 60 fokos) vízzel.
A kapcsolódó kódok pedig a szokott helyen, a github-on.
Amikor nekiálltam az építsünk okos házat projektnek, arra gondoltam, hogy az átlagos informatikai projektektől eltérően ez egy egyszerű dolog lesz, buktatók és problémák nélkül, pár hét alatt véget is ér. Annyira bíztam ebben, hogy még repository-t se csináltam, a forrásokat egyszerűen dropbox-on tartottam. Mostanra eljutottam oda, hogy az alapvetések már működnek, és újra se kell írni mindent (amíg nem jön az openhab v3). Igaz az ütemezéssel kicsit megcsúsztam, de hát mégicsak egy IT projektről van szó, ahol még azok sem mindig tudják mit akarnak, akik az általam használt komponenseket fejlesztik…
Jelenleg épp léptető motort programozok, 3D modelleket készítek nyomtatáshoz, integrálok, deriválok, szabadidőmben pedig egy megbízhatóbb MQTT kommunikációs protokol implementációján gondolkozom, az eszközök és az openhab között… Szóval az izgalmak még csak most kezdődnek (legalábbis annyi izgalom, amit az időm enged).
Újdonság viszont, hogy a projekt felkerült a github-ra, így az újabb dolgok már ott is megtalálhatók: https://github.com/voji/smarthome
Az előző Openhab-os post-ban a ping parancs segítségével állapítottuk meg, hogy egy adott eszköz elérhető-e a hálózaton, vagy sem. Ezzel a gyakorlati használat során több probléma is adódott. Példának okáért a telefonok teljesen ad-hoc módon eldobják a wifi jelet. Arról nem is beszélve, hogy az ‘{ exec=”<[‘ típusú változók a megadott polling intervallumon belül mindig frissülnek, aminek következtében az event log szépen szemetelődik a “Sh_VojiPcIsUp state updated to ON” üzenetekkel, akor is, ha nem változott semmi, az előző állapothoz képest.
Ha az IP cím és a wifi kapcsolat nem használható az aktuális helyünk meghatározására, akkor nem marad más, mint a GPS pozíció. Szerencsére ez az ötlet már másnak is eszébe jutott, és el is készítette az OwnTracks nevű alkalmazást. Az alkalmazás pont annyit tud, mint amire nekünk szükségünk van, időnként elküldi az aktuális helyzetünket, egy megadott címre.
Az első ilyen buktató, amibe belefutottam a HTTP alapú működés. Itt van fekete fehéren, hogy aki nem akar az MQTT-vel szívni (én pedig nem akartam, mert azt sem tudtam mi az, és úgy is rég php-ztem, gondoltam itt a remek alkalom, hogy kicsit újra elővegyem) annak készítettek egy szuper HTTP módot.
Ezen, és az ott látható példa POST híváson annyira fellelkesedtem, hogy telepítettem gyorsan egy apache-ot, beállítottam a plain http security-t (+ a fail2ban-t, amiről remélem Ti sem feledkeztek meg soha ha plain security-t használtok), készítettem php oldalt, ami megetetve a REST kéréssel tovább postolta azt az OpenHab rest api-nak…
Ami elkerülte a figyelmemet, az az oldalon lévő táblázat, ahol valami ilyesmi szerepel:
_type
iOS
Android
Usage
location
Y
–
Can return friend location objects.
Az egész oldalon a “-” jelnyi szó esik arról, hogy bármilyen szuper is ez a HTTP alapú kommunikáció, android-on sajna még nem csinálták meg. Én sajnos nem ebből jöttem rá, hanem abból. hogy bármennyire is kerestem ezt az opciót, nem találtam az alkalmazásban, és eztán egy forum post-ból, ahol éppen azon örömködnek, hogy mekkora királyság lesz ez a HTTP mode, és odaírták, hogy az Androidos verzió majd lesz… Amikor a “Spread the word, and tell us what you think about it” résznél tartottam, nagyon nagy önuralomról tettem tanúbizonyságot, hogy ennyi felesleges ráfordítás után sem írtam oda a véleményem.
Na de ne ragadjunk le a részleteknél, ha nincs HTTP mód, akkor csak az MQTT mód van, bármi legyen is az, jó ötletnek tűnt arra indulni. Az előzmények eltakarítása után (sok apt-get remove, és rm) el is jutottam a konklúzióig, hogy az MQTT egy message bróker, üzenetet lehet beküldeni, és aki fel van rá iratkozva, annak a kapott üzeneteket továbbküldi. Jan-Piet Mens aki a profilképén pont úgy néz ki mint egy shaolin pap (na nem mintha bármi bajom lenne a shaolin papokkal) egész érdekes dolgokkal foglalkozik. Többek között készített telepítési leírást az MQTT brókerhez Raspberry-hez, ami alapján a mosquitto-t én is telepítettem. A leírásban hivatkozott mosquitto-setup.sh-t is használtam, de azért ezzel óvatosan, nekem nem kicsit kusza beállításokat generált.
Telepítés után azok a dolgok amiket módosítottam a mosquitto configban:
Minden esetben kérjünk jelszót: allow_anonymous false
A jelszavakat itt tároljuk: password_file /etc/mosquitto/passwd
Kicsit visszavettem a logolásból, mert a debug azért túlzásnak tűnt: #log_type debug
Kulcsok helye, amit nem sikerült valami jól eltalálni elsőre
A titkosítás nélküli listener beállításait: listener 1883 127.0.0.1 ezt módosítottam: listener 1883
Az utolsó lépés nálam azért releváns, mert a szervert két helyről lehet elérni. LAN-on használható a 1883 port, ahol nem szükséges a titkosított adattovábbítás, kiajánlásra pedig úgyis csak a 8883 port kerül, ahol követelmény.
Ezután még létre kell hozni felhasználókat, melyre a mosquitto_passwd nevű programot használhatjuk, valahogy így:
A gyors konfiguráció után el is érkezett az ideje a tesztelésnek. Ezt a legegyszerűbben úgy tehetjük meg, hogy feliratkozunk a friss mqtt brókerünk várva várt eseményeire, és megnézzük, hogy érkeznek e. Ehhez első körben be kell állítani az OwnTracks alkalmazást,de ott nincs sok bonyodalom, megadjuk az ip címet, a felhasználói adatokat, és a szerveren generált ca.crt-t.
A sikeres beállítás után el is post-olja az alkalmazás az aktuális pozíciónkat, amit a képen pirossal keretezett ikon segítségével igény szerint tetszőleges számban megismételhetünk.
Ha már küldjük a szerverre az adatokat, érdemes lehet ezeket menteni is, hogy igény esetén vissza is tudjuk nézni, mikor merre jártunk, beazonosíthassuk a frekventált területek koordinátáit (vagy segítségével megkereshessük az elhagyott telefonunkat).
Erre az ot-recorder nevű alkalmazást érdemes használni, ami szintén az owntracks projekt része és elég jól használható, lekérdezhető. A telepítését nem kell túlbonyolítani, egy egyszerű apt-get-tel megoldható. Az indítása már keményebb dió, alapból nem készül hozzá init.d script, én pedig lusta voltam demonizálni, így nálam cron-ból indul.
Az indítást végző sh fájl:
A sikeres indítás és üzenetelvétel után elviekben láthatóvá vállnak az adatok a fenti címen.
Ha ez működik, akkor innen már egyszerű dolgunk van, el kell érnünk, hogy az openhab-ban is megjelenjenek ezek a pozíciók. Itt két irányban indulhatunk el. Ha csak arra van szükségünk, hogy valaki egy adott helyen tartózkodik e vagy sem, akkor használhatjuk az openhab számára készített Mqttitude Binding-et.
Én (vesztemre) ennél egy kicsit komplexebb dolgot képzeltem el, amiben fontos szerepe van az adott helytől történő távolságnak, és a mozgás irányának. Ezt oly módon tudjuk megvalósítani, hogy az Mqttitude binding helyett a sima mqtt bindinget használjuk. így ugyan nekünk kell az üzenetet parse-olni, távolságokat méregetni, státuszokat állítani, de bárki beláthatja, hogy minden ezzel töltött perc megtérül (nem).
Szóval akkor haladjunk sorjában, nézzük először a működéshez szükséges item-ek listáját:
Switch locSomeAtHome "Someone at home [%s]" &amp;amp;lt;house&amp;amp;gt; (S_Location)
String mqttPositionVoji "Voji Location Raw Data" { mqtt="&amp;amp;lt;[rpi:owntracks/voji/voji_phone:state:default]" }
Location locVoji "Voji Location" (S_Location, T_LocationMaps)
Number locVojiDistFromHome "Voji distance from home [%.1f m]" (S_Location)
Switch locVojiAtHome "Voji at home [%s]" &amp;amp;lt;phone&amp;amp;gt; (S_Location)
Itt a mqttPositionVoji a lényeges, ide érkezik az OwnTracks által küldött lokáció. A többi változó csak a számított értékek tárolására szolgál.
A kapcsolódó szabályok:
/*
* process mqtt location message
*/
val org.eclipse.xtext.xbase.lib.Functions$Function1 processLocationMsg = [
StringItem mqttLocationMsg |
val PointType homeLocation = new PointType("99.4484713,99.9011735")
val int homeRange = 100
val String userName=mqttLocationMsg.name.substring(12)
val String locItemName="loc"+userName
val String distanceItemName=locItemName+"DistFromHome"
val String locAtHomeItemName=locItemName+"AtHome"
val LocationItem locationItem = S_Location.members.findFirst[ name.equals(locItemName) ] as LocationItem
val NumberItem distanceItem = S_Location.members.findFirst[ name.equals(distanceItemName) ] as NumberItem
val SwitchItem atHomeItem = S_Location.members.findFirst[ name.equals(locAtHomeItemName) ] as SwitchItem
val String json = (mqttLocationMsg.state as StringType).toString
/*
* {"_type":"location","lat":99.4484713,"lon":99.9011735,"tst":1458648216,"acc":33,"batt":27,"tid":"ne"}
*/
val String type = transform("JSONPATH", "$._type", json)
if (type == "location") {
val String lat = transform("JSONPATH", "$.lat", json)
val String lon = transform("JSONPATH", "$.lon", json)
/*val String acc = transform("JSONPATH", "$.acc", json)
val String batt = transform("JSONPATH", "$.batt", json)*/
val PointType locationPoint = new PointType(lat + "," + lon)
if (locationItem!=null) {
locationItem.postUpdate(locationPoint)
} else {
logInfo("System", "Unable to update location, because item not found: " + locItemName)
}
val DecimalType homeDist = homeLocation.distanceFrom(locationPoint)
logInfo("System", "Updating location: " + userName + " Dist: " + homeDist.doubleValue)
if (homeDist&gt;homeRange) {
atHomeItem.postUpdate(OFF)
} else {
atHomeItem.postUpdate(ON)
}
if (distanceItem!=null) {
distanceItem.postUpdate(homeDist)
} else {
logInfo("System", "Unable to update distance, because item not found: " + distanceItemName)
}
} else {
logInfo("System", "Unknown location message. Type: " + type)
}
true
]
rule "MqttLocationChanged"
when
Item mqttPositionVoji changed
then
processLocationMsg.apply(mqttPositionVoji)
end
</pre>
Itt a mágia a processLocationMsg XBase funkcióban történik. A kapott String mqtt üzenetből kihámozzuk az aktuális lokációt (lat, lon), amit elrakunk egy PointType típusú változóba, és a kapott értékek alapján számolgatunk kicsit (például otthontól mért távolságot).
A funkciók használata során még annyi változás történt, hogy meguntam a paraméterek használatát, így egy változóhoz tartozó egyéb változókat név alapján próbálom előkeríteni. Ezáltal csak a megfelelő névkonvenciót kell tartani, és elég egy paramétert átadni a függvénynek.
És amikor azt hittem, hogy vége, azt tapasztaltam, hogy valamiért az egész mégsem működik. Olyan ötven méter után egy lokáció report sem érkezett meg. Mint kiderült ennek a T-Com által árult csoda Speedport W 724V dsl modem az oka. Ugyanis ha egy olyan dns bejegyzéssel találkozik, ami a külső lábára mutat, akkor azt meg sem próbálja belső címre fordítani, hiába van rá port forward szabály. Ezen a problémán sokat gondolkoztam, nem akartam a teljes belső hálózatomat feltúrni. A megoldás végül az lett, hogy a raspberry-re telepítettem egy dnsmasq csomagot, ami egy dhcp szerver, és egy dns forwarder, amit rendesen lehet konfigurálni. A modemen kikapcsoltam a dhcp-t, de gateway továbbra is maradt ő, és a dns fordításnál megadtam szabálynak, hogy ha belső hálózatról a szerver dns-ére hivatkoznak, akkor annak a belső ip címét adja meg.
Be kell vallanom, az első OpenHab post után azt hittem gyorsabban jön majd a folytatás, de időközben megérkezett a forrasztó kínából, az adafruit-os csomag Amerikából, de ezekről bővebben majd a a következő írások egyikében.
Az első openhab projekthez elviekben semmilyen okos eszközre nincs szükség. Okos ház helyett, az okos programokat vezérli, ezért bárki bármire használhatja. A cél egyszerű, ha elindítjuk a számítógépünket, álljon le a torrent kliens. Erre természetesen nem azért van szükség, hogy CS:GO alatt ne akadjon a játék, és nem is azért, mert a torrent szerver folyamatosan seedelne, vagy éppen töltene (ubuntu image-ket ofc).
A főbb funkciókhoz szükség volt pár shell scriptre, ezeket az sh könyvtárba raktam, kezdjük is ezekkel:
sh\hostup.sh – megnézi, hogy a paraméterül kapott IP elérhető e a hálózaton. Kimenete: ON vagy OFF
sh\qtorrentcmd.sh – a paraméterül kapott parancsot elpostolja a qtorrent szervernek. A lehetséges parancsokat nem sokat kerestem, elég a webes felületen kattintani, és firebug-ban szépen látszik, mikor mit küld a szervernek a böngésző.
sh\terraria_srv.sh – elindítja, vagy leállítja a terraria szervert. Ezt a netről loptam, sajnos a szerver idle állapotban is megeszik egy magot, ezért nem nagyon akarom, hogy állandó jelleggel fusson. Mivel console-ról lehet csak szépen leállítani, tmux-olni kell. Nem a legelegánsabb megoldás, de működik.
Mint az látható a openhab_base\items\default.items-ben a változók értékeit többnyire a scriptek határozzák meg.
A lényeg, hogy ha esemény változásnál futtatni szeretnénk valamit, akkor azt > jellel tudjuk (erre példa a Sh_qBittorrent változó), ha egy változó értékét szeretnénk külső program által meghatározni, azt pedig a < jellel (erre példa a Sh_VojiPcIsUp változó). A szintaxis kicsit fura (pl. a program paramétereket a @@ jelöli), és a frissítés gyakoriságát :10000: formátumban kell megadni.
A projekt tartalmaz még példát a wake on lan funkcióra, valamint az astro modulra, aminek segítségével a napfelkeltét, és a napnyugta idejét tudjuk követni. Ez majd a jövőben lesz érdekes, amikor a világítás is képbe kerül.
Ha a változóink megvannak akkor erre tetszőleges szabályokat készíthetünk. Ezek annyira egyszerűek, hogy nagyon nincs is mit hozzáfűzni. De nem árulok el nagy titkot, ha azt mondom, hogy nem lesz ez mindig így 🙂
A sitemap pedig egy lehetséges kinézete a jelenlegi működésnek, almenükkel, kategóriákkal.
Az gyorsan eldőlt, hogy az otthoni okos eszközök vezérlését az OpenHab végzi majd. Hogy miért annak számtalan oka van. Pl. azért mert ilyen eszközök vezérlése tervezték, mert nyílt forráskódú, ingyenes, és végezetül java-ban írták… Egyébként ez utóbbiért már csak szakmai érdeklődésből is szétkaptam volna, hogy megnézzem, hogy működik
Az OpenHab telepítését nem is boncolgatnám nagyon, Linux alatt elég egyszerű telepíteni apt-get-el a fejlesztők által készített telepítési leírás alapján. Windows alatt is hasonló a helyzet, csak apt-get nélkül 🙂
A telepítés után létrejön pár fontos könyvtár, melyek az alábbiak:
/etc/openhab – nem meglepő módon ide kerülnek az alkalmazás konfigjai
/var/log/openhab – ide pedig az alkalmazás logjai
/usr/share/openhab/webapps/images – itt vannak azok a képek, amikre hivatkozhatunk a konfigurációnkban
/usr/share/openhab/addons/ – itt pedig a feltelepített binding-ek
Bindingeket is érdemes apt-get-tel telepíteni, mert így maguktól tudnak frissülni.
Akárcsak a zenei masterre, az OpenHab telepítésre is igaz, hogy a kevesebb néha több. Tehát mindig csak azt a bindinget telepítsük fel, és azt a feature-t konfiguráljuk be, amit tényleg használni szeretnénk. Én kicsit problémásnak éreztem, hogy minden addon konfigurációja bele van rakva az openhab.cfg-be, ami ezáltal egy 2000 soros. Ebből a kezdeti setupban kb. 5 sort kellett módosítani, és ebben már a levélküldés beállítása is benne volt, a többi irreleváns.
Még mielőtt a tényleges implementációba belefolynánk tekintsük át az OpenHab főbb komponenseit:
Addons: ezek azok az opcionális komponensek, amik segítségével bővíthetőek az openhab alaprendszer funkcionalitásai. Ebből elég sok féle van, amik általam használatra kerülnek egy egy projekt kapcsán azt igyekszem majd leírni. Gyakorlatilag ezek a külső interfészek a HW eszközök, és minden más rendszer felé
Items: az eszközeink leírásai. Ide nem csak a fizikai eszközök tartoznak, mint pl. a villanykapcsoló, és az okoségő, hanem különböző logikai eszközök is létrehozhatóak (pl. számítógép be van e kapcsolva állapotjelző, amihez semmilyen HW érzékelő nem tartozik)
Rules: szabályok amik azt írják le, hogy bizonyos esemény bekövetkeztében (ez leggyakrabban időzítő, vagy eszköz állapot változás) mi történjen.
Sitemaps: itt tudjuk leírni, hogy az általunk definiált eszköz listából mit mutasson a rendszer a felhasználóknak, és hogyan. Én egy apró design flaw-nak tartom, hogy ide nem csak a mit rész került, hanem a hogyan rész is, mert ez a csoportok kezelésénél elég érdekes helyzeteket szül (csoport kezelés kapcsán már nem tudjuk befolyásolni a csoporton belüli item-ek megjelenését), de ne szaladjunk ennyire előre.
Ahhoz, hogy az OpenHab egyáltalán működjön, a fenti dolgokból létre kell hozni valamit, ellenkező esetben a program egy elegáns exception-nel, és call stack-al jelzi, hogy nincs default.sitemap. Az átlag felhasználó valahol itt adja fel a harcot (elég sok fórumon felmerül a probléma, hogy ez az exception jön, és ilyenkor mi a teendő).
Szégyen gyalázat, de ezen a ponton én is elakadtam. Az ötlet az volt, hogy dropbox-ba rakom a konfigurációmat, és majd symlink-el berakom a dropbox-bol a configurations mappát a /etc/openhab/ alá. Beletelt fél órába, amire rájöttem, hogy nem a kezdeti konfigurációval lesz itt a gond, hanem az openhab valamiért nem olvassa fel symlink-en keresztül a konfigurációt…
Hardlinkelni nem akartam, így maradt a fapados felhőtlen megoldás: kiajánlottam a /etc/openhab mappát samba-n, és raktam bele még pár symlink-et az images, és a log könytárra.
Az OpenHab konfigurációkat, rule-okat célszerű az OpenHab Designerrel csinálni, mert azon felül, hogy ellenőrzi a beírt kódokat, fel is tudja ajánlani az adott helyen alkalmazható kulcsszavakat. A designert windows alá sajnos csak 32bit-es jdk-ra fordították le (nem tudom miért). Ha esetleg valaki 64 bit-es jvm-et használ, akkor megszívja. Ebben az esetben az alábbit kell tenni:
Kitömöríteni a designert egy számára választott könyvtárba. Ide létre kell hozni egy jvm könyvtárat, amibe bele kell telepíteni egy 32 bit-es portable java-t. Ezután az openHAB-Designer.ini fájl elejére be kell szúrni az alábbi sort:
-vm ./jvm
És már működik is. Kezdetben érdemes a demo konfigurációból kiindulni, és kitörölgetni ami nem kell, aztán szépen lassan építgetni a saját rendszerünket a példák, és a gyűjtött tapasztalatok alapján.
Már egy ideje játszok a gondolattal, hogy milyen jó lenne ha bizonyos dolgok maguktól működnének otthon. Eddig mindig elvetettem az ötletet, mert bárki bármit mond, egy ház pont annyira tud okos házként működni, amennyi okos eszközt beletelepítenek, és azok a házak, amiket nem eleve ilyen céllal terveznek, sajnos igen komoly hátrányból indulnak.
De hát egy kis okosság nem árthat, ezért gondoltam teszek egy kis lépést, és beszereztem pár milight égőt. Az egyik ismerősöm ajánlotta, akciós, mit veszíthetek.
A terv az volt, hogy szépen bekötöm a hálóba, és munkanapokon reggel 7 körül elkezd majd feléledezni, én pedig erre felébredek, vagy ha nem is erre, de mindenesetre könnyebben mintha csak az óra keltene.
Sajnálatos módon a csomagban rögtön 4 izzó volt, ezért elkezdett bonyolódni a dolog.
Szerverem, milight API van, a cron és egy egyszerű bash script megoldja jól az égőkapcsolgatás nem túl komplex problémáját, nincs miért aggódni.
Aztán az api-k olvasgatása közben ráakadtam az OpenHab-ra, amit pont ilyen eszközök kapcsolgatására találtak ki. Miközben épp mindenkinek az okos égőimmel dicsekedtem, amikor a barátom csak annyit mondott, hogy nagy dolog, nála már egy ideje a raspberrypi vezérli a fűtést…
Azt hiszem ez volt az a pillanat, amikor tudtam, hogy elvesztem. Én is akartam weboldalról vezérelhető fűtést, grafikont, mobilklienst… És azt hiszem ezzel egy időben kezdett jelezni egy apró kis lámpa is a fejemben, hogy megint egy olyan területre sodródtam, ami rengeteg időt elrabol majd az életemből… De hát mint tudjuk az élet kegyetlen, és mint mondtam, szerverem már úgyis volt, szóval el is kezdtem a tervezgetést 🙂
Azóta foglalkoztam már a relékkel, gpio protokollal, kábelekkel, ellenállásokkal, hőmérőkkel, és egy rakat programmal mindezekhez… De igyekszem tartani magam a fokozatosság elvéhez, így a fűtésvezérlés projekt már csak nyárra marad, akkor talán nem lesz annyira nagy probléma, ha pár hétig nem jó a fűtés.
Első körben összeszedtem az elvárásokat az új rendszerrel kapcsolatban:
Ha hazajövök, kapcsolódjanak fel az ajtó előtti, és folyosói lámpák
Ha bekapcsolom a TV-t akkor a nappaliban tompuljon le a világítás
Ugyanez a számítógépnél
Munkanapokon reggel szépen fokozatosan kapcsoljon fel a lámpa a hálóban
Ha elmegyek otthonról minden lámpa kapcsoljon le
Ha bekapcsolom a számítógépemet, álljon minden olyan ami jelentős hálózati forgalmat generál (pl. a qbittorrent amivel rendszerint a legújabb ubuntu iso-kat töltöm le)
+ fűtés vezérlés
Természetesen mindezt lehessen vezérelni egyszerűen, és lehetőleg mindenhonnan (számítógép, telefon, tablet, és társai) ahol van internet.
A megvalósítás során fontos szempont volt, hogy ha megáll a szerverem, akkor ne álljon meg minden, ezért a hagyományos lámpa funkciókat is meg szeretném tartani. Szerencsére minden szobában 3 kábelt húztak fel a lámpákhoz. Egyet összekötök fixen (kapcsolótól függetlenül lesz benne áram), ez megy majd az okos égő foglalatába, a lámpa többi része pedig hagyományos lámpaként funkcionál majd tovább. A fűtés esetén pedig a termosztát kábelét osztom ketté, így egy váltókapcsolóval bármikor vissza lehet majd állni a hagyományos termosztát alapú vezérlésre.
Ennyit a nagy tervekről, az elkövetkező postok várhatóan a megvalósításról, buktatókról, és a vég nélküli szívásokról fog szólni… Addig is olvassátok a devttys0 blog-ot, hogy még időben elmenjen a kedvetek az okos eszközöktől, és megkíméljétek magatokat mindattól ami még előttem áll 🙂
