Windows PC optimalizálás

Réges rég elkövettem azt a hibát,  hogy windows alapú gépen kezdtem el zenélni. Aztán hozzászoktam, megszerettem, és bár azóta volt szerencsém más operációs rendszereket is kipróbálni, a végén mindig visszatértem hozzá. A számítógépen történő zenélés nagyon furcsa dolog, ha menet közben bármi megakad, akkor lehet újracsinálni a munka egy részét, és vannak olyan pillanatok, amiket később már nem lehet, vagy nagyon nehéz újracsinálni, tehát ehhez egy elég stabil rendszer kell. Sokan ezen a ponton alapból lemondanak a windows-ról, pedig kitartó munkával (és nem kevés utánajárással) meglepő eredményeket lehet elérni, hozzáállás kérdése az egész. Míg egy debiant szépen lassan épít fel az ember, a windowsnál épp az ellenkezőjét kell csinálni, szépen lassan lebontani a rétegeket.

tl;dr: Az optimalizált windows olyan mint egy jó versenyautó: Gyors, de egyáltalán nem kényelmes. Átlag felhasználóként a driverek frissítése az egyetlen szükséges lépés, a többi beállítás inkább problémát fog okozni, és érezhető előnyt nem jelent.

Mi is az optimalizálás célja: az alkalmazásunk működése és a hw komponensek között a lehető legkisebb késleltetés történjen, és ebbe az operációs rendszer lehetőleg ne keverjen bele.

Hardware:

  • lehetőleg dedikált hangkártyát használjunk (pci / firewire)
  • az usb eszközök számát minimalizáljuk (ps/2 billentyűzet)
  • usb hub-ot semmiképp se használjunk

BIOS:

  • kapcsoljuk ki a hyper threadingot
  • mindenféle virtualizáció támogatást
  • HPET-et
  • Integrált videó és hangkártyát

Driverek:

Ha ezzel megvagyunk, akkor állhatunk neki a windows-nak. Alapesetben én azt javaslom, hogy mindenből a legfrissebb drivert rakjuk fel, de a driver-ek minőségének megállapítása során csak a folyamatos mérések nyújthatnak támpontot. A driverek frissítésére kiválló a Snappy Driver Installer, a driverek minőségének ellenőrzésére a LatencyMon alkalmazást tudjuk használni.

Windows komponensek:

Ezek után el kell távolítani a windows összes olyan összetevőjét, amit valószínűleg sosem fogunk használni:

– Internet Exploder
– Windows Location Provider
– Work folders client
– XPS services
– XPS viewer

Én a print services-t is levettem, nem szándékozok papírra nyomtatni a közeljövőben.

Windows:

A főbb alapvetéseket a Focusrite elég jól összefoglalta, érdemes követni a leírásukat. A lényeg kivonatolva:

  • Power management -> high performance, cpu minimum és maximuma is 100% legyen
  • Rendszerhangok kikapcsolása
  • Processzor prioritás: Background services
  • Tűzfal, vírusírtó kikapcsolás
  • Vizuális effektek

És egy dolog, amit itt nem írnak: fix (min  == max) méretű swap file használata.

Hálózat:

Ha ez megvan, akkor kikapcsolhatjuk az összes olyan dolgot, amire nincs szükségünk a hálózaton (és lássuk be elég kevés dologra van szükségünk valójában):

snap75

Az IPV6 kikapcsolásához már a registry-t kell átírnunk: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\

new DWORD (32-bit) Value ->  DisabledComponents = 0xff

(forrás)

Amennyiben a hálózat késleltetése számít nekünk, akkor a szükséges optimalizációkat elvégezhetjük a TCPOptimizer nevű alkalmazással, de ez inkább streaming, és játékok esetén lehet hasznos.

Szolgáltatások:

Ezek után már csak azt kell elérnünk, hogy csak azok a programok fussanak, amire tényleg szükségünk van. Mivel a windows a legtöbb komponensét szolgáltatásokon keresztül indítja, itt is kell leállítanunk őket. Ezt a services.msc futtatásával tehetjük meg.

