Azure-Insider

Soup to Nuts: Von Hardware bis zum Cloud-fähigen Gerät

Bruno Terkaly
Steven Edouard

Wir befinden uns mitten in einem neuen Goldrausch. Dieses Mal geht es jedoch nicht um die begehrten Nuggets, sondern um den Markt für innovative Consumergeräte in der Cloud. Letzten März schon stellte der neue Microsoft CEO Satya Nadella fest, dass diese Geräte ohne die Cloud vollkommen nutzlos seien.

Diese Aussage macht Sinn. Was nützt es, wenn das Gerät über Sensoren und Kameras, aber nicht über die nötige Kapazität zur Analyse der Daten verfügt? Viele Einsteigergeräte wie Raspberry Pi bieten einfach nicht die nötige Rechenleistung und Speicherkapazität. An dieser Stelle kommt die Cloud ins Spiel, die zudem für Sicherheit, Geräteverwaltung und vieles mehr sorgt. Diesen Monat krempeln wir die Ärmel hoch und wollen herausfinden, wie wir dem Paradigmenwechsel im IT-Bereich im Hinblick auf Hardware und Software begegnen.

SmartDoor ist eine Lösung für das "Internet der Dinge", die wir von Grund auf eigenhändig umsetzen. Dazu schrauben wir einfach eine Türklingel, eine Kamera und einen Raspberry Pi-Minicomputer zusammen (siehe Abbildung 1). Stellen Sie sich einfach vor, jemand steht vor Ihrer Tür und drückt auf die Klingel. Durch das Betätigen der Klingel wird automatisch ein Foto aufgenommen, das dann als Pushbenachrichtigung an ein mobiles Gerät gesendet wird (siehe Abbildung 2). Die Nachricht ist mit dem Foto der Person verlinkt, die an Ihrer Tür klingelt. Das Neue daran: Sie wissen, wer vor Ihrer Tür steht, auch wenn Sie nicht Zuhause sind.

Abbildung 1 – Ein Gerät aus Türklingel, Kamera und Raspberry Pi-Minicomputer

Abbildung 2 – Eingang der Pushbenachrichtigung auf dem Windows Phone

Zunächst erklären wir Ihnen genau, wie wir die Hardware beschaffen und zusammenbauen. Sobald wir damit fertig sind, entwickeln wir zwei Arten von Software, eine für das Gerät und eine andere für Microsoft Azure. Der Schwerpunkt in diesem und zukünftigen Artikeln wird jedoch auf der erforderlichen Software liegen.

Unser Code muss in der Lage sein, das Drücken auf den Auslöser zu steuern und das Foto in Azure hochzuladen. Von der Cloud aus senden wir eine Pushbenachrichtigung an die entsprechenden mobilen Geräte. So erfährt der Empfänger, dass jemand an seiner Tür geklingelt hat, und kann die Person auf dem Foto betrachten. Aufgrund der Komplexität dieses Projekt verweisen wir an vielen Stellen auf weiterführende Blogbeiträge, die die Arbeit dokumentieren und die erforderlichen Details liefern.

Einfach wie Pi

Wir stellen Ihnen die Codelösungen vor, die auf dem Raspberry Pi-Computer selbst und in der Cloud – speziell in Azure Mobile Services – ausgeführt werden. Auf dem Raspberry Pi-Computer installieren und führen wir die kostenlose Open-Source-Anwendung Xamarin Mono aus. Diese stellt ein Microsoft .NET Framework-kompatibles Toolset inklusive C#-Compiler und CLR bereit. 

Der Vorteil von Mono besteht darin, dass Sie .NET-kompilierten Code unter Windows programmieren und ohne Anpassungen auf dem Raspberry Pi ausführen können. Im konkreten Beispiel nehmen wir damit ein Foto auf und laden es in den Azure Storage hoch. In zukünftigen Artikeln werden wir die Codebasis erweitern, um das Senden von Pushbenachrichtigungen an ein Windows Phone zu unterstützen. Dazu müssen wir die entsprechende Funktion in Azure Service Bus nutzen und eine Windows Store- oder Windows Phone-App schreiben.

