TinkerForge: Einstieg mit Master Brick 2.1, WIFI Master Extension 2.0 und Voltage/Current Bricklet 2.0

TinkerForge ist eine deutsche Firma aus Schloß Holte-Stukenbrock, die sich seit 2011 bemüht, die Arbeit mit eingebetteten Systemen zu vereinfachen. Ein Stecksystem erübrigt den Griff zum Lötkolben und  detaillierte Kenntnisse in Elektronik werden überflüssig. In diesem Artikel möchte ich testen, in wie weit dies gelungen ist und meine persönliche Erfahrung beschreiben.

Einführung

TinkerForge setzt konsequent auf den Open Source Gedanken und veröffentlicht den Quellcode und weitere Informationen zu den einzelnen Produkten im Firmenaccount auf Github in aktuell 178 Repositories.

Um das Ziel der Vereinfachung zu erreichen, setzt TinkerForge auf ein Baukastensystem aus Bricks, Bricklets und Master Extensions.

Bricks und Master Extensions besitzen eine einheitliche Grundfläche von 4x4cm und werden über den Stack Connector zu Stapeln verbunden. Der wichtigste Brick ist dabei der Master Brick, dieser erfüllt mehrere Aufgaben. Zum einen ermöglicht er den Anschluss von bis zu 4 Bricklets,  bietet die direkte Kommunikation via USB zu einem PC und dienst als Master der Kontrolle des Stapels (nur der Master Brick, um unteren Ende des Stapels dient als tatsächlicher Master, die anderen bieten dann nur  den Anschluss von weiteren maximal 4  Bricklets). Weitere Bricks erlauben den direkten Anschluss von Gleichstrommotoren, Modellbauservos und Schrittmotoren oder dienen als 9-Achsen Lagesensor (IMU Brick). In der Dokumentation findet sich eine Liste der Bricks neben einer Liste der Master Extension.

Bei den Bricklets wird bewusst auf ein einheitliches Format verzichtet, da so ganz unterschiedliche Sensoren, Aktoren, Konverter zu anderen Bussystemen und verschiedenen Mensch-Maschine-Schnittstellen verbunden werden können. Eine vollumfängliche Liste der Bricklets findet man sich in der Bricklet-Dokumentation. Verbunden werden die Bricklets mit vorkonfektionierten Kabeln unterschiedlicher Längen von 6cm bis zu 2m.

Allen Modulen gemein ist ein Raster der Befestigungslöcher von 5mm, zur Befestigung bietet Tinkerforge Montageplatten für den schnellen Aufbau auf dem Schreibtisch an.

Tinkerforge bietet aktuell für 14 Sprachen (davon 3 als spezielle Ausprägungen für mobile Geräte) fertig APIs an. Diese basieren alle auf dem TCP/IP Protokoll, deshalb sollte eine Adaption für weitere Sprachen durchführbar sein (Swift fehlt zum Beispiel in der Liste der unterstützten Sprachen bisher).

Persönliche Erfahrung

Für den Einstieg entschied ich mich für folgende 3 Module:

Das Ziel ist die kombinierte Messung der von einer Solarzelle gelieferten Spannungs- und Stromwerte und der Transfer in ein Grafana.

Bestellt habe ich direkt bei TinkerForge, geliefert wurde ohne Aufschlag bereits am nächsten Tag.

Installation des Brick Daemon (brickd)

Der Brick Daemon abstrahiert als Systemdienst die Kommunikation zwischen den APIs und dem Master Brick über USB. Den Quellcode findet man im brickd-Repository und Pakete für Debian-artige Distributionen zum Download auf tinkerforge.com.

Allerdings ist die Standardkonfiguration des suboptimal, da auf allen IP Adressen des Rechners ohne Authentifizierung gelauscht wird. Hier sollte man sich doch eher auf localhost 127.0.0.1 beschränken. Dies kann nachträglich in der Datei /etc/brickd.conf mit der Option listen.address angepasst werden. Zusaetzlich habe ich einen Pull-Request erstellt, der das Default anpasst.

Nach der Einrichtung der WIFI Master Extension kann jedoch direkt deren IP Verbindung genutzt werden und der brickd wird obsolet.

Installation des Brick Viewer (brickv)

