Mobile Forum Stuttgart und die Cross-Plattform Entwicklung für mobile Geräte

Am vergangenen Freitag war ich auf dem ersten Mobile Forum in Stuttgart - und es war sehr interessant. In diesem Beitrag möchte ich kurz zusammenfassen, was mir besonders in Erinnerung geblieben ist.

Cross-Plattform Entwicklung

Nur wenige Vorträge haben sich mit nur einem bestimmten System auseinandergesetzt. Fast alle Vorträge hatten alle aktuell populären Systeme im Blick und stellten Möglichkeiten vor, wie man am besten damit umgeht. Dabei haben die Referenten die Nachteile nicht unter den Tisch fallen lassen, was ich sehr lobenswert finde.
Die folgenden Möglichkeiten möchte ich hervorheben.

jQuery Mobile

Die meisten, die im mobilen Bereich arbeiten, haben sicherlich schon von jQuery Mobile gehört. jQuery Mobile ist vor allem dann nützlich, wenn es sich um Daten getriebene Web-Applikationen handelt, die auch mobil bereit gestellt werden sollen. Durch Annotationen / HTML-Attribute können z.B. Listen oder Tabellen einfach durchsuchbar oder sortierbar gemacht werden (jQuery Mobile generiert die nötigen Elemente automatisch in den HTML Code) - und das Layout passt sich automatisch dem Gerät des Benutzers an (Responsive Webdesign).

Für bestimmte Designs oder zur Einhaltung der Corporate Identity steht der exzellente Theme Roller bereit. Nie war es einfacher, ein Design online mit ein paar Klicks für alle UI Komponenten flexibel zu gestalten. Definitiv ein großes Plus!

Titanium Mobile

Titanium Mobile hat einen anderen Ansatz. Anstatt auf eine mobile Website zu setzen, kann man mit Titanium Mobile Apps erstellen - für jede Plattform! Das hört sich erstmal wie PhoneGap / Apache Cordova an, ist es jedoch nicht. Während PhoneGap zwar Apps erstellen kann, ist die App tatsächlich eigentlich nichts anderes als ein Fullscreen-Browser, der HTML5 (mit Javascript auf native API-Funktionen) anzeigt.

Das Resultat von Titanium Mobile hingegen sind echte, native Apps. Man entwickelt in Titanium Mobile mit JavaScript Syntax und "deployed" dann die App mit Hilfe eines Cross-Compilers für die jeweilige Plattform. Kurz: Titanium Mobile übersetzt die Plattform-unabhängige Syntax in nativen Code.

Die Vorteile liegen auf der Hand: Man kann alle Funktionen einer App ausschöpfen, die App ist performant und man kann diese zeitgleich für iPhone, Android, BlackBerry, Windows Phone 8,... etc. anbieten. Der Haken? Wird eine neue Version einer Plattform (z.B. iOS 7) veröffentlicht, ist man auf ein Update des Titanium SDKs angewiesen.

Fazit

Das Mobile Forum Stuttgart bot viel Abwechslung und spannende Vorträge. Es wurden viele unterschiedliche Tools vorgestellt, so dass sicherlich für jeden etwas dabei war. Alle Tools haben Stärken und Schwächen und so sollte man bei der Entscheidungsfindung genau überlegen, was der Anwendungszweck der mobilen Applikation sein wird.

Wünscht der Kunde ein Spiel für iPhone und iPad, mag jQuery Mobile sicherlich eher der schlechteste Ansatz sein. Für eine Web-Applikation, die auch mobil schnellen Zugang zu wichtigen Daten bieten soll, mag jQuery Mobile hingegen eine einfache Lösung sein - insbesondere wenn sich die Entwickler bereits mit "gewöhnlicher" Web-Entwicklung (HTML+JS+CSS) auskennen.

Aufbau einer Intranetsuche leicht gemacht, dank Open Source

