Tag Archives: Java

Maschine-zu-Maschine Kommunikation per GSM (Cinterion EGS5), Teil 1

Die Vernetzung unterschiedlichster Geräte vom Toaster bis zum Auto schreitet voran. So wird unsere Umgebung immer mehr zu einer Art Benutzeroberfläche, bei der die Gesamtheit der intelligenten Geräte die eigentliche Anwendung ausmacht.

Es gibt zahlreiche populäre Plattforme wie I/O-Boards à la Arduino oder Einplatinen-Computer à la Rasperry Pi, die das Erstellen solcher Lösungen bereits für verhältnismäßig kleines Geld erlauben. Auch die Telekommunikationsanbieter wie Telefonica und Deutsche Telekom mischen in diesem Bereich mit und helfen durch Hardware-Bundles, dem Bedarf angepasste SIM-Karten und speziell für diesen Bereich entwickelte Services sowie APIs.

Apropos SIM-Karte und GSM basierter Vernetzung: Interessant ist hier beispielsweise das auf dem Cinterion EGS5 basierende Developer-Kit der Firma MC Technologies. Dieses zeichnet sich außerdem dadurch aus, dass es Java als Entwicklungssprache unterstützt.

Setup und Modem-Treiber

Nach dem Zusammenbau inkl. SIM-Karte wird das Cinterion basierte Board im einfachsten Fall per USB mit dem Entwicklerrechner verbunden, das Stromkabel angeschlossen und anschließend durch die unter Cinterion EGS5\Treiber mitgelieferten Treiber als Modem verfügbar gemacht. Um die nicht mehr ganz taufrischen Treiber auch unter Windows 8 ins System zu bekommen habe ich mich dem Trick aus diesem Video hier bedient. Als nächstes benötigt man den zugewiesenen seriellen Port – diesen ermittelt man beispielsweise im Gerätemanager (bei mir ist es COM8). Außerdem ist im Developer Kit auch gleich noch ein passendes Konfigurationsprogramm Cinterion EGS5\SDK\CCFG_00-01-00-33\CCfg.exe enthalten, mit dem man die Funktionsfähigkeit des Setups gleich testen kann, indem der COM-Port eingetragen und die rote Read-Schaltfläche unten links zum Auslesen der Eigenschaften betätigt wird.

AT-Befehlssatz

Einmal eingerichtet, kann das Board als Modem per AT-Befehlsatz gesteuert werden. Hierfür nutze ich das Terminalprogramm PuTTY. Auch dort muss natürlich der COM-Port eingetragen werden. Außerdem ist es hilfreich in der Kategorie Terminal die Option „Local echo“ per „Force on“ zu erzwingen. Anschließend kann man das Modem nun per Kommandozeile steuern. Ein guter Start ist das Abrufen von Statusinformationen wie der aktuellen Signalstärke via AT+CSQ oder des aktiven Profils via AT&V.

SMS senden und empfangen

Eine schöne Fingerübung für den AT-Befehlsatz ist der Versand einer SMS. Nach dem Aktivieren der PIN (sofern erforderlich) über AT+CPIN=1234 (natürlich mit der passenden PIN) und dem Festlegen des Textmodus via AT+CMGF=1 wird der Versand durch den AT-Befehl AT+CMGS=03212345 (natürlich mit der passenden Rufnummer) eingeleitet. Jetzt erfolgt die Eingabe der Nachricht, die mit der Tastenkombination Strg+Z abgeschlossen wird. Der eigentliche Versand geschieht automatisch. Übrigens können Textnachrichten auch empfangen und z. B. per AT+CMGL="ALL" aufgelistet werden. Die Details einer empfangenen Nachricht zeigt der Befehl AT+CMGR=1, wobei die 1 dem Index der Nachricht entspricht.

The voice controlled coffee machine

I recently had a DiY workshop together with my Developer Garden colleague and firefighter Frank Zimmer and the great guys from Oracle. Oracle is working on M2M devices – obviously based on Java. After some Java experiments with a Cinterion driven embedded device this was my first time playing with the famous Raspberry PI and Java. Raspberry PI is a very small Linux PC similar in size to embedded boards like Arduino or .Net Gadgeteer. Our approach was controlling a coffee machine with a phone to serve George Clooney a coffee (sorry, in this case I was George Clooney´s lame replacement, but the Nespresso is real).


