Anruferliste mit dem Raspberry Pi

Nachfolgend möchte ich erklären, wie wir unseren Raspberry Pi dazu verwenden können eine Anruferliste anzulegen.
Wir möchten bei einem eingehenden Anruf das Signal erkennen, die Rufnummer auslesen und in einem eigenen Script verarbeiten.

Dazu benötigen wir folgende Hardware:

  • Anschluss für Telefon
    (i.d.R. am Router)
  • USB-Modem (bspw. dieses)
  • T-Stück (bspw. dieses)
  • Raspberry Pi

Anschluss des Modems

Das Modem schließen wir via USB am Raspberry an und ermitteln welchem Stream wir in unserem Script „lauschen“ müssen:

ls -laGh /dev/serial/by-id/

Für uns interessant ist das Ziel des Alias. Merken!

Das Modem müssen wir noch mit der Telefondose / dem Router verbinden.
Um zeitgleich ein analoges Telefon und das Modem „klingeln“ zu lassen, benötigen wir das T-Stück, um aus einem Anschluss zwei Anschlüsse zu machen.

Das Script

#!/bin/sh
# V0.1

echo "AT+VCID=1" > /dev/ttyACM0
while read line; do
  echo "Input $line"
done </dev/ttyACM0

Wir sehen, dass wir im Script an zwei Stellen das Ziel des Alias eintragen.

Mit AT+VCID=1 teilen wir dem Modem mit, dass wir an Informationen wie der Telefonnummer des Anrufers interessiert sind.
Anschließend lauschen wir auf dem Stream nach hereinkommenden Infomationen und geben diese Zeilenweise aus.

An Stelle des echo-Befehls können wir nun jede eigene Programmlogik implementieren, oder die Rufnummer an ein anderes Programm weiterleiten.

Starten wir das Script, erhalten wir folgende Ausgabe:

Rückgabe des Scriptes

Erweitern wir unser Script, so dass wir nur die Telefonnummer auslesen.

#!/bin/sh
# V0.1

### FUNCTIONS

# isnmbrline(string, substring)
#
# Returns 0 if the specified string contains the specified substring,
# otherwise returns 1.

isnmbrline() {
    string="$1"
    substring="$2"
    if test "${string#*$substring}" != "$string"
    then
        return 0    # $substring is in $string
    else
        return 1    # $substring is not in $string
    fi
}

### PROGRAMM
streamSrc="/dev/ttyACM0"
echo "Source: $streamSrc"

echo "AT+VCID=1" > $streamSrc

while read line; do
    #callTimestamp=$(date "+%Y-%m-%d %H:%M:%S")
    isnmbrline "$line" "NMBR" && echo "$line"
done <$streamSrc

Ergebnis

Anstelle der Ausgabe in eine Logdatei, können wir auch eine Datenbank befüllen oder die Rufnummer auf anderem Wege weiterverarbeiten.
In dieser Anleitung haben wir die Logdatei gewählt.

Beispielhaft mit Logtastic angezeigt, sehen wir nachfolgend die via Skript gefüllte Anruferliste.
Bestimmte Rufnummern werden hervorgehoben und die Länderrufnummer ausgegraut dargestellt.

Anruferliste

Anmerkungen

Die Befehle und Ausgaben der verschiedenen Modems können variieren.
Hier ist eine Übersicht zu finden, die als erster Startpunkt dient:
https://de.wikipedia.org/wiki/AT-Befehlssatz
http://www.tcp-ip-info.de/tcp_ip_und_internet/hayes-befehle.htm

Detailliertere Informationen, befürchte ich, müssen der Dokumentation des Modems entnommen werden, sofern es diese mit entsprechender Detailtiefe überhaupt gibt.

Lichtschalter in der Tasche

 : „Jetzt hier drücken, um das Licht anzuschalten.“
 : „Ja, mein Meister.“

Soll uns das Haus vorschreiben, wie wir das Licht anzuschalten haben oder sollte es nicht andersrum sein? Sollten wir nicht dem Haus mitteilen, was zu tun ist?
Ich sage: auch das ist nicht der ideale Weg.