Der Brick Viewer ermöglicht den Zugriff auf auf lokal angeschlossene Bricks über USB und auch per IP auf entfernte Bricks. Auch hier ist der Quellcode im entsprechenden brickv-Repository zu finden, deb-Pakete finden sich als Downloads auf tinkerforge.com.

Leerer Master Brick
Setup-Reiter eines Master Brick ohne weitere Module

Der Brick Viewer zeigt bei einem einzelnen Master Brick natürlich noch nicht viele Informationen an:

Update Dialog
Dialog zum Aktualisieren der Firmwares

Allerdings ist schon jetzt eine Verbindung via USB möglich und es kann zum Beispiel ein Update der Firmware vorgenommen werden (Changelog).

Schließt man nun den Voltage/Current Bricklet 2.0 an einen beliebigen Port des Master Bricks an, so wird dieser automatisch erkannt.

Master Brick mit Voltage/Current Bricklet 2.0
Setup-Reiter eines Master Brick mit angeschlossenem Voltage/Current Bricklet 2.0

Hat man nun der Beschriftung des Bricklets entsprechend die Stromquelle und den Verbraucher angeschlossen, so kann man auf dem entsprechendem Reiter sofort mit der Messung beginnen.

Erste Messung
Einfache Graphen im Brick Viewer

Über die Funktion “Data Logger” im Setup-Reiter kann bereits jetzt mit einer dauerhaften Aufzeichnung von Daten in eine CSV-Datei begonnen werden. Allerdings ist eine USB Verbindung für eine Messung am Fenster (mit der Solarzelle) nicht praktikabel.

Eine Möglichkeit wäre eine der vielen Bastelplatinen mit USB und WLAN zu verwenden oder man greift zur WIFI Master Extension 2.0. Diese ersetzt die USB-Verbindung und den lokalen Brick Daemon durch ein WLAN Modul.

Aufbau des Stapels

Die Bricks und Master Extensions werden über die mitbestellten Befestigungskits verschraubt, nachdem die Module korrekt ausgerichtet worden (man beachte die weiß markierten Ecken!).

Master Brick und WIFI Master Extension 2.0
Stapel aus Master Brick und WIFI Master Extension 2.0

Auch die WIFI Master Extension wird direkt im Brick Viewer erkannt:

WIFI Konfiguration
Konfiguration der WIFI Master Extension 2.0 im Brick Viewer

Nach der Konfiguration als WLAN-Client (General und Mode) muss noch das richtige WLAN ausgewählt werden. Anschließend kann über “Show Status” geprüft werden, ob die WLAN Einrichtung erfolgreich war und welche IP der Stapel bekommen hat. Die kann man dann zur Kommunikation zwischen Brick Viewer und dem Stapel verwenden.

Nutzung der Python API

Das Modul installiert man einfach mit pip:

pip install --user tinkerforge

Folgendes Skript öffnet zunächst eine IPConnection zu dem aufgebauten Stapel über die WIFI Master Extension. Anschließend wird auf das angeschlossene Bricklet zugegriffen und sekündlich die Werte für Spannung, Stromstärke und Leistung ausgegeben.

HOST = "192.168.178.203"
PORT = 4223
UID = "FKC"

from tinkerforge.ip_connection \
    import IPConnection
from tinkerforge.bricklet_voltage_current_v2 \
    import BrickletVoltageCurrentV2
from time import sleep

if __name__ == "__main__":
    ipcon = IPConnection() 
    ipcon.connect(HOST, PORT) 

    vc = BrickletVoltageCurrentV2(UID, ipcon) 

    while True:
        voltage = vc.get_voltage()/1000.
        current = vc.get_current()/1000.
        power = vc.get_power()/1000.

        print(str(voltage) + " V " + \
              str(current) + " A " + \
              str(power) + " W")
        sleep(1)

Weitere Dokumentation zur API findet sich auf der Webseite von Tinkerforge.

Fazit

Mit den Bricks und Bricklets von TinkerForge erhält man ein einfach zu verwendendes Modulsystem. Die Verarbeitung der Module wirkt qualitativ hochwertig. Dies und die einfache Handhabung durch die unterstützende Software rechtfertig in meinen Augen den leicht höheren Preis. Auch die Auswahl der bereits jetzt existierenden Module lädt zu weiteren Experimenten ein.

