Házautomatizálás - Docker építés

Elkezdtem a Docker infrastruktúra felépítését a Hyper-V szervereimen a házautomatizálás (és más) rendszereimhez.
A komfort zónám, ha linuxról beszélünk elsősorban az Ubuntura és a Debianra terjed ki. Különböző forrásokból azt hallottam, hogy Alpine linux-ok kéne a Docker-hez használni. Tulajdonképpen már belefutottam néhány előregyártott Docker image-be amik Alpine-on alapulnak a munkám során. Szóval úgy döntöttem, hogy az új rendszert Alpine-ra építem, ez jó lehetőség a tanulásra.
Első:
Letöltöttem a virtualizált gépnek optimalizált telepítőt, gyártottam egy Gen2-es Hyper-V gépet és elindítottam.
Igen, virtualizációra optimalizált, csak épp nem a Hyper-V-re. El se indult.
Második:
Letöltöttem a standard telepítőt. Ez végre elindult a Hyper-V-ben így felraktam egy vhdx-re.
Miután általában másolom az alap vhdx-et, az újabb virtuális gépek előállításához, az Alpine itt kap egy plusz pontot tőlem, miután nem kell a boot folyamatot patkolni ehhez mint az Ubuntunál.
Felraktam a nano-t, miután pár konfig fájlt szerkesztenem kell a kész gépeken, és szétmásoltam a vhdx fájlokat, elkezdtem gépeket gyártani belőlük.
Harmadik:
Beállítottam az IP címet, a gép nevét, a DNS-t, átjárót, stb. Csak a szokásos dolgokat.
Újraindítás után nem indult el mégegyszer. Az ok a chronyd. Miután nem tudta az internetről az időt begyűjteni, megállította a boot folyamatot. Örökre. Se konzol, se SSH.
Ok, kinyírtam a gépet, újragyártottam az alap vhdx-ből. Körültéztem, nem találtam semmi megoldást. Végül megnéztem a chrony csomag tartalmát és kiderült, hogy a timeout opciót a /etc/conf.d/chronyd fájlban tudom beállítani. Az ARGS opcióba beírtam: -t 60
Negyedik:
Átkonfiguráltam az SSH-t, hogy nekem megfeleljen, hozzáadtam azt a repo-t ami a Docker telepítéséhez szükséges extra csomagokat tartalmazza.
Felraktam az összes x64-es gépen a Dockert, beállítottam, hogy boot-nál induljon el.
Ötödik:
Elindítva a Docker-t ezt kapom:

Jónéhány próbálkozással sem sikerült ezt a dolgot rendbeszedni, de közben találtam cikkeket arról, hogy az Alpine nem alkalmas a feladatra:
http://janhapke.com/blog/alpine-linux-sucks-for-hosting-docker-containers/
http://www.nathanbak.com/?p=37

Döntöttem. Elfelejtem ezt és megyek vissza az Ubuntura. A következő próbálkozásom a vadiúj Ubuntu 18.04 LTS-el lesz.

Házautomatizálás központ

2016-ban elkezdtem dolgozni egy házautomatizálási projecten amit végülis félreraktam.
Azóta egyre jobban érzem, hogy tennem kéne valamit az ügyben. Miután befejeztem a Robo3D nyomtatóm javítását, nem volt aktuális projectem, tehát kiraktam egy szavazást ide a bal oldalra, hogy mi legyen a következő projectem.
A házautomatizálás központ lett az egyértelmű nyertes. Elkezdtem gondolkozni, hogy mit csináljak és hogyan.
A döntéseim:

• Modulárisan akarom felépíteni a rendszert a központtal kezdve (a jelenlegi project csak a központról szól)
• OpenHAB-ot fogok használni központként (ez az ami támogatja a meglévő Conrad FHT/FS20 termosztátjaimat)
• Hibatűrő megoldást akarok
• Akkor is működjön, ha nincs internet
• Valami egykártyás mikrogépre fogom rakni (SBC)
• 64 bites rendszer legyen - kicsit a jövőnek építem
• Lehetőleg meglévő dolgokat szeretnék használni

A meglévő IT infrastruktúrámról - ennek jelentős befolyása van a döntéseimre:
Két, VPN-el összekötött helyszínem van. Az egyik a házam, a másik az irodám. Jelenleg 4 MS Hyper-V szervert futtatok. 3 az irodában 1 itthon van.
A rendszer alapvetően Docker-re fog kerülni. Azt tervezem, hogy építek, egy 1U-s rack dobozt, beleteszek két Pine64 panelt, két 5V-os tápot és talán még két SSD-t.
Két Docker Swarm cluster épül:

1. Egy x64-es Cluster: két Manager/Worker kombinált node-al amik az irodai Hyper-V-kre kerülnek és egy csak Manager node-al ami az itthoni Hyper-V-re kerül.
2. Egy ARM Cluster: két Manager node amik az irodai Hyper-V-kre kerülnek, egy ami az itthonira kerül ésa Worker-ek a Pine64 panelek lesznek.

Az OpenHAB konténer(ek) menn(ek) a Pine64-ekre, plusz GlusterFS, plusz HAProxy mint hibatűrő megoldás
Az x64 Clusterre mennek a kiszolgáló dolgok:

• Privát dokker registry
• Zabbix, vagy Nagios monitoring
• Egyéb konténerek amik a munkámhoz kellenek (nem kapcsolódnak a házautomatizáláshoz)