Schauen wir uns die aktuelle Lage auf dem Hausautomatisierungsmarkt an, merken wir schnell, dass wir das Anknipsen des Lichtes lediglich auf das Telefon oder Tablet verlagert haben. Der Lichtschalter ist an eine andere Stelle gerückt.
Ich finde es wenig praktikabel das Telefon aus der Tasche holen zu müssen, bevor mir ein Licht aufgeht.
Lichtschalter und die Lampe dienen hier lediglich als Platzhalter und können auch durch Thermostat und Heizkörper ersetzt werden.

So kommen wir zum Kern der Einleitung: der Begriff Hausautomatisierung suggeriert, dass das Haus selbstständig „Entscheidungen trifft“ – ohne manuelles Eingreifen seiner Bewohner.
Und somit sollte das System uns keine Aktionen aufdrücken und im Idealfall ist kein manuelles Eingreifen durch den Hausbewohner erforderlich, da das Haus weiß (genauer: lernt), in welchem Raum das Licht aktiviert, welcher Raum zu welcher Tageszeit wie geheizt und wann morgens der Kaffee gekocht werden soll.

Wie weit wir diesen Gedanken treiben wollen bleibt zum Einen jedem selbst überlassen, zum Anderen den verfügbaren Technologien und Softwarelösungen.
Wir müssen uns bewusst machen: je mehr Elektronik wir uns in die eigenen vier Wände holen, desto größer die Gefahr unsere Gewohnheiten und Lebensstile unbewusst einem oder mehreren Unternehmen zur Verfügung zu stellen, die sicher nicht nur Gutes damit anstellen.

Der wichtigste – und darum zum Schluss genannte – zu bedenkende Punkt: Sicherheit.
Viele Hersteller haben diesen Gedanken bisher vernachlässigt.
Doch selbst wenn bspw. Funkkomponenten ihre Inhalte verschlüsselt übertragen, lassen sich diese abfangen und so können Einbrecher ermitteln zu welcher Tageszeit ein Haus in der Regel unbewohnt ist.

Unabhängig davon, wie stark wir unser Haus automatisieren und ihm „Intelligenz verleihen“, müssen wir aufpassen am Ende nicht mehr Zeit mit der Konfiguration und Benutzung der vielen neuen Möglichkeiten zu verbringen, als wir eigentlich einsparen wollten.
Einen dazu passenden Beitrag haben wir hier bereits veröffentlicht und ebenfalls lesenswert ist dieser Artikel auf futurezone.at.

Es gibt für alles eine App

Application OverloadNahezu täglich erscheint ein neuer Hersteller mit einem interessanten Gadget, das uns das Leben erleichtern, oder zumindest angenehmer gestallten soll.

So weit so gut. Doch die Sache hat einen Haken – zumindest für mich:
Apps, Apps, Apps. Jedes neue Gadget, sei es eine Glühbirne, eine Pfanne oder die Heizungssteuerung, kommen mit einer eigenen Smartphone-App umher.
Dies führt zu einer enormen Anzahl an Apps auf dem eigenen Handy, an dessen regelmäßiger Ausführung ich starke Zweifel hege.

Das Problem sehe ich nicht bei der App, die auf das Gadget zugeschnitten ist, sondern in der oftmals fehlenden offenen Schnittstelle am Gadget selbst, mit der andere Entwickler/Hersteller diese Geräte in einem großen Konzept vereinen können.
Wäre es nicht wünschenswert mit dem Schalter von Hersteller A die Lampe von Hersteller B schalten zu können?
Ansätze dafür gibt es – auch sind die ersten Produkte bereits auf dem Markt. Dennoch sehe ich bei vielen Herstellern Nachholbedarf.

Dem unbedarften Kunden entgehen viele spannende Möglichkeiten. Denn sind Schnittstellen gegeben, werden Entwickler und Bastler kreativ und spannende Ideen entwickeln sich.

Metadaten von Funksignalen Sicherheitsrisiko

In dem unten verlinkten Beitrag wird angeführt, dass sich Signale von via Funk kommunizierenden Devices abfangen und auf diesem Wege Profile erstellen lassen.
Einbrecher können so ermitteln, wann die Bewohner für gewöhnlich zu Hause sind und entsprechend ihren Einbruch planen.

Die Signale zu verschlüsseln wird da nicht ausreichen. Verschlüsselt lassen sich zwar die Informationen nicht auslesen, dennoch werden die Daten gesendet, was nach wie vor abgefangen werden kann.

