Archivi tag: cubieboard

Esp8266 ed http, che fatica!

Operazioni di restauro della stazione meteo, allagata e poi ripristinata con un nuovo circuito stampato, qualche sensore nuovo, connettori stagni e fori di sfogo dell’umido. Una persona ragionevole pensa “il più è fatto” e “basta rimettere il software vecchio e tutto funzionerà come prima”. Nemmeno per sogno. Il software vecchio funziona, ma non carica i dati sul server.

Il caricamento dei dati sul server avviene attraverso un banalissimo script PHP che viene invocato da un GET HTTP, con tutta una serie di parametri, una cosa di questo tipo:
http://192.168.x.y/meteo/add.php?temperatura=19.48&umidita=77.29&pressione=995.74&dewpoint=15.40&direzione=234.45&velocita=7.22&pioggia=0&sensore=tetto

Sul server la cosa funziona così:
192.168.x.r – – [20/May/2018:19:38:36 +0200] “GET /meteo/add.php?temperatura=22.68&umidita=52.19&pressione=99696.80&dewpoint=12.38&direzione=234.45&velocita=1.03&pioggia=0&sensore=tetto HTTP/1.1” 400 0 “-” “-“

Tutto finisce con un “400, bad request”. Se la chiamata viene inviata da un browser (copia ed incolla della STESSA stringa), tutto funziona:
192.168.x.k – – [20/May/2018:19:38:43 +0200] “GET /meteo/add.php?temperatura=23.22&umidita=50.15&pressione=99699.11&dewpoint=12.27&direzione=165.76&velocita=6.91&pioggia=0&sensore=tetto HTTP/1.1” 200 453 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Safari/537.36”

Ho cercato informazioni in rete ed ho visto che il protocollo HTTP, con il metodo GET, richiede che siano passati una serie di parametri al server:
GET
Host
User-Agent
Connection

Ottime informazioni si trovano su questo link. In pratica RFC che descrive il protocollo. Una prima versione del mio firmware inviava una stringa senza “user-agent”. Aggiunto questo parametro l’errore è rimasto. Il debug del problema lo ho effettuato con tcpdump sotto linux, impostando l’opzione “-vvv”, che analizza completamente il protocollo. Analizzando bene il traffico, ho notato che il campo host era valorizzato in modo errato. Come si evince dal RFC, la mancata valorizzazione del campo comporta un “bad request” da parte del serve. Ho modificato il codice impostando il campo “host” a “localhost” e tutto ha iniziato a funzionare. Vabbè, ho perso 3 giorni di tempo, sono stato due ore sul tetto ma ho imparato un sacco di cose! Di seguito l’analisi del protocollo fatta con tcpdump.

GET /meteo/add.php?temperatura=19.54&umidita=72.92&pressione=99537.58&dewpoint=14.55&direzione=94.69&velocita=0.00&pioggia=0&sensore=tetto HTTP/1.1
Host: localhost
User-Agent: wget/1.12
Connection: close

Questo invece il codice in ESP8266:

void http_client(){
Serial.println(“HTTP CLIENT: ———————————————————————–“);
Serial.print(“Host: “);
Serial.println(host);
Serial.print(“Port: “);
Serial.println(httpPort);
if (!WFclient.connect(host, httpPort)) {
Serial.println(“connection failed”);
++wrong;
error_flag=1;
return;
}
String agent = “wget/1.12”;
String hosth = “localhost”;
delay(100);
String url = “/meteo/add.php?”;
url += “temperatura=”;
url += temp;
url += “&umidita=”;
url += humi;
url += “&pressione=”;
url += pres;
url += “&dewpoint=”;
url += dewp;
url += “&direzione=”;
url += wdirection;
url += “&velocita=”;
url += wspeed;
url += “&pioggia=”;
url += pioggias;
url += “&sensore=”;
url += sensore;

Serial.print(“Requesting URL: “);
Serial.println(url);

WFclient.print(String(“GET “) + url + ” HTTP/1.1\r\n” + “Host: ” + hosth + “\r\n” + “User-Agent: ” + agent + “\r\n” + “Connection: close\r\n\r\n”);

unsigned long timeout = millis();
while (WFclient.available() == 0) {
if (millis() – timeout > 10000) {
Serial.println(“>>> Client Timeout !”);
WFclient.stop();
return;
}
}

E per adesso… funziona.

[DISPLAY_ULTIMATE_SOCIAL_ICONS]

Maledetto ossido!

Situazione: sensore di temperatura collegato alla cubieboard attraverso un breve cavo e due connettori a passo 2.54mm. Tutto funziona regolarmente. All’improvviso ieri sera, noto che i dati del sensore meteo non si aggiornano più.

Faccio una scansione del bus I2C e, meraviglia delle meraviglie, non trovo nulla. Bizzarro, non ci sono stati sbalzi di tensione, fulmini, black-out. Sono giorni che non salgo di sopra a fare un giro.

Ipotizzo che sia un problema di ossidazione, dato dalla mostruosa combinazione di umidità e temperatura che regna sovrana in quel luogo. Per dare credito alla mia ipotesi non tocco nulla, mi reco al solito negozio di materiale elettronico (Electronic Fittings) e compero uno spray disossidante della DUE-CI: il R-11 contact cleaner.

Lo spruzzo direttamente nella femmina del connettore al quale è collegato il sensore e invio un timido comando “i2cdetect -y 1”. Meraviglia delle meraviglie, tutto torna a funzionare. Dalla prossima volta si salda tutto!

 

L’angolo del ciambotto.

Se dovessimo giudicare la nostra civiltà da quello che si vede in rete, avremmo una visione un po’ distorta: pieno di fotografi ovunque, che si destreggiano impavidi negli spazi di colore più impensati. Sportivi ovunque che riprendono e pubblicano video in ogni dove. Soprattutto un tasso enorme di geni, visto che sui blog tutti i progetti funzionano, danno i risultati sperati, non si guastano mai.

Io invece faccio delle foto discutibili, posto anche i video di quando mi parte l’anteriore a motocross e voglio dedicare un post alla mia ultima cialtronata.

Devo monitorare lo stato di una finestra con la (infame) CubieBoard. Bene, prendo un sensore magnetico e lo collego al GPIO. Ottimo.

Fantastico vero? Un occhio meno “rincoglionito” del mio, noterà sicuramente che se il contatto sulla finestra è aperto, il piedino della GPIO è “floating”. E questo causa un comportamento molto bizzarro del sistema, del quale mi sono accorto in fase di test: apro la finestra, faccio girare il codice e vedo dei “rimbalzi” sullo stato di una variabile. Monitoro il GPIO e questo cambia allegramente stato per i fatti suoi. Controllo lo schema, mi percuoto e faccio ammenda.

Ho corretto lo schema. Adesso il GPIO è collegato ad un pull-up con un 10k e la finestra è collegata verso la massa: finestra chiusa piedino a livello logico basso, finestra aperta piedino a livello logico alto grazie al pull-up.

Ogni tanto l’angolo del ciambotto deve essere rispolverato!

CubieBoard: Monitoraggio presenza tensione

Nella nuova dimora accade, ogni tanto, che la fornitura di energia elettrica risulti un po’ ballerina. Ci sono stati dei casi di black-out molto prolungato che hanno messo a dura prova i miei UPS, portando le battarie all’esaurimento e creando qualche attimo di panico con il NAS.

Per questo ho deciso di implementare un sistema di monitoraggio della tensione di rete, che fosse in grado di:

  • rilevare l’assenza della tensione di rete;
  • comunicare via mail l’evento;
  • inviare mail periodiche in caso di perdurare del balck-out;
  • spegnere in modo graceful NAS.

La cosa è stata più facile sulla carta che non da vero, come sempre. In effetti ho dovuto lottare con le I/O della Cubieboard (come ho descritto in questo articollo).

CubieBoard. GPIO e che fatica!

Il rilevatore di tensione lo ho realizzato implementando uno schema che ho trovato in rete. Si tratta di utilizzare un piccolo trasformatore di tensione 220V -> 5V e di connetterlo ad un GPIO della Cubieboard attraverso un regolatore di tensione a 3.3V. Il trasformatore sarà collegato ad una presa di energia elettrica non servita da UPS. Al momento del black-out, la tensione in uscita dal trasformatore passa a 0 e lo stato logico del piedino di I/O della Cubieboard è 0. Lo schema è semplice ed efficace, solo che occorre mettere in conto che il trasformatore, consuma (pochissimo ma….).

IMG_20160417_105230

A questo punto ho quindi un sistema hardware che è in grado di creare un evento su un PIN della Cubieboard in caso di Black-Out. Il software è stato scritto in “bash” (strano vero?) . Lo script viene eseguito ogni minuto dal crontab e verifica lo stato del piedino di monitor. In caso sia a livello logico alto non succede nulla, in caso sia a livello 0 inizia una complessa routine per la gestione degli alert e degli eventi. Il funzionamento dello script si basa su alcuni files che vengono creati in /tmp/ e che contengono flag o timestamp per tenere traccia di quello che sta succedendo. Forse non è il modo migliore di programmare, ma questo è ciò che riesco a fare.

Una volta approntato il software è necessario configurare alcuni aspetti del sistema operativo, per fare in modo che le mail vengano inviate utilizzando Gmail. Per questo mi sono avvalso di una guida reperibile a QUESTO indirizzo.

Visto che avevo le mani  sulla tastiera, mi sono anche divertito a configurare l’applicazione Telegram sulla piattaforma Cubieboard. In effetti lo step due dello sviluppo del sistema sarà quello di abilitare anche il controllo bidirezionale del sistema via Telegram (per adesso è solo una idea, il tempo per lo sviluppo del codice e delle idee è sempre pochissimo).

Per quanto riguarda la programmazione in bash, il web è pieno di tutorial base o avanzati, basta sapere cercare un po’ su Google.

Per lo spegnimento del QNAP l’unica strada percorribile è quella di effettuare login sul sistema utilizzando SSH e dare il comando “halt”. Il comando poweroff non è altrettanto efficace e rischia di lasciare alcune parti del sistema attive. Per effettuare il login con il protocollo ssh sul NAS occorre utilizzare i certificati, in modo che non siano richieste le credenziali di autenticazione. Una guida alla configurazione si trova QUI.

Il codice è scaricabile dalla sezione DOWNLOAD del sito, nella sezione “Software”.

 

CubieBoard. GPIO e che fatica!

Per realizzare un progettino di cui parlerò tra qualche tempo, mi sono imbattuto nella necessità di lavorare con il GPIO della Cubieboard2. Alcune considerazioni:

  • la documentazione è pessima, questo riguarda tutto il progetto. Quindi, nessuna nuova!
  • Le GPIO sono a passo 2mm davvero scomode.

La mia CB monta un sistema operativo Debian 8.3 MainLine, come descritto QUI. Pertanto

The Allwinner-specific script.bin isn’t needed anymore.

L’accesso alla GPIO si effettua direttametne da SYSFS, solo che occorre “pescare” il PIN giusto. Per fare questo innanzitutto si individua il PIN FISICO sul quale vogliamo operare: io ho scelto il pin 17 del connettore U15 (ponendo la scheda con la alimentazione in basso, è il connettore sulla destra). Il PIN17 si chiama CSI1-D6. Guardando su questo schematico (è per la CB con A10 ma non cambia molto a quanto pare), si scopre che questo PIN fa capo al segnale PG10 del System On Chip. Pertanto si può applicare la formuletta trovata qui, per capire come referenziare correttamente il PIN: G-> 7a lettera dell’alfabeto

(numero_lettera_alfabeto – 1) * 32+(numero_pin) —> (7-1)*32+10=202

Per abilitare il PIN occorre digitare:

/bin/echo 202 > /sys/class/gpio/export
/bin/echo in > /sys/class/gpio/gpio202/direction

In qeusto modo, con il comando cat si può ricavare il valore del PIN:

root@cubieboard:~# cat /sys/class/gpio/gpio202/value
1
root@cubieboard:~#

Semplice vero? No. Ho impiegato DUE ore a capire questa cosa.

Maledetti!

Network Monitoring

Casa nuova, nuova rete, vecchie manie. Come già avevo fatto tanti, tanti anni addietro, ho installato tutto il necessario per monitorare le prestazioni della mia rete domestica. Questa è composta da un NAS, un AP, una MikroTik ed un server, oltre al router che fornisce la connettività verso Internet.

Il server ho deciso di realizzarlo sfruttando una board che avevo comperato nel 2011 e mai utilizzato: la cubieboard 2. Si tratta di un embedded basato su ARM A20, molto interessante e dotato di una buona dotazione di porte, compresa una SATA. Il sistema operativo (Debian per ARM) risiede su una SD da 16GB. La cubieboard è il cuore della mia rete e funge da server MySQL e aggregatore dei dati SNMP. Sono molto soddisfatto del suo funzionamento.

Per visualizzare i dati e le prestazioni dei sistemi mi sono inizialmente avvalso di Cacti, un sistema che conosco abbastanza bene ed utilizzo con successo anche in ufficio. Parallelamente ho voluto anche sperimentare LibreNMS.

Cacti è un sistema consolidato, che ha dalla sua una discreta community di utenti e un forum di supporto. L’aggiornamento del software è molto lento e la roadmap che si erano proposti gli autori è ampiamente non rispettata. Nel mio caso, l’ultima versione rilasciata ha funzionato al primo colpo, consentendomi di tracciare con discreta facilità i grafici di cui ho bisogno. Il supporto per hardware “moderni” è decisamente scarso: i template non sono aggiornatissimi e bisognerebbe mettersi a scrivere il proprio, per coprire esigenze paricolari.

LibreNMS è un pacchetto software per il monitoraggio della rete molto accattivante. Si installa davvero facilmente, non richiede esoterismi particolari. Ha un interfaccia grafica molto gradevole e molto dinamica, lasciando il puntatore su un host, compaiono delle miniature dei grafici salienti.

nmt_01

nmt_02

Si possono configurare alerts, messaggi, e tutta una serie di features che rendono il prodotto particolarmente gradevole e abbastanza facile da usare. Il carico del POLLER sulla CPU del mio sistema si sente abbastanza, ma non ho mai avuto esperienza di rallentamenti o hang. Nella figura che segue, a sinistra il carico di sistema con LibreNMS+Cacti a destra solo con Cacti.

nmt_03

Attualmente ho configurato il sistema con Cacti, in quanto più leggero e maggiormente leggibile per me che lo uso da 3 o 4 anni. La scelta è tuttavia non definitiva, in quanto LibreNMS è ancora presente nel mio server, ho solo momentaneamente disabilitato il poller. Appena avrò tempo, voglio lavorere un po’ con gli alert per cercare qualche nuova feature.

Buon monitoraggi e ricordate di cambiare la default community SNMP quando installate un prodotto di rete!