Jeder kennt vermutlich das folgende Szenario aus eigener Erfahrung: Vor längerer Zeit hat man an einem Projekt gearbeitet und sucht nun verzweifelt nach einem Dokument, in dem bspw. eine Schnittstelle fachlich spezifiziert wurde. Doch wo wurde das Dokument bloß von den Kollegen abgelegt?

Dieser Blogeintrag beschreibt die einfache Realisierung einer Suchanwendung im Intranet für Dokumente unterschiedlichster Dateiformate, die in einem SVN-Repository sowie auf zentralen Laufwerken abgelegt sind. Dies bedeutet also, dass die Suchanwendung Input aus verschiedenen Quellsystemen erhält.
Als Suchserver wird elasticsearch verwendet. Das Frontend für die Suche wurde mit Grails umgesetzt.

Indexieren der Dokumente

Zunächst ist es wichtig, die Dokumente zu indexieren und eine regelmäßige Aktualisierung des Indexes zu gewährleisten, um Änderungen an den Dokumenten in der Suche abbilden zu können.
Zur Indexierung der Laufwerke wird ManifoldCF in der Version 1.1.1 eingesetzt. ManifoldCF ist ein Open Source Projekt, dessen Ziel es ist, verschiedene Quellsysteme zur gemeinsamen Indices oder Repositories zu verbinden. ManifoldCF bietet einige Vorteile:

• Im Idealfall ist kein eigener Code nötig, um geänderte Dokumente aufzufinden und diese zu indexieren
• Unterstützung für eine Vielzahl von Quellsystemen, wie bspw. SharePoint oder zentrale Laufwerke
• Nicht auf elasticsearch als Suchserver beschränkt; es ist eine Vielzahl sogenannter OutputConnectoren vorhanden, z.B. auch für Solr
• Graphische Oberfläche wie in der nachfolgenden Grafik exemplarisch dargestellt zur leichteren Konfiguration der zu indexierenden Ordner, Planung der Ausführungszeitpunkte etc.)

ManifoldCF Oberfläche

Der in ManifoldCF bereits vorhandene Elasticsearch-Output-Connector wurde angepasst, da die vorhandene Implementierung für den Anwendungsfall nicht ausreichend geeignet war. Diese Anpassungen sind im Wesentlichen

• Statt des attachment-Plugin von Elasticsearch übernimmt der Connector selbst die Analyse der Dokumente (unter Verwendung von Tika). Dadurch ist eine wesentlich feinere Kontrolle der im Index gespeicherten Informationen möglich.
• Die Verbindung zum Elasticsearchserver wurde von einem HTTP-Client auf einen TransportClient geändert. Beim HTTP-Client treten einige Probleme mit Sonderzeichen, Zeilenumbrüchen etc. beim Senden der extrahierten Informationen an Elasticsearch auf.

Input aus den Quellsystemen

ManifoldCF ist derzeit nicht in der Lage SVN-Repositories direkt zu indexieren. Jedoch ist es möglich, Ordner im lokalen Dateisystem zu indexieren. Damit ist es möglich, das Repository auszuchecken und danach mit svn up regelmäßige Updates durchzuführen, um die ausgecheckten Dateien zu aktualisieren. Diese Dateien werden schließlich mit ManifoldCF indexiert.
Aus Performancegründen wurde diese Lösung jedoch verworfen. Wenn man svn up ausführt, so erhält man eine Liste mit allen hinzufügten, geänderten oder gelöschten Dateien sowie jeweils die Angabe, welcher Fall vorliegt.
Über eine separates kleines Javaprogramm die Ausgabe des svn-Updates eingelesen und nur die darin verzeichneten Dateien wird die entsprechende Aktion durchgeführt. Obwohl dieses Programm die Aktionen in mehreren Threads parallel ausführt, ist es nur etwa 150 Zeilen lang. Zur Analyse der Dokumente wird ein Teil des angepassten ManifoldCF-Codes, der oben beschrieben wurde, wiederverwendet.
Dieses Vorgehen erspart gegenüber ManifoldCF die Iteration über alle ausgecheckten Dateien, um neue, geänderte und gelöschte Dateien zu identifizieren. Da im Anwendungsfall die Anzahl der geänderten Dateien gegenüber der Gesamtzahl Dateien sehr klein ist, beschleunigt sich der Indexierungsprozess enorm. Der gesamte Vorgang wird über einen cronjob gesteuert. Wenn keine Änderungen vorliegen, ist die Dauer des Vorgangs im Wesentlichen identisch mit der Zeit, die svn up benötigt. Müssen dagegen alle oder fast alle Dokumente neu indexiert werden, so dauert der Vorgang etwa so lange wie mit oben beschriebenen ManifoldCF-basierten Ansatz.

