Gør det selv-IOT: Sådan bygger du en dims der kan tænde/slukke for andre dimser over internettet – Del 4/4: Softwaren og test af det endelige ’produkt’

VIGTIGT: LÆS DETTE, før du beslutter dig for at bygge noget i denne retning. Denne enhed forbindes direkte til 230V, hvilket er livsfarligt at rode med! Jeg joker ikke – Det gør i bedste fald p*sseondt at få stød, og i værste fald DØR du af det. Du kan starte en brand og det kan man også DØ af! Du bør ikke rode med netspænding uden et minimum af viden&erfaring.

I de forløbne tre klummer har vi specificeret hvad vi vil have at enheden skal kunne gøre. Vi har foretaget nogle valg, og vi har forberedt vores raspberry pi til at virke i den kontekst som vores produkt skal. Senest har vi loddet noget hardware sammen. Vigtigst af alt: Jeg har overlevet. Ingen stød og software-frustrationerne har ikke været af en så alvorlig karakter at det har kunnet få mig til at hoppe ud af vinduet. Success!

Denne fjerde og sidste del af serien vil handle om selve den software vi skal skrive for at implementere vores API og for at kunne manipulere med GPIO pindene.

Jeg afslutter artiklen med en lille demo.

Først skal vi lige have afklaret cliff-hangeren fra sidste del, og se det færdige produkt. Her er dimsen i al sin gloværdighed:

Ikke det mest sexede design, men som ingeniør er jeg fokuseret på funktion frem for design, og det væsentligste funktionelle krav, at minimere risikoen for at jeg dør af elektrisk stød, er opfyldt.

Men hvad er dog det for to underlige huller i frontpladen? Det er et klassisk eksempel på konsekvensen af at man ikke tænker sig om. Jeg skulle montere Raspberry pi’en i kassen og sad og prøvede alle mulige kombinationer. Det var på den forkerte side af kl. 23.00 en hverdagsaften, og jeg havde sat mig et mål om at kassen skulle være færdigmonteret før jeg gik i seng. Jeg fandt den optimale placering, tænkte ’Yes!’, greb boremaskinen og borede to huller til skruerne. Så vendte jeg boksen om… og sprang direkte til sidste del af punkt 5 i hardware opskriften fra sidste afsnit:

 

Nå heldigvis er skaden ikke så stor, da jeg alligevel har tænkt mig at sætte en lille rekvalme på fronten af boksen som kommer til at dække over det.

Apple, go home!

Nu skal der kodes! Først laver jeg et lille script som skal styre status-LED’en. Som I måske husker så fandt jeg en RGB LED i skuffen, og kan dermed lave masser af farver. Det giver mulighed for at signalere en masse forskellige ting (system ok, men wifi ikke forbundet, forkert wpa key, intern temperatur for høj, etc.), men jeg vælger at være lidt primitiv og blot implementere rød (= fejl/ikke forbundet til internettet) og grøn (=hvad tror du selv?). Mere fancy funktionalitet må skydes til version2.