Die Hardware ist schnell beschafft, da fast alle Komponenten in einem Raspberry Pi-Kit mit dem Namen Canakit enthalten sind. Weitere Informationen finden Sie auf "canakit.com". Das Kit enthält einige nützliche Dinge für die Montage unseres IoT-Geräts, z. B. eine Systemplatine, einen Netzadapter, eine GPIO (General Purpose Input/Output)-Schnittstelle, eine Steckplatine mit Kabelset, Widerstände und LEDs. Außerdem benötigen Sie einen externen Monitor sowie Tastatur und Maus, um den Raspberry Pi zu konfigurieren und zu testen. Zusätzlich zum Canakit benötigen wir noch eine handelsübliche Türklingel und eine Raspberry Pi-kompatible Kamera, was beides einfach zu beschaffen ist.

Auch wenn das Hardwaregebilde in Abbildung 3 auf den ersten Blick abschreckend wirkt, ist es dennoch einfach zusammenzubauen. Die SmartDoor-Lösung ist genauso einfach zusammengesetzt wie ein Puzzle. Als Erstes schließen Sie das Kameramodul an den Port der Raspberry Pi-Platine an. Nehmen Sie die Kamera dazu aus der Verpackung, und schließen Sie das Flachbandkabel an die Raspberry Pi-Platine an. Weitere Informationen zum Senden von Fotos an die Cloud finden Sie unter bit.ly/1rk3vzk.

Abbildung 3 – Raspberry Pi-Canakit (Kamera nicht im Lieferumfang enthalten)

Zur Installation der Türklingel auf dem Raspberry Pi sind einige Lötarbeiten nötig, die wir in einem zukünftigen Artikel ausführlich beschreiben werden. Fürs erste schließen wir eine Steckplatine an, die als Versuchsaufbau für die elektronischen Verbindungen im Raspberry Pi dient. Zur Simulation der Türklingel verwenden wir Überbrückungskabel und die Steckplatine.

Eine der wichtigsten Komponenten ist die GPIO-Steckbrücke. Mit der 26-poligen GPIO-Leiste (nummeriert von links nach rechts) können Sie das System erweitern, um mit anderen Geräten zu interagieren. Normalerweise lassen sich darüber Sensoren, Aktuatoren, LEDs und andere Geräte anschließen. Dennoch unterscheiden wir drei Arten von Pins. Es gibt zwei Pins, die Spannung für die angeschlossenen Geräte bereitstellen (3,3 und 5 Volt) und einen Pin (0 Volt) für die Masse, der die Schaltung definiert. Die mit GPIO beschrifteten Pins sind einfache Ein-/Aus-Schalter. Für eine serielle Kommunikation verwenden Sie die TX- und RX-Pins (RS-232) zum Senden und Empfangen von Daten. Die Gerätesoftware muss in der Lage sein, diese Pins anzusteuern.

Eine der Schwierigkeiten bei der Kommunikation ist die Zuordnung der physischen und logischen Anschlüsse, über die die Software kommuniziert. Das hängt mit den Broadcom-Chips auf dem Raspberry Pi-Computer zusammen. Wenn ein Signal an "GPIO 0" gesendet wird, muss die Software tatsächlich GPIO 17 auslesen. Das kann verwirrend sein und erfordert besondere Sorgfalt.

Andere Hardwarekomponenten spielen ebenfalls eine wichtige Rolle. Widerstände steuern den Stromfluss und senken die Spannung ab, damit der Raspberry Pi oder angeschlossene Geräte nicht durchschmoren. Außerdem benötigen Sie einen einadrigen Draht, um die GPIO-Einheit mit dem Raspberry PI zu verbinden.

Tests, Tests

Nun müssen wir überprüfen, ob wir die Hardware ordnungsgemäß zusammengebaut haben. Das stellen wir am einfachsten fest, indem wir einen externen Monitor, eine Tastatur, eine optionale Maus und ein Netzteil an den Raspherry Pi anschließen. Stecken Sie dann den Netzstecker in die Steckdose, und achten Sie darauf, ob die Linux-Bootsequenz angezeigt wird. Als Benutzername wird standardmäßig "pi" und als Kennwort "raspberry" verwendet. Weitere Informationen zum Einrichten eines Raspberry Pi finden Sie unter bit.ly/1k8xBFn.