Neben dem SVN-Repository wird als zweites Quellsystem das öffentliche Firmenlaufwerk indexiert. Hier existiert für ManifoldCF ein Standard-Konnektor, der lediglich über die ManifoldCF-Oberfläche konfiguriert werden muss.

Performance

ManifoldCF ist in der Lage, den Fileshare (ca. 70 000 Dateien) in etwa 15 Minuten nach Änderungen zu durchsuchen und diese zu indexieren. Wurden sehr viele Dokumente geändert oder hinzugefügt, so verlängert sich die Laufzeit.

Elasticsearch

Es wird Elasticsearch 0.20.5 verwendet. Zum Betrieb der Suche werden keine Plugins benötigt. Das elasticsearch-head-plugin ist jedoch hilfreich, um den Zustand des Indexes zu überprüfen.

Such-Oberfläche

Die Grailsanwendung verwendet eine geringfügig angepasste Variante von FacetView als Oberfläche. Um die für den Suchbegriff relevanten Textausschnitte anzeigen zu können, werden die Suchanfragen von Facetview nicht direkt an Elasticsearch gesendet, sondern zuvor von der Grailsanwendung weiter verarbeitet.
Die Anwendung besitzt keine Domainklassen und benötigt auch keine Datenbank. Da keine Domainklassen indexiert werden und der Elasticsearchserver eigenständig läuft, wurde auf die Verwendung des grails elasticsearch plugins verzichtet. Stattdessen werden erneut TransportClients verwendet. Um die Anzahl der erzeugten Clients zu reduzieren und sicherzustellen, dass sie korrekt geschlossen werden, werden die Clients in einem Pool verwaltet. Daneben wurde die Möglichkeit, die Dokumente direkt herunterzuladen, geschaffen. Die Anwendung läuft auf einem Tomcat-Server.

Oberfläche der Suchanwendung

Fazit

ManifoldCF eignet sich sehr gut zum Indexieren von Dokumenten aus unterschiedlichen Quellen, jedoch gibt es spezielle Anwendungsfälle, in denen es ineffizient ist, das gesamte Quellsystem zu durchlaufen, um geänderte Dokumente zu finden. In diesen Fällen kann die Performance von ManifoldCF nicht mit einer Anwendung mithalten, die die Eigenheiten dieses Quellsystems, in dem hier beschriebenen Fall SVN, ausnutzt. Es wäre auch möglich, diese Optimierungen in ManifoldCF zu integrieren, indem man einen eigenen, sogenannten RepositoryConnector für SVN schreibt, der Dokumente aus dem Quellsystem bereitstellt. Dazu besteht jedoch in diesem Anwendungsfall keine Notwendigkeit.
ManifoldCF ist, abgesehen von einigen Kleinigkeiten, leicht zu konfigurieren und die Geschwindigkeit beim Aktualisieren des Indexes ist sehr zufriedenstellend.
Über die Qualitäten von Grails, FacetView und Elasticsearch wurde im exensio-Blog bereits berichtet.

exensio packt an - oder unser vermutlich etwas ungewöhnliches Team Event