Bizonyos szolgáltatásokat viszont nem nagyon tudunk leállítani (mint pl. a Task Scheduler) mert a windows ezt nem engedi. Ezeket a registry segítségével tudjuk kikapcsolni.

A szolgáltatások kulcsait itt találjuk: HKLM\SYSTEM\CurrentControlSet\Services

A szolgáltatások rövid névvel kerülnek ide elmentésre, de azokat láthatjuk a service listában is, az adott szolgáltatás Properties oldalán (pl. a Task Scheduler neve Schedule)

Az indítás módát a Start tartalmazza, a 4 érték jelenti a Disabled beállítást. (forrás)

A szükséges szolgáltatások:

snap76

A többi dolog nem szükséges.

A TCP/IP NetBIOS helper szolgáltatás a SAMBA megosztások eléréséhez szükséges.

Amennyiben fájlokat szeretnénk megosztani, el kell indítani a Server szolgáltatást.

Amennyiben a Windows Update-t szeretnénk használni, akkor előtte el kell indítani az alábbi szolgáltatásokat:

  • Network List Service
  • Network Location Awareness
  • Background Intelligent Transfer Service
  • Windows update

Figyelem:

  • a BITS az operációs rendszer más dolgaihoz is kellhet (pl. nyelvek telepítése, DISM és SFC javításokhoz), csak akkor állítsuk le, ha ezek már mind rendben vannak.
  • a Task Scheduler leállítása után nekünk kell futtatni azokat a dolgokat, amik az operációs rendszer hatékony működését biztosítják, és a Task Scheduler időzítve futtatta őket (pl. a WinSxS könyvtár takarítását).

Alkalmazások:

Bár a fentiek után ezt külön kiemelni nem is érdemes, fontos, hogy a gépen csak az az alkalmazás fusson, amit használni akarunk, ezért a Task Manager Startup szekciójából mindent állítsunk disabled-re. Ez nem csak a rendszer teljesítményére lesz jó hatással, hanem a boot time-ra is (nálam jelenleg 5 másodperc alatti). Amire még szükségünk lehet az a ctfmon alkalmazás (C:\Windows\System32\ctfmon.exe) ami a tray-en a billentyűzet nyelvének állítását teszi lehetővé. De lehetőleg ezt is csak akkor indítsuk el, ha szükségünk van a magyar billentyűzetre, és utána zárjuk is be szépen.

A fentiek után már kész is a szuper munkára fogható windows-unk, ami valahogy így fog kinézni:

15036412_1241479802592529_2999654407216518174_n

 

 

Oracle adatbázis séma gyors törlése

Le akartam törölni pár nagyobb sémát Oracle alatt, aminek az lett az eredménye, hogy 20 órát futott a DROP USER… Kis olvasgatás után az körvonalazódott, hogy ezt a funkciót nem sikerült jól implementálni, ezért inkább töröljek kézzel mindent, és csak a végén töröljem a már üres sémákat… Nagy nehezen kiizzadtam magamból a lenti scriptet, ami működik is, de mivel az impdb implementációja sem sikerült teljesen ezért a végső megoldás az lett, hogy el kell dobni a teljes adatbázist, és újra kell gyártani nulláról… De ha már megírtam, akkor elmentem, hátha még jól jöhet a későbbiekben…

BEGIN
  FOR r1 IN ( SELECT 'DROP ' || object_type || ' ' || owner || '.' || object_name || DECODE ( object_type, 'TABLE', ' CASCADE CONSTRAINTS PURGE' ) AS v_sql
               FROM all_objects
               WHERE owner in ('SCHEMA1', 'SCHEMA2') AND 
                object_type IN ( 'TABLE', 'VIEW', 'PACKAGE', 'TYPE', 'PROCEDURE', 'FUNCTION', 'TRIGGER', 'SEQUENCE' ) 
                ORDER BY object_type, object_name ) LOOP 
    BEGIN 
     EXECUTE IMMEDIATE r1.v_sql; exception when others then null; 
    END; 
   END LOOP; 
  END; 
/ 

DROP USER CUSTOMER SCHEMA1 CASCADE;
DROP USER CUSTOMER SCHEMA2 CASCADE;

Indie game dev infograph