Zur Ausführung von C#-Code benötigt der Raspberry Pi zusätzliche Software wie Mono. Bevor wir das Gerät verwenden können, müssen wir Updates für das Betriebssystem Raspbian installieren. Das Betriebssystem auf dem Pi ist bereits vorinstalliert. Wir müssen nur noch einige Befehle in einem Konsolenfenster eingeben, um das Betriebssystem auf die neueste Version zu aktualisieren. Im nächsten Schritt installieren wir die Mono-Laufzeit von Xamarin sowie einige vertrauenswürdige Stammzertifikate. Jetzt kann unser Gerät HTTP-Anforderungen senden. Alle diese Schritte werden im Blogbeitrag bit.ly/Unehrr ausführlich erläutert.

Die Softwareseite

Die Codierung erfolgt auf zwei Ebenen: der Clientebene (Raspberry Pi-Computer) und der Dienstebene (Azure Storage und Azure Mobile Services). Eine Vielzahl von Programmiersprachen und Back-End-Diensten stehen dafür zur Auswahl. Wir verwenden C# für den Client und Node.js/JavaScript für den Server. Dem mögen nicht alle zustimmen, weil allgemein angenommen wird, dass zwei verschiedene Sprachen die Implementierung komplizierter machen.

Unsere Lösung soll jedoch Vielfalt demonstrieren. Bei Node.js profitieren wir von der großen Anzahl von Bibliotheken und Paketen auf "npmjs.org", die den Servercode erheblich vereinfachen können. Aufgrund der umfangreichen Bibliotheken erzielen Anwender mit Node.js in vielen Fällen eine deutlich kleinere Codebasis. Weniger Code in einer zweite Sprache ist zweifellos besser als viel Code in derselben Sprache. Das Diagramm in Abbildung 4 zeigt den erwarteten Workflow, der drei Schritte umfasst:

1. Der Client fordert ein SAS (Shared Access Signature)-Token an, das im URL-Format bereitgestellt wird.
2. Die unter Azure Mobile Services ausgeführte Anwendung Node.js gibt eine SAS-URL zurück.
3. Der Client verwendet die SAS-URL, um das Foto als BLOB in Azure Storage hochzuladen.

Abbildung 4 – Architekturübersicht des SmartDoor-Projekts

Unsere Node.js-Anwendung wird in Azure Mobile Services gehostet und profitiert so von der integrierten Unterstützung für mobile Clients – Pushbenachrichtigungen, integrierter CRUD-Speicher, Identitätserkennung und eine benutzerdefinierte API.

Der Dienst im Fokus

Zunächst beginnen wir mit dem Dienst, weil er die Basis für den Client bildet, wenn noch keine Dienstebene vorhanden ist. Solange kein voll funktionsfähiger Back-End-Service implementiert ist, gibt es keine Möglichkeit, den Client auszuführen und zu testen. Unsere Dienst-API wird in Azure Mobile Services gehostet.

Die maßgeschneiderte API basiert auf Node.js und dem Express Web Framework. Unser Client (Raspberry Pi) nutzt diese Dienste, um ein SAS-Token anzufordern. Das Token wird anschließend vom Dienst verwendet, um das Foto in Azure Storage hochzuladen. Die SAS-URL gewährleistet den Schutz unseres Azure Storage-Kontos, da die Kontoanmeldeinformationen nicht auf dem Raspberry Pi gespeichert werden müssen. 

Weitere Sicherheitsaspekte haben wir in einem unserer früheren Artikel erörtert (msdn.microsoft.com/magazine/dn574801). SAS-Tokens haben aber noch einen anderen Vorteil. Sie entlasten die mittlere Ebene (Node.js-API), da für die Dateiübertragung vom Client an den Speicher kein Broker benötigt wird.

Bereitstellung von Mobile und Storage

Einige Klicks im Azure-Portal genügen, um Azure Mobile Services bereitzustellen. Das Gleiche gilt für die Bereitstellung von Azure Storage. Wie bei jeder Bereitstellung müssen Sie sich auch hier Gedanken über die URLs und die Namenskonventionen machen, die Sie für Ihre cloudbasierten Dienste verwenden möchten. Überlegen Sie sich auch, welches der weltweiten Rechenzentren Sie nutzen möchten. Wenn sich das Storage-Konto im selben Rechenzentrum befindet wie Azure Mobile Services, verkürzen Sie Latenzzeiten und vermeiden Übertragungskosten. Eine ausführliche Beschreibung der Schritte zur Bereitstellung von Azure Mobile Services und Azure Storage-Konto finden Sie unter bit.ly/WyQird.