Lange überlegten wir, wie wir den nächsten Team Event anders gestalten könnten. Auf übliche Team-Building-Events - bei denen den ganzen Tag Spiele gespielt werden, um zu analysieren, wie man sich verändern muss, um besser in ein Team zu passen - hatten wir irgendwie keine Lust. Go-Kart fahren, Kletterwand oder Kochkurs fanden wir auch nicht passend. Es sollte etwas sein, woran wir als Team zusammenarbeiten und in einem halben Tag (bspw. Samstagvormittag) abschließen können.

Unser Kollege Xuetao erzählte schließlich eines Tages beim Mittagsessen, dass im Ettlinger Kindergarten Wiesenzwerge - den sein Sohnemann besucht - 5 Tischbänke einer Renovierung bedürften. Somit stand fest, dass wir diese Aufgabe übernehmen werden.

Letzten Samstagmorgen trafen wir uns schließlich; nicht alle Kollegen fanden Zeit, jedoch die Mehrheit. Im Kindergarten empfing man uns mit Butterbrezeln und Kaffee. Danach ging es los. Wir IT-ler mussten jetzt beweisen, dass wir auch mit Schwingschleifern und Pinseln umgehen können :-). Nachdem alle Tischbänke abgeschliffen waren, konnten wir mit dem Anstreichen beginnen. Alles in allem haben wir 5 Stunden für die 5 Bänke benötigt. Ich denke kein lausiger Wert für IT-ler :-).

Dann hoffen wir, dass es bald sonnig und warm wird und die Kinder viel Spaß mit ihren renovierten Tischbänken haben.

Hier folgen noch ein paar Fotos:

Technische Umsetzung von Business Intelligence Applikationen mit Open Source

Nach dem mein Kollege Peter Soth im ersten Teil dieser Blogserie die fachlichen Hintergründe sowie die generelle Motivation zur Verwendung von Open Source im Business Intelligence Umfeld beleuchtet hat, geht dieser Teil tiefer auf die technische Umsetzung ein.

Technische Basis

Wie bereits erwähnt wurde das Grails-Framework für die Implementierung der Business Intelligence Applikation verwendet. Da Grails eigentlich als Framework für Webapplikationen bekannt ist, werden hier zunächst Gründe aufgeführt, die zu dieser Auswahl geführt haben.

• Keine zusätzlichen Lizenzkosten für die Software
• Mitverwendung der bestehenden Server-Infrastruktur
• Die Umsetzung als Webapplikation ermöglicht eine einfache Integration in existierende Web-Applikationen (wie bspw. Portale) mit dem kundenspezifischen Look&Feel
• Verschiedene Ausgabeformate können einfach durch Plugins unterstützt bzw. selbst implementiert werden
• Die Programmiersprache Groovy ist die Basis von Grails. Groovy eignet sich auch hervorragend, zur Durchführung von Operationen auf Datenstrukturen, was beim Transformieren der zu importierenden Dateien benötigt wird. Des Weiteren können mit Groovy relativ einfach DSL’s realisiert werden.

Ein weiteres wichtiges Kriterium ist die Möglichkeit zur Unterstützung von Batch-Funktionalitäten für die Umsetzung des ETL-Prozesses. Hierfür wird das Batch-Launcher Plugin [1] eingesetzt. Das Plugin ermöglicht die Ausführung von Grails außerhalb eines Servlet-Containers, in dem die Anwendung als normale Java-Applikation über eine Main-Methode gestartet wird. Der Vorteil ist hierbei, dass der ETL-Prozess unabhängig von der Web-Applikation läuft und damit dort zu keinen Ressourcen-Engpässen führt.

Da es mehrere Batches in der Applikation gibt, die auch entsprechend überwacht werden müssen, wurde zusätzlich ein leichtgewichtiges Batchframework aufgesetzt. Kern dieses Frameworks ist eine Datenbanktabelle in der die Aktivitäten und der aktuelle Status protokolliert werden. Dadurch kann insbesondere verhindert werden, dass der gleiche Batch mehrfach angestoßen wird und es können Abhängigkeiten zwischen den einzelnen Batches geprüft werden.