Az adatgyűjtés és az MQTT vezérlés elhelyezését/megvalósítását még nem találtam ki.
Ha a fenti rendszer összeállt, akkor fogok a szenzorok és beavatkozó szervek integrációjával foglalkozni.

És igen, mielőtt megkérdeznéd - Komplett idióta vagyok. :-D

Mesék a házautomatizálásról - ModulMánia

Ahogy tovább gondolkodtam, egyértelművé vált, hogy egy moduláris rendszert akarok csinálni. Valami hátlap egyenméretű modulokkal, a szenzorok, beavatkozó szervek, mikrovezérlő és a tápellátás különálló modulokon lesz.

Ennél még tovább mentem. Megterveztem a dobozt, a hátlapot és a modul méreteit. A modulok 5x5cm-es panelen kerülnek megvalósításra. Miért? Mert ez a méret olcsón (10$/10db) rendelhető a Kínai NYÁK üzemekből.

A tervezett modul csatlakozó tartalmaz egy SPI-t, egy I2C-t és nyolc GPIO-t. Ez 17 érintkező együtt a két tápsínnel (3.3V és 5V). A 17 érintkezős 0.1" osztású egysoros tüskesor elfér a panel 5cm-es élén.

A rendszerhez kitaláltam jó néhány modult, amiket meg akarok valósítani. A lista nem teljes és a modulok még változhatnak:

• Relé - Egy csatornás relé modul
• RCR - Az ugrókódos távirányító vevőjének a modulja
• Hálózati érzékelő - A hálózati feszültség meglétének ellenőrzése, ezt terveztem a kapcsolókhoz
• Hőmérséklet/páratartalom - AM2302 alapú modul (a szenzor maga, kívül is, belül is elhelyezhető)
• Esp01 - ESP-01 alapú "agy" a modul kapcsolható két GPIO és egy I2C között
• Esp07/12 + pcf8574 - ESP-07 vagy ESP-12 alapú modul I2C bővítővel
• Esp12e/f - Kérdőjeles. Ez akkor hozható létre, ha a belső flash memória SPI portja könnyedén megosztható külső SPI eszközökkel - tesztelés szükséges
• Arduino + nrl24l01+ - MySensors.org szenzor "agy"
• Tápegység - 5V/3.3V képes táp, egy HLK-PM01 és egy 3.3V LDO vagy buck konverter alapon
• Nrl24l01+ - Nordic kommunikációs modul - elsősorban a Beaglebone-hoz készül, hogy MySensors.org átjátszó lehessen belőle
• Barométer
• Busz bővítő
• Teljesítmény mérő - Áramváltó alapú
• Teljesítmény mérő - Hall elemes
• Teljesítmény mérő - Digitális mérőóra impulzus számláló
• Gázóra Hall szenzor
• SSR Modul
• GPIO Modul - Izolált I/O Modul, esetleg DC/DC konverterrel együtt.

Továbbá készül 4, 6, és 8 modulos hátlap. A hátlaphoz lesz egy plusz csatlakozó ami lehetővé teszi, hogy az egészet egy BeagleBone CAPE-hez csatlakoztassuk. Ez azt jelenti, hogy a moduláris rendszert a BBG alapú OpenHAB központhoz is fogom tudni használni.

Egy 3D nyomtatható, parametrikus doboz is készül.

Néhány panel terve már elkészült. Ugyan meg lehet rendelni a Kínai gyártótól, ugyanakkor minden terv idáig egyoldalas, ami lehetővé teszi, a könnyű házi gyártást.
A tervek nagyja (nem mind) kizárólag furatszerelt alkatrészeket használ, ami könnyebbé teszi az életet.

És így fog kinézni a modul és doboza. Első OpenSCAD-es animációm!

Mesék a házautomatizálásról - Hálózati feszültség érzékelő

Nem, nem akarom a hálózati feszültséget mérni (még).
A garázsvilágítást akarom átalakítani, a lehető legkisebb átalakítással.
Mit jelent ez?
A lámpát két kapcsoló kapcsolja (egy a garázsban, egy a házban a garázs ajtaja mellett) van, alternatív konfigurációban. Meg akarom tartani annak a lehetőségét, hogy a lámpa változatlanul kapcsolható legyen a kapcsolókról. Nem vagyok villanyszerelő, nem igazán akarok hozzányúlni a kapcsolókhoz és a falban menő kábelekhez (amúgy is sok piszokkal járó munka). Szerencsére a lámpa mellett van folyamatos tápellátás is (nem csak ami a kapcsolókról jön)
A terv az, hogy a beavatkozó szervet rákötöm a folyamatos tápforrásra és érzékelem, hogy a kapcsolók be, vagy ki vannak kapcsolva. Ezt a jelet arra használom, hogy átkapcsoljam a lámpát és nem az aktuális státusza határozza meg a lámpa állapotát. Amikor átkapcsolom valamelyik kapcsolót (be -> ki, ki-> be), változik a lámpa státusza.
Az érzékeléshez szükségem van valami elektronikára. A hálózat, nem gyerekjáték, a megfelelő leválasztás kritikus.
A lehető legegyszerűbb áramkört szeretném megvalósítani:
Egy kapacitív tápegység (két kondi, két ellenállás, egy dióda és egy zener), ehhez jön még egy optocsatoló. Az egész lehet, vagy 300Ft.
It a rajz:

