Prima di tutto bisogna fare distinzione tra Kinect V1 e V2, l’immagine qui sotto aiuta ad identificarli.

Per la versione V1 di Kinect vanno installati i seguenti pacchetti:

• Kinect for Windows Runtime v1.8
• Kinect for Windows SDK v1.8

A questo punto, una volta connesso il Kinect al pc, ci si dovrebbe trovare nella finestra di Gestione Dispositivi con questa situazione

Per fare la prima scansione di prova ho usato Skanect 2.2, la versione scaricabile gratuitamente qui è limitata a 5000 poligoni massimi ma non penso che questo possa essere un grosso limite in fase di sperimentazione.

La prima prova al volo è stata fatta prendendo come modello un pupazzo di mia figlia, prova effettuata senza particolare attenzione alla distanza e all’illuminazione cose che invece per risultati usabili sono indispensabili.

Dall’anno scorso però hanno chiuso tutti i servizi free, inserendo come costo base 5$ mensili; un po’ troppi per chi non ha grosse necessità come il sottoscritto.

Dopo un po’ di ricerche varie sono approdato su DuckDNS.org, un sito che offre lo stesso servizio di DynDns ma in maniera gratuita, arrivando a dare fino a 6 domini di terzo livello gratis.
Lati positivi sono l’assoluta chiarezza e semplicità del servizio, quasi minimale ma presente di tutto ciò che può servire.

Sono disponibile applicazioni per tutti i sistemi operativi per effettuare l’update del DNS in maniera del tutto automatica e, soprattutto, nella seziona About del sito, alla domanda “perchè avete fatto questo servizio?” rispondono con un “because we can, because before we started we couldn’t, learning is fun”. Questo è lo spirito che mi piace.

Mosh è installabile su molti sistemi, su ubuntu è in repository e basta quindi un
sudo apt-get install mosh
per installarlo

Unico aspetto in cui SSH è migliore è il carico CPU, maggiore in Mosh, ma nei sistemi di oggi non dovrebbe essere un gran problema.

La procedura e’ abbastanza semplice.

Per prima cosa nel server d’origine, che chiamero’ server A, va interrotto il sistema di aggiornamento dei feed.
A seconda di come e’ configurato il sistema puo’ essere basato su cron o su un demone in php; che sia un sistema o l’altro vanno disattivati per non trovarseli in mezzo ai piedi mentre si lavora sul database.

Secondo passo e’ quello di fare una copia di backup della cartella di installazione di TTRss, nel mio caso ho fatto uno zip della cartella /var/www/html/ttrss

tar -zcvf TtrssInstallation20151122.tar.gz /var/www/html/ttrss/

Passo poi al fare il dump del database, dove sono veramente contenute tutte le informazioni sui nostri feed.
Ttrss usa di default postgres come database, si potra’ usare quindi l’interfaccia web phppgadmin o le utility da riga di comando, io ho scelto la seconda strada.
Da una sessione ssh sul server A come utente postgres procedo a fare il dump del database, nel mio caso si chiama ttrss_sql. Ho quindi:

pg_dump ttrss_sql > TTRssDatabaseDump20151122

Da interfaccia phppgadmin invece, dopo il login, si seleziona il database che ci interessa esportare e poi si seleziona Esporta, avendo l’accortezza di selezionare l’esportazione sia dei dati che della struttura. Un veloce esempio su come si usa phppg admin si puo’ trovare qui

Trasferisco poi il file del dump del database dal server A al server B, qui i modi sono molteplici, stfp, wget. Io avendo Dropbox configurato su entrambi i server l’ho sfruttato per questa cosa.

Passo a questo punto alla fase di restore sul server , sul quale abbiamo bisogno di avere funzionanti PHP e un database tra postgres, consigliato perche’ piu’ veloce, o mysql.

Primo passo e’ quello di importare il database nel nostro nuovo server. Ovviamente un dump di postgres e’ compatibile solo con postgres come uno di mysql e’ compatibile solo con se stesso.
Per prima cosa creo l’utente che verra’ utilizzato da TTRss per accedere al database. Nel mio caso, gran fantasia, l’utente e’ ttrss.
Faccio partire l’utility psql che mi permette di agire direttamente sulla mia installazione di postgres e creo l’utente

CREATE USER ttrss WITH PASSWORD 'lamiapassword';