Der ETL-Prozess im Detail

Wie in BI-Applikationen üblich werden auch in diesem Projekt die Daten über den ETL-Prozess [2] importiert und aufbereitet, so dass sie für Analysen in der Applikation vom Endanwender genutzt werden können.

Grundlage sind ca. 50 Dateien im CSV-Format, die monatlich von den verschiedenen Quellsystemen geliefert werden. Die CSV-Dateien enthalten Daten über mehrere Monate und sind auch vom Aufbau unterschiedlich. Diese Dateien liefern die Inhalte auf dem untersten Level, die in das Starschema importiert werden.

Aus fachlicher Sicht wurden drei Hauptbereiche für Analysen identifiziert, die jeweils über eine eigene Faktentabelle mit den zugehörigen Dimensionstabellen abgebildet werden. In den Dimensionstabellen finden sich unter anderem die zeitlichen Aspekte oder auch Wirkstoffe, da es sich um eine Applikation aus dem Pharmabereich handelt. Die drei Faktentabellen werden jeweils durch einen eigenen Batch mit Inhalten der verschiedenen CSV-Dateien gefüllt. Die Batches sind entsprechend parametrierbar, da die Anzahl der enthaltenen Monate sowie die Monate selbst variieren.

Da die Daten zwischen den verschiedenen Quellsystemen abgeglichen und auch gefiltert werden müssen, werden entsprechende Transformationen und Regeln benötigt. Ein hierfür nützliches Hilfsmittel sind Closures [4] in Groovy, um diese Verarbeitungsschritte relativ einfach umzusetzen. Nachfolgend ist eine sehr einfache Bedingung zur Filterung von CSV-Zeilen exemplarisch dargestellt.

def ignoreConditionGeneric = { name ->
  return name && name != 'Summe'
}

Um für die 50 zu importierenden Dateien nicht unnötig viel ähnlichen oder gar doppelten Code zu erzeugen wurde eine Art DSL [5] entworfen, die für jede Datei die entsprechenden Eigenschaften definiert. Über die DSL wird z.B. definiert welche Spalten sich wiederholen und sich nur durch den Monat unterscheiden oder ob es sich bei den einzelnen Spalten um Beträge oder Namen handelt. Ändert sich die Struktur einer Datei kann somit schnell durch Anpassung der Konfiguration darauf reagiert werden.

Nachdem die Daten auf der untersten Ebene vorhanden sind, läuft für jede Faktentabelle ein weiterer Batch zur Aggregation der Daten. Hier werden beispielsweise auf der zeitlichen Dimension Daten quartalsweise oder jährlich summiert.

Die grafische Oberfläche

Eine fachliche Anforderung ist die Unterstützung von verschiedenen Ausgabeformaten. Die folgende Abbildung zeigt die verschiedenen Darstellungsformate exemplarisch für einen Report.

Die drei verschiedenen Darstellungsformate

Neben der HTML-Oberfläche stehen Exporte nach CSV sowie PDF zur Verfügung. Diese drei Ausgabeformate werden für sämtliche Reports innerhalb der Applikation auf jeder Ebene angeboten. Dies bedeutet ein Anwender selektiert über entsprechende Auswahlboxen Kriterien und lässt sich für diese einen entsprechenden Report generieren.

Für den PDF-Report wird eine Open Source Version der itext-Bibliothek eingesetzt. CSV-Dateien werden mit Hilfe des Export-Plugins von Grails umgesetzt.

Zusätzlich zu den tabellarischen Reportdarstellungen gibt es grafische Aufbereitungen in Form von Diagrammen. Auch hier wird auf die Bibliothek itext zurückgegriffen.

Grafische Aufbereitung von Kennzahlen

Fazit