Mesék a házautomatizálásról - A fűtés csatlakoztatása

Ahogy korábban már említettem, van egy rakás Conrad (ELV) FHT80B termosztátom, rádióvezérelt radiátorszelepekkel, és van egy CUL v3.2-es eszközöm. Most megpróbálom ezeket az OpenHAB-hoz kötni.
Mielőtt nekiláttam ennek a projectnek felraktam azt a CUL firmware-t amit az OpenHAB-hoz javasoltak, innen:
http://culfw.de/culfw.html
Az összeköttetésről itt találhatók információk:
https://github.com/openhab/openhab/wiki/FS20-Binding
https://github.com/openhab/openhab/wiki/CUL-Binding

Rakjuk össze a "binding"-ot:

1. Másoljuk be a szükséges addon-okat a /opt/openhab/addons mappába:

org.openhab.io.transport.cul-1.8.1.jar
org.openhab.binding.fht-1.8.1.jar

Ha van más FS20-as eszközöd a fűtésvezérlésen felül akkor még erre is szükséged lehet:

org.openhab.binding.fs20-1.8.1.jar

2. Szerkeszd meg a konfigurációs állományt /opt/openhab/configurations/openhab.cfg. Add hozzá a végéhez ezeket:

fht:device=serial:/dev/ttyACM0
fht:baudrate=38400
fht:parity=0
fht:housecode=XXXX

A housecode szabadon választott. Egy négyjegyű hexadecimális szám. És feltétlenül szükséges. Ha nem adod meg, a kommunikáció nem fog elindulni, és erről egy büdös hangot sem szól, logol. Hibát csak akkor látsz a logban, ha debuc módba kapcsolod.

Ez a kód a CUL eszköz kódja lesz és semmi köze az FHT80b kódjaihoz. Továbbá, ha azt akarod, hogy a dolog működjön, bizonyosodj meg róla, hogy az FHT80b "CEnt" beállítása "nA"-ra van kapcsolva.

3. Akkor most létre kell hozni, néhány item-et az items fájlban az FHT80B-hez. Valahogy így:

Number fhtRoom1Desired "Desired-Temp. [%.1f °C]" { fht="housecode=552D;datapoint=DESIRED_TEMP" }
Number fhtRoom1Measured "Measured Temp. [%.1f °C]" { fht="housecode=552D;datapoint=MEASURED_TEMP" }
Number fhtRoom1Valve "Valve [%.1f %%]" { fht="housecode=552D;address=00;datapoint=VALVE" }
Switch fhtRoom1Battery "Battery [%s]" { fht="housecode=552D;datapoint=BATTERY" }
Contact fhtRoom1Window "Window [MAP(en.map):%s]" { fht="housecode=52FB;address=7B;datapoint=WINDOW" }

A housecode a fenti példában az FHT80B eszközé. Ki tudod olvasni az FHT80B-ből. A code1 az első, a code2 a második része. Az olvasott kódókat át kell alakítani hexára.

4. Most el kell helyezni az olvasott értékeket a sitemap-on:

Frame label="Heating"
{
 Setpoint item=fhtRoom1Desired minValue=6 maxValue=30 step=0.5 
 Text item=fhtRoom1Measured
 Text item=fhtRoom1Valve 
 Text item=fhtRoom1Battery
 Text item=fhtRoom1Window
}

Az eredmény valami ilyesmi:

Még egy megjegyzés: Légy türelmes. Az adatok begyűjtése lassú. Néhány adat, csak akkor fog megérkezni amikor változik. Tehát eltarthat jó néhány percig, akár órákig is amíg megkapod az adataid.

Mesék a házautomatizálásról - Lámpakapcsolgatás

Menjünk tovább. Ez csak egy kis kopipaszta programozás.
A kódot innen szedtem:
http://iot-playground.com/blog/2-uncategorised/40-esp8266-wifi-relay-switch-arduino-ide

Lecseréltem az SSID-t és a jelszót, rákötöttem egy 150 ohmos ellenállást, meg az első LED-et amit az alkatrészes dobozban találtam az ESP8266 megfelelő lábára. Letöltöttem a kódot, elindítottam a soros monitort a Visual Studio-ban:

Ha kapcsolódom a webszerverhez egy böngészőből, be és ki tudom kapcsolni a LED-et.

Akkor most integráljuk az OpenHAB-ba.

Nem csináltam mást, mint módosítottam a korábbi rule-okat. Először, csak hozzáadtam a http hívásokat a korábbi szabályokhoz, de ez nem volt kielégítő. A távirányítóról tudtam vezérelni a LED-et, de a böngészőből nem. Tehát kicsit jobban hozzányúltam.

Íme az eredmény:

import org.openhab.core.library.types.*
import org.openhab.core.persistence.*
import org.openhab.model.script.actions.*

rule "GarageLightRemote"
when
    Item KeeLoq_Remote_B changed from CLOSED to OPEN
then
    if(Garage_Light.state == ON)
    {
        sendCommand(Garage_Light, OFF)
    }
    else
    {
        sendCommand(Garage_Light, ON)
    }
end

rule "GarageLightOffAction"
when
    Item Garage_Light changed from ON to OFF
then
        sendHttpGetRequest("http://10.1.2.129/gpio/0")
end

rule "GarageLightOffAction"
when
    Item Garage_Light changed from OFF to ON
