sabato 11 giugno 2016

Configurazione Raspberri PI 2

Dopo qualche mese di smanettamento con il raspberry, mi appunto qui una serie di note che ho raccolto nel frattempo.

Scelta del sistema operativo

La prima cosa da fare è selezionare il sistema operativo che girerà sul raspberry. Il consiglio che do è quello di provarne due o tre in prima persona, in modo da capire quale è quello più adatto alle proprie esigenze in base alle funzionalità offerte, configurabilità, versatilità.

La mia scelta è ricaduta su una distribuzione linux (che conosco bene), magari debian based (adoro apt), con Kodi installato sopra (mi interessa che sia un media center). In base a questi criteri, ho selezionato queste:
XBian e Osmc sono piuttosto simili, tranne che la seconda di default ha una skin personalizzata per Kodi, mentre XBian usa quella predefinita; sono entrambe debian-based, mentre OpenElec è una distribuzione ad hoc non basata su nessuna distro preesistente.

A livello di velocità di avvio, la più veloce risulta essere OpenElec, seguita da Osmc e per ultima XBian.

OpenElec, per contro, monta una serie di cartelle (tra cui /etc) su partizione read-only, per cui ha un livello di configurabilità post-installazione molto basso.

Attualmente sto usando Osmc (con skin predefinita di Kodi!) e mi sto trovando bene.

Modifica del file /boot/config.txt

La prima modifica ha lo scopo di aumentare le prestazioni, ma una ricerca di "overclock rpi2" su google porta ad un mole di risultati in cui è difficile districarsi; ad esempio ho trovato alcuni risultati interessanti qui, qui e qui, dai quali ho estratto la seguente configurazione di partenza:
arm_freq=1000
sdram_freq=500
core_freq=500
over_voltage=2
gpu_men=320
temp_limit=75
boot_delay=0
disable_splash=1
initial_turbo=30
Un'ottima guida del significato di questi e altri parametri è quella ufficiale.

La seconda modifica ha l'obiettivo di evitare che all'avvio il raspberry prenda il controllo della TV (switching automatico); questo si ottiene aggiungendo al file config.txt la riga:
hdmi_ignore_cec_init=1
Inoltre, va modificato il comportamento di Kodi direttamente nel suo menù di configurazione, raggiungibile da  Kodi > Settings > System > Input Devices > Peripherals > CEC Adapter > Devices to power on during startup....

La terza modifica serve ad avviare l'HDMI per default: questo perchè è possibile accendere la TV in maniera del tutto asincrona rispetto al raspberry, per cui voglio trovare Kodi acceso senza dover effettuare un riavvio. Questa modifica prevede l'aggiunta di queste due righe:
hdmi_force_hotplug=1
hdmi_drive=2
secondo quanto descritto qui. Questa terza modifica la volevo rimuovere a vantaggio di uno script che controlla se la tv è accesa o no, lanciando automaticamente Kodi.

La quarta modifica serve a registrare il decoder MPEG-2, in caso lo si sia acquistato separatamente. E' possibile infatti acquistare separatamente il codice che attiva la decodifica hardware di un flusso MPEG-2; il costo è abbastanza contenuto e può essere effettuato presso questo sito. Dopo qualche giorno arriva per posta il codice da inserire mediante la riga:
  
    decode_MPG2=0xYYYYYYY

Il comando che verifica se la registrazione è andata a buon fine è

    vcgencmd codec_enabled MPG2

che restituisce disabled o enabled a seconda dei casi.

Configurazione della rete

Una cosa fondamentale è quella di impostare un indirizzo IP statico, tipicamente al di fuori dell'intervallo di indirizzi gestito in DHCP dal router di casa. La comodità di usare lo stesso indirizzo IP è quella di impostare sui vari desktop (qui a casa abbiamo di tutto, PC Windows, Linux, Mac, tablet Android...) l'accesso alla condivisa samba.

Un'altra funzionalità comoda è quella di  impostare il dns dinamico come già indicato qui.

Configurare Kodi

La prima cosa da fare è configurare la lingua italiana, poi verificare che funzioni la condivisione samba ed eventualmente attivare la condivisione DLNA (richiesta dalla mia smart TV).

Avviare kodi solo se la TV è accesa


Lascio sempre il mio raspberry acceso anche se alcuni periodi lo uso molto poco. Le assicurazioni riguardo al suo bassissimo consumo vanno però corroborate da esperienza diretta, per cui mi sono collegato al raspberry e ho dato un bel htop e, sorpresa! In idle completo ho notato la CPU al 10/15% ! Mi sarei aspettato dei valori 0 virgola, eppure non era così! Allora sono andato a vedere cosa consumava più CPU e ho notato il processo Kodi.Bin.

Una ricerca su internet mi ha confermato che Kodi in idle consuma, e dipende anche dalla skin selezionata (io uso quella di default), anche se non si usa da ore ed è da quasi sempre acceso lo screensaver (il dimming).

Per questo motivo mi è venuta l'idea di lanciare kodi solo se la TV è accesa, ed ho visto che anche qualcun altro ha avuto la mia stessa idea, per cui ho deciso di creare il mio script di verifica della TV, ottenendo il seguente:
#!/bin/bash

ping -c 1 -W 1 192.168.1.7 > /dev/null

if [ $? -eq 0 ]; then

        systemctl -q status mediacenter > /dev/null

        if [ $? -ne 0 ]; then
                sudo systemctl start mediacenter
        fi

else

        systemctl -q status mediacenter > /dev/null

        if [ $? -eq 0 ]; then
                sudo systemctl stop mediacenter
        fi

