Currently I hear / read everywhere "Voice Interaction is the future". I'm not totally convinced so far. But I'm pretty sure that is a market for apps made for voice interaction.
In this post I want to write about the challenges I faced developing my first own app for voice interaction.

If you are located in Germany feel free to test my skill "BilloBenzin" for free. Feedback is very welcome.
To get it click the following link:
> BilloBenzin @ Amazon.de <

I was curious how hard it is to develop an own skill (application for voice in the amazon-universe). After attending a full-day workshop with @muttonia I got a very good overview what needs to be done to develop / publish an own skill.
Especially for the german market it is attractive to develop skills, because there are not that many skills in the store so far (I think @muttonia mentioned roughtly 2.000 compared to over 1 million in the US).

I started to groom some ideas to develop my first own skill and decided to go with the usecase of cheap petrol. The goal was to develop a skill that should tell you the cheapest petrol station in your area.
To keep the scope small for my first development I only want to target areas within Germany (only released for the german skill-store). Furthermore I wanted to limit the interaction to a minimum but still useful - that means after the user gets the answer the skill is stopped (no real conversations, which would be a tricky topic at the moment anyways).

Below I will go through the things I learned and the challenges I had to face.

Concept behind Alexa on Echo, Echo Dot,...

An Alexa-enabled device - I think that's how Amazon calls it - like the Echo or Echo Dot just acts as a bridge to cloud-functions. It permanently listens for a keyword like "Echo", "Alexa" or "Computer" followed by a command, the skill-invocation name and optionally a phrase containing some varible inputs (there is also an "inversion" of the sentence structure that works, see the invocation picture below).
Everything after the keyword "Alexa" is basically the intent, which is transformed via speech-to-text and send as a JSON file to the cloud . There it is processed by an AWS-Lambda-Function (or an alternative cloud-function). The result is returned back as a JSON to the Alexa-enabled device where a text-to-speech transformation is applied. The result is vocalized to the user.

Invocation-name and interaction model

To get the expected results you really need to care about the invocation-name, the syntax of your invocation sentences, the parameters (Intent-Slot-Types) and the error-handling.

invocation-name

The invocation-name is very tricky, especially in the german language if you want to come up with a nice syntactical meaningful phrase. You can only define one invocation-name (does not need to be the same as your skillname) - so be careful here.
During my development / review-process I had to change the invocation-name 2 times due to the following reasons:

• My first invocation-name was "benzinpreis" (means petrolprice) and I wanted to use it in combination with the command "erfrage" (means ask). That could give me some nice natural sounding german phrases like "Alexa, erfrage Benzinpreis" or "Alexa, erfrage Benzinpreis für Diesel in Frankfurt" - which would be pretty neat because the phrases are short and contain all the necessary inputs.
  This invocation-name was rejected in my first certification by Amazon because "erfrage" is not an allowed/official command for Alexa even if it is perfectly recognized all the times - most likely because it sounds similar to "frage" which is officially supported.