We hacked a Nespresso coffee machine, connected it to a Raspberry Pi and controlled it via phone. Please note, the video is just a rough cut to illustrate our proof of concept.

First of all we start the machine and need to wait until the machine is ready. But you can spend your time for so many things better than waiting: say writing Java. So we hacked the machine and connected it to the Raspberry PI running a small Java program. This program initiates a phone call via the Telekom Tropo API once the coffee machine is heated up. Now we need the way back from the phone to the Raspberry PI to finally start the coffee making. This is handled by Telekom Tropo which translates a phone call into a parameterized request which than writes a token. This token is handled by the Raspberry PI to start or stop the coffee making process.

I hope I can convince my friends from Oracle to publish the hardware specs and the Java code. And if you want to learn more about M2M and IVR-Systems (interactive voice response), feel free to come to our TechTalk at the 13th of December in Berlin.

Update: Some people asked how we did connect the Raspberry Pi and the coffee machine: Therefore we use the GPIOs and the Java library Pi4J.

Warum sind die Domänen übergreifenden Sicherheitsrichtlinien (Cross-Domain-Policy) eigentlich wichtig?

Immer wieder kommt die Frage, warum eigentlich dieser Aufwand mit den Cross-Domain-Policy Dateien (clientaccesspolicy.xml bei Silverlight und crossdomain.xml bei Flash, Java und Silverlight) betrieben werden muss, möchte man extern kommunizieren. Also wenn eine Inhalt von (Sub-)Domain A auf einen Inhalt von (Sub-)Domain B zugreifen möchte: Meist ist es dabei auch unerheblich, ob es sich bei dem zu ladenden Inhalt um Bild, Sound, Text, Video oder einen Datendienst (der dann ja einen Inhalt in der genannten Form – meist Text basiert – liefert) handelt. Im Folgenden soll eine einfache Erklärung ohne Anspruch auf Vollständigkeit und Exaktheit gegeben werden (denn das Thema ist doch sehr Facettenreich), denn Gründe für die Zugriffeinschränkung über (Sub-)Domänengrenzen hinweg gibt es viele:

Beispielsweise möchten Anbieter Ihre Dienste oder Inhalte nicht anderen frei zur Verfügung stellen. Ein anderer Grund sind Authentifizierungsprozesse, die nur von vertrauenswürdigen Stellen aus erlaubt sein sollen. Zurecht kommt nun jedoch der Hinweis, dass man dies ja einfach durch einen Proxy-Server umgehen kann, der diese Sicherheitseinstellungen ignoriert – also durch einen Server, der die Kommunikation mit der Domäne B durchführt und dem die Sicherheitsrichtlinien egal sind. Also warum dann der Aufwand, wenn sich das so einfach umgehen läßt? Ganz einfach: Diesen einen Server kann man relativ leicht erkennen und gegebenenfalls auch sperren. Was aber, wenn eine einfache SWF-Datei auf tausenden von Clients läuft, die über unterschiedliche Netzwerkanbieter und dynamische IP-Adressen kommen? Dann wäre eine Sperrung von großen Teilen des Internets mit weitreichenden Folgen für die Erreichbarkeit notwendig. Ein weiteres Beispiel sind DNS-Angriffe: Wenn also von Domain A auf Domain B so viele Anfragen ausgeführt werden, bis Domain B überlastet und somit nicht mehr erreichbar ist. Dies wäre vermutlich durch einen einzelnen Proxy ohnehin kaum zu leisten und selbst wenn, dann könnte der Server schnell erkannt und gesperrt werden. Aber tausende von Clients, die über unterschiedlichste Netzwerkadressen direkt auf die Domain B zugreifen, sind kaum alle zu sperren. Fazit: Gut, dass es Sicherheitsrichtlinien gibt und diese Art der “Angriffe” somit mit Flash, Java und Silverlight nicht möglich sein sollten…