Ritkán adódik alkalom arra, hogy belelássunk egy-egy független játék készítésének költségeibe, és bevételeibe, pedig ezek elég jó támpontot nyújthatnak azoknak, akik ilyesmiben gondolkoznak. Nem is tudom mit tehetnék hozzá, beszéljenek helyettem a számok…

 

 

Windows shares

Több mint 10 éve linux alapokon működött a szerverem. Akkor azért váltottam Windowsról, mert feltörték a rajta futó IIS szervert egy expolit-on keresztül (szégyen gyalázat), és úgy döntöttem, többet ilyen nem lesz. Az utóbbi pár évben, viszont semmi sem történt… Rájöttem, hogy már nem szórakoztat az ubuntu, minden működik, már a dist upgradek sem a régiek, hogy utána összeomlana a rendszer és újra össze kell rakni darabokból… Szóval egy hirtelen ötlettől vezérelve, arra gondoltam, hogy megpróbálom ugyanezt Microsoft alapon is, mert miért is ne.

A Microsoft azért nem aprózza el ezt a bemutatkozás, és felhasználói élmény dolgot, az első pár nap alatt feltépődtek a régi sebek, jöttek újak, annak ellenére, hogy a Windows 3.1 óta midnig Windowst használtam desktopra…

A szerverem az Raspberry térhódításával majdhogynem csak egy NAS-ra degradálódott, pár extra funkcióval. Gondoltam első körben megosztok pár dolgot, elvégre mégiscsak az Ms találta ki az smb protokollt. Na de az összes meghajtót ami a gépben van, azt viszont nagyon nem terveztem megosztani.  Ez volt az első dolog (a windows 10 update dialógus ablak után) ahol gyökeresen eltért a véleményünk a dolgok menetével kapcsolatban… A Windows szerint nincs is annál jobb dolog, mint az administrative shares (nem tudom ki találta ki, és az IT security hogy hagyhatta ezt produkcióba kerülni, és azóta is miért létezik ez még egyáltalán, de legalább a net send-et kivették… az is valami 🙂

Aki ki szeretné kapcsolni ezen remek funkciót a gépén nem kell mást tennie, mint létrehozni egy AutoShareWKS nevű DWORD(32) kulcsot az alábbi helyre:


HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Paramerts

Igen, még létre sincs hozva 1 értékkel, hogy csak át kelljen írni, és ezen infók fórumok útján terjednek…  Vannak dolgok, amik nem változnak, ekkor már éreztem, hogy megérkeztem 🙂

És természetesen a network credential-os bug-ot sem sikerült javítani az elmúlt ~20 év alatt. Pedig nem bonyolult reprodukálni. Fogunk egy szervert, ahol pár megosztás bárki számára lekérdezhető. Aztán belerakunk pár olyan megosztást, ami csak adott felhasználók számára elérhetőek. Amikor a windows authentikál először megpróbálja kérdés nélkül a bejelentkezett felhasználó adataival (Ez egyébként megint egy érdekes kérdés, miért történik így. Vajon csak nekem jutott eszembe, hogy egy speciális megosztással, és egy megfelelő rainbow táblával viszonylag egyszerűen megtudható az adott felhasználó jelszava?). Ha a windows egyszer sikeresen azonosította magát egy szerveren, akkor a felhasználó hiába ír be jó azonosító adatokat az idők végtelenségéig a privilegizált megosztáshoz, csak a lenti dialógusablakot fogja látni:

winAuth

Ilyenkor mindenki elkezdi keresni a szerveren a problémát, hiszen Access is denied, mi más lehet a probléma… Úgy gondolom, hogy az emberek többsége itt adja fel, de nézzük csak meg mi történik, ha ugyanezt tesszük parancssorból?

C:\Users\voji>net use \\192.168.1.10\openhab
The password is invalid for \\192.168.1.10\openhab.

Enter the user name for '192.168.1.10': openhab
Enter the password for 192.168.1.10:
System error 1219 has occurred.

Multiple connections to a server or shared resource by the same user, 
using more than one user name, are not allowed. 
Disconnect all previous connections to the server 
or shared resource and try again.

Minderről a GUI annyit mond, hogy Access is denied. Grafikus felületről akarsz csatlakozgatni mindenhova? Akkor úgysem értesz hozzá, minek is terhelne az operációs rendszer ezzel a sok felesleges információval… A “soft” mountokat GUI-ról szintén nem lehet látni, szóval amúgy is mindegy lenne… De ha már itt tartunk, akkor kicsit jobban megnézve, milyen share is van jelenleg “mountolva”:

C:\Users\voji>net use
New connections will be remembered.
Status Local Remote Network
-------------------------------------------------------------------------------
OK \\192.168.1.10\IPC$ Microsoft Windows Network
The command completed successfully.

Bizony, IPC (Inter Proces Communication), amit az RPC (Remote Procedure Call) használ. Egyszerűen hibátlan… És ha tudnátok, hogy az RPC-n belül még mennyi rövidítés van (EPM, COM+, BIT, RPCSS, és még csak a jéghegy csúcsát karcolgatjuk…)

A lényeg, hogy jelen probléma megoldására a bátrak használhatják az alábbi parancsot:

 net use * /d

Kevésbé bátrak beírhatják a * helyére a mount nevét is (ami a fenti példában: \\192.168.1.10\IPC$)

És ezek csak azok a dolgok amik NT4 óta így maradtak… Az újakba, mint pl. a fastboot még bele se mentünk… Pedig…

A microsoft kitalálta, hogy a kernel modulok, és driverek viszonylag ritkán változnak az operációs rendszer élete során, ezért ezeket felesleges is mindig nulláról betöltögetni. Ezért az új windows verziók esetében (8+) bevezették a fastboot-ot, ami annyit tesz, hogy amennyiben kikapcsoljuk a gépet, akkor valójában nem az történik, amire a felhasználó első körben számít. Ugyanis a windows fogja és hasonló dolgot csinál, mint amikor hibernate-t mondunk, egy különbséggel. Nem a teljes memóriát menti, hanem csak a futó szolgáltatások memóriaképét. Zseniális ötlet, akit érdekel, hogy működik, itt olvashat egy felületes cikket a témában: http://www.eightforums.com/tutorials/6320-fast-startup-turn-off-windows-8-a.html

A probléma nem is ezzel van, hisz mivel ez az alapbeállítás, a világ elég nagy részén így kapcsolják ki kedvenc operációs rendszerüket. Ellenben volt a windowsban egy funkció, amit elég gyakran használtam, mégpedig a Group Policy Editorban a startup / shutdown scripts. Ez pont annyit tud(ott), mint amit a neve is mond: megadható neki egy program, amit a rendszer Local System-ként végrehajt a rendszer indulása és leállása során. A fastboot viszont kicsit bekavart a képbe, mert a be/kikapcsolás már nem inicializálja a rendszert a megszokott módon, és ebben az esetben nem is fut le egyik megadott script se. Hogy ebből mit lát a végfelhasználó? Megírja a scriptet, restart, működik. Aztán shutdown, és nem fut az a script, ami az előbb még futott. Aztán előbb utóbb összerakja, hogy hát itt valaki nagyon vicces kedvében volt, mert a startup/shutdown script csak restart esetén fut. A megoldásra két lehetőség van: Vagy kikapcsoljuk a fastboot-ot tokkal-vonóval, és akkor működni fog a startup és shutdown script, vagy továbbra is használjuk a fastboot-ot, de akkor nincs lehetőségünk korrekt módon programokat futtatni a windows indulása/leállítása során (én legalábbis nem találtam, de ha valaki tud ilyet és megosztja velem, akkor jár neki a Mars szelet).

Aztán kipróbáltam még az új Storage Spaces Pool-t (gyk.: mdadm by microsoft). Azt még nem tudom, mi fog történni, ha összeomlik a RAID array, mert ezzel kapcsolatban a Microsoft azt mondja, hogy nem omlik, de ilyen apróságoktól nem szoktam megrettenni. Az mondjuk azért nem annyira bíztató, hogy a disk kivételéről még csak nem is zenélnek a grafikus felületen. A problémára a megoldást természetesen megint egy fórumban lehet megtalálni, vagy jobb esetben, a fórum alapján készült blogbejegyzésben 🙂

És a viccesebbnél viccesebb hibákról még nem is beszéltem. A mostani kedvencem a KB3053711 (user error-nak szoktam hívni). Tessék elolvasni a kapcsolódó knowledge base article-t és a javasolt megoldást… Igazából minden szava arany, csak azt sajnálom, hogy a kapcsolódó forráskódot nem mellékelték, mert ez már az a szint amit minden szakmabelinek látnia kellene…

A Microsoft egyértelműen utolérhetetlen a felhasználói élmény fokozásában… 🙂

A google inbox tudja

Régen ledöbbentem, amikor a levélben “tomorrow 14:00”-ra az ipad felajánlotta, hogy ezt beírná a naptáramba. Ma pedig ezt produkálta az Inbox:

 

snap251

 

Szerintem ez még csak egy ügyes grep, de a jelenleg futó személyi asszisztens és AI fejlesztések mellett ez a vonal elég messzire vezethet a közeljövőben…

Openhab #3 – Owntracks, MQTT és egyéb finomságok

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:

sudo mosquitto_passwd /etc/mosquitto/passwd testuser

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.

2016-03-23 15.25.51

Az eseményekre történő feliratkozás a szerveren:

mosquitto_sub -t ‘owntracks/#’ -d -u testuser-P aaaaa

Sikeres üzenet fogadása esetén ilyesmit kell látnunk:

Client mosqsub/22511-raspberry received PUBLISH (d0, q0, r1, m0, ‘owntracks/voji/voji_phone’, … (109 bytes))
{“_type”:”location”, “lat”:99.4484811, “lon”:99.9012079, “tst”:1458742457, “acc”:30, “batt”:68, “t”:”u”, “tid”:”ne”}

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:


#!/bin/sh

export OTR_USER="otrecorder"
export OTR_PASS="****"

/usr/local/sbin/ot-recorder --http-host 192.168.1.11 --http-port 8083 'owntracks/#' &amp;

A crontab bejegyzés:

@reboot /home/openhab/scripts/ot-rec.sh

A sikeres indítás és üzenetelvétel után elviekben láthatóvá vállnak az adatok a fenti címen.

Untitled

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;amp;lt;house&amp;amp;amp;gt; (S_Location)

String mqttPositionVoji "Voji Location Raw Data" { mqtt="&amp;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;amp;lt;phone&amp;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&amp;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
&lt;/pre&gt;

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.

A kapcsolódó dnsmasq config:

bogus-priv
no-resolv
server=8.8.8.8
server=8.8.4.4
no-hosts
dhcp-range=192.168.1.50,192.168.1.150,12h
dhcp-range=192.168.1.1,192.168.1.49,static,255.255.255.0,infinite
dhcp-option=3,192.168.1.254
dhcp-option=option:router,192.168.1.254
dhcp-authoritative
address=/speedport.ip/192.168.1.254
address=/home.server.hu/192.168.1.10
address=/mqtt.server.hu/192.168.1.11

dhcp-host=ff:ff:a5:6f:ff:ff,voji-pc,192.168.1.30
dhcp-host=ff:ff:23:28:ff:ff,milight,192.168.1.20


Az openhab projekt a fűtés miatt jelenleg romokban van, de hamarosan jön az újabb, felturbózott verzió.

 

Openhab #2

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.

 


Switch Sh_qBittorrent "Torrent download [%s]" (S_Network) { exec=">[ON:/mnt/storage_local/openhab/scripts/qtorrentcmd.sh@@resumeAll] >[OFF:/mnt/storage_local/openhab/scripts/qtorrentcmd.sh@@pauseAll]" }
Switch Sh_VojiPcIsUp "Voji-Pc status [%s]" (S_Network) { exec="<[/mnt/storage_local/openhab/scripts/hostup.sh@@192.168.1.68:10000:]" }

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.

További részletekkel az exec binding dokumentáció  tud szolgálni.

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.

A demo projekt letölthető innen: http://voji.hu/downloads/openhab_base.zip

Az eredmény androidon valahogy így néz ki:

2016-03-02 19.19.37

 

OpenHab – az első lépések

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.