A netflix már egy ideje hivatalosan is elérhető Magyarországon. Aztán lokalizálták a honlapot is magyarra, és az utóbbi időben elszaporodtak a magyar feliratok, és ami meglepett a magyar szinkronos filmek is. Bár ezekre az embedded app-okon belül nem nagyon lehet keresni, és a webes felületen se triviális, az alábbi linket megnyitva szépen le lehet szűrni a magyar nyelvű contentet:
Spotify számcímek a lejátszási listákból
Ha valaki ki szeretné másolni a spotify playlist-ből az előadók és számok címeit, akkor az alábbi javascript kóddal érdemes próbálkozni:
var tracks = document.getElementsByClassName("track-name-wrapper");
for(var i = 0; i < tracks.length; i++)
{
var trackTitle = tracks[i].getElementsByClassName("tracklist-name")[0].innerHTML;
var trackArtist = tracks[i].getElementsByClassName("tracklist-row__artist-name-link")[0].innerHTML;
console.log(trackArtist + " - " + trackTitle);
}
A router, az agy, és két füstölgő puskacső
Olyan szerencsés helyzetben vagyok, hogy az utcánkban fellelhető pokoli ADSL vonalat már jó ideje optikára cserélte a T. Mivel a média fogyasztási szokásaink teljes egészében átcsatornázódtak az online felületekre (Netflix, HBO online, Youtube, Twitch, Spotify és társai), az internet előfizetést is átcsoportosítottam, és a kábeltévé helyett lett az 1000mbit/s .
Elsőre ez jól hangzik, de az ördög a részletekben rejlik. Pl. a T által adott modem még elméletileg sem tud ennyi adatot átengedni magán, kezelni aztán meg végkép nem. Ezt gondolom ők is érezték, ezért adtak mindenféle instrukció nélkül egy D-LINK (brrrr) DIR-842-es “router”-t.
A koncepció az lehetett, hogy bár a noname kínai modem nem tudja kihajtani a vonalat, ha a D-LINK-et használjuk erre PPPoE módban (tehát kvázi modemként) akkor valamivel jobb lesz a helyzet. Ezzel a setup-al kb. 600-800mbit/s már elérhető az 1000-ből ha nem nagyon terhelt a hálózat. Gondoltam egy PPPoE beállítás nem okozhat gondot (első hiba). Már a PPPoE jelszóval elakadtam, amit bár láttam a T-COM-os modem felületén, de csak jelszó mezőként. Visszaalakítottam text-é ami egy elkódolt karaktersorozatot tartalmazott. Sikerült firmware-t találnom hozzá, amúgy is szeretem az ilyen cuccok dolgait nézegetni, pár óra alatt meg is lett a kódolást végző script, meg nekem a python átiratom hozzá, így már nem csak felhasználónevem, hanem jelszavam is volt.
Széttúrtam az addigi infrastruktúrát, bekötöttem a routert ami az átvétel óta a polcon porosodott, és vártam a széles sávú csodát.
Ennyi élettapasztalattal már tudom, hogy csodák csak ritkán vannak (ezért hívják őket csodának), így meg sem lepődtem, amikor az internet kapcsolatot jelző ikon továbbra is pirosan világított.
Olvastam kicsit a neten, elviekben összedugdosás után mindennek magától kellene működnie, ezzel is elment pár óra, végül csak felhívtam az ügyfélszolgálatot, ahol a szokásos intró után (tududu du dummmm) egy AI-nak kellett volna elmagyaráznom, hogy nem működik a PPPoE kapcsolatom… Elég jól elbeszélgettünk, aminek átirata valahogy így nézett ki:
- Üdvözlöm, én az ostoba AI vagyok, amit rengeteg pénzért eladtunk a TCOM-nak, felismerek szavakat amiket hallok aztán majd lesz valami
- Szia, én az ügyfél vagyok, és nem működik a PPPoE kapcsolatom
- Az interneteléréssel van probléma?
- Igen
- Hálózati probléma van?
- Nem
- Az Internet eléréssel van probléma?
- ….
A végén már egész jól tudtam, milyen szavakat kerüljek a kommunikációnk során, és akkor 2-3 teljesen felesleges kör után az ügyintézőhöz kapcsol… Ezúton is köszi valakinek, aki kitalálta ezt a szart, és jár a gratuláció annak aki meg is vette.
Ezek után megtudtam, hogy PPPoE jelszót meg tudom változtatni online is, ezt a kört meg is futottam (feleslegesen, mert mint kiderült jól fordítottam vissza a jelszót, nem az volt a gond), továbbra sem lett jó. Ismét telefonáltam, AI, várakozás, elmondták, hogy ők nem tudják, kérdés van e internet PPPoE nélkül. Mondom van. Hát akkor ők nem tudják, ők csak a routerig érdekesek, hívjam a fizetős ügyfélszolgálatot.
Itt volt az első pillanat, amikor legszívesebben elővettem volna azt a bizonyos puskacsövet, és bementem volna az ügyfélszolgálatra ügyet intézni. De mivel én ilyen visszafogott csávó vagyok, puskacsövek nélkül, 3-4 órányi beszélgetés után úgy döntöttem lesz ami lesz, felhívom a fizetős ügyfélszolgálatot (szuperszervíz), ahol a srác tényleg értelmesebb volt mint a másik helyen az összes többi együtt, és korrekt is, mert elmagyarázta, hogy ez pénzbe fog kerülni ha segít, de igazából nem is tud segíteni, mert ezt a problémát a T ingyenes ügyfélszolgálata tudja megoldani, mégpedig úgy, hogy átkapcsolják a fos modemjüket PPPoE módba. Abban maradtunk, hogy ne mondjak bonyolult mondatokat, ne is próbáljam meg elmondani, hogy miért meg hogyan, csak azt mondjam hogy “modem -> PPPoE mód -> bekapcsolás”. Akkor hátha átmegy az üzenet.
Felhívtam őket, lekűzdöttem az intelligens asszisztenst (az uborkákról és a paradicsomokról beszélgettünk), hogy aztán egy vele egyszintű emberi hasonszőrűvel kb. 25 perc várakozás után lefolytassam a következő beszélgetést:
- Legyen kedves átkapcsolni a modememet PPPoE módba
- Ööö nem tudom miről beszél, de átkapcsolom egy technikus kollégákhoz
Ez volt az a pont, amikor már csak 30 perc választott el attól, hogy a technikus kolléga az én “régi” eszközömet távolról PPPoE módba tudja kapcsolni. Hittem benne, hogy meg tudja csinálni, kb. 3x mondta, hogy egy pillanat, még kipróbálok valamit, és én egyszer se mondtam el neki Yoda mester örök érvényű szavait: tedd, vagy ne tedd, de ne próbáld… Pedig sokszor eszem bejutott…
Ezek után el is indult az internet, és jött a következő állomás, az igen neves D-Link cég routernek nevezett terméke, ami egész addig működött, amíg nem próbáltam beállítani rajta pár port forward szabályt. Aztán kicsit önellentmondásba keveredett a saját route szabályaival, és bizonyos kérések hatására meg-megállt pár percre. No meg egy port forward szabály se működött…
Sajnos az OpenWrt, DDWrt körről pont egy hw revízióval maradtam le, szóval ez a router max wifi AP-nek használható… Sebaj, ahogy a mondás tartja, ingyen routernek ne nézd a firmware-jét, elkezdtem hát inkább más routereket nézni.
A router piac teljesen megváltozott mostanában. Vannak már Gaming routerek, amik erősen középkategóriásak, és mind wifi-s. Az áruk nem azért sok, mert annyira tudnak route-olni, meg csomagokat kezelni, hanem mert a legszuperebb wifi szabványokat támogatják, ami nekem pont nem kell. De ha kellene se fizetném ki egy kisebb számítógép árát, egy wifi routerért, ami sok mindent tud, de gyorsan, és jól routolni azt pont nem. Ami tényleg jó, és bír sok klienst, meg nagy sávszélességet az kb. 80k és még wifi sincs benne. Mivel a PPPoE már megvolt, a szerverem úgy is mindig megy, gondoltam átrakom a router funkcionalitást oda. Ott nem lesz melegedési gond, és a PPPoE, routing, és társai kb. nem kimutatható cpu kapacitást emésztenek fel egy mai gépen. Ezzel egy probléma volt, amit pedig úgy hívtak, Microsoft.
Tudtam, hogy nem lesz egy leányálom Windows 8 alatt routing-ot konfigurálni, főleg olyat, ami nekem kell.
Ez az a pont, ahol megint számot kell vetnem magammal, és leírnom, miért is váltottam windows szerverre:
- akkor és ott jó ötletnek tűnt
- szeretem a kihívásokat
- van rajta onedrive kliens
- van rajta norton antivírus amiből volt egy privát előfizetésem
- unalmas volt, hogy ubuntu alatt minden átlátható, és általában működik is
Szóval a PPPoE kapcsolat felkonfigurálása gyorsan ment. Van ott egy kis kavar, hogy a fizikai interfész furcsa státuszban marad amin a kapcsolat megy, de kikapcsoltam róla minden protokollt, akkor már nem sok vizet zavart. Az internet megosztásért az Internet connection sharing felel, pár kattintás, és láss csodát működik. Pontosabban: működik, olyan microsoft-osan.
Egy demo erejéig ezek a funkciók nagyszerűek, és jól prezentálhatók. Csak éppen a megosztás után a teljes belső subnet-em elmászott a 192.168.137.x tartományba. Gondoltam sebaj, kerestem a neten, meg lehet változtatni. Meg is változtattam, itt:
HKLM\System\CurrentControlSet\services\SharedAccess\Parameters
(REG_SZ) ScopeAddress
(REG_SZ) StandaloneDhcpAddress
Ezek után már volt DHCP szerverem, csakhogy olyan módon, hogy a létező teljes címtartományból oszt címeket… Hogy mi alapján rejtély. Ez nem annyira jó, mert nálam nem minden DHCP-ről megy, és van pár dolog aminek akkor is fix ip kellene, ha arról menne (pl. QoS miatt). Na range definíciót, vagy hw adress mapping-et persze már nem tud. Gondoltam sebaj, elengedem, használok másikat, vagy konfigurálok egyet linuxon, de ezt a csodát kikapcsolni se nagyon lehet. Én az alábbit tettem: a lan interfész IP címét megváltoztattam az ICS beállítás után, a registryben pedig egy másik címtartományt adtam meg. így valamiért a routing működött (talán mert az interface alapú…) de a DHCP szerver nem tud mit kezdeni magával és az eltérő címtartományokkal, ezért el sem indul (erről persze se log, se dokumentáció, se semmi). Innentől már csak az OpenDhcp szervert kellett telepíteni, és volt is normális belső hálózatom DHCP-vel, windows alatt.
Aztán ott van a windows tűzfal, a maga 100000 szabályával. Ezt elég egyszerűen bekonfiguráltam. Letöröltem mindent, felvettem azt a 6 szabályt ami nekem kellett (Deny All, Allow lan, pár port), és láss csodát működött. A windows tűzfal nem rossz, csak szerintem külön csapat csinálta a tűzfalat, és a front-end konfigurációt.
Miután már tűzfalam is volt, csak a port forwarding volt hátra. Ezt a PPPoE adapternél az ICS beállításoknál lehet matatni, egyszerű: Port, hova, protokoll, és kész is. Elméletben. Minden forgalom, ami a szerverre érkezett, az működött. Minden ami külső szerverre (pl. a virtual box-ban futó ubuntu-ra) az nem. Ezzel futottam pár kört, a megoldást végül szintén egy külső alkalmazás jelentette: a PassPort ami egy egyszerű port forwarding implementáció. Tehát a WAN lábról forwardoltam a portokat a szerverre, a szerverről ezzel a belső hálózatra, és így már működik.
A fenti problémák elviekben korrektebbül megoldhatóak Windows server edition alatt (ott pl. van RRAS is), de nekem nem ilyen windows-om van 🙂
A QoS-t már tényleg point and click-el beállítottam, azok a fejlesztők valószínű a tűzfalas fejlesztőkkel voltak haverok 🙂
Ezek után jött a teszt, ami egy egyszerű Ookla-s speedtest volt. Az eredmény egy kék halállal egybekötött kernel security check volt… Itt már kicsit elvesztettem a lelkesedésemet, és nagyon csúnyán kezdtem nézni a norton antivírusra. A csúnya nézésből a 3. konfigurációs próbálkozás és kifagyás után uninstall lett, és láss csodát. 2-3 nap alatt talán sikerült a windows 8.1-ből egy normális router gépet faragni…
Klímaváltozás és az autók
A napokban volt egy előadás a Széchenyi István Egyetemen, ami eredetileg azt boncolgatta volna, hogy mikorra tűnnek el a mostani robbanómotoros autók. Az előadást Dr. Hanula Barna tartotta, aki jelenleg a járműmérnöki kar dékánja, de tanítás előtt 22 évig az iparban dolgozott mint motorfejlesztő mérnök, így van némi rálátása a témára. Egy óra nem kimondottan sok egy ilyen előadásra, de a felszínt kapargatva is feltűnhet, hogy nem annyira egyszerű ez a kérdés, mint amennyire sokan látni szeretnének.
Akinek van egy kis ideje, nézze meg, megéri:
EXCEL LastIndexOf
Ilyen valamiért nincs, pedig néha hasznos lenne. Gondoltam írok egyet, mert miért ne, úgy is rég visual basic-eztem:
Function LastIndexOf(src As Range, char As String)
Dim value As String
Dim valueLen As Integer
value = src.Cells(1, 1).value
valueLen = Len(value)
For i = valueLen To 1 Step -1
If Mid(value, i - 1, 1) = Left(char, 1) Then
LastIndexOf = i
Exit Function
End If
Next i
End Function
Használni így kell: =LastIndexOf(A1; “d”)
Proteus is here, ez a jó hír
Egész sokat arduino-ztam, és meglepő módon későn botlottam bele a Proteus-ba, ami eredetileg egy áramkör tervező/modellező cucc, de mellesleg egy egész jó arduino emulátor. Azóta a sarokban porosodik a breadboard, és a kábelkötegek, éljen a digitális világ, és a mérnöki tervezés.
A proteus alapesetben egy fizetős cucc, de aki ki szeretné próbálni innen tölthet egy működő verziót.
A telepítés után még játszani kell vele kicsit, fontos, hogy a MODELS könyvtárban található módosított fájlokat nem csak a telepítés helyén (alapesetben: “c:\Program Files (x86)\Labcenter Electronics\Proteus 8 Professional\MODELS”) hanem a library könyvtárban (alapesetben “c:\ProgramData\Labcenter Electronics\Proteus 8 Professional\MODELS”) is cserélni kell, különben a másolásvédelem miatt a szimuláció crash-elni fog… Nincs mit tenni, ezek a drm rendszerek már csak ilyenek.
Ha már van egy működő Proteus-unk, akkor érdemes képbe kerülni pár alapfunkcióval. Valamiért túlnyomó többségben indiaiak készítenek oktatóvideókat ehhez a szoftverhez, és ők megmagyarázhatatlan okból az arduino IDE-vel fordítanak, és a fordítás eredményeként előálló hex fájlt töltik be a virtuális arduino chipre. Ez is egy lehetséges mód, de erre a célra sokkal egyszerűbb magát az eszközt használni, arduino IDE nélkül.
Projekt létrehozásnál használhatunk üres projektet, de a legegyszerűbb a From Developement Board opciót választani:
A program pont olyan fapados mint a CAD szoftverek általában (úgy látszik ez minden CAD szoftver speciális képessége), de egy idő után meg lehet szokni / szeretni.
Alapesetben az egyes tool csoportok nincsenek hotkey-hez rendelve, én a Cubase vonalat követtem, szépen hozzárendeltem az összes főbb funkciót az 1-9 számokhoz. Itt fontos még a P betű, azzal lehet új dolgokat felvenni a palettára, amit aztán az áramkörünkhöz csatolhatunk. Ezek közül a fontosabbak:
– RES: ellenállás
– BATTERY: egyenáram forrás
– BUTTON: gomb
– LED-YELLOW: sárga led
A kábeleket egyébként nem kell direktben összekötni, használhatunk helyette címkéket (Wire Label). Ha két kábelvégnek a címkéje azonos, akkor a program úgy veszi, hogy összekötöttük őket. Ez első ránézésre szokatlannak tűnhet, de végeredményben sokkal átláthatóbbak lesznek a tervezett dolgaink.
Általános szabály, hogy az adott elemek tulajdonságait dupla klikkel tudjuk megnyitni, ahol az eszköz paramétereit állíthatjuk:
Az arduino esetén az Edit Firmware gomb dob át a kód editorra, ahol standard arduino kódot írhatunk (nem kell külön fordítgatni, a szimuláció indítása során fordul).
A PROBE és INSTRUMENTS fülön találhatók a virtuális mérőműszerek. Itt az alap dolgokon felül van pár igen hasznos tool, mint pl. terminál emulátor, i2c, spi debugger és társai.
Az Arduino Blink projekt fájl innen letölthető
Az mindenképp a szimuláció mellett szól, hogy egy egy hibát sokkal kevesebb füsttel meg lehet úszni, mint ha IRL próbálná ki a dolgokat az ember…
Windows és a fájlnevek
Azt hittem a “hosszú” fájlnevek problémája csak az emlékeimben él, és a minket követő generációk számára ez a fogalom (akárcsak a ~1 végű fájlok) ismeretlen lesz. Úgy tűnik a Windows ezt másképp gondolja, Ő még őrzi a régi hagyományokat:
Én tényleg nem tudom ki, és mit üzemeltet windows alatt, de minden tiszteletem az övé…
Céges karácsony
Nem titok, hogy az IT területen mozgó emberek a legtöbb céges eseményt kicsit másképp élik meg, mint más területen dolgozó kollégáik. Nem kivétel ez alól a céges karácsony sem. Az általános IT-s karácsony élményt vau tökéletesen összefoglalta, a céges karácsonyi buli című írásában.
Mivel abban a szerencsés helyzetben vagyunk, hogy nálunk szinte mindenki az IT területen dolgozik, adott volt a lehetőség, hogy olyan karácsonyi bulit szervezzünk, ami nekünk IT-soknak tetszik. A játszunk számítógépes játékkal alapvetést nem akartam én kijátszani, mégiscsak játékfejlesztésből kerültem a vállalati szektorba, és a világért sem szerettem volna a saját érdeklődési körömet ráerőltetni másokra. Szerencsére más irányból is felmerült ez az ötlet, és ha már így alakult nem is volt kérdés, hogy belevágjunk a projektbe.
A döntés megszületése után az első problémát maga a játék kiválasztása jelentette. Skill-t követelő játék nem nagyon jött szóba, hiszen mind játéktapasztalatban, mind korban nagyon nagy volt a szórás.
Végül a választás a Bomberman ’93 nevű klasszikusra esett. Az irányítása egyszerű, bármin elfut, és lehet egyszerre 4-en játszani.
Hogy senki ne tegyen jelentős előnyre szert, magát a játékot egészen a kezdésig titokban tartottuk. A játék, irányítás bemutatására készült egy rövid prezetnáció, de aki ezt mellőzni szeretné, használhatja az eredeti kézikönyvet is:
A fordulókat kétfős csapatokkal játszottuk, melyek kialakítása során az volt a feltétel, hogy a csapattársnak egy másik területről kell jönnie. Ez okozott némi kavarodást, de abban bíztam, hogy ezáltal nem lesznek túl erős csapatok, hiszen a csapattársak kevésbé ismerik egymást, és a cégen belül is felpezsdül a területek közötti kommunikáció. A csapatok kialakítására egy egyszerű Google Sheets-et használtam. A szükséges ellenőrzési logikát (validateTeamData) pedig megírtam gscript-ben. Nem lett hibátlan, de a célnak tökéletesen megfelelt.
Mivel a játék turbografx-16-on jelent meg, így a választott emulátor a mednafen lett, retroarch alól futtatva. Még meg kellett oldani az irányítást, amire eredetileg usb-s nes controllereket szerettem volna beszerezni, de a létszámra, és az idő rövidségére való tekintettel ezt végül elvetettem. Maradt az 1 gép, 1 monitor, 2 billentyűzet felállás, billentyűzetenként két játékossal.
A billentyűzetek controllerként viselkedjenek két dologra volt szükség: a vJoy-ra ami mint neve is mutatja virtuális joystick vezérlőket gyárt, és a Virtual Controller-re, amivel a virtuális joystick-okat a billentyűzetek bemenetével lehet etetni.
Szerencsére az egyszerű vezérlés miatt (4 irány 1 gomb) a vJoy beállítások nem lettek valami túl bonyolultak:
A Virtual Controller kapcsán már kicsit összetettebb a dolog:
- A billentyűzet kezelést át kell állítani Raw módra, hogy a 2 billentyűzet ne akadjon össze (Options – IO Devices – Input – Keyboard Settings – API: RAW Input)
- Engedélyezni kell a vJoy támogatást, hogy a cél eszköz lehessen a vJoy (Options – IO Devices – Output – vJoy Settings – Enabled: true)
- Meg kell csinálni a mapping-eket a Controls menüpont alatt, a Quick Binding menü segítségével. Ez nekem nem működött tökéletesen, de jó alapot adott, hogy mit is kellene összerakni kézzel. A végleges fájl letölthető innen: bomberman.bnd
A kész beállítások tesztelhetők a Monitor vJoy alkalmazással:
Sajnos a RetroArch konfigurálás nem volt olyan egyszerű mint elsőre gondotlam, ugyanis else if van a retroarch binding kódjában. Tehát ha kapott billentyűzet inputot, akkor már nem nézte a joystick inputot. A megoldás végülis az lett, hogy készítettem egy mapping-et a Virtual Controllerben Xbox 360 controllerhez vJoy-ra, ezzel már tudtam menteni a vJoy beállításokat a RetroArch-ba. Még 3x megismételni a beállítást nem sok kedvem volt, ezért a többi játékos esetén már kézzel szerkesztettem a config-ot a retroarch.cfg-be. Ezen felül törölni kellett minden bind-ot (az F1 és az ENTER kivételével), hogy a véletlen mellégépelésekből ne legyen probléma.
A Windows kapcsán a szokásos “gamer” beálllításokat kellett megtenni:
- Power Options – High performance profile
- Power Options – Ne kapcsolja ki a gépet / monitort / merevlemezt
- Intel HD – Disable Hotkeys
- Disable Sticky keys
A csapatok állását a challonge.com-on vezettem, kicsit aggódtam is, mi lesz ha lehal a szerver, de szerencsére nem halt le.
A döntőt streamelni szerettük volna kommentátorokkal, de végül ez technikai okok miatt nem sikerült.
Persze mint minden ilyen rendezvénynél, itt is voltak technikai problémák, és olyan dolgok, amiket lehetett volna jobban csinálni. Iyenek pl.:
- A billentyűzetekre lehetett volna nyomtatni színes matricákat, amik mutatják, hogy melyik helyről melyik játékost irányítjuk
- Jól jött volna egy a csapatokról, és csapattagorkról készített fényképes tabló, hogy ha épp kerestünk egy csapatot vagy tagjait, akkor gyorsabban megtaláljuk
- Streamelni vagy dedikált capture card-al, vagy arra alkalmas hw támogatással lehet (ShadowPlay / ReLive). Az OBS software streaming használhatatlan (belassult / begagyott tőle az emulátor)
- Mindent a saját letesztelt infrastruktúrával kell megoldani. Pl. építettem az iroda wifi-jére, de arra nem számítottam, hogy az ipad amin a pontokat rögzítettem nem fogja túlzottan kedvelni azt.
- A windows update-t is érdemes kikapcsolni, mert az egyik gép az esemény előtt 3 órával internet kapcsolat nélkül rájött, hogy 160 frissítést fel szeretne telepíteni, amibe aztán belebukott, aztán megpróbálta a módosításokat visszavonni…
Az esemény a malőrök ellenére úgy gondolom jól sikerült, legalábbis elég sok pozitív visszajelzés érkezett. Örültem, hogy olyan menő kollégáim vannak, akik kortól / nemtől függetlenül ezt az egészet bevállalták. Szívbemarkoló volt a pillanat, mikor még a szabad játék alatt minden gép előtt ültek, és akik nem fértek oda a váluk fölött nézték, hogy ki hogy játszik, elemezték hogy mi a jó taktika. Tisztára mint egy retro számítógépes klubban.
Már csak ezért is megérte. No meg az érmekért…
(Mellesleg az éremmel sokat szívtam, mert a rajta látható képet nem volt egyszerű megtalálni… Az eredetit végül itt leltem fel, amiről még az izzadságcsepepket is le kellett varázsolni 🙂 )
PID alapú fűtésvezérlés
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):
https://apmonitor.com/pdc/index.php/Main/ProportionalIntegralDerivative
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.
Smarthome@github
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