then
        sendHttpGetRequest("http://10.1.2.129/gpio/1") 
end

És az áramkör:

Mesék a házautomatizálásról - ESP8266, Arduino, Visual Studio

Nem vagyok nagy barátja az Arduino ökoszisztémának. A hulladék fejlesztőkörnyezet, a normális debugger hiánya távol tartott tőle.
A másik oldalon, be kell vallanom, sokat fejlődött az utolsó találkozásunk óta, és egyre megkerülhetetlenebbnek tűnik.
Az OpenHAB rendszeremhez szükségem van távoli szenzorokra, beavatkozó szervekre. Nagyrészüket építeni (és nem venni) akarom. Körülnézve két könnyen használható megoldást találtam:

• ESP8266 alapú WiFi modulok
• MySensors.org NRF24L01+ és Arduino alapú mesh hálózat

Mindkettőt ki akarom próbálni. Miután nem igazán van arduino-m (van pár a szekrényben, de különböző gyártóktól, különböző nyűgökkel, és nem igazán illenek ebbe a projectbe), tehát az ESP8266-tal akarok először játszani.

Azt olvastam, hogy a LUA értelmező nem igazán jó nagyobb projektekhez, így eleve az Arduino környezetet választottam. Egyenlőre csak tanulom, tehát nem tudom, hova vezet.
Az első célom, hogy képes legyek GPIO-t kapcsolgatni az ESP8266-on HTTP REST API-n keresztül.
Ahogy feljebb, már jeleztem, kellően útálom az Arduino IDE-t. Korábban különböző problémákba futottam vele amikor a 3D nyomtató Marlin firmware-ét próbáltam konfigurálni. Később megtaláltam, hogy a megbízható Visual Studio-t (amit napi szinten használok a munkámban, különböző projectekhez) is használhatom, ezzel a kiegészítéssel:
http://www.visualmicro.com/
a feladatra.
Rakjuk össze a környezetet:

1. Telepítsük fel az Arduino IDE-t. Innen tölthető le: https://www.arduino.cc/download_handler.php?f=/arduino-1.6.8-windows.exe

2. Telepítsük fel a Visual Studio 2015-öt. Én a Professional kivitelt használom, de az ingyenes is megfelel. Innen tölthető le: https://go.microsoft.com/fwlink/?LinkId=615448&clcid=0x409
Bizonyosodjunk meg róla, hgy a C++ komponens telepítésre került.

3. Indítsuk el a Visual Studio-t. Menjünk a Tools/Extensions and Updates menübe. Válasszuk ki az Online pontot a baloldali panelen. Keressünk rá az Arduino-ra
Töltsük le az Arduino IDE for Visual Studio komponenes-t

Telepítsük fel és az utasításoknak megfelelően, indítsuk újra a gépet.

4. Az újraindítás után megjelenik az Arduino konfigurációja. Be kell állítanunk az Arduino IDE elérési útját és a az ESP8266 Board Manager URL-t:
http://arduino.esp8266.com/stable/package_esp8266com_index.json

Nyomjuk meg az OK gombot.

5. A menüsoron az Arduino board választó mellett kattintsunk a nagyító ikonra. Válasszuk ki a Manage Boards fület.
Nyissuk ki az ESP8266 pontot és jelöljük meg a 2.1.0-ás verziót.
A felugró ablakban nyomjunk OK-t a telepítéshez

Ezen a ponton egy kenmény hibába futottam. A gépem tartományi tag. A dolgaimat mezei felhasználóként futtatom, ami csökkentett jogokat jelent (természetesen van admin felhasználóm, de csak akkor használom, ha szükség van rá). Úgy tűnik, hogy a telepítő hibás. A profilkönyvtáram nevében van egy pont. A telepítő ezt átkonvertálta aláhúzásra bizonyos helyeken, és egy Access Denied hibát dobott - mert ugye a könyvtár nem létezett és létre sem tudta hozni.

Tehát létrehoztam a könyvtárat adminként, és adtam magamnak jogot rá. Ezután a telepítő lefutott, de az első fordításnál hibát kaptam. A hibaüzenet teljesen használhatatlannak bizonyult. Jó néhány próbálkozás, Process Monitorozás (Micosoft, korábban Sysinternals eszköz), bemásoltam a helyükre az aláhúzásos profil temp könyvtárában felejtett dolgokat. Mostmár működik, sok óra elvesztegetve.

6. Próbáljuk ki
Gyors tesztet akartam, tehát, csak létrehoztam egy demo projectet, a blink-et a Visual Studio listájáról.

Miután kiválasztottam a megfelelő board-ot (esetemben a NodeMCU v0.9-et) és soros portot, feltöltöttem a kódot és elkezdett működni.

Úgy tűnik az ESP8266 környezet kész egy bonyolultabb feladatra.

Mesék a házautomatizálásról - Távirányító integráció

Ahhoz, hogy az ugrókódos távirányító működni tudjon az OpenHAB-bal, az első dolog, hogy a GPIO binding-ot engedélyezni kell. Egy egészen használható dokumentációt találunk az OpenHAB wikiben:

https://github.com/openhab/openhab/wiki/GPIO-Binding

Nagyjából azt követtem el, amit a doksi írt, de némi módosítés szükséges volt.

1. Telepítsük fel a natív JNA library-t:
apt-get install libjna-java

