Linux OS ir žaidimai

Daugelis pasakys, kad tai nesąmonė ir kad tai neveikia. Ypač tie kurie nelabai žino kas ta linux OS arba geriausiu atveju kažkada išbandė Ubuntu, bet supratimo kaip veikia ši operacinė neturi.

O realybė tokia, kad per pastaruosius penkis metus situacija labai smarkiai pasikeitė. Ir labiausia reikėtų padėkoti VALVE kompanijai.

Bet pradžioje visus žaidimus reikėtų padalinti į dvi stovyklas. Pirmieji, kurie ir buvo paruošti šiai operacinei (native), o antrieji kurie veikia proton’o pagalba, kur didžiausią darbą ir nudirbo VALVE.

Taigi, kas tas proton (https://github.com/ValveSoftware/Proton)? Proton yra įrankių rinkinys (apimantis wine, dxvk ir kitus) kurių pagalba Steam klientas gali paleisti windows platformai skirtus žaidimus.

Wine – kaip patys autoriai sako, tai ne emuliatorius, netgi šis pavadinimas tai ir reiškia Wine Is Not an Emulator. Wine pagalba sukuriamas programinis sluoksnis kurio pagalba windows aplikacija galvoja, kad bendrauja su windows sisteminiais dll ir/ar branduoliu, o realybėje po šiuo sluoksniu veikia linux OS (jei tiksliau bet kuri kita POSIX operacinė).

DXVK – taip pat yra programinis sluoksnis, tik šis sluoksnis nebando padengti visos windows operacinės, o tik directx 9/10/11. Tam tikra prasme jį galima pavadinti linux’iniu directx’u.

Kaip žinoti prieš perkant ar žaidimas veiks? Yra du keliai. Nusipirkti ir pabandyti paleisti, jei neveikia arba veikia ne taip kaip turėtų, galima tiesiog paprašyti, kad gražintų už žaidimą pinigus (refund). Antras kelias yra apsilankyti https://www.protondb.com ir pasitikrinti ar veikia norimas žaidimas. Beje ten pat galima užpildyti raportą apie tai kaip veikia/neveikia vienas ar kitas žaidimas.

Kaip matosi iš viršuje esančio paveiksliuko šiai dienai yra parašyti raportai apie 16 579 žaidimus iš kurių 13 104 veikia linux OS. Tad jei neesi išprotėjęs geimeris tikrai galima rasti ką pažaisti laisvalaikiu. Tai mes sėkmingai ir darome 🙂

Visų pirmą ko reikia, tai Steam kliento. Diegimas priklauso nuo naudojamos distribucijos.
Antras žingsnis yra nustatymuose uždėti kelias varneles:

Ir viskas, daugiau vartotojui nereikia nieko daryti, spaudžiam PLAY ir žaidžiam (jei veikia 🙂 )

Daugelis žaidėjų (ypač jei kalba eina apie komandinius) tarpusavyje bendrauja naudodami Discord (https://discord.com) kuris puikiai veikia linux OS.

Turbūt daugelis transliuotojų (stream’erių) naudoja OBS žaidimui transliuoti twitch ar youtube platformoje. OBS puikiai veikia linux OS. Net ir nereikia būti transliuotoju, su juo labai patogu įrašinėti žaidimo, lango ar viso ekrano vaizdą.

Šiai dienai mano kompiuterio parametrai: AMD Ryzen 7 3800X, 32G RAM, NVIDIA 2070, 144Hz monitorius.
Nuo pat ~2003 (tada tai buvo naudota GeFoce 2) metų renkuosi tik NVIDIA vaizdo plokštes. Taip, kažkada Linusas parodė vidurinį pirštą jiems (https://www.youtube.com/watch?v=IVpOyKCNZYw), bet kas liečia vaizdo plokštes staliniams kompiuteriams, jos tiesiog visada veikia.

Na ir pabaigai sąrašas:
1. Counter-Strike: Global Offensive. Šis žaidimas yra skirtas linux OS (native) tad veikia be jokių papildomų įrankių.
2. Automobilista 2. Šis jau naudojasi proton’o pagalba. Veikia puikiai. Mato pajungta vairą. Vienintelis minusas, kad persijungus į kitą programą ir grįžus atgal ekranas tampa juodas. Šį bėda buvo pataisyta su naujausia proton versija, tad grįžus atgal dabar jau vaizdas yra, bet yra pametamas vairas.
3. Assetto Corsa Competizione. Dar vienas lenktynių simuliatorius kuris pastaruoju metu bando išstumti (ir galbūt išstums) antroje vietoje esanti Automobilista2. Veikia be priekaištų.

Viso Steam’e yra 44 žaidimai, tad visko nevardinsiu. Bet iš populiaresnių puikiai veikia: F-1, DirtRally, Project Cars2, Quake Champions.

Pirmas ansible “prasukimas” ant Ubuntu mašinos

Ansible (https://www.ansible.com/) tai automatizacijos įrankis. Tarkime turime 2.. 5 .. 100 .. 200 ir daugiau linux’iniu mašinų (mačiau lyg yra ir windows, bet pastarosios nenaudoju, tad nežinau) kažkiek valdyt galima ir vmware, ir norime visuose mašinose atlikti tokius pačius veiksmus. Tarkime super paprastas pavyzdys instaliuoti visuose mašinose vim. Lendant giliau, galima naudoti sąlyginius sakinius, kintamuosius, galima kurti, trinti, redaguoti failus (konfigus), instaliuoti paketus ir praktiškai viską ką galima padaryti konsolėje. Tad jei yra daugiau nei vienas serveris kurio konfiguracija turi būt tokia pat, ar labai panaši – ansible jūsų draugas.

Taigi situacija. Penkios Ubuntu 16.04 LTS mašinos. Ansible playbook’ą paleidinėja (prasukinėja?) Jenkins (https://jenkins.io/). Pridedu šeštą Ubuntu 16.04 LTS į hosts failą, SSH raktą ir važiuojam! … ir nevažiuoja:

SSH Error: data could not be sent to remote host

Bandau jungtis iš Jenkins į naująjį Ubuntu, viskas puikiai veikia. Iš Ubuntu pusės matosi, kad susijungimas įvyksta. Apkaltinam Jenkins. Mintis sukasi apie Jenkinso SSH agenta, gal jis turi kažkokį seną raktą ar nepasiima naujo… Ta proga atnaujinamas Jenkinsas ir visa distribucija. Reboot. Neveikia. Visi kiti likusieji Ubuntu veikia kuo puikiausiai.

Bandau leisti ansible playbook’ą iš savo kompiuterio… Ta pati klaida. WTF? Ryšys tikrai yra, ssh’išintis galiu.. pingas eina. Niekas neblokuota (viskas default, nes ansiblas tai neprasuktas). Googlinu, nieko nerandu. Ir taip staiga mintis galvon, o pythonas yra?

apt install python

Viskas veikia 🙂

Išvada:
1. Ansible klaida apgaulinga (ar suprasta ne taip), o prie jos prisirišus sudeginta bereikalingai laiko.
2. Ubuntu 16.04 LTS server eina be python paketo… Kas galėjo pagalvoti?

SSD sparta


SSD kompiuteryje naudoju jau turbūt >7 metai. Pirmasis diskas (jis vis dar veikia ir nė kart nepavedė) yra OCZ-AGILITY3. Pastarojo talpa yra 64GB tad su laiku jau tiesiog netilpo visa root particiją su Android Studio, keleta Steam žaidimų. Todėl buvo pakeistas į Samsung SSD 860 EVO 250GB

Vieną dieną rašo draugas: “Nusipirkau Samsung SSD, padariau greičio testus bet greitis tik ~200MB/s” Tada priėjom išvados, kad jo kompiuterio SATA jungtis yra senoka t.y. 3Gb/s. Po disko keitimo man net į galvą nešovė pažiūrėti kaip greitai veikia naujasis. Žiūrim ir matom:

Timing cached reads: 23102 MB in 1.99 seconds = 11585.15 MB/sec
Timing buffered disk reads: 818 MB in 3.00 seconds = 272.59 MB/sec

Beje, disko greitį matuoju su:

sudo hdparm -Tt /dev/sda1

O gi pasirodo, kad maniškio kompiuterio motininė plokštė turi du SATAIII 6Gb/s ir keturis SATAII 3GB/s, taip gavosi, kad visus diskus jungiau eilės tvarka ir SSD diskui atiteko SATAII 3Gb/s spartos jungtis. Taisom šitą klaidą ir testuojam iš naujo:

Timing cached reads: 24158 MB in 1.99 seconds = 12116.03 MB/sec
Timing buffered disk reads: 1580 MB in 3.00 seconds = 526.18 MB/sec

Realaus greičio skirtumo nepajutau.

PS: Diskui pajungti panaudotas Supermicro SATA Flat Straight-Straight 81cm Cable (CBL-0481L)

ADS-B+Banana PI=flightradar24

Paruošus darbui Banana PI visai atsitiktinai toptelėjo mintis pasidalinti ADS-b duomenimis su Flightradar24 (www.flightradar24.com).

ADS-b tai atvirai lėktuvų transliuojamos metrikos (aukštis, greitis, koordinatės ir t.t.). Visa tai transliuojama 1090MHz dažniu ir gali būt priimama su vos 10€ kainuojančiu USB TV tiuneriuku. Aš juos turiu kelis, bet šiuo konkrečiu atveju naudojamas šis:

Aliexpress puslapyje į paiešką parašius “ads-b” tikrai rasite ne vieną tokį ar panašų tiuneriuką. Svarbiausia, kad jo mikreschemų rinkinys (chipset) būtų RTL2832U.

Jungiam tiuneriuką prie kompiuterio ir instaliuojam rtl-sdr
Ubuntu:

apt install rtl-sdr

Archlinux:

pacman -Sy rtl-sdr

Nesvarbu kuria OS naudojat (kad ir bet kuria kita linux distribuciją) reikia uždrausti (blacklistinti) dvb_usb_rtl2832u kernel modulį. Pastarasis modulis yra skirtas skaitmeninei TV žiūrėti, jis yra kernelio dalis, todėl užsikraus pirmasis ir “trukdys” mums naudotis tiuneriuku ne pagal jo tiesiogine paskirtį.

Patikrinimui ar viskas gerai veikia, naudojam:

rtl_test -t

Iš puslapio https://www.flightradar24.com/share-your-data kopijuojame pateikta komanda ir leidžiama kaip root. Mano atveju tai buvo:

bash -c "$(wget -O - https://repo-feed.flightradar24.com/install_fr24_rpi.sh)"

Šis skriptas suinstaliuos fr24feed servisą. Konfiguruojame su:

fr24feed --signup

Aš iš anksto jau buvau užsiregistravęs flightradar24 puslapyje, tad čia panaudojau tuos pačius prisijungimo duomenis.

Maniškė konfigūracija atrodo taip:

root@bpi-iot-ros-ai:~# cat /etc/fr24feed.ini 
receiver="dvbt"
fr24key="***************"
path="/usr/bin/dump1090-mutability"
bs="yes"
raw="yes"
logmode="1"
procargs="--net"
windowmode="0"
logpath="/var/log/fr24feed"
mpx="no"
mlat="no"
mlat-without-gps="no"

Enable’inam servisą:

systemctl enable fr24feed

Startuojame:

systemctl start fr24feed

Jei viskas veikia, adresu http://_jūsų_serverio_IP_adresas:8754 turėtumėt matyti kažką panašus:

O adresu http://_jūsų_serverio_IP_adresas:8080 (vaizdas su nauja antena, aprašymas žemiau)

Norint matyti šį vaizdą konfiguracijos ketvirta ir aštunta eilutės yra privalomos.
Šiam lange rodomi šiuo metu tiuneriuko matomi lėktuvai. Jei per minutę joks signalas negaunamas, lėktuvėlis iš šio žemėlapio yra šalinimas. Taigi, šiuo mementu maniškis banana pi priima signalą iš 11 lėktuvų ir dar du iš kurių pilnai duomenis nepaimami (per toli?).

Ir paskutinis bet svarbus įrenginys visame šitame yra antena.

Pirmas tris savaites tiuneriukas buvo pajungtas prie “bet kokios” (PMR dažniui skaičiuotos Yagi tipo) antenos. PMR dažnis yra 446MHz, lėktuvai transliuoja 1090MHz… tad tai net nėra panašų, bet su tokia komplektacija lėktuvai buvo matomi iki 120km spinduliu.

Kiek pasigoolinus nusprendžiau pasidaryti šiam dažniui skirta anteną “voriuką”. Antena tikrai nedidutė, gero sprindžio dydžio. Antenos “brėžinys” matosi vienoje iš nuotraukų. Visų strypelių ilgis 68mm, kampai 45 laipsnių.


Po antenos pakeitimo, matymo spindulys padidėjo nuo ~120km iki 210km t.y. beveik dvigubai.
Atstumo galima pasiekit ir didesnio, bet antena yra ant vieno aukšto namo, kuris aplinkos atžvilgiu yra šiokioje tokioje dauboje.

Taip pat daugiau kaip šimtu padaugėjo per diena nuskaitomų lėktuvų kiekis:

Už tai, kad teikiu duomenis flightradar24 puslapiui, mano Basic paskyra pavirto į Business, todėl puslapyje galiu prieiti prie visiškai visų duomenų ir be reklamos.

PS: Su šiuo tiuneriu galima nuveikti ir dar daugiau smagių dalykų, gal kada aprašysiu.
PSS: Nuotraukoje aukštoji yra CB antena, gal kada ir apie tai parašysiu.

Banna PI OS instaliavimas

Šis kompiuteriukas man į rankas pateko jau senokai. Palyginus su pirma aviete jis turi spartesni procesorių, daugiau RAM atminties ir gigabitinį LAN (tikroji išmatuota sparta 396 Mbits/sec) ir esminis skirtumas, turi SATA jungį.

Tada buvo suinstaliuotas Archlinux (internete rastas disko atvaizdas), bet pastebėjau, kad po sistemos atnaujinimo jis tiesiog nesikraudavo. Į pacman.conf įdėjau, kad ignoruotu kernelio ir systemd paketus. Kažkuriam laikui padėjo, bet po eilinio update ir nesikrovimo kompiuteriukas buvo užmirštas gan ilgam.

Po ilgo laiko vėl googlinant ir ieškant Archlinux’o atvaizdo teko nusivilti, kažko naujo nėra. Kompiuteriukas jau paseno ir nelabai kas jam atnaujina tuos atvaizdus. Pirminis bandymas buvo vadovaujantis https://wiki.archlinux.org/index.php/Banana_Pi pasigaminti atvaizdą pačiam. Bet po keturių (o gal ir daugiau) nesėkmių nuleidau rankas. Sistema nesikrovė.

Tada užkliuvo (http://wiki.banana-pi.org/Banana_Pi_BPI-M1#Ubuntu_Server), kad yra Ubuntu 16.04. Pagalvojau, kad man to pakaks. Siunčiu atvaizdą, rašau į kortelę. Kraunasi. Valio.

O dabar smagiausia dalis. Kaip priversti užmountinti root particiją iš disko prijungto per SATA jungti. Ir ko aš nebandžiau, SD kortelėje redaguoti armbianEnv.txt, fstab, boot.src ir dar bala žino kas. O jis nieko, užsispyręs, mountina antra SD kortelės particiją kaip root nors tu ką.

Ir vis dėlto atsakimą radau. Kaip dariau aš:
Antra SD kortelės particiją (root) nusikopijavau į SATA 2.5″ diską (mano atveju tai senasis mano SSD diskas OCZ AGILITY3).
Po kopijavimo SATA diske, paredaguojam /etc/fstab

/dev/sda1  /               ext4   defaults,noatime  0       1

Prijungiam SATA diską. Įjungiam kompiuteriuką. Prisimountinam pirmą SD kortelės particiją:

mount /dev/mmcblk0p1 /mnt

Redaguojam failą:

vim /mnt/bananapi/bpi-m1/linux/boot.cmd

Ir svarbiausias momentas:

mkimage -C none -A arm -T script -d /mnt/bananapi/bpi-m1/linux/boot.cmd /mnt/bananapi/bpi-m1/linux/boot.scr

Štai jau sistema kraunasi iš SD kortelės ir root particiją naudoja iš disko prijungto per SATA jungtį. Viskas labai puikui, BET pas mane SD kortelė 16GB iš kūrių 8GB užima boot particija ir senoji root. Boot particija tik 256MB. Nesinori dėl tiek naudoti tokios didelės kortelės, tuo labiau, kad ant stalo guli sena 2GB kortelė.

Vėl prasidėjo smagioji užsiėmimo dalis. Kaip iš atvaizdo kuriam yra trys (!) particijos, palikti tik dvi ir jas suklonuoti į SD kortelę. Klonuoti po vieną particija man nepavyko. Pirmoji atvaizdo particija lyg ir tuščia (jos dydis 105MB) bet be jos sistema nesikrauna, panašu, kad ji kažkam naudojama.

Vėl gelbėja google. https://softwarebakery.com/shrinking-images-on-linux. Panaudoju paskutinį aprašyta būdą:

truncate --size=$[(729087+1)*512] 2018-07-26-ubuntu-16.04-server-preview-bpi-m1-m1p-r1-sd-emmc.img

Rezultate gaunu 356MB disko atvaizdą, kuris puikiai klonuojasi į 2GB (mažesnės jau neturiu) kortelę.
Po klonavimo reikėjo persikopijuoti aukščiau generuota bananapi/bpi-m1/linux katalogą, nes šiuo atvėju aš redagavau originalų iš interneto atsiųsta atvaizdą kuris vėl mountino root iš SD antros particijos.

Dabar jau viskas veikia kaip ir turi veikti. Boot particija SD kortelėje, visas root SSD diske.

Duomenų rašymas į nutolusį influxdb naudojant Redis

Pradinė schema.
Raspberry pi surenka termometrų duomenis ir PHP bei CURL’o pagalba (rašiau čia) keliauja į dvi influxdb bazes. Viena yra lokaliai pačioje avietėje, kita yra nutolusiam VPS serveryje.

Problema pažymėta raudona rodykle. Kartais dingsta namuose interneto ryšys (vis dar 5GHz antena, 100mbs planas, laukiu kada suvirins šviesolaidį). To pasekoje išsiskiria duomenys tarp abiejų influxdb.

Senesnės influxdb versijos turėjo clustering funkcionalumą, bet šitas malonumas dabar mokamas.

Taip pat yra tokie sprendimai kaip influx-relay, bet This retry logic is NOT sufficient for for long periods of downtime as all data is buffered in RAM.

Problemos sprendimo schema:

Duomenys rašomi lygiagrečiai į lokalų influxdb ir redis.

Į redis’ą patogiai rašyti galima su phpredis. Archlinux’e pkgbuild’as yra AUR’e, nutolusiam VPS’e yra Centos 7 tad ten teko susikompiliuoti iš source. Abiem atvejais reikia paredaguoti php.ini ir pridėti extension=redis.so.

Tad palyginimui kodas tarp CURL’inimo į influxdb ir redis:

//Post to influxDB
$ch = curl_init("http://127.0.0.1:8086/write?db=termometrai");
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS,"temperaturos ".$daviklioHWID."=".$tempvalue);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_exec($ch);
curl_close($ch);
//Post to redis
date_default_timezone_set("UTC"); 
$redis = new Redis();
$redis->connect('127.0.0.1', 6379);
$redis->rPush('VPS1',"temperaturos ".$daviklioHWID."=".$tempvalue." ".strval(time()));
$redis->close;

Į redis rašau POST duomenis, tam kad kitam gale aklai galėčiau juos vėl pakišti CURL’ui. Vienas skirtumas, kad pridedu šio momento timestamp’ą. Jis reikalingas tam, kad duomenys iš redis’o iki nutolusio serverio, ryšio dingimo metu, gali keliauti ir kelias valandas. Atsiradus ryšiui ir surašius duomenis be timestamp’o į influxdb duomenys sukristu ne su laiku kada jie buvo įrašyti į redis, o su laiku kada buvo įrašyti į influxdb. Tad šiuo atveju duomenis atkeliauja jau atsinešdami ir laiką kada buvo nuskaityti.

Nutolusiam VPS serveryje duomenis iš redis’o skaito PHP skirptas. Redis duomenis skaitau su:

$redis->lPop('VPS1');

Ši funkcija paima vieną įrašą iš nurodytos “eilės” (kuri šiuo atveju yra VPS1) ir iškarto ta įrašą ištrina. Sekančiu kartu paimama kita reikšmė ir pašalinama. Tokiu būdų gaunamas duomenų FIFO.

Rezultate turime labai greitai ir labai mažai resursu naudojančia redis. Avietė pildo duomenis naudodama RPUSH, nutolęs serveris duomenis tuo pačiu metu skaito ir trina su LPOP.

Dingus ryšiui, (nutolęs serveris nemato Rasbery Pi) consumer’is kas 10 sekundžių kartoja prisijungimo procedūrą tol kol prisijungia. Po viena ima visus duomenis tol kol ištuštėja eilė. Kai eilė ištuštėja “užmiega” dešimčiai sekundžių po kurių vėl pasitikrina ar yra duomenų. Jei nėra, toliau “miega” 10 sekundžių, jei yra “sukramto” tai kas yra.

Consumer’io (php skripto) veikimą užtikrina Supervisord. Tai labai nedidelis servisas kuris gali užtikrinti bet kokio skriptuko ar programos nenutrūkstama veikimą. Jei skriptas dėl kažkokios priežasties nulūžtu arba jį tiesiog nu kill’inus, supervisord pasirūpina jo paleidimu.

Rezultatas

Per dvi valandas dirbtinio ryšio nebuvimo, duomenys sukrito per ~15 sekundžių.

Metrikoms: influxDB + Grafana

Vienintelės mano renkamos metrikos yra temperatūra apie kuria rašiau Protingas namas. 1 Dalis. Temperatūra.. Tiesa nuo tada termometrų padaugėjo ir dabar jų aštuoni. Ir duomenys jau senokai saugomi ne mariadb/mysql, o influxDB. O duomenims peržiūrėti ir analizuoti naudoju Grafana.

Oficealaus influxdb paketo nėra, tad teks susikompiluoti iš AUR:

yaourt -S influxdb

Pirmuosius influxdb žinksnius galima rasti čia. Tikrai nėra nieko sudėtingo.

Mano duomenų bazė vadinasi termometrai, o lentelė temperaturos.

Duomenys atrodo taip (stulpelių yra daugiau, apkirpau, kad tilptu į puslapį):

> select * from temperaturos limit 20 
name: temperaturos
time                28-0000052D4E36 28-0000052DC554 28-0000052DCA4A
----                --------------- --------------- ---------------
1491421622470175617                                 20.6875
1491421622933431847 5.6875
1491421624775957066                 20.1875
1491421683164960608                                 20.6875
1491421683725053335 5.6875
1491421685386914026                 20.1875
1491421743393921182                                 20.6875
1491421743956469988 5.6875
1491421745634864667                 20.1875
1491421802759609752                                 20.6875
1491421803239163911 5.6875
1491421804969827574                 20.1875

Duomenys taip pabire, nes kiekvienas termometras įrašomas atskirai (skiriasi įrašymo laikas). Viso to išvengti galima surinkus visus duomenis ir įrašinėjant viską vienu metu, viena užklausa. Taip užklausa, nes duomenis įrašinėjami kreipiantis tam tikru portu CURL‘u, WGET‘u ar kita programine įranga darant GET užklausą. Galima tiesiog į naršyklės URL’ą suvesti atitinkama adresą.

Aš duomenis rašau su PHP paCURL‘inant URL‘ą. Kodas žemiau:

        //Post to influxDB
        $ch = curl_init("http://localhost:8086/write?db=termometrai");
        curl_setopt($ch, CURLOPT_POST, 1);
        curl_setopt($ch, CURLOPT_POSTFIELDS,"temperaturos ".$daviklioHWID."=".$tempvalue);
        curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
        curl_exec($ch);
        curl_close($ch);

daviklioHWID yra termometro DS1820 adresas.
time (laiko) reikšmės paduoti nereikia.

Tame viskas ir paprasta, tiesiog aklai padavinėju termometro adresą ir jo reikšmę. Jei sistemoje atsiranda naujas termometras (naujas adresas) nieko daryt papildomai nereikia, stulpelis influxDB atsiranda automatiškai.

Dabar apie duomenų atvaizdavimą. Duomenis grafiškai atvaizduoti naudoju grafana.

sudo pacman -Sy grafana

Kai pradėjau naudoti Grafana tada dar ji nemokėjo skaityti iš mariadb/mysql. Dabar paskutinėse versijose ji tai gali daryti. Bet influxdb veikia akivaizdžiai greičiau, ypač kai db serveris paleistas ant Raspberry Pi model B.

Pirmą kartą prisijungus prie Grafana reikia prisidėti Data source t.y. duomenų šaltinį. Šiuo atveju tai indluxdb.

Turint duomenų šaltinį galima bandyti susikonfiguruoti Dash board t.y. langas kuriame bus grafikas/grafikai.

Maniškis atrodo taip (paspaudus pasididina):

Vienos metrikos (vienos linijos grafike) užklausa atrodo taip:

Visos keturios užklausos:

Atkreipiam dėmesį į GROUP BY. Grupuoju dėl dviejų priežasčių. Pirmoji, tai kaip minėjau aukščiau, duomenis įrašomi ne tuo pačiu momentu (skiriasi keliomis sekundėmis). Panaudojus grupavimą tiesiog skaičiuojamas, šiuo atveju trijų minučių vidurkis (tam ir naudojamas mean()) nesvarbu kiek matavimu per tas tris minutes buvo padaryta. Taip visi grafikai laiko atžvilgiu tampa lygus.

Antroji priežastis, kad termometrai nėra super tikslūs ir esant tomis pačiomis sąlygomis jie atiduota kažkiek kintamus (po kablelio) duomenis. Tad šiuo atveju grafikas kiek sulyginamas ir panaikinami 0.xxx nuokrypiai.

Protingas namas. 2 Dalis. Apšvietimo valdymas.

Iškarto sakau, nebuvo minties valdyti kambarių apšvietimo, tame prasmės aš nematau. Pažaisčiau pats, parodyčiau draugams tuom viskas ir pasibaigtu.

Tikslas buvo kiemo apšvietimo valdymas. Namo perimetre yra 10W “senukiniai” LED žibintai, parkavimosi vieta apšviesta 20W LED žibintu. Ir statybininkai visiems nameliams sustatė ~50cm aukščio žibintus su 5W LED lemputėmis. Taip pat statytojas pasirūpino, kad 5W žibintas automatiškai užsidegtu nusileidus saulei (ant stogo yra šviesos imtuvas). Visi kiti šviestuvai jau mano paties montuoti.

Visų žibintų maitinimas paimtas nuo minėto šviesos daviklio, o tai reiškia, kad ir labai norit, šviesiu paros metu žibintai nedega.

Viskas pajungta nuo Raspberry gpio pin’ų (jungčių). Naudotas rėlių blokas iš Kinijos. Buvo minčių bloką lituotis pačiam, bet perkant detales pvz Lemonoj, vien jos kainuoja daugiau nei gatavas produktas.

Programinė įranga ir kaip viską valdau. GPIO išvadus labai paprasta valdyti su WiringPi. Aš naudoju Archlinux, tad šį paketą instaliuoju:

sudo pacman -Sy wiringpi

Pasinaudodami gpio komanda pasižiūrime ką turime išvaduose:

[dinux@alarmpi ~]$ gpio readall
 +-----+-----+---------+------+---+-Model B1-+---+------+---------+-----+-----+
 | BCM | wPi |   Name  | Mode | V | Physical | V | Mode | Name    | wPi | BCM |
 +-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+
 |     |     |    3.3v |      |   |  1 || 2  |   |      | 5v      |     |     |
 |   0 |   8 |   SDA.1 |   IN | 1 |  3 || 4  |   |      | 5V      |     |     |
 |   1 |   9 |   SCL.1 |   IN | 1 |  5 || 6  |   |      | 0v      |     |     |
 |   4 |   7 | GPIO. 7 |  OUT | 0 |  7 || 8  | 1 | ALT0 | TxD     | 15  | 14  |
 |     |     |      0v |      |   |  9 || 10 | 1 | ALT0 | RxD     | 16  | 15  |
 |  17 |   0 | GPIO. 0 |   IN | 0 | 11 || 12 | 1 | IN   | GPIO. 1 | 1   | 18  |
 |  21 |   2 | GPIO. 2 |   IN | 0 | 13 || 14 |   |      | 0v      |     |     |
 |  22 |   3 | GPIO. 3 |   IN | 0 | 15 || 16 | 0 | OUT  | GPIO. 4 | 4   | 23  |
 |     |     |    3.3v |      |   | 17 || 18 | 0 | IN   | GPIO. 5 | 5   | 24  |
 |  10 |  12 |    MOSI |  OUT | 1 | 19 || 20 |   |      | 0v      |     |     |
 |   9 |  13 |    MISO |  OUT | 1 | 21 || 22 | 0 | OUT  | GPIO. 6 | 6   | 25  |
 |  11 |  14 |    SCLK |  OUT | 0 | 23 || 24 | 1 | IN   | CE0     | 10  | 8   |
 |     |     |      0v |      |   | 25 || 26 | 1 | IN   | CE1     | 11  | 7   |
 +-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+
 | BCM | wPi |   Name  | Mode | V | Physical | V | Mode | Name    | wPi | BCM |
 +-----+-----+---------+------+---+-Model B1-+---+------+---------+-----+-----+

Rėlių valdymui panaudojau pin’us pagal BCM 10, 9, 11, pagal wPi 12, 13, 14
Pagal nutylėjimą šie pin’ai (jei neklystu) buvo IN todėl jų rėžimą keičiu

gpio mode 12 out
gpio mode 13 out
gpio mode 14 out

Po šių komandų mano minėti pin’ai jau dirba kaip išėjimas (taip kaip parodyta aukščiau esančioje lentelėje)

Norint įjungti/išjungti rėlę pajungta prie wPi 12 kontakto, naudojame:

gpio write 12 1
# arba
gpio write 12 0

Jungimo schema taip pat labai paprasta. +5V ir GND paimiau nuo laisvų GPIO išvadu, valdymo signalas jau ankščiau minėti pin’ai. Įtampai ir signalams perduoti naudojau UTP kabelį (atstumas ~1 metras) prie jo galų litavau Dupont cable jumeper

Vis dėlto, vienoje vietoje buvau strigęs. Atrodo viskas sujungta gerai, signalas ateina (indikacinis LED užsidega), bet rėlė nesuveikia. Pasirodo problema buvo vienas blogas kabeliukas ir būtent GND. Pakeitus jį jau netik indikacinis LED užsižiebdavo, bet ir rėlė suveikdavo.

imgp3647-pef_6cbkryimgp3649-pef_r1lbryimgp3655-pef_8q5dryimgp3656-pef_gjnoryimgp3658-pef_3587qyimgp3659-pef_2g3qry

Na ir žemiau video. Tiesa prastokos kokybės, bet esmė yra parodoma.

Pagaliau Raspberry veikia stabiliai

Kaip jau rašiau, buvo bėdų su maitinimu, kurias galvojau, kad išsprendžiau, bet pasirodo — ne. Problema pasirodo išliko, tik ne tokia dažnai pasireiškianti. Avietė kartą per savaite/dvi pamesdavo HDD, užtekdavo perkrauti ir vėl viskas dirbdavo tvarkingai iki kito karto. Taip kentėjau beveik pusmetį, kol neperskaičiau, kad Western Digital išleido specialų diską avietei, kuris vadinasi PiDrive. Nuorodą į produktą: http://wdlabs.wd.com/products/wd-pidrive-314gb/.

Šis diskas specifinis tuo, kad jis savyje neturi nei SATA nei IDE jungties. Ant jo valdymo plokštės yra USB3.0 jungtis. Lygiai tokie pat diskai montuojami į WD Passport išorinius, nešiojamus diskus. Skirtumas tas, kad šis diskas truputi modifikuotas. Jo startui reikalinga mažesnė srovė (diskas įsisuka lėčiau), tai pat sulėtintas jo valdiklio taktinis dažnis (naudojama mažiau energijos) na ir žinoma keista talpa už kiek didesnę kainą.

Diskas iš Nyderlandu (Olandija) iki durų Kaune atkeliavo DHL pagalba per maždaug savaitę, bėda tik tame, kad pačio išsiuntimo teko laukti tris savaites (gavau atsiprašymo laišką dėl vietinės WD logistikos apkrovimo).

Atkeliavus diskui, kopijuoju viską į naują. Kompiuteris startuoja, viskas veikia, viskas puiku.

Praėjus, berods keletai dienų, pasigirsta iš disko keisti garsai. Įrašas čia: https://www.youtube.com/watch?v=IGtzaIlMgWA Keičiau ir kabelius ir maitinimo blokus, jungiau per usb switch’ą su išoriniu maitinimu.. niekas nepadėjo. Taip avietė praleido gerą mėnesį išjungta, nelabai buvo laiko aiškintis kas čia daros ir internetas šiuo klausimu nieko nepadėjo.

Pradėjus vėl domėtis šiuo klausimu WD supporto forume atsirado tema, pasirodo ne pas mane viena tokie garsai sklinda. Pradėjus gilintis į bėda, kolega IRC (o taip aš jį vis dar naudoju) pasiūlė pasidomėti hdparm rakto S ir B parametrais.

Finalinis rezultatas:

sudo hdparm -B 255 /dev/sda1

Ši komanda išjungia disko Advanced Power Managment, diskas dabar sukasi tyliai, jokie pypsėjimai ar kiti pašaliniai garsai nesklinda.

Vėl paišosi temperatūros grafikas:
Ekranvaizdis_2016-07-26_23-01-26

Žiūrint į grafika matosi, kad oro temperatūra lauke buvo pakilus iki 40,4C. Kad ir kokia karšta diena buvo, bet tai nėra realu. Pats daviklis yra ant stogo šešėlyje, įdėtas į baltą dėžutę nuo foto juostelės, bet panašu tas negelbėja. Sekantis žingsnis konstruoti taip vadinama Stevenson Screen.

Raspberry PI + USB HDD = maitinimo bėdos

Jau antrą kartą šiais metais ir nežinia kelintą kartą per visą avietės naudojimo istoriją griūna SD kortelė. Tiesa pati pirmoji naudota, kuri, jei nemaišau buvo 2GB microSD įdėta į perėjimą, veikė pakankamai patikimai kol nebuvau priverstas pakeisti į kažką talpesnio.

Toliau sekė bent keleta 4GB kortelių, vieną iš jų (paskutinioji) buvo Kingston gamintojo.

Taigi nusipirkau vos ne pirmą pasitaikiusią, pigiausia (~11€) USB dėžutę 2.5″ SATA diskui, susikuriu boot ir root particijas (taip kaip nurodyta daryti šviežiai diegiant Archlinux’ą į avietę). Ištraukiu SD kortelę, pajungiu HDD ir… diskas nesisuka, pasirodo per silpnas maitinimas. Maitinimas HP 1A pakrovėjas. Greitai pasikuičiu stalčiuje ir randu HTC pakrovėją. Ant jo taip pat rašo 1A.

Prie HTC pakrovėjo jungiu USB dėžutės vieną iš USB (dėžutė turi dvi USB jungtis, kad būtų galima iškarto pajungti į dvi USB jungtis, tam, kad diskui užtektu srovės iš USB jungčių). Kitą jungiu į avietės USB. Pačią aveitę užmaitinu nuo HP pakrovėjo.

Viskas startuoja, bet pala… OS nesikrauna. Greitas pagooglinimas ir paaiškėja, kad kompiuteris moka startuoti tik iš SD kortelės. Taigi SD kortelė grįžta į savo vietą, bet prieš tai atsidarau boot particijoje esančią bylą /boot/cmdline.txt ir joje paredaguoju root reikšmę. Rezultate turiu tokią eilutę:

[dinux@alarmpi ~]$ cat /boot/cmdline.txt
root=/dev/sda2 rw rootwait console=ttyAMA0,115200 console=tty1 selinux=0 plymouth.enable=0 smsc95xx.turbo_mode=N dwc_otg.lpm_enable=0 kgdboc=ttyAMA0,115200 elevator=noop init=/usr/bin/init

Vėl jungiu. Viskas veikia, OS kraunasi. Krovimasis žymiai spartesnis nei iš SD kortelės.

Džiaugiuosi situacija gal vieną dieną.. avietė pakimba, na gal kas nutiko…, perkraunu, dar po dienos ar dviejų vėl kabo. Patikrinu log’us, matau:

usb 1-1.3: device descriptor read/64, error -71

Googlinu. Kažko labai naudingo nerandu. Nusprendžiu, kad gal tai dėl maitinimo trūkumo. Sukeičiu pakrovėjus. Dabar HP maitina diską, HTC kompiuterį. Panašu, kad bėda dingo. Bet mintis, kad viskas veikia “ant ribos” ir nelabai tvarkingai (du pakrovėjai) neduoda ramybės.

Ieškau pas kinus galingesnio maitinimo, galvoju gal vis dėlto pajungti taip vadinama industrinį 5V maitinimą, bet paskui netyčia aptinku 3.1A USB pakrovėją su dviem jungtim. Nuotraukoje parodytos dvi USB jungtis, prie vienos parašyta 2.1A prie kitos 1A. Realybėj nusipirkus šį pakrovėją šių užrašų nėra.

HDD jungiu į tą USB kur puslapyje parašyta 2.1A, avietę prie 1A.

Dabar jau sistema veikia kažkiek laiko ir galima teigti, kad viskas tikrai gerai, jokių lūžimų, jokių klaidų loguose.

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close