Da ricordarsi i singoli apici prima e dopo la password e il punto e virgola finale.
Creo poi il database ttrss_sql di cui poi concedero’ tutti i diritti, cioe’ il pieno utilizzo, al mio utente ttrss.
In questo modo, in caso di compromissione di TTRss, un eventuale malintenzionato avrebbe accesso al solo database di TTRss. Regola base e’ usare un utente per ogni database/applicazione in modo da minimizzare l’eventuale impatto di una compromissione del sistema.

CREATE DATABASE ttrss_sql;
GRANT ALL PRIVILEGES ON DATABASE ttrss_sql to ttrss;

A questo punto posso uscire da psql con

\q

e passare allo step successivo: l’importazione del dump del database. Molto semplicemente, semre da ssh con utente postgres, si fa con

psql ttrss_sql < TTRssDatabaseDump20151122

A questo punto il database e’ pronto, si passa ad usare git per copiare i file di ttrss in locale. Ovviamente serve git installato (su debian con un apt-get install git)
Mi sposto nella mia cartella html

cd /var/www/html

e faccio il clone del repository git di ttrss

git clone https://tt-rss.org/git/tt-rss.git ttrss

In questo modo ora ci sara’ la cartella /var/www/html/ttrss contenente i file aggiornati di TTRss.

Ora bastera’ un browser e far partire l’installazione di TTRss andando all’indirizzo http:\\IP_MIO_SERVER\ttrss\install

Verra’ chiesto username, password e nome del database che vorremo usare, ovviamente bisogna ricordarsi durante la procedura guidata d’installazione di non reinizializzare il database ma di mantenere il contenuto presente, pena altrimenti perdere i dati del dump appena importato.

Per la configurazione di TTRss rimando alla documentazione ufficiale che e’ presente qui

Installazione https://tt-rss.org/gitlab/fox/tt-rss/wikis/InstallationNotes

Configurazione feed update https://tt-rss.org/gitlab/fox/tt-rss/wikis/UpdatingFeeds

Visto che uso il sistema domotico RFTide UDOiT che come gateway usa una Raspberry perchè non sfruttare la cosa anche per monitorare la qualità della connessione? Detto fatto!

Login via SSH come root e si prepara la cosa, primo passaggio installare speetest-cli, un utilty scritta in Python che permette di usare da riga di comando il famoso servizio di monitoraggio della connessione Speetest. Lo script funziona con Python versione 2.4 o superiore.

pip install speedtest-cli


Creiamo poi una cartella per il file di log che andremo a creare. Io ho scelto /var/log/speedtest

mkdir /var/log/speedtest

Aggiungiamo poi una entry in cron per far eseguire il test quando vogliamo, nel mio caso il sistema lo eseguirà ogni ora.

crontab -e

E aggiungiamo

00 * * * * date >> /var/log/speedtest/speedtest.log; /usr/local/bin/speedtest-cli --simple >> /var/log/speedtest/speedtest.log

Ci ritroveremo così in automatico i risultati dei test nel file /var/log/speedtest/speedtest.log.
Attenzione solo che lo script non ha controllo sulla dimensioni del file log e alla lunga potrebbe generare un file di grosse dimensioni. Solitamente però il monitoring della connessione è una necessità temporanea, basterà ricordarsi di disabilitare la entry in cron quando non ne avremo più bisogno.
In alternativa logrotate sarà il vostro amico, tenendo a bada la crescita del file in modo automatico.

EDIT: diamo un’occhiata al log dopo una nottata di test

less /varlog/speedtest/speedtest.log

e nel mio caso mi ritrovo

 Ping: 91.658 ms
 Download: 5.80 Mbit/s
 Upload: 0.36 Mbit/s
 Sat Nov 14 18:40:01 CET 2015
 Ping: 637.724 ms
 Download: 5.45 Mbit/s
 Upload: 0.23 Mbit/s
 Sat Nov 14 19:40:01 CET 2015
 Ping: 206.48 ms
 Download: 5.87 Mbit/s
 Upload: 0.28 Mbit/s
 Sat Nov 14 20:40:01 CET 2015
 Ping: 251.091 ms
 Download: 6.07 Mbit/s
 Upload: 0.33 Mbit/s
 Sat Nov 14 21:40:01 CET 2015
 Ping: 96.834 ms
 Download: 6.23 Mbit/s
 Upload: 0.26 Mbit/s
 Sat Nov 14 22:40:01 CET 2015
 Ping: 155.289 ms
 Download: 5.74 Mbit/s
 Upload: 0.30 Mbit/s
 Sat Nov 14 23:40:01 CET 2015
 Ping: 168.945 ms
 Download: 5.16 Mbit/s
 Upload: 0.26 Mbit/s