Brother DCP-9017CDW und Linux

Das alte Faxgerät meines Vater ging leider kaputt und wurde zuletzt eh nur noch als Kopierer verwendet. Als Ersatz wurde ein Brother DCP-9017CDW auserkoren, da dieses Gerät:

  1. ein duplexfähigen Farblaser zur Ausgabe verwendet (trocknet einfach nicht ein),
  2. einen moderaten Anschaffungspreis besitzt,
  3. per WLAN auch mit Linux als Drucker verwendet werden kann und
  4. über ein einfaches Touch Display bedient werden kann.

Kurz um, das Gerät scheint das richtige zu sein, zumal auch eine Funktion “Scan2Email” auf der Funktionsliste steht. Leider sagt das Kleingedruckte “Benötigt Brother-Software” und verweist auf einen optionalen kostenlosen Download für Linux aus dem Brother Solutions Center. Ebenso leider existiert dann kein Download für Linux im Brother Solutions Center (Stand 25.12.2017). Ergo kein offizieller Weg für Scan2Email. Na danke.

Ohne Brother Software kann das Gerät allerdings auf (lokale) FTP-Server scannen. Lokal deshalb, da FTP als unsicher einzustufen ist (Link, Link, …).

Die Idee ist nun: vom Brother DCP-9017CDW wird in ein FTP-Verzeichnis pro Email-Adresse gescannt. Auf dem FTP-Server wird auf eingehende Dateien reagiert und diese per Mail versendet.

Folgende Software wurde ausgewählt:

  • vsftpd als FTP-Server,
  • mpack zum Versand der Dateien als Anhang,
  • exim4 mit Smarthost zum Versand der Mails und
  • incron zum Reagieren auf neue Dateien.

Zunächst erlaubt man dem vsftpd in seiner Konfiguration das Schreiben von Dateien (write_enable=YES) sowie lokale User (local_enable=YES). Somit kann auf dem DCP-9017CDW testweise auf den FTP-Server gescannt werden.

Anschließend exim so einrichten, dass er Mails nach außen versenden kann. Das passiert in diesem Szenario mit einem Smarthost. Dann sollte man testen, ob mpack auch Anhänge versenden kann:

mpack -s SUBJECT /PATH/TO/FILE MAILADRESSE

Kurz danach sollte die Datei als Anhang eintreffen.

Abschließend noch incron konfigurieren, damit auf neue Dateien reagiert werden kann:

  • den Nutzernamen, unter dem per FTP die Dateien abgelegt werden, in der Datei /etc/incron.allow vermerken
  • mit incrontab -e pro Verzeichnis bzw. Email Adresse eine Zeile der Form
    $PFAD IN_CLOSE_WRITE $Script $@/$# $MAIL

    eintragen

Das Script übergibt mpack die Datei und die Mailadresse und löscht die Datei nach dem Versand.

Et voilà, Scan2Mail funktioniert doch.

Debian Pakete bauen im Docker-Container

Leider gibt es wohl für Debian 8 Jessie kein (aktuelles) Netatalk gibt, hier eine kleine Beschreibung wie man sich mit Docker und checkinstall ein entsprechendes Paket selber erstellen kann, ohne seinen Host mit den zur Paketerstellung notwendigen Abhängigkeiten zu belasten. Als Einstieg diente mir das Wiki von Netatalk und das Blog von Daniel Lange.

Zunächst das Dockerfile:

# Wir wollen das Paket später auf Debian 8 einsetzen. Andere 
# Distributionen sind analog möglich
FROM debian:8

# Update der Paketbasis und Installation der benötigten Abhängigkeiten
RUN apt-get update -y; \
    apt-get install -y build-essential \
        devscripts debhelper cdbs autotools-dev dh-buildinfo \
        libdb-dev libwrap0-dev libpam0g-dev libcups2-dev libkrb5-dev \
        libltdl3-dev libgcrypt11-dev libcrack2-dev \
        libavahi-client-dev libldap2-dev libacl1-dev \
        libevent-dev d-shlibs dh-systemd wget libtdb-dev checkinstall