SAS (Shared Access Signature)

Wie in Abbildung 4 dargestellt, fordert der Raspberry Pi-Client ein SAS-Token von Azure Mobile Services an. Dazu sendet er von einer API, die in Azure Mobile Services definiert wird, eine GET-Anforderung. SAS-Tokens entlasten die mittlere Ebene (Node.js-API), da für die Dateiübertragung vom Client an den Speicher kein Broker benötigt wird.

Der Code in Abbildung 5 ist ein Auszug aus dem Node.js-Code, der in Azure Mobile Services als API-Dienstendpunkt ausgeführt wird. Der Zweck besteht darin, SAS-Tokenanforderungen von Raspberry Pi-Clients zu verarbeiten. Der Raspberry Pi sendet eine GET-Anforderung an den in Azure Mobile Services gehosteten Endpunkt. Dabei übergibt er den Anwendungsschlüssel, der ein eindeutiger Bezeichner unseres mobilen Diensts ist.

Abbildung 5 – Node.js-Code für die Microsoft Azure Mobile Services-API

exports.get = function(request, response) {
  // These are part of "App Settings" in the configuration section
  // of your service. Shouldn't be hardcoded into this Node.js script.
  containerName = request.service.config.appSettings.PhotoContainerName;
    accountName = request.service.config.appSettings.AccountName;
    accountKey = request.service.config.appSettings.AccountKey;
  // Connect to the Blob service.
  blobService = azure.createBlobService(
    accountName,accountKey,accountName + '.blob.core.windows.net');
  createContainer();
  createPolicies();
  var sasResponse = GetSAS();
  return request.respond(201, sasResponse);
}

Der Anwendungsschlüssel ist ein sicherer Weg, um mit dem gewünschten Azure Mobile Service zu kommunizieren. Der Dienst fordert diesen Schlüssel vom Portal an, das von der Gerätesoftware auf dem Raspberry Pi genutzt wird. Halten Sie den Schlüssel bereit, um ihn in den Clientcode einzufügen. Der Client empfängt eine in einer URL gekapselte SAS, die er später zum Hochladen eines Fotos verwenden kann.

Jetzt konzentrieren wir uns auf einen anderen Codebereich: die Node.js-Anwendung auf der Serverseite. Unter bit.ly/Unnikj finden Sie ein leistungsstarkes Node.js SDK speziell für Azure. Die Codebasis bietet umfangreiche Unterstützung für andere Bereiche der Azure-Plattform wie das Arbeiten mit Tabellen, Warteschlangen, Themen, Benachrichtigungshubs, zentrale Verwaltung und vieles mehr. Ein Lernprogramm zur Integration von Node.js und Azure BLOB-Speicher finden Sie unter bit.ly/1nBEvBa.

In unserem Beispiel ist die SAS, die von der Node.js-Anwendung an den Client zurückgegeben wird, an das zuvor bereitgestellte Speicherkonto gebunden. Folglich benötigt die Node.js-Anwendung den Kontonamen und den Verwaltungsschlüssel des Speicherkontos.

Mit Azure Mobile Services lassen sich Konfigurationseinstellungen aus der Node.js-Anwendung externalisieren. Allgemein gilt es als schlechter Programmierstil, Kontoschlüsseleinstellungen fest im Code zu codieren. In den App-Einstellungen können Sie Schlüssel-Wert-Paare festlegen, die von der Dienstlaufzeit ausgelesen werden. Weitere Informationen erhalten Sie unter bit.ly/1pwGFRN.

Schließlich gibt der Node.js-Code eine URL mit der SAS zurück, die der Client zum Hochladen von Fotos verwendet. Zusammen mit dem SAS-Token gibt die Node.js-App den HTTP-Status 201 aus. Dadurch bestätigt sie, dass die Anforderung erfüllt und eine neue Ressource (das SAS-Token) erstellt wurde.

Eine ausführliche exemplarische Vorgehensweise zu Node.js, SAS-URL und den App-Einstellungen finden Sie unter bit.ly/WyQird.

Einblicke in den Raspberry Pi-Code