Velocità decenti per essere una 7 Mega ma ping… lasciamo perdere…

Ho la necessità di accendere e spegnere in maneira temporizzata le luci esterne della mia abitazione, luci comandate dai relè wireless UDOiT. Il primo tentativo è stato quello di inserire il controllo delle luci direttamente in cron, mettendo ora di accensione e spegnimento fisse.

Tutto bene tranne ovviamente il fatto che l’orario di alba e tramonto mutano durante l’anno, ritrovandomi che alla sera le luci si accendevono troppo tardi rispetto al tramonto.

Dopo aver provato varie soluzioni ho trovato quella che sembra fare per me: sunwait

Sunwait è un programma scritto in C che, date le coordinate di un punto, può calcolare vari dati interessanti, tra cui gli orari di crepuscolo. Potremmo usare quindi sunwait come trigger per il controllo delle luci esterne.
Qui qualche appunto sull’installazione e sulla configurazione di questo programma sul sistema domotico UDOiT.

Ovviamente si parte facendo login sul sitema Raspberry come root e poi si passa al download e scompattamento del programma sunwait nella cartella /home/RF

cd /home/RF
wget http://www.risacher.org/sunwait/sunwait-20041208.tar.gz
tar -xzf sunwait-20041208.tar.gz
cd sunwait-20041208

Passiamo poi al compilare il programma e a copiarlo nella cartella appropriata

make
cp sunwait /usr/local/bin/

Ora il programma sunwait è pronto per essere utilizzato. Ma cosa fa in poche parole sunwait?
Sunwait, usando come parametri le coordinate e l’evento che si vuole calcolare, nel nostro case alba e tramonto, crea un processo che aspetterà in background il momento esatto dell’evento per poter eseguire un’azione.

Nel nostro caso inserirò due chiamate a sunwait in cron, una per l’alba e una per il tramonto, che allo scattare dell’evento controlleranno le luci esterne.
Le chiamate a sunwait per mia comodità le inserirò ogni giorno alle ore 14.

Per prima cosa occorre trovare le coordinate della propria posizione, per questo basta sfruttare Google Maps. Si cerca la località interessata, si clicca sulla mappa e maps ci darà latitudine e longitudine in formato WGS84 come servono a noi.
Ad esempio prendiamo il Duomo di Milano, si vede come nell’immagine qui sotto, nella parte in basso siano presenti le coordinate 45.464093 e 9.192871, corrispondenti a latitudine e longitudine di Piazza del Duomo

Ora è il momento dell’ultimo passaggio, inserire le chiamate a sunwait in cron. Chiamo l’editor per cron

crontab -e

e inserisco in fondo queste righe. Attenzione alle andate a capo, sono sole due righe.
00 14 * * * /usr/local/bin/sunwait civ down 45.464093N 9.192871E; python /home/RF/Script/ExternalLightsControl.py ON
01 14 * * * /usr/local/bin/sunwait civ up 45.464093N 9.192871E; python /home/RF/Script/ExternalLightsControl.py OFF

Due parole di commento a queste entry. Queste richiamano alle 14:00 e 14:01 sunwait, usando rispettivamente come evento di trigger il crepuscolo civile e alba civile, usando come punto di calcolo le coordinate del Duomo di Milano trovate prima e passandogli come azione da eseguire uno script da me scritto per il controllo delle luci.
Di questo script scriverò presto due righe a riguardo e lo metterò disponibile per il download.
Al momento giusto il processo di sunwait verrà eseguito e sarà il trigger per l’accensione, o lo spegnimeno, delle mie luci. Questo sì che è fare domotica

All’annuncio della chiusura su blog e social network si rincorrevano discussioni tra utenti sul dove migrare: chi su Feedly, e questa sembrerebbe la scelta presa da molti, chi su Netvibes o chi fa la fila per entrare nella beta a numero chiuso di The Old Reader.