• My second invocation-name was "billobenz" (just a catchy name). This one I had to change, because Alexa seems to have some problems with the german language. In most of the cases "billobenz" was understoud by Alexa as "below bands" and than it could not handle it / find a skill matching "below bands".
• I ended up with "billobenzin" (catchy name, means something like "cheapypetrol). This one is perfectly recognized, but it makes meaningful invocation-phrases longer, e.g. "Alexa, frage BilloBenzin nach dem günstigsten Diesel Preis in Frankfurt".

intent-scheme

The intent-scheme is a JSON-File that defines the intents you (can) handle in your cloud-function and what parameters (so called Slots) they take as an input.
Below you can see a definition of 2 intents - one custom and the standard HelpIntent. As you can see the custom intent defines 2 input-slots.
In the intent-scheme you can define more intents than you currently resolve / handle in your cloud-function. This allows you to adjust the cloud-function while your skill is live without a new review process. I would not recommend to do this, because if you do not predefine sample utterances for your unimplemented intents they will most likely not be recognized. If you add sample utterances for unimplemented intents you will get problems if the user starts such an intent, because you do not handle it.
If you really want to go with that I highly recommend to at least provide a stub implementation in your cloud-function that tells the user that this intent will be handled / implemented later and route her to the help-intent. But: This is not a good UX!

{
  "intents": [
    {
      "slots": [
        {
          "name": "city",
          "type": "AMAZON.DE_CITY"
        },
        {
          "name": "petrolType",
          "type": "PETROL_TYPE"
        }
      ],
      "intent": "GetCheapestPetrolForCityWithPetrolTypeIntent"
    },
    {
      "intent": "AMAZON.HelpIntent"
    }
  ]
}

slot-types

Slot-Types define the input-"words" that should be recognised for an intent. You have to give your input a type / a list of values that Alexa knows / recognises. In the US you can use Literal-Type too, which is any input with the consequence that you need to provide a lot more sample utterances to make it close to deterministic. For german skills Literal-Type is not supported.
In the JSON-codesnipped above you see two of my slots for a custom-intent. petrolType has a custom slot-type. city uses a predefined type "AMAZON.DE CITY" which I extended. It contains basically a list with 5.000 german city-names. It was a challenge for me to find the right type for city, because first I wanted to use something like a Literal for free input, because the backend that resolves the area also supports streets, zip-codes, e.g. I wanted to handle any address input all at once. I had to change my way of working / thinking here and needed to be more explicit. So I decided to use the predefined type "AMAZON.DE_CITY" which covers about 5.000 cities. Unfortunately I had to find out that not all Cities I tested are covered. E.g. "Nossen" (the town where I lived the first years of my life) is not recognised. So I had to extend the type. Unfortunately there is an uncertainty that I did not add a city a customer will ask for. That is a drawback of this type.

syntax

You should support the machine-learning algorithms of Amazon with a lot of Sample-Utterances how to invoke your skill - there you also define which element of the phrase is a parameter / slot you want to handle in your cloud-function (see examples of my skill in picture below).

In the Alexa workshop it was recommended to use at least 40 samples. The more you provide the better the intention of the user is recognised.

AWS

I know the concepts of serverless-computing and lambda-functions in the cloud, but I never had the chance to work with them before.
Amazon offers developers everything you can think of as a cloud-based service that you paid only on a usage / time / request base. For Alexa-skills the integration is made very easy for you because Amazon already gives you Alexa presets for a quick start. It is highly recommended to use AWS.
My skill uses the following AWS-Components: A Lambda function based on the alexa-skill-kit-sdk-factskill written in Node.js / Javascript, a DynamoDB and S3 for Skill-Graphics. Using all these components from Amazon makes it easy and fast to develop your skill. But it comes with the risk of a vendor-lock-in.
I would highly recommend to use a lambda function based on the alexa-skill-kit-sdk-factskill template (for the start) because it includes already the alexa-sdk, so you can directly start developing your intent-handlers.
It is also quite handy to use a DynamoDB for persisting the state of your skill. In my skill e.g. I store the petrol-type and the city the user asked for. So in future requests for the cheapest price she can take the shortcut in just asking Alexa to open the skill and it will respond with the latest price for the remembered city and petrol.
Your AWS-Lambda function has a unique identifier that can be directly connected to your skill in the Amazon Developer console (Alexa) (see example in picture below).

Provide Cards in your skill

Amazon offers the functionality to put detailed / additional information on so called cards that appear in the Alexa-App (and maybe on the Echo show?). In my skill Alexa just responds with the one and only cheapest petrol-station in speech but I show the Top 3 with additional information in a card (see screenshot below).

Unit-Testing a skill

Unfortunately I didn't try it so far. But it is definitely on my list because the bigger your skill gets the more tricky it gets to test it manually.
As a start I recommend reading the following blog-post: Unit-Testing an Amazon Alexa Skill.

Certification / review process

I didn't pass the certification of my skill two times. But most of the review comments really helped me to improve my skill and make it more robust.
I recommend to read through the Submission Checklist because it is pretty helpful.

Skill propagation

That's something I also have to figure out. How to attract potential customers with your skill? Currently they only can search for specific keywords in the skill-store and will find several skills fulfilling the same usecase. I think you need a lot of unique users to get featured by Amazon. I hope to find this out during the lifetime of my skill. I will update this post accordingly.
Any tips in this direction are highly welcomed.

Attract customers through behavior - Nir Eyal's Hook Model

Nir Eyal is a Silicon Valley based product designer 👨‍🎨 who came up with the Hook Model / Habit-forming products in his bestseller book Hooked: How to Build Habit-Forming Products.
I just want to go through the 4 aspects shown in the picture above in quick to describe how my skill (not) addresses them.

• Trigger The actual trigger that leads the user to use the skill. An external trigger could e.g. be that the user has seen the Skill-Icon and the good reviews in the store and wants to try it out herself. After the first use she repeats to use the skill (internal trigger).
• Action The user should be able to interact with ease and according to human behaviour. In the case of my skill this would be short invocation sentences in a natural, familiar german syntax.
• Variable Reward The skill should vary its responses to sound more natural. You could e.g. define several answer-templates and choose one randomly. This motivates the user to keep on using the skill and get to hear the other answers. This variation differentiates Nir Eyal's Model from traditional feedback loops. I currently do not vary the answers in my skill (besides the actual price-infos) but will encourage this in one of the next updates.
• Investment The more the user invests into the product (money, time, information) the more she values it. For my skill the user has not that much information or money she needs to invest. The only investment is the time she uses the skill. And maybe the precision of the inputs to get more tailored answers.
  In complex skills like role-playing games the user can build an inventory and gets more and more knowledge of the game. She invests time to bring the game to an end and that's an investment.

This was just a quick outtake. I highly recommend to read the book of Nir Eyal. Your future app-developments will profit from it 😉

Useful Links

• Alexa Node Skill SDK on Github as a reference how to implement things
• AWS Console for cloud-functions
• Amazon Developer Console to create and test your actual skills
• Echosim.io - simulates an Echo in to test your skill with voice for the times you have no real echo in reach (seems to work only in Firefox)

Mit dem Release der Developer Preview von Android IOT bringt Google Android auf Embedded Devices. Insbesondere Android-Entwicklern soll so die IOT-Welt zugänglicher gemacht werden, da die generelle Programmstruktur bzw. der Application-Lifecycle dem einer Android-App sehr ähnlich sind.

Vorerst werden lediglich Intel Edison, Intel Joule, NXP Pico und Raspberry Pi 3 Boards unterstützt. Mein vorhandener Raspberry Pi 1 leider nicht, ich nehme an, dass die älteren RaspberryPi-Boards zu wenig RAM für Android haben und deshalb offiziell nicht unterstützt werden.
Der Raspberry Pi 3 stellt den günstigsten Einstieg in Android IOT dar. Für den RasPi 3B, eine SanDisk Extreme 16GB microSD-Card und das offizielle Gehäuse habe ich insgesamt knapp 58€ gezahlt. Ein Micro-USB-Netzteil war noch von meinem Raspberry Pi 1 vorhanden. Ebenso habe ich bereits früher ein Sunfounder Super Kit V2.0 gekauft welches einen Grundschatz an LEDs, Widerständen, Display, Motor, Breadboard ... bereitstellt. Dies ist sehr nützlich um mit IOT-Projekten jeglicher Art zu starten (Arduino, RaspberryPi, ...) wenn man sich nicht ausschließlich auf Konsolenausgaben limitieren möchte. Ein vergleichbares Kit kann man beispielsweise unter folgendem Link erwerben: Sunfounder Starter Kit.

Die SanDisk Extreme Speicherkarte bietet sehr gute Transferraten und das offizielle Gehäuse ist sehr flexibel, da es Modular aufgebaut ist und Möglichkeiten hat die GPIO-Ports und Anschlüsse wahlweise zu bedecken oder zugänglich zu machen.

Zum Start mit Android IOT ist es empfehlenswert sich auf den offiziellen Google-Seiten einzulesen (https://developer.android.com/things/preview/index.html). Google bietet auch einen Elektronik-Crashkurs / Basiswissen - falls man noch nie an Elektronik gebastelt hat oder sein Wissen auffrischen möchte, ist die folgende Page lesenswert: https://developer.android.com/things/hardware/hardware-101.html.

Benötigte Software:

• ADB (Android Debugging Bridge) enthalten in den Android SDK Commandline Tools im Paket Platform-Tools. Download unter folgendem Link: https://developer.android.com/studio/index.html#downloads
• Android IOT-SystemImage: https://developer.android.com/things/preview/download.html
• (Empfehlenswert ist es zudem die AndroidStudio-Entwicklungsumgebung zu installieren: https://developer.android.com/studio/index.html#downloads)

Bootstrapping

Ich arbeite unter macOS, deshalb beziehen sich alle folgenden Konsolen-Codesnippets auf den Mac. Unter Windows muss man alternativ wahrscheinlich die adb.bat / oder adb.exe verwenden.

Um die erste IOT-App auf den RaspberryPi zu deployen sind folgende Schritte notwendig:

1. Android-IOT muss auf der MicroSD-Karte des RaspberryPi installiert werden.

• Neueste Version vom Android IOT SystemImage downloaden: https://developer.android.com/things/preview/download.html
• Image entpacken und auf die MicroSD-Karte installieren (unter dem folgenden Link findet man Anleitungen für Win, Linux und macOS: https://www.raspberrypi.org/documentation/installation/installing-images/)

2. MicroSD-Karte mit vorinstalliertem Image in RaspberryPi stecken, Display per HDMI und Netzwerk per LAN-Kabel anschließen.

• Display wird initial benötigt, da nach dem Bootvorgang die IP des RaspberryPi im Display eingeblendet wird.
• LAN-Verbindung brauchen brauchen wir initial um eine erste Internetverbindung bereitzustellen (IP per DHCP). Darüber kann das WIFI-Setup durchgeführt werden.

3. AndroidIOT booten indem man den RaspberryPi per MicroUSB mit Strom versorgt.

• Nach erfolgreichen Boot wird unten im Display die IP des RaspberryPi angezeigt

4. Testen ob man sich auf den RaspberryPi verbinden kann.

$ cd <AndroidSdkPath>/platform-tools
$ ./adb connect <IP des RaspberryPi>

5. Wifi installieren.

$ adb shell am startservice \
    -n com.google.wifisetup/.WifiSetupService \
    -a WifiSetupService.Connect \
    -e ssid <WLAN-Name> \
    -e passphrase <WLAN-Passwort>

• Nach einem Neustart wird auch die WLAN-IP im Display angezeigt und man kann das Netzwerkkabel entfernen und sich mittels ADB (adb connect) per WLAN mit dem RaspberryPi verbinden.

Hello World

Um zu schauen ob alles funktioniert, können wir eine erste kleine App erstellen, welche lediglich die verfügbaren GPIO-Ports in die Konsole postet.

• Neues Android Studio Projekt anlegen (File > New > New Project) mit folgenden Eckdaten:
  • App-Name: IotTest
  • Target Android Devices: Phone and Tablet, Minimum SDK API 24 (AndroidIOT ist noch nicht als Target aufgeführt, ist aber an der Stelle kein Problem, da Wir das Projekt später dahingehend anpassen werden)
  • Activity-Template: Empty Activity
  • Activity-Name: HomeActivity
  • IOT-Apps sind sehr ähnlich zu den normalen Android-Apps. Aus diesem Grund können wir auch das "Phone and Tablet" Template nehmen.
• Wir müssen unsere App mitteilen, dass sie die IOT-Systemlibrary nutzen soll, dazu müssen wir die dependencies-Section der Build.gradle des app-Projekts um folgende Zeile Code ergänzen:
  provided 'com.google.android.things:androidthings:0.1-devpreview'
• Des Weiteren müssen wir in der AndroidManifest.xml ergänzen, dass die IOT-Library genutzt wird (<uses-library android:name="com.google.android.things"/>) und mindestens einen Intent-Filter hinzufügen, damit das System unsere App nach dem Booten startet.

          <intent-filter>
                <action android:name="android.intent.action.MAIN"/>
                <category android:name="android.intent.category.IOT_LAUNCHER"/>
                <category android:name="android.intent.category.DEFAULT"/>
            </intent-filter>

Wir werden einen weiteren Intent-Filter setzen, damit Android-Studio unsere HomeActivity beim Klick des Run-Buttons startet.

            <intent-filter>
                <action android:name="android.intent.action.MAIN"/>
                <category android:name="android.intent.category.LAUNCHER"/>
            </intent-filter>

Am Ende sieht meine AndroidManifest.xml wie folgt aus:

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="csdev.it.iottest">

    <application
        android:allowBackup="true"
        android:label="@string/app_name"
        android:theme="@style/AppTheme">
        <uses-library android:name="com.google.android.things"/>

        <activity android:name=".HomeActivity">
            <!-- Launch activity as default from Android Studio -->
            <intent-filter>
                <action android:name="android.intent.action.MAIN"/>
                <category android:name="android.intent.category.LAUNCHER"/>
            </intent-filter>

            <!-- Launch activity automatically on boot -->
            <intent-filter>
                <action android:name="android.intent.action.MAIN"/>
                <category android:name="android.intent.category.IOT_LAUNCHER"/>
                <category android:name="android.intent.category.DEFAULT"/>
            </intent-filter>
        </activity>

    </application>

</manifest>

Da wir kein UI verwenden können wir einige überflüssige Sachen die mit dem App-Template reinkamen aus dem Manifest löschen, wie z.B.:

• android:icon="@mipmap/ic_launcher"
• android:roundIcon="@mipmap/ic_launcher_round"
• android:supportsRtl="true"
  Wichtig an dieser Stelle ist, dass android:theme="@style/AppTheme"enthalten bleibt, da die App sonst nicht startet.

In den Resource-Files des Projekts (res) kann man ebenfalls alle Layouts (aktuell nur eins), sowie alles unter mipmap (die Icons) löschen, da wir keine UI verwenden.

• Als letztes muss noch unsere HomeActivity angepasst werden. In der onCreate() Methode geben wir unser Hallo World aus und lassen uns vom PeripheralManagerService alle verfügbaren GPIO-Ports auflisten.
  Meine HomeActivity sieht wie folgt aus:

package csdev.it.iottest;

import android.support.v7.app.AppCompatActivity;
import android.os.Bundle;
import android.util.Log;

import com.google.android.things.pio.PeripheralManagerService;

public class HomeActivity extends AppCompatActivity {

    private static final String TAG = "HomeActivity";

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        Log.d(TAG, "Hello World");

        PeripheralManagerService service = new PeripheralManagerService();
        Log.d(TAG, "Available GPIO: " + service.getGpioList());
    }
}

Auch hier kann man setContentView(R.layout.activity_main); löschen, da wir kein XML-Layout nutzen.
Vielleicht kommt in einer der nächsten Android-Studio-Versionen ein "bereinigtes" IOT-Template von Google hinzu.

• Um die App auszuprobieren müssen wir uns zunächst per ADB mittels WLAN/LAN mit dem RaspberryPi verbinden, dazu kann man am einfachsten die in Android-Studio mitgelieferte Konsole nutzen oder alternativ ein Terminal aufmachen:

$ ./adb connect <IP des RaspberryPi>

• Eine erfolgreiche Verbindung zum RaspberryPi wird mit folgender Ausgabe quittiert:

* daemon not running. starting it now at tcp:5037 *
* daemon started successfully *
connected to <IP des RaspberryPi:Port>

• Nachdem die Verbindung hergestellt ist, können wir unsere HelloWorld-App mit Android-Studio auf dem RaspberryPi deployen. Dazu einfach den grünen Run-Button drücken und anschließend den RaspberryPi (z.B. "unknown Iot_rpi3 (Android 7.0, API24) in der Deployment-Target-Liste auswählen und den "OK"-Button drücken. Daraufhin wird die App gebaut und auf dem RaspberryPi installiert sowie die HomeActivity gestartet.
  Über Android-Studio (Android Monitor > logcat)können wir die Konsolenausgabe des RaspberryPi aufrufen und schauen ob unser HelloWorld ausgegeben wird (alternativ per Terminal $ ./adb logcat). In den Logs sollten 2 Zeilen ähnlich den folgenden zu finden sein:

03-18 14:19:02.048  1754  1754 D HomeActivity: Hello World
03-18 14:19:02.055  1754  1754 D HomeActivity: Available GPIO: [BCM12, BCM13, BCM16, BCM17, BCM18, BCM19, BCM20, BCM21, BCM22, BCM23, BCM24, BCM25, BCM26, BCM27, BCM4, BCM5, BCM6]

Mit diesem HelloWorld-Beispiel schafft ihr den ersten Durchstich um Apps auf AndroidIOT zu deployen. Wesentlich spannender ist die Interaktion der IOT-Apps mit externen Hardwarekomponenten, auf welche ich hoffentlich in künftigen Blogposts eingehen kann.

Im letzten Abschnitt habe ich den Zusammenbau beschrieben.
Hier soll es nun kurz um die softwareseitige Ansteuerung der Ampel gehen.

Ich habe mich dazu entschieden den Arduino passiv anzusteuern. Dafür wurde per ArduinoIDE StandardFirmata auf den Arduino gespielt, wodurch er sich über USB seriell ansteuern lässt. Dies erleichtert einige Dinge und verlagert sämtliche Logik auf den PC an den die Ampel angeschlossen ist. Ein wesentlicher Vorteil ist, dass man auch komplexere Netzwerk-Settings (VPN/Proxy/etc) relativ easy umsetzen kann. Nachteil dieser Lösung ist sicherlich, dass man einen Rechner braucht, der sich um die Ansteuerung kümmert.
In meinem Fall war es wichtiger den Arduino möglichst einfach in ein VPN zu bringen. Der Rechner ist sowieso vorhanden :-)

Die serielle Steuerung des Arduinos übernimmt in meinem fall ein kleines NodeJS-Script, welches den aktuellen Teamcity-Build-Status alle 15 Sekunden abfragt und die Ampel-Lampen per Arduino entsprechend "grün" (letzter Build erfolgreich), "gelb blinkend" (Build / Tests laufen gerade) oder "rot" (Probleme beim letzter Build) schaltet.
Die serielle Ansteuerung des Arduino erfolgt mittels des Johnny-Five IoT-Frameworks Dieses Framework ist die einzige Dependency und stellt bereits eine Menge Funktionalität (Schieberegister, LCD-Ansteuerung, Animationen,...) von Haus aus bereit.

Das komplette Projekt habe ich unter MIT-Lizens auf meinem Github unter folgendem Link bereitgestellt: UnoJohnnyBuildInfo.
Es wurde weitestgehend modularisiert, sodass sich die Teamcity-Anbindung über eine Config-Datei anpassen lässt und alle Dependencies in der package.json Datei verwaltet werden.
Es soll lediglich einen Ansatz für künftige Modifikationen / Nachbauten liefern.

Falls ein Leser etwas ähnliches umsetzt, so kann er mich gerne anpingen.

Im letzten Artikel bin ich auf die verbauten Komponenten eingegangen. Hier soll es nun um den Zusammenbau aller Teile gehen.

Als erstes wurde die prototypische Schaltung vom Breadboard auf eine Lochrasterplatine übertragen, sprich die Mosfets, Jumper-Kabel und der 4-Pin-Molex-Anschluss miteinander verlötet.

Anstatt die Lampenfassungen direkt mit der Platine zu verlöten, habe ich mich für Lüsterklemmen entschieden. Diese ermöglichen den schnellen Ausbau / Wechsel der Platine im Falle späterer Erweiterungen bzw. wenn Probleme auftreten sollten.

Im unteren (grünen) Modul der Ampel wurde der Arduino und die Platine untergebracht, da hinter den Lampen jede Menge Platz vorhanden ist. Sowohl USB-Kabel des Arduino als auch der 12v Molex-Anschluss wurden durch den untern Arm der Ampel nach außen geführt.

Die Ampel ist insgesamt knapp einen Meter hoch. Auf dem folgenden Bild wird die Relation deutlich.

Im kommenden Artikel werde ich noch kurz auf die softwareseitige Ansteuerung der Ampel eingehen.

Im ersten Beitrag bin ich kurz auf die Projektidee eingegangen. An dieser Stelle soll es um die verbauten / benötigten Komponenten gehen.
Zunächst werde ich aufführen, was in der fertigen Ampel verbaut wurde:

• Siemens Straßenampel (380V, e27-Lampenfassung)
• Arduino Uno Microcontroller
• 3x 12v e27 LED-Lampe -> 3x 0.7A
• 3x MOSFET
• 1x Lochrasterplatine
• einige Jumperkabel / Kabel / Lötzinn
• 230v auf 12v Netzteil 2A (ursprünglich gedacht um PC-Festplatte extern anzuschließen) -> perfekt für dieses Projekt geeignet.

Die Ampel konnte ich günstig über eBay-Kleinanzeigen erwerben. Sie basiert auf 380Volt-Technik, was einige Dinge erschwert und ein Sicherheitsrisiko darstellt. Hier erfolgte, nach der initialen Reinigung, ein Umbau des gesamten Systems auf 12Volt-Technik (deshalb die oben aufgeführten 12V-Komponenten).

Ursprünglich hatte ich geplant LED-Matritzen zu löten und in die einzelnen Module zu verbauen. Da der Arduino jedoch nur eine geringe Anzahl an LEDs mit Strom versorgen kann hätte ich auch für diesen Ansatz eine externe Stromquelle benötigt. Als ich mich nach Alternativen umgeschaut habe, bin ich auf die 12v LED-Glühbirnen für e27-Fassung gestoßen, welche für den Camping-Bedarf gedacht sind, sich jedoch perfekt für mein Projekt eignen. Da die Ampel bereits mit e27-Lampenfassungen ausgestattet ist, musste ich lediglich die Stromversorgung der Fassungen auf 12v anpassen.

Der Arduino Uno ist lediglich in der Lage 3,3v bzw. 5v bereit zu stellen. Für die 12v Spannungsversorgung erwies sich ein altes Netzteil (230v->12v-Trafo) als sehr nützlich das ursprünglich dafür gedacht war interne Festplatten extern anzuschließen. Es kann über einen (handelsüblichen PC-) 12v 4-Pin-Molex-Stromanschluss die benötigte Stromversorgung bereitstellen.
Um Spannungen von 12v und mehr mit dem Arduino schalten zu können, habe ich MOSFETs verwendet. Sie ermöglichen es den Stromfluss mittels der Arduino Digital-Pins zu Kontrollieren (HIGH = Strom fliest, LOW = Strom unterbrochen).

Um zu testen ob alles funktioniert wie geplant, habe ich die zugegeben einfache Schaltung erstmal auf einem Breadboard realisiert und mit den Komponenten der Ampel getestet.
Nachdem alles funktionierte wie angedacht, wurde die Schaltung auf einer Lochrasterplatine realisiert. Dazu mehr im kommenden Artikel.

RaspberryPi, Arduino und co. interessieren mich schon länger. Ich habe auch bereits an Workshops teilgenommen in denen kleinere Projekte umgesetzt wurden. Bisher hatte ich jedoch keine konkrete Idee, die ich umsetzen kann. Ich bin jedoch der festen Überzeugung, dass man am produktivsten ist und am meisten lernt, wenn man auf ein konkretes Ziel hinarbeitet.

Ich habe vor Jahren einen RaspberryPi der ersten Generation (256MB RAM) gekauft. Dieser war anfangs als Kodi-Mediacenter im Einsatz, verstaubt jedoch seit einiger Zeit im Regal. Was wäre also naheliegender als ihn für dieses Projekt als Controller zu benutzen. Dies war zumindest der ursprüngliche Plan.
Ok, Raspberry rausgekramt, Raspbian Linux installiert - Ready. Mir fehlten jedoch noch Komponenten (LEDs, Widerstände etc) um mit dem Experimentieren zu starten. Daraufhin habe ich mir das Sunfounder Super-Kit bestellt. Dieses umfasst vom Breadboard über LEDs, 7-Segmentanzeigen bis hin zum LCD alles was man für den Start braucht.

Während ich auf das Komponenten-Kit wartete bin ich noch sehr günstig an einen Arduino Uno gekommen. Ich begann damit zu "spielen" und als das Kit ankam ein paar Schaltungen für den Arduino zu bauen.

Das Projekt

Da ich mich in meinem Job aktuell intensiv mit Continuous Integration auseinander setze, hat sich die Projekt-Idee entwickelt eine "Build-Ampel" zu bauen, welche auf einfache Weise visualisiert, ob ein Build aktuell läuft, fehlgeschlagen ist oder erfolgreich war. Ein gutes Thema für den Einstieg, welches sich beliebig erweitern lässt.

Der Grundaufbau besteht aus einem Microcontroller (RaspberryPi / Arduino / etc.) welcher die Ampel entsprechend der Build-Informationen schaltet. Die Daten werden per Rest-API vom Build-Server geladen und dann verarbeitet.
Dies stellt lediglich den Basis-Aufbau dar. Man kann die Konstruktion beliebig erweitern. Denkbar wäre beispielsweise eine Uhr, die die Buildzeit darstellt, ein Lautsprecher, der auf den fertigen / fehlgeschlagenen Build hinweist, ....