Author: voji

Posted on

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.

 

 

Posted on

SmartHome – az első lépések

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 🙂

Posted on

418 lóerős ford focus

A black friday kapcsán találtam ezt a gyöngyszemet az emag-on, az “autó, sport” kategóriában… Gyári 418LE ennyiért…

De természetesen csak egy elírásról volt szó 🙁

Snap1

Posted on

Oracle 11g lejáró jelszavak és account lockout

A napokban kaptam egy hibaüzenetet a szokásos oracle login-nál, hogy a jelszavam hamarosan lejár… Mint kiderült az Oracle-nál a 11-es verzióban valakinek jó ötletnek tűnt, hogy egy adatbázisnál alapértelmezett beállítás az, ha lejárnak a jelszavak. Szerintem ez egy nagyon rossz ötlet, ami elég sok komplikációt okozott, ami aztán rengeteg blog és dokumentáció olvasásához vezetett (+1 db restore-hoz). Ezért gyorsan le is írom mire jutottam:

Azt, hogy egy oracle felhasználóra milyen jelszó lejárati/kitiltási beállítások vonatkoznak a felhasználó profile beállítása írja le. Hogy milyen profile tartozik az adott felhasználóhoz, azt az alábbi select mondja meg:

select profile from DBA_USERS where username = 'DETDB';

Ha megvan a profile (jó esetben DEFAULT) akkor annak a beállításait lekérdezhetjük az alábbi módon:

select resource_name,limit from dba_profiles where profile='DEFAULT';

Itt mindennek UNLIMITED-nek kellene lenni, kivéve a PASSWORD_VERIFY_FUNCTION változónak, mert annak NULL

Ha valaki sql-ből szeretné ezt állítani, akkor:

alter profile default limit password_life_time unlimited;

De a beállítások elérhetőek az Oracle Enterprise Managerben is: Server->Profiles->Default->Edit->Password->Expire in->Unlimited

(Oracle EM indítása (shell, oracle user): emctl start dbconsole)

Ha már megtörtént a baj (lejárt a jelszó), akkor az alábbit kell tenni:

 ALTER USER DETDB IDENTIFIED BY ******;
 ALTER USER DETDB ACCOUNT UNLOCK;

Ez megváltoztatja a felhasználó jelszavát (ezáltal újra resetelődik a lejárati idő) és visszaengedi a felhasználót. Célszerű a limitek módosítása után ezt megtenni, akkor többet nem kell vele foglalkozni.

Ha ezután sem tudunk belépni, akkor érdemes megvizsgálni azokat a felhasználókat akikkel gond van:

SELECT username, account_status, created, lock_date, expiry_date
 FROM dba_users
 WHERE account_status != 'OPEN';

Ha a felhasználónkat (mondjuk a jelszóváltoztatás után) folyamatosan zárolják a rossz jelszóval történő próbálkozások miatt, akkor jó lenne tudni, hogy ki és honnan. Ezt alapból nem tudjuk meg, ehhez engedélyezni kell a bejelentkezési események auditálását…

AUDIT network BY ACCESS;

Unlockoljuk a felhasználót, és várjuk a csodát (a 1017 return kóddal záródó login próbálkozásokat)

SELECT username,userhost,returncode, t.TIMESTAMP
 FROM dba_audit_session t
 WHERE username='DETDB' and returncode='1017'
 ORDER BY sessionid DESC;

A listában látható host-okon kell megváltoztatni a jelszót, és egy ideig megint minden jó lesz…

 

 

Posted on

Napi okosság

Ha mindig ugyanazt teszed, amit mindig is tettél, akkor mindig ugyanazt az eredményt kapod, amit mindig is kaptál.

– Henry Ford

Posted on

Svn pre-commit hook and conflict markers

Előfordul néha, hogy a nagy lelkesedésben conflict makereket tartalmazó fájlt commitolnak a fejlesztők a repository-ba. Ez nem túl gyakori hiba, de azért tud kellemetlen lenni. Keresgettem egy kicsit, de nem találtam nekem tetsző script-et, ezért írtam egyet.

 

SVNLOOK=/usr/bin/svnlook
for x in `$SVNLOOK changed "$REPOS" -t "$TXN"`; do
 if [ "$updated_file" == true ]; then
    mimetype=`$SVNLOOK propget "$REPOS" svn:mime-type -t "$TXN" "${x}" 2>/dev/null`
    #ignore binary files
    if [ -z ${mimetype} ]; then
      if $SVNLOOK cat -t "$TXN" "$REPOS" "${x}" | grep -qE '^+?(<<<<<<<|>>>>>>>)'; then
        echo "Commited conflict marker detected, commit rejected!" 1>&2 && exit 1
      fi
    fi
    updated_file=false
    continue
 else
    if [ "$x" = "U" ]; then
      updated_file=true
    fi
 fi