Personalmente questa vicenda mi ha ricordato che tutti i servizi gratuiti di cui si usufruisce sul web, in caso non riescano a generare un business profittevole, sono sempre a rischio chiusura. Quindi ho deciso che torneró come anni fa ad appoggiarmi su un server personale.
Ad ora il setup che andró a creare parte dalla prerogativa di avere connettivitá adeguata, ho scartato quindi di utilizzare l’adsl casalinga come connessione, e di costare poco. Ancora meglio se quel poco fosse zero

Quindi la lista della spesa sará

• Amazon AWS Free Tier che permette di sfruttare con certi vincoli il cloud computing di Amazon in maniera gratuita. Vengono offerti 15 GB di traffico mensile, due IP pubblici statici, 10 GB di storage, 1 CPU virtuale e 512 MB di ram. Il tutto con 750 ore di funzionamento mensili, piú che adeguate per un server singolo h24
• Ubuntu 12.04 Server piú per curiositá che altro dopo esperienze passate tutte a marchio Debian voglio dare un’occasione alla versione server della distribuzione Linux piú famosa
• Tiny Tiny RSS o, per gli amici, TTrss. Ë́ uno dei reader web-based piú utilizzati e dopo la diaspora da Goole Reader ha avuto un nuovo impulso allo sviluppo. Ha tutto quello che mi serve: leggero e minimale, permette di salvare gli articoli che piú mi interessando su Pocket, ha la capacitá di condividere gli articoli verso i social network piú conosciuti e, soprattutto, ha un’applicazione Android che si sincronizza in maniera perfetta con l’applicativo php che gira sul server. Di piú non ho da chiedere.

É probabile che nei prossimi giorni trascriva qui gli appunti dell’installazione e configurazione di questo server.

Disinstallare completamente e poi reinstallare il programma gnome-raw-thumbnailer. Da utente root o anteponendo sudo

apt-get purge gnome-raw-thumbnailer && apt-get install gnome-raw-thumbnailer

Creare il file di configurazione per le thumbnail delle immagini in formato RAW. Questo file si chiama raw.thumbnailer e va creato nella directory /usr/share/thumbnailers/
Ad esempio usando il programma gedit potremmo, sempre da utente root o usando sudo, usare il seguente comando

gedit  /usr/share/thumbnailers/raw.thumbnailer

Il contenuto del file sarà il seguente

[Thumbnailer Entry]
Exec=/usr/bin/gnome-raw-thumbnailer -s %s %u %o
MimeType=image/x-3fr;image/x-adobe-dng;image/x-arw;image/x-bay;image/x-canon-cr2;image/x-canon-crw;image/x-cap;image/x-cr2;image/x-crw;image/x-dcr;image/x-dcraw;image/x-dcs;image/x-dng;image/x-drf;image/x-eip;image/x-erf;image/x-fff;image/x-fuji-raf;image/x-iiq;image/x-k25;image/x-kdc;image/x-mef;image/x-minolta-mrw;image/x-mos;image/x-mrw;image/x-nef;image/x-nikon-nef;image/x-nrw;image/x-olympus-orf;image/x-orf;image/x-panasonic-raw;image/x-pef;image/x-pentax-pef;image/x-ptx;image/x-pxn;image/x-r3d;image/x-raf;image/x-raw;image/x-rw2;image/x-rwl;image/x-rwz;image/x-sigma-x3f;image/x-sony-arw;image/x-sony-sr2;image/x-sony-srf;image/x-sr2;image/x-srf;image/x-x3f;

Chiudere gedit salvando il file. E questo è tutto.

Se sei interessato lascia un commento qui sotto con una mail valida e ti ricontatterò subito.

EDIT: Vendute

Avendo la necessità di gestire ancora più a fondo l’hardware del mio eeePc 901Go per aumentare ulteriormente l’autonomia ho modificato il codice aggiungendo la possibilità di accendere/spegnere la webcam, il modem 3G UMTS integrato e il lettore di schede SD.

Il pacchetto é stato testato solo sul mio netbook con Ubuntu 10.10, non escludo che possano esserci dei problemi su altre combinazioni di distribuzione e hardware. E’ possibile scaricarlo da qui e si installa usando

sudo dpkg -i jupiter_0.0.42.1_all.deb

Dopo l’installazione il sistema deve essere riavviato prima di poter utilizzare Jupiter.