fi

exit 0 

Poi ho creato il file /etc/systemd/system/checkHdmi.service con il seguente contenuto:
[Unit]
Description=Pinga la TV

[Service]
Type=simple
ExecStart=/home/osmc/checkHdmi.sh

Ed il file /etc/systemd/system/checkHdmi.timer che lancia il servizio ogni minuto:
[Unit]
Description=Check if TV is on

[Timer]
OnBootSec=60
OnUnitActiveSec=60
Unit=checkHdmi.service

[Install]
WantedBy=timers.target

Ho abilitato ed avviato il servizio con i comandi: 

systemctl enable checkHdmi.timer   
systemctl start checkHdmi.timer

Dns dinamico


La necessità è quella di raggiungere dall'esterno il server casalingo che abbiamo messo su, magari per farci ssh dall'esterno della lan di casa, un client torrent web al quale aggiungere .torrent dal telefonino mentre siamo in giro o un sito http per provare wordpress o tomcat.

Ci sono una serie di siti che forniscono dns dinamico gratuitamente, tra i quali:
  • noip (richiede mensilmente la conferma, anche se usato)
  • afraid (i subdomain possono sparire in maniera impredicibile)
  • duckdns
  • nsupdate (richiede annualmente la conferma, se non usato)

Se siamo abbstanza fortunati sul pannello di configurazione del modem/router ADSL c'è già la possibilità di settare un indirizzo dinamico, altrimenti bisogna configurarselo a mano.

Configurare il server casalingo per comunicare il nuovo IP al sito dns dinamico è un vero inferno se usiamo dyndns o inadyn, ma abbastanza semplice se usiamo il comando http che ci fornise il sito dns dinamico; tale comando aggiorna sul sito il nostro nuovo indirizzo IP visibile dall'esterno.

Per il servizio afraid è un comando wget che ho inserito nello script /etc/rc.local, ma il problema è che tale script viene eseguito prima che internet sia raggiungibile; va quindi inserito un test per verificare la connettività.

Tale test lo prendiamo per esempio da qui, ed aggiungiamo un'attesa con retry infinito, il risultato è la seguente sezione di script (ringraziamo sempre il sito tohtml.com per la conversione in HTML):
#!/bin/sh

isConnected="0"

while [ $isConnected -eq "0" ]
do
        sleep 10
        wget -q --spider http://freedns.afraid.org
        if [ $? -eq 0 ]; then
                isConnected="1"
        fi
done

wget -O /dev/null http://freedns.afraid.org/dynamic/update.php?XXX

exit 0
Da notare di questo script:
  • se internet non è raggiungibile questo script non esce;
  • se si riavvia il modem, cambia l'indirizzo IP assegnato dall'ISP e andrebbe rilanciato questo script.
Il passo successivo è attivare il port forwarding sul router, in modo da indicare che le richieste che arrivano al modem dall'esterno su determinate porte vanno rigirate sul server casalingo.

Configurazione in systemd


Adottato ormai in quasi tutte le distribuzioni, va configurato in modo che lanci all'avvio lo script di update DNS inserito sopra:
  • bisogna creare il file /etc/systemd/dynamicDns.service con il seguente contenuto:
[Unit]
Description=Aggiorna il server DNS
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
ExecStart=/home/osmc/updateDns.sh

[Install]
WantedBy=multi-user.target

Dove il file indicato nel campo ExecStart contiene lo script di cui sopra.

venerdì 3 giugno 2016

Telecomando WII per Kodi su Xbian (e forse anche per altre distribuzioni)


Per far funzionare il telecomando wii con Kodi ho dovuto effettuare i seguenti passaggi:
  1. Recuperare un dongle bluetooth
  2. Installare lo stack bluetooth di linux bluez con il comando apt-get install bluez
  3. Lanciare il comando hcitool scan e premere contemporaneamente i tasti 1 e 2 del telecomando wii: i led del telecomando lampeggieranno per una ventina di secondi in attesa del comando di accoppiamento
  4. Se il comando precedente non va a buon fine lanciare il comando hciconfig hci0 reset e riprovare con il comando al punto precedente
  5. Installare i driver wiimote con il comando apt-get install python-cwiid xbmc-eventclients-common
  6. Recuperare lo script xbmc-wiimote dalla pagina https://github.com/paulvt/xbmc-wiimote, renderlo eseguibile con il comando chmod -x e metterlo in una cartella del PATH (io l'ho messo in /usr/bin)
  7. Lanciare lo script del punto precedente con il parametro -b , dove è il valore trovato con il comando del punto 3, nel formato di 6 numeri separati da ':'
  8. In kodi il telecomando sarà riconosciuto e funzionante!
  9. Per rendere le modifiche effettive ad ogni riavvio, copiare il comando al punto 7 nel file /etc/rc.local
  10. al successivo riavvio, premere insieme i tasti 1 e 2 del telecomando wii per riattivarne il controllo

Il lettore CD non si apre


Ho una configurazione hardware per la quale non si apre lo sportello del lettore CD, ne con il tastino, ne da windows con il comando espelli, ne da linux con il comando eject.

Per windows ho risolto installando un applicativo di terze parti di cui non ricordo il nome (quando riavvierò il PC in windows lo inserirò qua dentro).

Per linux ho visto risolto usando il parametro -p, per cui il comando
eject -p
ha fatto al caso mio.

Il comando man indica la seguente informazione:
  -p   This  option  allow  you to use /proc/mounts instead /etc/mtab. It
            also passes the -n option to umount(1).
Resta da capire perchè così funziona e normalmente no...