# Quellcode beziehen und extrahieren
RUN wget http://prdownloads.sourceforge.net/netatalk/netatalk-3.1.10.tar.bz2; \
    tar xvf netatalk-3.1.10.tar.bz2

Anschließend bauen wir das Docker-Image:

docker build --tag=docker_build_netatalk .

Auführen mit:

docker run -v /tmp:/target --rm -ti docker_build_netatalk

Im Container dann folgendes durchführen:

$ cd netatalk-3.1.10
$ ./configure \
    --with-init-style=debian-systemd \
    --without-libevent \
    --without-tdb \
    --with-cracklib \
    --enable-krbV-uam \
    --with-pam-confdir=/etc/pam.d \
    --with-dbus-daemon=/usr/bin/dbus-daemon \
    --with-dbus-sysconf-dir=/etc/dbus-1/system.d \
    --with-tracker-pkgconfig-version=1.0
$ make
# Legt einige Verzeichnisse an, wird ja eh weggeworfen
$ make install 
$ checkinstall \
    --default \
    --install=no \
    --requires="libtdb1,libcrack2"
# Benutze cp oder scp, um das erzeugte Paket zu sichern
$ cp /netatalk-3.1.10/netatalk_3.1.10-1_amd64.deb /target
$ exit

Nach dem Ende löscht sich der Container dank –rm selbst und wir haben mit netatalk_3.1.10-1_amd64.deb ein schönes Debian-Paket, welches auch sauber wieder entfernt werden kann.

Docker.io in der Praxis – OpenVPN Server

Nach dem ersten Artikel zu Docker nun ein weiterer Post zum Thema.

Diesmal direkt mit dem Erstellen eines eigenen Images. Es geht um OpenVPN, ein open-source VPN, welches eine Vielzahl von Plattformen (Windows, OS X, Linux, Android und iOS) unterstützt.

Veröffentlicht habe ich das ganze unter github.Die zentrale Datei ist die Datei Dockerfile, welche den Build des Images steuert.

FROM debian

MAINTAINER Joachim Lusiardi

RUN apt-get update; \
    apt-get -y install openvpn ;

ADD start.sh /start.sh

RUN chmod +x /start.sh

VOLUME ["/etc/openvpn"]
VOLUME ["/var/log/openvpn"]

EXPOSE 1194/udp
EXPOSE 1194/tcp

ENTRYPOINT /start.sh

FROM legt ein Basis-Image fest, hier die neuste Version von Debian.
MAINTAINER gibt den Betreuer des Images an.
RUN führt Befehle innerhalb des Images aus. Hier das Updaten der Packet-Quellen, Installieren von OpenVPN und dem Ausführbarmachen des start-Skripts.
ADD fügt eine Datei dem Image hinzu.
VOLUME gibt an, das ein Verzeichnis des Images beim Ausführen auf ein Verzeichnis des Hosts gelegt werden kann.
EXPOSE definiert welche Ports von ausserhalb des Images erreichbar sein sollen. Diese sind nicht automatisch beim Starten des Images auf eine öffentliche IP gebunden.
ENTRYPOINT gibt an, welches Kommando ausgeführt werden soll.

Weitere Detail auf github und auch unter https://registry.hub.docker.com/u/shing19m/docker-openvpn-server/.

Docker.io in der Praxis – Installation

Nachdem Docker immer mehr gehyped wird (LinuxMagazin 09/14, c’t 17/2014), soll das ganze hier mal für einen Root-Server inklusive folgender Dienste getestet:

  • WordPress (inklusive MySQL Datenbank)
  • OpenVPN Server
  • getrennter SSH Server für IRC mit irssi in screen oder tmux

Zusätzlich soll als Option das schnelle und einfache Bereitstellen von weiteren Diensten auf Basis von Technologien wie Node.js und NoSQL Datenbanken möglich sein.

Installation von Docker auf dem Root-Servers

Zunächst muss Docker installiert werden. Das soll nun hier besprochen werden.

Basisinstallation

Der Hoster bietet hier Debian-76-wheezy-64-minimal an.

Nach der Installation muss die Liste der Paket-Quellen angepasst werden (Debian Testing wird benötigt). Dabei hilft der Debian Sources List Generator:

deb http://ftp.debian.org/debian testing main contrib 
deb-src http://ftp.debian.org/debian testing main contrib 

deb http://ftp.debian.org/debian/ jessie-updates main contrib 
deb-src http://ftp.debian.org/debian/ jessie-updates main contrib 

deb http://security.debian.org/ jessie/updates main contrib 
deb-src http://security.debian.org/ jessie/updates main contrib

Anschließend mit apt-get update und apt-get dist-upgrade auf die Debian-Version jessie (bzw. testing) updaten.

Nun für den richtigen Kernel sorgen:

echo "deb http://ftp.us.debian.org/debian wheezy-backports main" > \
    /etc/apt/sources.list.d/wheezy-backports.list
apt-get update
apt-get -t wheezy-backports install linux-image-amd64

Docker installieren

Für Docker gibt es ein Ubuntu Repository, welches auch für Debian verwendet werden kann:

apt-key adv --keyserver keyserver.ubuntu.com \
    --recv-keys 36A1D7869245C8950F966E92D8576A8BA88D21E9
echo "deb http://get.docker.io/ubuntu docker main" > \
    /etc/apt/sources.list.d/docker.list
apt-get update
apt-get install lxc-docker

Die beiden letzen Schritte nach dieser Anleitung: http://doduck.com/docker-install-on-debian-7/

IPv6 für die Container

IPv6 ermöglicht es, für jeden Container eine eigene IP zu reservieren.

Leider wird IPv6 von Docker zum aktuellen Stand (23. August 2014, Docker Version  1.2.0) noch nicht unterstützt, kann aber über lxc direkt an den Container durchgereicht werden. Wenn IPv6 nicht verwendet werden soll, so kann dieser Abschnitt übersprungen werden.

Für IPv6 muss in der Datei /etc/sysctl.conf folgende Zeile eingefügt oder wieder eingkommentiert werden:

net.ipv6.conf.all.forwarding=1

Und der Docker-Daemon muss auf den lxc Treiber umgestellt werden. Dazu unter Debian in der Datei /etc/default/docker folgendes eintragen:

DOCKER_OPTS="--exec-driver=lxc"

Zusätzlich muss das lxc Paket installiert werden:

apt-get install lxc

Nun muss der von Docker angelegten Bridge noch eine  IPv6 IP hinzufügen:

ip -6 addr add aaaa:bbbb:cccc:dddd::1:1/112 dev docker0

Dabei muss natürlich aaaa:bbbb:cccc:dddd durch einen entsprechenden Teil des eigenen IPv6 Subnetzes ersetzt werden.

Um das Ganze zu Vereinfachen, bietet es sich an, Container dann mit folgendem Script zu starten:

#!/bin/bash

NW_IP=$1
shift
NW_GW=aaaa:bbbb:cccc:dddd::1:1
#shift
REST=$@

docker run \
    --lxc-conf="lxc.network.flags=up" \
    --lxc-conf="lxc.network.ipv6=$NW_IP" \
    --lxc-conf="lxc.network.ipv6.gateway=$NW_GW" \
    $REST

Beim Aufrufen muss die IPv6 Adresse inklusive Subnetzmaske angegeben werden, also aaaa:bbbb:cccc:dddd::1:2/112.

Résumé

Nun ist es möglich mit Docker Container zu verwenden und sogar IPv6 direkt in die Container zu leiten.

Zeitzonenprobleme mit Tomcat 6 auf Debian 6

Beim Einrichten einer Webapplikation auf einem Tomcat 6 auf einem Debian 6 Host fiel mir auf, dass die Zeitstempel in den Tomcat Log-Dateien “falsch” waren. Falsch meint hier, dass sie nicht mit der Rechneruhrzeit übereinstimmten. Dies deutete auf ein Zeitzonenproblem hin.

Kurzes googeln ergab, man muss in der Datei /etc/default/tomcat6 der Variablen JAVA_OPTS die Angabe der lokalen Zeitzone hinzufügen. In meinem Fall war dies -Duser.timezone=Europe/Berlin. Nach anschließendem Neustart des Tomcat waren die Zeitstempel in den Log-Dateien “richtig”.

Eine Erklärung liefert Debian Bug #645221.