Die Implementierung der Hardware-/Softwareschnittstelle ist im Grunde sehr einfach. Man kann sich den clientseitigen Code als einen riesigen Zustandsautomaten vorstellen, der in einer Endlosschleife den Status der GPIO-Pins abfragt. Wie aus dem Code in Abbildung 6 ersichtlich, geht es darum, ob ein Pin ON/OFF oder TRUE/FALSE ist.

Abbildung 6 – Raspberry Pi GPIO-Schnittstelle: Zustandsabfrage in einer Endlosschleife

while (true)
{
  // If pin 17 is off, we are ready.
  if (!s_Gpio.InputPin(FileGPIO.FileGPIO.enumPIN.gpio17))
  {
    showReady(true);
    // If pin 22 is true, indicate to the user that the system is busy,
    // take a photograph and then upload to the cloud.
    if (s_Gpio.InputPin(FileGPIO.FileGPIO.enumPIN.gpio22))
    {
      showReady(false);
      TakeAndSendPicture();
    }
  }
  else
  {
    // Not ready to take a photo yet.
    showReady(false);
    break;
  }
  // Pause for one-tenth of a second.
  System.Threading.Thread.Sleep(100);
}

Es gibt zwei Möglichkeiten, den Pinstatus zu überprüfen. Im ersten Fall werden die GPIO-Pins über das Dateisystem angesteuert, worauf auch unser Ansatz basiert. Indem wir Dateien mit bestimmten Werten suchen und auslesen, erfahren wir, ob der Status ON oder OFF ist. Eine zweite und zugleich leistungsfähigere Alternative besteht darin, bestimmte Speicheradressen abzufragen. Obwohl langsamer, gilt die Nutzung des Dateisystems und des integrierten Linux-Treibers als der sicherere Weg.

Wenden wir uns nun dem C#-Code zu, der auf dem Raspberry Pi-Computer auf der Anwendung Mono aufsetzt. Der Raspberry Pi führt vier grundlegende Schritte aus: Als erstes reagiert er auf das Betätigen der Klingel; zweitens macht er ein Foto vom Besucher und speichert es im lokalen Speicher; drittens fordert er ein SAS-Token an, das zum Hochladen des Fotos verwendet wird; viertens lädt er das Foto als BLOB in den Azure Storage. Obwohl der Code in C# programmiert wird, basiert er vollständig auf REST. Diese vier Schritte können also von jeder HTTP-fähigen Programmiersprache und -umgebung ausgeführt werden.

Durch die Kommunikation mit der GPIO-Schnittstelle können wir den Raspberry Pi ansteuern. Es gibt also nur vier Ereignisse, für die unsere Anwendung GPIO 2 als Eingang und GPIO 1 als Ausgang nutzt. Anhand eines C#-Codes demonstrieren wir die Kommunikation mit diesen Pins. Schauen Sie sich dazu die C#-Hauptschleife für den Raspberry Pi in Abbildung 6 an. Die Pins 17 und 22 signalisieren die Bereitschaft des Systems, als Reaktion auf das Betätigen der Klingel ein Foto aufzunehmen und hochzuladen.

In einer Endlosschleife wird kontinuierlich die Spannung der Pins abgefragt. Auf diese Weise steuert die Software bestimmte Aktionen, z. B. die Fotoaufnahme durch die Kamera. Die Abfragerate der Schleife liegt bei etwa 10 Hz. Weitere Informationen zu Vergleichstests finden Sie unter bit.ly/1trFzt9.

Jede Sprache hat ihr eigenes Tempo. Beispielsweise ist Python als relativ langsame Sprache für leistungsintensive Szenarien nicht geeignet. In unserem Beispiel reichen 10 Hz völlig aus, um zu überprüfen, ob die Spannung an Pin 22 durch Betätigen der Klingel auf Plus geht.