Mit dem hier vorgestellten Ansatz lassen sich kostengünstig Standardreports erstellen, die vor allen Dingen homogen in bestehende Unternehmens-Applikationen und Infrastrukturen integriert werden können. Applikationen dieser Art sind für Endanwender im Vergleich zu den speziellen BI-Werkzeugen sehr einfach zu bedienen und bieten trotzdem verschiedene Sichten mit entsprechenden Drill-Down Möglichkeiten auf den Daten.

Links

[1] Batch Launcher Plugin
[2] ETL-Process
[3] Star Schema
[4] Groovy Closures
[5] Domain Specific Language

Wissensdatenbank – ein pragmatischer Ansatz

Die Bedeutung von Wissen in Unternehmen ist bereits vielfach beleuchtet worden. Geistiges Kapital stellt einen zentralen Wettbewerbsfaktor dar und ungenügender Austausch von Wissen führt zu Defiziten, die das Unternehmenswachstum behindern können. Ein mangelnder Wissenstransfer zwischen verschiedenen Unternehmensbereichen beinflußt alle möglichen Aspekte wie die Produktentwicklung oder den Kunden-Service.

Aktuelle Dokumente

Vielfach fängt das Problem bereits einen Schritt vor dem „Wissen“ an. Da stellt sich die Frage nach der aktuellsten Information oder Version eines Dokuments. Wo finde ich die Produktdatenblätter, Verkaufsunterlagen, Angebotsvorlagen oder die Übersicht zu den Konditionen, die dem neusten Stand entsprechen? Hier helfen Standard IT Lösungen, insbesondere DMS (Dokumenten Management Systeme).

Wie sieht es aber mit Wissen aus? Wo finde ich den Hinweis, dass nach den ersten Erfahrungen im Außendienst, der Verkaufsprospekt bei den Kunden nicht positiv ankommt und stattdessen das Produktdatenblatt verwendet werden sollte? Oder wo bekomme ich mit, dass ein Konkurrent zurzeit eine Kampagne startet und Sonderkonditionen anbietet? In diesen Fällen hilft das Dokumenten Management System alleine nicht mehr.

Gerade dieses wertvolle Wissen wird in aller Regel per elektronischer Post verteilt – und üblicherweise werden diese Emails nur von einem Bruchteil der Adressaten faktisch gelesen und berücksichtigt. Das Email Aufkommen ist in den meisten Unternehmen nach wie vor einfach zu hoch und der Zeitaufwand, die extrem relevanten Emails zu finden, enorm.

Foren und Wikis zum Austausch

Eine Lösung, um den Austausch zwischen den Unternehmensbereichen zu verbessern, ist die Nutzung von Foren und Wikis. Dies ist ein erster effektiver Schritt, um etwa Innen- und Außendienst zusammenzubringen und die Kommunikation und Zusammenarbeit zu fördern. So kann der Innendienst zeitnah auf das Feedback des Außendienstes reagieren. Es können zu den Beiträgen Dokumente angehängt werden, beispielsweise eine Unterlage der Konkurrenz oder andere relevante Dateien.
Mit diesem Vorgehen wurde eine weitere Plattform für den Austausch geschaffen. Allerdings entsteht hierdurch eine neue Quelle, in der nach Informationen und Wissen gesucht werden kann und muss.

Suchen und Finden

Der nächste logische Schritt ist somit, eine Unternehmenssuche zu implementieren, die sowohl das DMS als auch die Foren und Wikis berücksichtigt. Die Suchergebnismenge wird durch Dokumente, die sowohl im DMS als auch in den Wikis hinzugefügt wurden, verwässert. Redundante Ergebnisse und ggf. unterschiedliche Versionen erschweren es, das Gewünschte zu finden.

Wissensdatenbank

Genau diese Probleme adressiert unsere Wissensdatenbank. Zum einen können Dokumente verwaltet werden, mit den aus einem DMS üblichen Funktionen. Es stehen Funktionalitäten zur Abbildung von Wiki und Diskussionsforen zur Verfügung und es ist eine integrierte Suche enthalten. Die Suche umfasst natürlich alle Inhaltselemente, Dokumente sowie Inhalte des Wikis / Forums. Dokumente, die beispielsweise an ein Wiki Eintrag gehängt werden, kommen in das Dokumenten Center. Damit ist eine zentrale Dokumentablage gewährleistet ohne Redundanz.