Scriptet skriver jeg i python (Den komplette kildekode finder du her: http://www.nørdoteket.dk/index.php/2016/02/06/gds-iot-kildekode-til/)

Virkemåden er, at jeg bestemmer netværkets default gateway, som er routerens IP adresse. I et uendeligt loop pinger jeg den IP adresse, og hvis der er svar sætter jeg LED til grøn, og hvis der ikke er svar sætter jeg LED til rød.

Koden er ganske simpel og python er dejlig nemt at bruge. I python bruger jeg RPi.GPIO biblioteket til at kontrollere GPIO pins. LED’en er forbundet til GPIO#9, 10 og 11 (Grøn, Blå, Rød). GPIO skal initialiseres som enten input eller output pins:

GPIO.setmode(GPIO.BCM) # Use Broadcom pin numbers
GPIO.setup(9, GPIO.OUT) # Green LED, set as output

Og man tænder for en pin ved at sætte den til HIGH:

GPIO.output(9, GPIO.HIGH) # LED on
GPIO.output(9, GPIO.LOW) # LED off

Det primære loop, hvor jeg pinger ser således ud:

while True: # infinite loop
    response = os.system("ping -c 1 " + hostname) # send one ICMP packet to host
    if response == 0: # Reply
        # Network is reachable, LED=Green
        GPIO.output(11, GPIO.LOW)
        GPIO.output(9, GPIO.HIGH)
    else: # No reply
        # Network is NOT reachable, LED=Red
        GPIO.output(11, GPIO.HIGH)
        GPIO.output(9, GPIO.LOW)

Dette program skal køre automatisk ved boot, og derfor skal det tilføjes rc.local:

rpi_admin@skarpline-iot:~ $ sudo nano /etc/rc.local

Tilføj ” /home/rpi_admin/status.py > /dev/null” til filen (husk at tilpasse home dir navn til din bruger, eller hvor du nu måtte lægge status.py filen), så det endelige resultat ser således ud:

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

/home/rpi_admin/status.py > /dev/null

# Print the IP address
_IP=$(hostname -I) || true
if [ "$_IP" ]; then
  printf "My IP address is %s\n" "$_IP"
fi

exit 0
 

Med denne metode vil lampen lyse grønt så længe routeren svarer, selv hvis der ikke er forbindelse til internettet. Hvis man udskifter default gateway med noget ude på internettet, f.eks. Google’s DNS server 8.8.8.8, er testen mere retvisende. Det undlader jeg personligt at gøre, da det ikke er god stil at lave noget der kontinuerligt står og generer trafik mod andre menneskers servere.

Nu til selve koden der implementerer API’et. Den komplette kildekode finder du her: http://www.nørdoteket.dk/index.php/2016/02/06/gds-iot-kildekode/.

Det foregår som en webservice, og derfor er det første vi skal gøre, at validere brugeren. Det gøres med HTTP Digest (RFC-2617), og derfor starter vi med at afvise alle requests til vores server, der ikke har authentication information med i headeren. Vi afviser med en ”http 401 / unauthorized”-header, og tilføjer en unik værdi, kaldet et ”nonce” (Løst oversat: en engangs-term).

Kigger vi i TCP pakkerne (med wireshark – hvis du ikke har prøvet det endnu, så er det på høje tide. Fantastisk og helt uundværligt værktøj!) ser det således ud:

Rød tekst er request fra klient. Blå tekst er svaret fra GDS-IOT dimsen.
Og i koden ser det således ud:

if (empty($_SERVER['PHP_AUTH_DIGEST'])) {
  header('HTTP/1.1 401 Unauthorized');
    header('WWW-Authenticate: Digest realm="'.$realm.
     '",qop="auth",nonce="'.uniqid().'",opaque="'.md5($realm).'"');
 
  die('UNAUTHORIZED');
  }

$_SERVER er php’s reserverede variabel der indeholder al den information som er med i det request der er modtaget (http://php.net/manual/en/reserved.variables.server.php).

Nonce genereres med php’s uniqid( ) funktion, der genererer en unik streng, baseret på tidspunktet for requestet (hvis man sender det samme hver gang er man sårbar for playback-angreb).

Hvis vi nu sørger for at sende en request header med korrekt authorization information, kan vi se at vi får det ønskede svar (og en http 200 / ok-header).

Der er en del information i det svar, som vi lige skal gennemgå. Først skal vi sikre, at klienten har sendt alle de nødvendige data. Det gøres ved at parse PHP_AUTH_DIGEST variablen.

// analyze the PHP_AUTH_DIGEST variable
if (!($data = http_digest_parse($_SERVER['PHP_AUTH_DIGEST'])) ||
    !isset($users[$data['username']]))
      die('WRONG_CREDENTIALS');

Dernæst beregnes det response som vi forventer at få, hvis ellers afsenderen har brugt korrekt brugernavn og password. Det foregår i HTTP Digest ved at tage et MD5 hash af informationerne (som beskrevet i RFC-2617, §3.2.2).

// generate the valid response
$A1 = md5($data['username'] . ':' . $realm . ':' . $users[$data['username']]);
$A2 = md5($_SERVER['REQUEST_METHOD'].':'.$data['uri']);
$valid_response = md5($A1.':'.$data['nonce'].':'.$data['nc'].':'.$data['cnonce'].':'.$data['qop'].':'.$A2);

Og sluttelig tjekker vi om det modtagne response svarer det det vi selv har beregnet.

 
if ($data['response'] != $valid_response)
  die('WRONG_CREDENTIALS');
 

Nu er brugeren valideret, og vi skal se hvad der bliver bedt om i requestet. Når man skal levere information i et ”http/get” gøres det i URL’en med ”parameter=værdi” par. I PHP læses parametrene med $_GET[’parameter’]:

 $action = $_GET['action']; $port = $_GET['device']; 

Device skal mappes til den korrekte GPIO port, og vi skal sikre, at der ikke spørges efter et ugyldigt device. Det gøres med en switch statement:

switch ($port)
{
case 1:
    $portreal="27"; // Device#1 maps to GPIO#27
    break;
case 2:
    $portreal="17"; // Device#2 maps to GPIO#17
    break;
default:
    die('INVALID_DEVICE');
    break;
}

Endelig, efter så megen skriveri, lodderi og koderi, er vi nået til kernen i det hele: Bliver vi bedt om at tænde eller slukke for et strømudtag. Det tjekker vi også med en switch statement:

switch($action)
{
case ’ON’: // Vi vil tænde
  ..tænd for device
case ’OFF’: // Vi vil slukke
  ..sluk for device
case ’STATUS’:
  ..returner om der er tændt eller slukket
}

Selve interaktionen med GPIO pins foretager vi med WiringPi som blev installeret i del2 (link til del2). WiringPi er et lib til shell kommandoer, hvilket vil side, at vi fra PHP skal lave et systemkald. Det kan gøres med shell_exec kommandoen (hvor $portreal= 17 eller 27):

    $gpio_on = shell_exec("/usr/local/bin/gpio -g write " . $portreal . " 1"); // Turn on the desired GPIO
    $gpio_stat = shell_exec("/usr/local/bin/gpio -g read " . $portreal); // Read status of port

Hermed er projektet nået til sin ende. Egentlig imponerende hvor meget jeg kan skrive om så lidt, og stadig have fornemmelsen af kun lige have ridset overfladen!

Men vi skal da lige have demonstreret dimsen – ellers tror I bare ikke på at den virker. Det er lidt svært at gøre på skrift, så jeg har bikset en lille video sammen til jer.

Med reference til det første afsnit (link til del 1) så er det elektriske apparat som skal testes selvfølgelig den obligatoriske kaffemaskine. Problemet er blot, at min kaffemaskine er en fancy sag, som kræver tryk på en knap for at brygge en kop kaffe.

Hvordan klarer jeg nu det problem? Et helt nyt projekt begynder at forme sig i mit hovede: Et legotårn, en servo, en afhugget finger. Argh, stop! Jeg bliver aldrig færdig med at skrive, og Computerworld løber tør for anslag, så nu holder jeg mund.

Sig goddag til Steens kælderlab, se en demo af GDS-IOT dimsen og ikke mindst, se hvordan jeg løste problemet med at trykke på kaffemaskinens knap her.

Håber I har nydt at læse serien. Jeg har lavet og laver mange af denne slags småprojekter, men det er første gang jeg har prøvet at beskrive det i detaljer på denne måde. Er der interesse for lignende beskrivelser i fremtiden, så skriv det gerne i kommentarfeltet nedenunder.

Al kildekode finder I som sagt her: http://www.nørdoteket.dk/index.php/2016/02/06/gds-iot-kildekode/ og den står til fri afbenyttelse i henhold til revision 42 af Beer-ware licensen (en af mange geniale ting fra phk’s hånd).

Hvis jeg havde mere tid
Hvis nu man ville lege videre med udgangspunkt i denne dims:
Hardware:
– Flere udtag
o Det kommer an på dit behov. Det er særdeles nemt at udvide med flere, det koster blot en stikkontakt og et relæ samt driver kredsløb per stk.
– Måling af effektforbrug per udtag
o Det kunne være sjovt at lege med. Kræver en strømsensor per udtag. Output fra strømsensorer er typisk analoge, så en ADC (analog til digital konverter) skal bruges per strømudtag. Eller man kunne overveje at skifte Raspberry Pi ud med en anden platform der allerede har ADC kanaler.
– Mulighed for at lysdæmpe en lampe tilsluttet et udtag
o Måske ikke så relevant ved en strømskinne?
– Skrumpning af design, så det kan skohornes ind i en strømskinne.
– Læg print ud og lav det hele fra bunden, bedre, billigere og mindre.
– Andre forslag?
Software:
– Skriv en app til kontrol. Det er jo så moderne.
– Timerfunktion
o Udvid API, så man kan sige ”tænd device X, og sluk det automatisk om Y minutter”
– ’Feriemode’
o Lav funktion som tænder og slukker for de forskellige udtag på tilfældige tidspunkter
– WPS, så det er nemt at installere
– UPnP, så det er nemt at installere
– Andre forslag?