Jeder dieser drei Pins erfüllt eine andere Funktion. Der erste Eingang, also Pin 17, muss auf Masse gelegt sein (was von C# als FALSE interpretiert wird). Wenn dieser Schritt nicht erfolgt, wird das Programm beendet. An Pin 22 muss eine Spannung angelegt werden (was als TRUE interpretiert wird). Wenn die Abfrage von Pin 22 TRUE ergibt, wird die Fotoaufnahme durch "TakeAndSend­Picture" gestartet. Die showReady-Methode verwendet den Ausgabepin 4, um per LED zu signalisieren, dass das Programm bereit zum Aufnehmen und Hochladen eines Fotos ist.

Da die Lösung konditionale Kompilierungssymbole verwendet, wird der entsprechende Code auf dem Betriebssystem Raspbian anstatt unter dem normalen Windows-/Desktop-Betriebssystem ausgeführt. Die Abweichungen im Code resultieren daraus, dass die Aufnahme eines Fotos unter Raspbian kein API-Aufruf ist. Der Code führt in einem internen Prozess eine Programmdatei aus. Unter Windows 8 verwenden Sie dagegen die CaptureFileAsync-API von "CameraCaptureUI".

Zum Aufnehmen des Fotos rufen wir das integrierte Programm "raspistill" auf, wie in Abbildung 7 dargestellt. Dieses Programm ist für die Aufnahme und das Speichern eines Fotos im JPEG-Format konfiguriert. Dateiname, Fotoqualität und Bildgröße können von Ihnen festgelegt werden. Raspistill wird als untergeordneter Prozess gestartet. Während das Foto aufgenommen wird, fordert der Code eine SAS-URL vom Azure Mobile Service an. Anschließend wird das Foto in den Azure BLOB-Speicher hochgeladen.

Abbildung 7 – Aufnehmen und Hochladen eines Fotos in die Cloud

static void TakeAndSendPicture()
{
#if LINUX
  // Start photo-taking process. This will kick off the raspistill process.
  // We'll wait for it to exit after we get the photo URL.
  Process raspistill = new Process();
  raspistill.StartInfo = new ProcessStartInfo("/usr/bin/raspistill",
    "-n -q " + photoQuality +
    " -o /home/pi/Desktop/me.jpg -h 200 -w 200 -t 500")
    {
      UseShellExecute = false
    };
    raspistill.Start();
#endif
  // Get Photo URL while the picture is being taken.
  WebRequest photoRequest = WebRequest.Create(
    "https://raspberrypiservice.azure-mobile.net/api/getuploadblobsas?");
  photoRequest.Method = "GET";
  photoRequest.Headers.Add("X-ZUMO-APPLICATION", 
    "AIzNtpTdQLjORKJJhTrQWWRSHSnXcN78");
  PhotoResponse photoResp = null;
  using (var sbPhotoResponseStream = 
    photoRequest.GetResponse().GetResponseStream())
  {
    StreamReader sr = new StreamReader(sbPhotoResponseStream);
    string data = sr.ReadToEnd();
    photoResp = JsonConvert.DeserializeObject<PhotoResponse>(data);
  }
  Console.WriteLine("Pushing photo to SAS Url: " + photoResp.sasUrl);
  WebRequest putPhotoRequest = WebRequest.Create(photoResp.sasUrl);
  putPhotoRequest.Method = "PUT";
  putPhotoRequest.Headers.Add("x-ms-blob-type", "BlockBlob");
#if LINUX
  // Wait until the photo is taken.
  raspistill.WaitForExit();
  FileStream fs = new FileStream(@"/home/pi/Desktop/me.jpg", 
    FileMode.Open);
#else
  FileStream fs = new FileStream(@"testPhoto.jpg", FileMode.Open);
#endif
  using (fs)
  using (var reqStream = putPhotoRequest.GetRequestStream())
  {
    Console.WriteLine("Writing photo to blob...");
    fs.CopyTo(reqStream);
  }
  using (putPhotoRequest.GetResponse())
  {
  }
}

Die Visual Studio-Lösung kann sowohl auf einem Raspberry Pi als auch auf einem Windows-Betriebssystem ausgeführt werden. Sie verwendet konditionale Kompilierungssymbole, sodass der entsprechende Code auf dem Betriebssystem Raspbian anstatt auf dem normalen Windows-/Desktop-Betriebssystem ausgeführt wird. Die Abweichungen im Code resultieren daraus, dass die Aufnahme eines Fotos unter Raspbian plattformspezifisch ist. Aus Gründen der Einfachheit wird bei der Kompilierung für Windows 8 kein Foto aufgenommen. Stattdessen laden wir ein vorhandenes Foto ("testPhoto.jpg") in die Cloud hoch.

Die gute Nachricht ist, dass sehr viele Codeelemente zwischen Windows und Raspbian austauschbar sind – von der Anforderung des SAS-Tokens bis hin zum Hochladen des Fotos. Wenn der Code also unter Windows funktioniert, wird er auch unter Raspbian problemlos laufen. Dadurch lässt sich der Entwicklungs- und Testaufwand für clientbasierten Code erheblich verringern. Der Raspberry Pi ist ein eingeschränktes Gerät, weshalb die Arbeitsschritte auf dem Gerät selbst auf ein Minimum reduziert werden sollten.

Nachdem ein Foto aufgenommen wurde, sollte es an zwei Orten sichtbar sein: einmal auf dem Gerät selbst unter dem in der Befehlszeile festgelegten Pfad "in /home/pi/Desktop/me.jpg" und natürlich im entsprechenden Container des Azure-Speicherkontos.

Zusammenfassung

Dieses Projekt ist eine gute Ausgangsbasis, um eine eigene Lösung für das "Internet der Dinge" zu entwickeln. Von der Beschaffung und Montage der Hardware über die Programmierung und Installation der Software bis hin zu Tests haben wir versucht, alle Punkte zu berücksichtigen. Zudem enthält dieser Artikel zahlreiche Links zu weiterführenden Blogartikeln – noch aber ist die Lösung nicht perfekt.

Im nächsten Beitrag beschäftigen wir uns mit Pushbenachrichtigungen. Sie erfahren, wie diese an mobile Geräte gesendet werden, damit die Person, die an der Tür klingelt, auf einem Foto betrachtet werden kann. Außerdem stellen wir den in Azure Service Bus integrierten Benachrichtigungsdienst vor und erstellen eine Windows Phone-App, die Pushbenachrichtigungen von Azure empfangen kann. Den Abschluss bilden weitere Speicherlösungen, wie eine MongoDB NoSQL-Datenbank, und eine Back-End-Lösung zur Gesichtserkennung. Bleiben Sie dran am "Internet der Dinge" mit Azure.

---

Bruno Terkaly arbeitet als Entwicklungsexperte für Microsoft. Seine fundierten Kenntnisse sind das Ergebnis langjähriger Programmierungserfahrung mit einer Vielzahl von Plattformen, Sprachen, Frameworks, SDKs, Bibliotheken und APIs. Er schreibt Code, Blogs und referiert live über die Entwicklung cloudbasierter Anwendungen, insbesondere mit der Microsoft Azure-Plattform. Lesen Sie seinen Blog unter blogs.msdn.com/b/brunoterkaly.

Steven Edouard arbeitet als Entwicklungsexperte für Microsoft. Zuvor war er als Softwaretestingenieur für das .NET Runtime-Team tätig und hat Produkte wie .NET Framework 4.5 und .NET Native Compilation mit auf den Weg gebracht. Nun möchte er die Menschen durch mitreißende technische Demonstrationen, Onlineinhalte und Präsentationen für das grenzenlose Potenzial der Cloud Computing-Dienste begeistern.

Unser Dank gilt den folgenden technischen Experten bei Microsoft für die Durchsicht dieses Artikels: Gil Isaacs und Brent Stineman
Mit mehr als 20 Jahren in der IT-Branche hat Brent Stineman von Großrechnern bis zu mobilen Technologien alle Entwicklungen mitgemacht. Aktuell gilt seine ganze Leidenschaft dem Cloud Computing und der Azure-Plattform, um Enterprise-Architekten mit Expertenrat zur Seite zu stehen. Dafür setzt er sich mit der TED-Gruppe (Technical Evangelism and Development) und de DX-Team (Microsoft Developer Experience) ein. Folgen Sie Brent auf: twitter.com/brentCodeMonkey.

Gil Isaacs gehört dem DX-Team (Developer Experience) als Experte für die Microsoft Azure-Plattform an. Er sieht seine Aufgabe darin, Kunden zum schnelleren Erfolg mit cloudbasierten Architekturen zu verhelfen. Seine Erfahrung verdankt Gil seiner jahrelangen Tätigkeit als Programmierer und Experte für heterogene Kundenumgebungen. Aktuell konzentriert sich Gil auf die Integration von Open-Source-Technologien und Azure. Folgen Sie Gil auf twitter.com/gilisaacs.