Taxonomie

Als weiteres verbindendes Element verfügt unsere Wissensdatenbank über eine Taxonomie (hierarchischer Klassifikationsbaum), die kundenindividuell aufgebaut wird. Sämtliche Begriffe dieser Klassifikation stehen als Schlagworte zur Verfügung. Diese können allen Inhaltselementen zugeordnet werden, d.h. sowohl Dokumenten als auch Wiki Einträgen. Zudem stehen die Schlagworte – neben üblichen Metadaten wie Erstellungsdatum oder der Name des Autors – als Filterkriterien für eine facettierte Suche (siehe auch den Blog Post Verbesserung der Usability mittels Faceted Search) zur Verfügung. Damit lassen sich Informationen und Wissen extrem schnell auffinden.

Fazit

Mit diesem pragmatischen Ansatz für eine Wissensdatenbank – die im Übrigen komplett auf Open Source Software aufgebaut ist – steht eine effiziente Lösung zum Management von Informationen und Wissen zur Verfügung, die die Zusammenarbeit zwischen verschiedenen Bereichen eines Unternehmens fördert. Die Einsatzbereiche sind vielfältig, ob für Forschungs- und Entwicklungsbereiche oder Marketing, Vertrieb und Kundenservice.
In der Disziplin Wissensmanagement geht es faktisch immer um das Wissen in den Köpfen der Mitarbeiter, das nicht in vollem Umfang dokumentiert werden kann und entsprechend eine Wissensdatenbank nur bedingt weiterhilft. Aber auch hierzu gibt es Unterstützung durch Softwarelösungen, die dabei helfen, den richtigen Ansprechpartner zu einer dedizierten Fragestellung zu finden. Unser Expert-Finder ist eine solche Lösung. Mehr zu diesem Thema in einem weiteren Blog-Beitrag.

Messanwendung mit dem Raspberry Pi, SHT21, Play!, WebSockets, NVD3.js. Teil 2: Installation des Raspberry Pi und Anpassung des C-Programms

Der Raspberry Pi ist ein ec-kartengroßer Computer,  der sich durch einen sehr geringen Energieverbrauch auszeichnet.  Das verwendete  Modell B verbraucht nur 3,5 Watt.

Betriebssystem installieren und starten:

Das verwendete Betriebssystem heißt Raspian, basiert auf Debian und wurde für den Raspberry Pi  optimiert. Das Image kann unter der URL http://www.raspberrypi.org/downloads heruntergeladen werden.  Um das Image, mit dem Betriebssystem,  auf die SD-Karte kopieren zu können  ist für Windows folgender Image Writer zu empfehlen: https://launchpad.net/win32-image-writer.  Er ist einfach und intuitiv anwendbar. Nach dem Schreiben des Images auf die SD-Karte kann die SD-Karte im Raspberry Pi eingelegt werden.  Zur Konfiguration des Raspberry Pi wird dieser mit einem Router verbunden. Nach dem Anschluß der Stromversorgung startet der Raspberry Pi. Ein Aufbau einer ssh-Verbindung von einem anderen Computer zum Raspberry Pi ist nun möglich. 

WLAN:

Die Verbindung mit einem WLAN kann nach der Installation des TightVNC Servers, mit dem Kommando „sudo apt-get install tightvncserver“, bequem über eine graphische Oberfläche erfolgen. Ein TightVNC Client ist hierfür notwendig. Nach Anschluß eines WLAN-Adapters und korrekter WLAN-Konfiguration kann das LAN-Kabel entfernt werden. 

Einbindung von der Bibliothek libcURL:

Der SHT21 Sensor, zur Messung der Temperatur und Luftfeuchtigkeit, wurde steckfertig von emsytech gekauft und an den Raspberry Pi angeschlossen. Das Basisprogramm, ebenfalls von emsytech,  zum Auslesen der Werte, wurde über WinSCP auf den Raspberry Pi kopiert.  Die Bibliothek libcURL wurde in dasselbe Verzeichnis kopiert.  Die Datei makefile im source-Verzeichnis des Programms wurde um das Flag „-lcurl“ erweitert.

Anpassung der Anwendung in der Datei main.c:

Die Includes der main.c wurden um zwei Includes erweitert:

 
#include <string.h>
#include <curl/curl.h>

Folgende Variablen wurden hinzugefügt:

int intervall;
CURL *curl;
CURLcode res;
intervall = 1;

Es wurde die Struktur string (diese wird für die unteren Methoden verwendet) deklariert:

struct string {
  char *ptr;
  size_t len;
};

Die folgende Funktion init_string initialisiert eine struct string. 

void init_string(struct string *s) {
 s->len = 0;
 s->ptr = malloc(s->len+1);
 if (s->ptr == NULL) {
 fprintf(stderr,"malloc() failed\n");
 exit(EXIT_FAILURE);
 }
 s->ptr[0] = '\0';
}

Bei der Bibliothekl libcURL existiert die Callback- Option CURLOPT_WRITEFUNCTION. Mit dieser Option kann festgelegt werden, welche Funktion aufgerufen wird, sobald libcURL Daten empfängt, die gespeichert werden sollen. 

size_t writefunc(void *ptr, size_t size, size_t nmemb, struct string *s)
{
  size_t new_len = s->len + size*nmemb;
  s->ptr = realloc(s->ptr, new_len+1);
  if (s->ptr == NULL) {
    fprintf(stderr, "realloc() failed\n");
    exit(EXIT_FAILURE);
  }
  memcpy(s->ptr+s->len, ptr, size*nmemb);
  s->ptr[new_len] = '\0';
  s->len = new_len;

  return size*nmemb;
}

In unserer Anwendung kann der Intervall für die Abfrage der Sensordaten dynamisch gesetzt werden. Der Benutzer hat über die Oberfläche der Webanwendung die Möglichkeit den Intervall einzustellen. Bei jeder Übergabe von Messdaten an die Webanwendung wird der Intervall als Response, von der mit Play! realisierten Webanwendung, zurückgeliefert. 

Das Intervall war statisch auf 10 Sekunden eingestellt. Dies wurde in if((TimeCounter % intervall) == 0) verändert. 

Der folgende Quelltext ist für den Aufbau der aufzurufenden URL, den cURL Anfrage und die Verarbeitung der Antwort zuständig.

char str[100];
sprintf(str,"http://localhost:80/newValues?hum=%d&temp=%f",Humidity,Temp);
printf(str);
curl = curl_easy_init();
if(curl) {
   struct string s;
   init_string(&s);
   curl_easy_setopt(curl, CURLOPT_URL,str);
   curl_easy_setopt(curl, CURLOPT_WRITEFUNCTION, writefunc);
   curl_easy_setopt(curl, CURLOPT_WRITEDATA, &s);
   res = curl_easy_perform(curl);
  
   if(res!= CURLE_OK){

    fprintf(stderr,"curl_easy_perform() failed: %s\n", curl_easy_strerror(res));
   }else{
    printf("\n%s\n", s.ptr);
    intervall = atoi(s.ptr);
    free(s.ptr);
    curl_easy_cleanup(curl);
 }
 
 
}

Compilieren und starten des C-Programms:

Mit dem Befehl sh ./buildrun.sh compiliert und startet die Anwendung. Die Webanwendung zum Speichern und Streamen der Messanwendung muss nicht zwingend gestartet sein. Es bietet sich an ein Startskript in das Verzeichnis /etc/init.d/ abzulegen, damit die Anwendung gleich nach dem Booten des Betriebssystems, gestartet wird.