2. Módosítsuk a /opt/openhab/start.sh-t
Adjuk hozzá a java parancssori paraméterek listájához:
-Djna.boot.library.path=/usr/lib/jni

3. Módosítsuk a /etc/init.d/openhab fájlt.

Adjuk hozzá a DAEMON_ARGS paraméterek listájához:
-Djna.boot.library.path=/usr/lib/jni

és adjuk hozzá a GPIO unexport parancsokat a daemon leállási feladatokhoz:



4. A korábban letöltött distribution-1.8.1-addons.zip-ből (része az OpenHAB letöltéseknek) csomagoljuk ki a következő fájlokat:
     org.openhab.io.gpio
     org.openhab.binding.gpio

A /opt/openhab/addons könyvtárba

5. Indítsuk újra az OpenHAB-ot:

/etc/init.d/openhab restart

Mostmár az OpenHAB kész a GPIO kezelésére. Kell némi konfiguráció módosítás, hogy használni tudjuk.

6. Addjuk hozzá a szükséges elemeket.

A GPIO bemenetek Contact-okkal reprezentálhatóak az OpenHAB-ban. Tehát adjuk hozzá a  /opt/openhab/configurations/items könyvtár valamelyik fájljához (Én itt már kidobtam a demo konfigurációt, tehát nálam ez a saját házam item listája) a következőket:

Contact KeeLoq_Remote_A "Remote A [MAP(en.map:%s]" (<ID of your Group>, Windows) { gpio="pin:66"}
Contact KeeLoq_Remote_B "Remote B [MAP(en.map:%s]" (<ID of your Group>, Windows) { gpio="pin:67"}
Contact KeeLoq_Remote_C "Remote C [MAP(en.map:%s]" (<ID of your Group>, Windows) { gpio="pin:69"}
Contact KeeLoq_Remote_D "Remote D [MAP(en.map:%s]" (<ID of your Group>, Windows) { gpio="pin:68"}

Ha minden rendben van a következőt fogjuk látni:

És, ha megnyomjuk a távirányító valamelyik gombját a, a closed felirat open-re vált, majd vissza, ha elengedjük a gombot.

7. A világításhoz, ez nem lesz elég
Arra van szükségünk, hogy megtartsuk a státuszt, ahogy az be és kikapcsol.
Tehát, hozzádunk még egy Switch-et az items fájlhoz:

Switch Garage_Light "Garage Light" (<ID of your Group>, Lights)

Ez csak egy egyszerű kapcsoló, tehát, ha távirányítóról akarjuk vezérelni, még egy szabályt is létre kell hozni. Ezt a /opt/openhab/configurations/rules mappában lévő rules fájl szerkesztésével oldhatjuk meg:

rule "GarageLightToggle"
    when
        Item KeeLoq_Remote_B changed from CLOSED to OPEN
    then
        if(Garage_Light.state == ON)
        {
            sendCommand(Garage_Light, OFF)
        }
        else
        {
            sendCommand(Garage_Light, ON)
        }
end

Ezek után, ha megnyomjuk a B gombot a távirányítón, be és ki fogja kapcsolni a fenti switch elemet.
Ez még nincs hatással a fizikai lámpára. Ahhoz még gyártanom/vennem kell valami beavatkozó szervet.

Mesék a házautomatizálásról - Ugrókódos távirányító

[2016.04.16]: Amikor írtam ezt a cikket, nem vettem észre, hogy a cape manager slots fájlja a régi helyre mutat. Javítva.

Ha az autódban ülsz és be akarsz jutni a garázsodba, tudom, hogy nem divatos, de a leg kényelmesebb eszköz a kulcskarikádon lógó kicsi távirányító (valami az autoba integrált cucc jobb és divatosabb lenne, talán csinálok valami ilyesmit később).

Ahhoz, hogy távirányítani tudjam az OpenHAB-ot és rajta keresztül a garázskaput/világítást, vettem egy ilyen ugrókódos távirányítót az aliexpressen:

http://www.aliexpress.com/item/RF-Rolling-Code-Decoding-Receiver-Module-2-Transmitters-DC-5V-4CH-TTL-Output-Learning-Momentary-Toggle/32295201884.html

A tervem az, hogy a garázsvilágítás, a garázskapu és még néhány (miután két gombja marad, pontosan kettő) dolog távirányítására használom.
Először is felraktam egy breadboard-ra, bekapcsoltam, hogy kipróbáljam, működik-e.
Az első próbálkozásra tökéletesen működött, kitalálni, melyik csatorna melyik gombhoz tartozik, gyerekjáték volt.
Az egyetlen probléma a cuccal, hogy 5V-os logikai kimenetei vannak, én a BeagleBone Green-hez akarom kötni, aminek a GPIO portjai nem tolerálják az 5V-ot.
Úgy döntöttem, hogy a világ legyegyszerűbb szintillesztőjét fogom használni hozzá. Egy ellenállásosztót. Egy 39K-s és egy 68K-s ellenállás megoldoja a kérdést, multiméteren mérve.