done
set -e
Posted on

Windows downgrade

A windows 10 frissítés után tudatosult bennem, hogy bár a windows 10-el önmagában semmi probléma nincs, a számítógépes zenélést el is felejthetem mert ott még komoly kompatibilitási problémák vannak. Ez nem új dolog, és nem is csak Windows specifikus, OSX-en is hasonló a helyzet az El Captain kapcsán… Azt hittem ez nem lehet probléma, visszatelepítem a régi windowst (8.1), otthon az érdemi dolgok úgyis külön partíción, vagy dropbox-ban vannak.

A telepítéshez szükséges kulcsokat mindig mentem keepass-ba, így a kulcs is megvolt. Ha valaki esetleg elmulasztotta volna ezt a lépést, és nem tudja, hogy az általa használt windowsnak mi a telepítési kulcsa, akkor azt utólag is kinyerheti a Magical Jelly Bean Keyfinder alkalmazással.

Az első komoly problémát a windows telepítő beszerzése jelentette. A microsoft még mindig egy tucat telepítőt gyárt, amik csak bizonyos kulcsokat fogadnak el. Én azt hittem msdn által telepített windows verzióm van (általában mindig olyat telepítek) de mivel a mostani windowsomat upgradek hada állította elő (win7 -> win8 -> win10) az msdn.es telepítő nem fogadta el a kulcsomat.

Ekkor került képbe Janek által fejlesztett Ultimate PID checker. Az alkalmazás segítségével meg lehet határozni egy megadott windows telepítési kulcs típusát. Az általam használt kulcs RETAIL típusú, amihez természetesen nem volt telepítőm. A megoldást meglepő módon a microsoft szállította, és még csak MSDN subscription sem kell hozzá. A Windows 8.1 Media Creation Tool letöltése után csak ki kell választani a system type-ot, nyelvet, editiont (amit szintén megmond a PID checker) és már tölti is a megfelelő telepítőt, amit közvetlenül pendrive-ra is fel tud rakni (működött, így nem kellett megfutni egy rufus-os plusz kört).

Az újratelepítés során egyetlen dolgot rontottam el. A letörölt windows 10 kulcsát nem mentettem el, mielőtt letöröltem, így az elveszett. Azt visszaszerezni már csak bonyolultan lehet (le kell menteni a Windows 8 lemez képét, azt mountolni egy virtuális gépre, ott bootolni, upgradelni win10-re, lementeni a kulcsot, törölni az egészet). A free upgrade 2016 juliusig él, tehát mindezt még ez előtt lenne célszerű megcsinálni… Majd egyszer, talán…

Mint felhasználó nem tudom, a szivatáson kívül mi értelme van ezeknek a különböző Microsoft telepítőknek, edition-oknak, időhöz kötött upgrade-knek. Jobs a leopárd kapcsán viccelődött is ezzel, egyszer talán majd Nadella is elsüti ezt lenti poént: https://www.youtube.com/watch?v=gtSDlSVDibA

Posted on

Új mame, régi frontend

A mame-t minden játéktermi gépen edződött fiatal ismeri (aki valamiért mégsem, gyorsan kezdjen ismerkedni vele :). Zseniális emulátor, de a fejlesztők a minél tökéletesebb emuláción kívül nem sok mindennel foglalkoznak (szerencsére), ezért sokan gyártottak hozzá különböző front-end-eket.

Ellenben az utóbbi időben az újabb mame verziókkal valahogy semmilyen front-end nem akart működni. Ennek az az oka, hogy a mame v.162 óta megváltozott a generált gamelist.xml fájl formátuma, aminek tartalmára a front-end-ek erősen támaszkodtak. A változás miatt az újabb mame verzió által generált xml fájlon már nem nagyon igazodnak ki.

Erre jelenthet megoldást az alábbi parancs:

</pre>
sed -e "s/machine+/game+/g" -e "s/<!ELEMENT machine/<!ELEMENT game/g" -e "s/<!ATTLIST machine/<!ATTLIST game/g" -e "s/<machine/<game/g" -e "s/<\/machine/<\/game/g" < gamelist.xml > gamelist_of.xml
<pre>

Ez az új formátumú mame gamelist.xml-t konvertálja át a régi formátumra.

A problémáról az alábbi linken írnak a Mala front-end kapcsán, de ugyanúgy érinti a Maximus Arcade felhasználókat is:

http://forum.arcadecontrols.com/index.php/topic,145865.0.html