Auf Sicherheitslücken in ins lokale Netzwerk eingebundenen Devices gehen wir ein anderes Mal ein. Denn auch dort gibt es Einiges zu beachten.

Weitere Informationen: www.itespresso.de

Twine: guter Ansatz, aber dann!

Twine Dashboard

Kennt ihr Twine?
Ein kleines Device (@Supermechanical | https://twine.cc) mit ein paar coolen Ansätzen.
Auf ganzer Linie überzeugt es mich leider nicht.

Aber erst einmal kurz erklärt, worum es geht:
Twine ist eine kleine Einheit, an das verschiedene Sensoren angeschlossen werden können:
– Magnetsensor
– Feuchtigkeitssensor
– Relais, für eigene Anwendungsfälle

Zudem sind im Gerät bereits ein guter und sensibler Bewegungssensor, ein Sensor für die Ausrichtung des Twines, sowie ein Temperaturfühler integriert.

Während der Erst-Installation des Gerätes, welche ich sehr smart fand, merkt man aber schnell einen enormen Nachteil: Es ist zwingend ein Account beim Hersteller nötig.

Auf der Webseite kann man Aktionen für die Wertänderungen eintragen, die dann unmittelbar ausgeführt werden.
Möglich sind u.A. der Versand einer E-Mail, das Absetzen eines Tweets, oder der aufruf einer individuell einstellbaren URL. So weit so gut.

Doch selbst wenn man über den Account-Zwang noch hinwegsehen könnte, läuft auch ansonsten nichts ohne des Herstellers Webservice. Es gibt keine Möglichkeit auf Werte, oder gar Wertänderungen, des Devices direkt zuzugreifen.
Hätte das Gerät eine Schnittstelle, die man im hauseigenen Netzwerk direkt ansprechen könnte, wäre das Twine um ein Vielfaches interessanter – oder, ich würde sogar soweit gehen: erst sinnvoll einsetzbar.

Persönliches Fazit: für den Preis … Finger weg und eine, wenn auch etwas teurere, flexiblere Lösung suchen.

Dennoch ein paar Anwendungsbeispiele:
– Benachrichtigung, wenn die Waschmaschine, oder der Trockner fertig sind.
– Meldung bei geöffneter Tür, Katzenklappe, Briefkasten, …
– Warnung, wenn Wasser im Keller eindringt.

HomeKit vorgestellt! Und nun?

Apple HomeKit

Nach der Vorstellung von Apples HomeKit auf seiner Keynote der WWDC2014 liegt es nun an den Herstellern, dieses in ihre Produkte einzubinden und somit den Weg für eine standardisierte Kommunikation zwischen Mobiltelefon und Tablet und den Geräten im Haus zu ebnen.

Dies soll ebenfalls den Wildwuchs an unzähligen Drittanbieter-Apps eindämmen. Bisher hat jeder Hersteller seine eigene App bereitgestellt und hat der Anwender bspw. Heizungsthermostate von zwei unterschiedlichen Herstellern, war er auch auf zwei Apps angewiesen.

Zukünftig soll es möglich sein, mehrere einzelne Aktionen zu bündeln – so genannte Szenarien. Beim Kino-Szenario werden bspw. die Rolladen etwas herabgelassen und der Fernseher automatisch eingeschaltet.

Da die Kommunikation über Apples Schnittstelle läuft, soll die Steuerung auch per Siri funktionieren.
Der Anwender kann somit „Ich möchte einen Film schauen“ in sein Telefon sprechen und dieses koordiniert die nötigen Aktionen.

Wie diese Szenarien und Aktionen konfiguriert und mit entsprechenden Sprachbefehlen verknüpft werden, ist noch unklar – wird sich aber wohl in den nächsten Monaten klären, wenn die ersten Entwickler die Beta-Versionen aufgespielt und mit dem Entwickeln und Testen begonnen haben.

Nachfolgend eine Liste der Hersteller, die auf der Keynote als Partner genannt wurden – es dürften schon in Kürze weitere folgen:
– www.idevicesinc.com
– www.ihomeaudiointl.com
– www.sylvania.com
– www.cree.com
– www.chamberlain.de
– www.skybell.com
– www.august.com
– www.honeywell.de
– www.haier.com/de/
– www.schlage.com
– www.lighting.philips.com/main/subsites/dynalite/projects/smart_home/
– www.kwikset.com
– www.broadcom.com
– www.netatmo.com

Apple Keynote – der Einstieg ins SmartHome-Geschäft?

Heute Abend 19 Uhr, unserer Zeit, findet auf der jährlich stattfindenden Entwicklerkonferenz WWDC in Cupertino die Keynote statt, bei der Apple neue Produkte und Dienstleistungen vorstellt.
Den Gerüchten der letzten Wochen nach, könnte es auch Neuigkeiten zum Thema Hausautomation geben.
Bisher nur ein Gerücht. Allerdings hat Apple im letzten Quartal 2013 ein entsprechendes Patent angemeldet. Hierbei handelt es sich um ein Verfahren, bei dem der iPhone-Benutzer in seinem Haus geortet werden kann und dann, abhängig von Position, verschiedene Aktionen ausgeführt werden können.

Persönlich kann ich mir nicht vorstellen, dass Apple selbst Bauteile für die Hausautomation bereit stellt. Allerdings könnte Apple versuchen einen Standard für die Kommunikation der Komponenten verschiedener Hersteller untereinander etablieren.
Dies wäre phantastisch, sofern die Hersteller mitziehen. Wir kennen bereits aus der Vergangenheit Beispiele, bei denen Apple sich nicht durchsetzen konnte, obwohl die Technik nachweislich besser war – bspw. FireWire und aktuell Thunderbold und auch Quicktime.

In einigen Stunden wissen wir mehr.


EDIT:
Soeben ist die WWDC-Keynote beendet.
Es ist, wie vermutet. Apple kümmert sich, mit bekannten Herstellern im Boot, um einen Standard.

Hausautomation mit unzähligen Kippschaltern

Schaltzentrale

Die Anzahl der Werbeanzeigen zum Thema „Hausautomation“ im TV und Print sind in den letzten Monaten stark angestiegen.
Wie ich finde, entwickelt sich dies – zumindest derzeit noch – in die falsche Richtung.
Lösungen, vor allem diese für den Konsumer mit kleinem Geldbeutel, basieren häufig auf bspw. einem Heizkörperthermostat und einer Handy-App.
Bleiben wir bei diesem Beispiel – selbstverständlich ist dieses Thema viel viel weitreichender.

Stelle ich mir dieses Szenario einmal vor:
Schritt 1: Mobiltelefon in die Hand nehmen
Schritt 2: Entsperren
Schritt 3: App öffnen
Schritt 4: entsprechenden Heizkörper auswählen
Schritt 5: neuen Wert setzen u. bestätigen
Schritt 6: App schließen

Dieses Szenario werde ich öfters bei der Vorstellung gegenüber Freunden in geselliger Runde durchführen, als im eigentlichen Alltag.

Mein Verständnis von Hausautomation, oder Smart-House, geht in eine andere Richtung: Dass ich selbst eben keine Aktionen ausführen muss. Das Haus, bzw. die Wohnung sollte autonom entscheiden, was zu tun ist.
Selbstverständlich in einmalig bei der Installation festgelegten Szenarien.

In der Regel sind meine „Zu-Hause“-Zeiten ähnlich, so dass ich die Wohnung bspw. wochentags erst ab 16 Uhr heizen muss. Selbst wenn ich an einem Tag erst gegen 19 Uhr daheim bin, rechtfertigt dies noch keine Fernsteuerung.
(Urlaube sind an dieser Stelle als ein weiteres Szenario zu sehen.)

Öffne ich ein Fenster, sollten alle Heizkörper in diesem Raum automatisch aufhören zu heizen und ebenfalls automatisch wieder starten, sobald das Fenster wieder geschlossen ist.

Zusammenfassend ausgedrückt:
Im Idealfall bedarf es eben keiner zu betätigenden Schalter, Hebel und Tasten durch den Anwender.
Bei der Hausautomation sollten Szenarien automatisch verarbeitet werden und die Eingabe nicht einfach von einem Gerät, wie einem Heizungsthermostat, auf das Handy oder Tablet verlagert werden.