A következő rész, a BeagleBone GPIO felkonfigurálása. Az OpenHAB a Linux GPIO Sysfs interfészt használja, ami nagyon egyszerű (https://www.kernel.org/doc/Documentation/gpio/sysfs.txt).

Először megpróbáltam adatot olvasni parancssorból. A vevő egy csatornáját rákötöttem a BBG 60-as GPIO (P9, 12-es érintkező) portra.

A konzolon a következő parancsokat szükséges kiadni:

echo '60' > /sys/class/gpio/export

echo 'in' > /sys/class/gpio/gpio60/direction

Ezek után az érték, ezzel a paranccsal olvasható:

cat /sys/class/gpio/gpio60/value

A parancsok jól működtek, de akár megnyomtam a gombot akár nem, mindíg 1-est kaptam vissza.

Megmérve a bemenetet, 1.6V-ot kaptam akkor is amikor a vevő kimenetén 0V volt. Ez azt jelenti, hogy a BBG bemenet tápra van húzva.

Ebből adódóan két lehetőségem maradt:

1. Kikapcsolom a felhúzó ellenállást valahogy
2. Az ellenállások helyett valami aktív szintillesztőt használok.

Az elsőt választottam.
Körülnézve tisztán kiderült, hogy a felhúzó ellenállás vezérlése nem része a Linux GPIO csomagnak. Sokat olvasva kiderült, hogy a BBG Cape Manager Overlay-eket használ ennek megoldására. Ez a múltban (korábbi kernel verziók) hol volt, hol nem volt. A 4.1.x-esre amit én használok, viszont már része a mainline kernelnek.

Itt van némi olvasnivaló:

https://github.com/jadonk/validation-scripts/blob/master/test-capemgr/README.md
http://www.thing-printer.com/cape-manager-is-back-baby/
http://www.valvers.com/embedded-linux/beaglebone-black/step04-gpio/

Az overlay repository (tanulhatsz belőle, de nem szükséeges ennek a feladatnak a megoldásához):
https://github.com/RobertCNelson/bb.org-overlays

A leghasználhatóbb dolog amit találtam ez a tool volt:

http://kilobaser.com/blog/2014-07-28-beaglebone-black-devicetreeoverlay-generator

Ez képes a szükséges overlayt előűllítani.

Tehát a 60-as GPIO felhúzóellenállásának a kikapcsolásához a következőkre van szükség::

1. Mentsük el a következő fájlt a /lib/firmware könyvtárba bspm_p9_12_2f-00A0.dts néven:

/*

 * This is a template-generated file from BoneScript

 */

/dts-v1/;

/plugin/;

/{

    compatible = "ti,beaglebone", "ti,beaglebone-black";

    part_number = "BS_PINMODE_P9_12_0x2f";

    exclusive-use =

        "P9.12",

        "gpio1_28";

    fragment@0 {

        target = <&am33xx_pinmux>;

        __overlay__ {

            bs_pinmode_P9_12_0x2f: pinmux_bs_pinmode_P9_12_0x2f {

                pinctrl-single,pins = <0x078 0x2f>;

            };

        };

    };

    fragment@1 {

        target = <&ocp>;

        __overlay__ {

            bs_pinmode_P9_12_0x2f_pinmux {

                compatible = "bone-pinmux-helper";

                status = "okay";

                pinctrl-names = "default";

                pinctrl-0 = <&bs_pinmode_P9_12_0x2f>;

            };

        };

    };

};

2. Fordítsuk le:

dtc -O dtb -o /lib/firmware/bspm_P9_12_2f-00A0.dtbo -b 0 -@ /lib/firmware/bspm_P9_12_2f-00A0.dts

3. Töltsük be:

echo bspm_P9_12_2f > /sys/devices/bone_capemgr.?/slots
echo bspm_P9_12_2f > /sys/devices/platform/bone_capemgr/slots

Ezután a felhúzóellenállás megszűnt létezni. A távirányító státusza olvasható lett.

Rendben, ez most működik egy csatornára, de mi van néggyel? Tudok négy overlay-t generálni, de hogyan kombinálom egy fájlba? Elég kevés infót találtam, mindaddig amíg rá nem akadtam erre az Adafruit dokumentációra:

https://learn.adafruit.com/introduction-to-the-beaglebone-black-device-tree/device-tree-overlays

A doksi alapján sikeresen kombináltam a négy generált overlay-t. Végülis a P8 7-10 lábait használtam.

Az overlay (suf_keeloq-00A0.dts):

/*

 * SUF - 4-Channel Keyloq receiver cape

 */

/dts-v1/;

/plugin/;

/{

    compatible = "ti,beaglebone", "ti,beaglebone-black";

    part_number = "SUF-KEELOQ";

    exclusive-use =

        "P8.7",

        "P8.8",

        "P8.9",

        "P8.10",

        "mmc1_sdcd",

        "gpio2_3",

        "gpio2_5",

        "gpio2_4";

    fragment@0 {

        target = <&am33xx_pinmux>;

        __overlay__ {

            suf_keeloq_pins: pinmux_suf_keeloq_pins {

                pinctrl-single,pins = <

0x090 0x2f

0x094 0x2f

0x09c 0x2f

0x098 0x2f

>;

            };

        };

    };

    fragment@1 {

        target = <&ocp>;

        __overlay__ {

            suf_keeloq_pinmux {

                compatible = "bone-pinmux-helper";

                status = "okay";

                pinctrl-names = "default";

                pinctrl-0 = <&suf_keeloq_pins>;

            };

        };

    };

};

fordítás és betöltés:

dtc -O dtb -o /lib/firmware/suf_keeloq-00A0.dtbo -b 0 -@ /lib/firmware/suf_keeloq-00A0.dts 

echo suf_keeloq > /sys/devices/bone_capemgr.?/slots
echo suf_keeloq > /sys/devices/platform/bone_capemgr/slots

Ez már működik, csak jó lenne valahogy boot időben betölteni.
Ahhoz, hogy ezt elérjük, hozzá kell adnunk a /boot/uEnv.txt fájlhoz:

cape_enable=bone_capemgr.enable_partno=suf_keeloq

Következik: Integráció az OpenHAB-bal

Mesék a házautomatizálásról - OpenHAB telepítés

Akkor itt most felrakom az OpenHAB-ot mint központi házvezérlőt.
Az OpenHAB egy java alapú rendszer, tehát telőször is szükségünk van egy Oracle Java-ra. Ahhoz, hogy ezt felrakjuk hozzá kell adnunk a PPA repository-ját.
Melleseleg: Tudom, hogy a sudo vudu alapvetően fontos, a biztonsághoz. Magam részéről a saját Windowsos gépemet egyszerű felhasználóként használom XP óta, amikor az UAC még tervként sem létezett.
De amikor valamit összerakok, akár Windows-on akár Linux-on és amit csinálok az tisztán adminisztratív dolog, azt adminként csinálom. Tehát az első dolog amit csinálok a linuxon, amikor jó néhány dolgot telepítenem kell, ezzel kezdem:

sudo su

Ezért a továbbiakban nem fogok minden sor elejére sudo-t írni.

1. Adjuk hozzá a dpkg-hez az Oracle Java PPA repository-ját és rakjuk fel:

apt-get install software-properties-common

add-apt-repository ppa:webupd8team/java apt-get update apt-get install oracle-java8-installe 

2. Töltsük le az OpenHAB fájljait. Ezekre lesz szükségünk:

https://bintray.com/artifact/download/openhab/bin/distribution-1.8.1-runtime.zip
https://bintray.com/artifact/download/openhab/bin/distribution-1.8.1-addons.zip
https://bintray.com/artifact/download/openhab/bin/distribution-1.8.1-demo.zip

Én alapvetően a Windowsos gépemen szoktam ilyesmit letölteni és után WinSCP-vel átmásolom a linux-ra.

3. Csomagoljuk ki a fájlokat és gyártsunk konfigurációt

mkdir /opt/openhab

unzip distribution-1.8.1-runtime.zip -d /opt/openhab/

unzip distribution-1.8.1-demo.zip -d /opt/openhab/

cp /opt/openhab/openhab_default.cfg /opt/openhab/openhab.cfg

4. Miután még mindíg sudo módban vagyunk el is indíthatjuk az OpenHAB-ot, hogy ellenőrizzük a funkcionalitását:

/opt/openhab/start.sh

Némi várakozás után megnézhetjük az eredményt egy böngészőben:

http://<ip cím>:8080/openhab.app?sitemap=demo

Rendben. A szerverünk működik, de még nem végeztünk. Itt áljunk meg egy pillanatra.

Először: talán észrevetted, hogy nem csináltam specifikus felhasználót az openhab-hoz. Ennek oka van.

Az Ubuntut nem beágyazott rendszerekhez tervezték. Ezért, nincs arra beépített megoldás (vagy én nem tudok róla), hogy a mezei felghasználó hozzáférjen a hardver GPIO portokhoz (ha te tudsz erre egyszerű megoldást, kérlek, ne tartsd meg magadnak). A következő részekben, használni akarom a GPIO-t. Ezek alapján az OpenHAB a root nevében fog futni.

Másodszor: Szükségünk van egy megoldásra, hogy az OpenHAB daemon-ként fusson. Tehát...

5. Töltsük le a daemon scriptet innen:

https://github.com/openhab/openhab/wiki/Samples-Tricks#how-to-configure-openhab-to-start-automatically-on-linux

Mentsük el az /etc/init.d mappába openhab néven.
Állítsuk be:

chmod a+x /etc/init.d/openhab
update-rc.d openhab defaults

Szerkesszük meg a kedvenc szövegszerkeszőnkkel. Valószínüleg csak a RUN_AS bejegyzést kell openhab-ról root-ra állítani.
Indítsuk el:

/etc/init.d/openhab start

Most újra ellenőrizheted a böngészőben, hogy megy-e, és a /var/log/openhab.log-ban nézhetjük meg, hogy van-e hiba.

Mesék a házautomatizálásról - Irány a komfortzónám

Ok, kezdjük el:

Nem vagyok egy Linux guru. A piacon rengeteg különböző disztribució létezik, de nekem, csak az Ubuntuval és a Debiannal van némi tapasztalatom. Továbbá általában nem használok semmilyen linux GUI-t.
Tehát amikor belekezdek egy Linux alapú projectbe, az azt jelenti, hogy felrakok egy Ubuntut.
Miután úgy döntöttem, hogy ezt a projectet BeagleBone Green-re építem, fel kell raknom rá egy 14.14 LTS-t.
Az alap információ itt található: http://elinux.org/BeagleBoardUbuntu

1. Le kell tölteni a kész image-et innen: https://rcn-ee.com/rootfs/2016-02-11/flasher/BBB-eMMC-flasher-ubuntu-14.04.3-console-armhf-2016-02-11-2gb.img.xz
(ma a 16.04 már létezik, de én maradok a régebbinél, mert az stabilabbnak tűnik). Le kell tölteni továbbá az image író eszközt (Win32DiskImager):

https://sourceforge.net/projects/win32diskimager/files/latest/download

És szükségünk van egy minimum 2GB-os uSD kártyára is.

2. Csomagoljuk ki az image-et egy mappába a gépen. A 7-Zip pl. alkalmas a feladatra. Telepítsük fel a Win32DiskImagert.

3. Írjuk ki az image tartalmát a uSD kártyára

4. Amikor az írás kész, rakjuk át a kártyát a Beaglebone-ba. Nyomjuk meg és tartsuk lenyomva a boot select gombot (a uSD foglalathoz legközelebb lévő gomb) miközben tápellátást adunk a panelnek. Egy rövid indulási fázis után a LEDek Knight Rider-est fognak játszani (Hmm, mindenki tudja még, hogy mi az a Knight Rider?). Várjuk meg amíg befejezi és az összes LED bekapcsol.

5 Dugjuk fel az eszközt az Ethernet hálózatra. Ha ki tudjuk deríteni a DHCP által adott címet, akkot a 6-8 pont opcionális. Csak indítsuk újra a panelt, a tápellátásának ki és bekapcsolásával.

6. Telepítsük fel a panel PC meghajtóját. A Windows meghajtó itt található:
64 bit: http://beagleboard.org/static/beaglebone/latest/Drivers/Windows/BONE_D64.exe
32 bit: http://beagleboard.org/static/beaglebone/latest/Drivers/Windows/BONE_DRV.exe
Ez NEM egy soros port emulátor, amint azt várnánk, hanem egy virtuális ethernet meghajtó. Egy SSH terminálra (pl. PuTTY) lesz szükségünk a csatlakozáshoz.

7. Csatlakoztassuk a BeagleBone-t a PC-hez. Ha már hozzá volt kötve, csak húzzuk ki az USB kábelt és dugjuk vissza. Amikor kihúztuk, vegyük ki a uSD kártyát is. A továbbiakban nem lesz rá szükségünk.

8. Ha lefuttatjuk az ipconfig-ot a gépen, egy új ethernet interface tűnik fel:

A címe 192.168.7.1. A Beaglebone a 192.168.7.2-es címen található. Csatlakozzunk az SSH terminálunkkal hozzá.

9. Ha nem használtuk az USB/Ethernetet a csatlakozáshoz, csak csatlakozzunk a DHCP-től kapott címmel. Az alapértelmezett felhasználó/jelszó páros: ubuntu/temppwd

Ha statikus címre van szükségünk, csak szerkesszük meg az /etc/network/interfaces fájlt.

10. Ha ellenőrizzük a DNS beállításainkat, azok valószínüleg nem működnek. A /etc/resov.conf szerkesztése nem oldja meg a problémát, miután a következő újraindításnál felülírásra kerül.

Szerkesszük meg a /etc/resolvconf/interface-order fájlt és rakjuk az eth* bejegyzést a lista tetejére. Ez korrgálja a DNS beállításokat.

11. Indítsuk újra a szerkezetet.

12. Telepítsük fel a frissítéseket:

apt-get update
apt-get upgrade

Mesék a házautomatizálásról - Miért?

Miért ne?

Azóta tervezem ezt mióta elköltöztünk 2009-ben. Akartam valami ház automatizálást rögtön a kezdetektől. Van egy barátom aki mélyen benne van a KNX rendszerekben. Azt mondta, hogy a költség a ház kb. 10%-a. Nem akartam ennyit kifizetni, így egyszerűen dobtam az ötletet.

Természetesen az automatizálás megjelent a házban itt-ott, de integráció nélkül.

Volt néhány kísérletem az automatizálásra, de nem mentem ennél tovább.

Csak a gyűjtemény kedvéért:

- Vettem egy pár Conrad FHT80B termosztátot és a kapcsolódó szelepeket. Ezek működnek a házban ma, de "szigeteket" képeznek.

- Vettem és telepítettem egy páratartalom érzékelőt és kapcsolót (része a Conrad FS20 rendszernek) a páramentesítőhöz (a beépített vezérlő használhatatlannak bizonyult)

- Vettem egy számítógép interfészt és egy kód monitort az FS20 rendszerhez. Az interfész változatlanul a dobozában van. A kód monitort (vagy hívjuk debuggernek) használtam párszor

- Vettem egy CUL v3.2-t az FS20 rendszer vezérlésére, de ez is az egyik alkatrész dobozomban kallódott mostanáig.

- Terveztem és építettem egy pár hőmérőt, amit arra szántam, hogy egy későbbi termosztát project alapját képezze, aminek neki se kezdtem.

Ahogy látod máig semmi kb. sem történt.

Miért most?

Ahogy haladok az elektronikai projectjeimmel, néhány dolog felkeltette a párom érdeklődését. Ebből pedig született egy kérés.

A garázsban nem látunk semmit, ha nincs felkapcsolva a lámpa, de nem tudod kikapcsolni, miután beültél az autoba. Az eredmény: Ha lusta vagyok (ami néha megesik), a lámpa felkapcsolva marad.

Ezt meg kéne oldani.

Az egy egyszerű megoldás lenne, hogy lecseréljük a kapcsolót egy nyomógombra, hozzáteszünk egy időzítőt, de...

Én össze akarok hozni egy ház automatizálási rendszert. Ez egy jó kiindulópont. Tehát az egyszerű megoldás helyett, miért ne építsünk valami nagyot?