Daniel Biella – IT@UDE https://blogs.uni-due.de/zim ZIM - Wissen schafft IT Tue, 27 May 2014 16:23:05 +0000 de hourly 1 https://wordpress.org/?v=6.7 Integration einer Garagentorsteuerung in OpenHAB mittels Tinkerforge https://blogs.uni-due.de/zim/2014/05/27/integration-einer-garagentorsteuerung-in-openhab-mittels-tinkerforge/ Tue, 27 May 2014 16:30:50 +0000 https://blogs.uni-due.de/zim/?p=1985 Weiterlesen ]]> Während des ZIM talks über Home automation und Datenvisualisierung wies Th. Eichstädt-Engelen vom OpenHAB-Projekt auf die mittlerweile gute Unterstützung seitens OpenHAB für die Module von Tinkerforge hin.

Inspiriert von seiner Anmerkung und durch diesen Beitrag wird im Folgenden exemplarisch dargestellt, wie eine Umsetzung in OpenHAB möglich ist. Als Anwendungsbeispiel dient eine Handfernsteuerung für ein Garagentor, welche durch Tinkerforge Module physikalisch integriert und letztlich über den Bus von OpenHAB angesprochen werden soll.

Hands-on

Folgende Utensilien werden dafür benötigt:

  1. Eine bereits gepaarte Garagentorsteuerung (möglichst ein Zweitgerät, ohne Garantie). Dieses Gerät muss im Wesentlichen über einen Schalter verfügen.
  2. Tinkerforge Master Brick,
  3. Tinkerforge Industrial Quad Relay Bricklet,
  4. 2 Kabel und
  5. ein Lötkolben.

Zunächst sind auf der Platine der Fernbedienung am Schalter die beiden aktiven Anschlüsse zu identifizieren. Dies lässt sich leicht feststellen, indem man sie probeweise mit einem Kabel überbrückt. An die beiden so identifizierten Anschlüsse des Schalters wird dann je ein Kabel gelötet. (Achtung: Dies geschieht auf eigene Verantwortung! Hierdurch kann schlimmstenfalls die Fernbedienung unbrauchbar werden!) Die Enden dieser beiden Kabel werden dann einem der vier Schaltrelais auf dem Industrial Quad Relay Bricklet zugeführt (im Bild sind dies das rote und das grüne Kabel im ersten bzw. im der Kamera zugewandten Relais).

tinkerforge_setupBild: Industrial Quad Relay Bricklet, Master Brick und die Platine einer vorhandenen Fernsteuerungen

Das Industrial Quad Relay Bricklet wird am Master Brick befestigt und letzterer mittels USB angeschlossen, nämlich an den Rechner, auf dem der so genannte „Brick Daemon“ laufen muss.

Software – Brick Viewer und Brick Daemon

Zur Umsetzung ist neben OpenHAB auch Software von der Tinkerforge-Website notwendig. Zunächst wird mit dem Tinkerforge Brick Viewer die ID des Industrial Quad Relay Bricklets ausgelesen und notiert, z.B.: ifd. Diese ID wird später für die Konfiguration von OpenHAB benötigt.

Danach wird auf einem von OpenHAB erreichbaren Server der Brick Daemon installiert. Dies kann natürlich auch derselbe Server sein, auf dem OpenHAB läuft.

Konfiguration in OpenHAB

In OpenHAB wird nun zunächst die Tinkerforge Binding so konfiguriert, dass der Brick Dämon per IP auf dessen Standard-Port erreicht werden kann:

####### Tinkerforge Binding #######
tinkerforge:hosts=127.0.0.1

Listing openhab.cfg (Auszug)

Jetzt sind zwei Items zu definieren. Das erste Item (hier: QR1) repräsentiert das physikalische Tinkerforge Relais, das zweite Item Garage wird benötigt um den physikalischen Druckschalter einer Fernbedienung über den Touchscreen eines Smartphones zu simulieren. In OpenHAB wollen wir für die Nutzung von Touchscreens nur ein „button pressed“ Event auswerten, nicht aber zusätzlich ein „button released“ Event. Also wird beim Antippen des Switch-Items Garage das Relais über das Switch-Item QR1 aktiviert und nach 1,5 Sekunden – über eine Zeitverzögerung gesteuert – wieder unterbrochen. Die subid referenziert das benutzte Relais; hier ist es der erste von insgesamt vier Stück, also relay0.

/* Garage */
Switch QR1    "QR1" {tinkerforge="uid=ifd, subid=relay0"}
Switch Garage "Garage" <garagedoor>

Listing Items (Auszug)

Zur Realisierung der Aktivierung und zeitverzögerten Deaktivierung des Schalters wird noch eine Regel hinzugefügt.

rule "Garage"
when
Item Garage received command
then
QR1.sendCommand(ON)
Thread::sleep(1500)
QR1.sendCommand(OFF)
// Sure it is off? Wait...
Thread::sleep(1500)
// ...and send again...
QR1.sendCommand(OFF)
end

Listing Rules (Auszug)

Schließlich wird die interaktive Schaltfläche als Button Element in die Sitemap eingefügt.

 Switch item=Garage mappings=[ON="Door"]

Listing Sitemap (Auszug)

Für Näheres sei auf die OpenHAB-Binding-Doku zu Tinkerforge verwiesen.

Im Ergebnis zeigt das OpenHAB UI dann einen interaktiven Button, bei dessen Druck die Handfernbedienung 1,5 Sekunden lang über das Relais geschaltet wird.

tinkerforge_openhab_ui

Bild: OpenHAB UI (hier mit Button für eine Garagentorsteuerung)

Fazit

Das hier beschriebene Vorgehen ist rein experimenteller Natur und empfiehlt sich nur sehr bedingt zur Nachahmung. Eine derartige Modifikation einer Fernbedienung führt sehr wahrscheinlich zum Verlust des Garantieanspruchs! Außerdem kann eine Fernbedienung grundsätzlich beim Löten beschädigt werden. Eine derartige Schaltung (hier: Relais) kann natürlich auch über viele andere Mechanismen und dann ggf. preiswerter realisiert werden, z.B. über den GPIO-Port eines Raspberry Pi oder über Schaltkreise hinter einer seriellen Schnittstelle. Als Einstieg in die Ergänzung von OpenHAB um Tinkerforge ist eine solche Schaltung aber gut geeignet, da man sehr schnell zu Ergebnissen gelangt.

]]>
RFID/NFC-Blocker https://blogs.uni-due.de/zim/2012/06/12/rfidnfc-blocker/ https://blogs.uni-due.de/zim/2012/06/12/rfidnfc-blocker/#respond Tue, 12 Jun 2012 15:26:50 +0000 https://blogs.uni-due.de/zim/?p=1447 Weiterlesen ]]> Die Speicherung personenbezogener Daten auf Plastikkarten ist nichts Neues. Ab den 1970er Jahren gab es die ersten Kreditkarten mit Formprägungen zur mechanischen Übernahme von Kreditkartennummern auf Papierzettel – einige erinnern sich vielleicht noch an das obligatorische „ritsch-ratsch“-Geräusch bei Bezahlvorgängen mit frühen Kreditkarten. Später zogen elektromagnetische und kontaktbasierte Techniken nach. Mittlerweile ist die digitale Datenspeicherung auf Chips Standard, und es gibt hauptsächlich zwei Varianten der Datenübertragung: die kontaktgebundene und die kontaktlose. Letztere ist auch als „Radio frequency identification“ (RFID) oder „Near field communication“ (NFC) bekannt und ist u.a. durch die ISO-Normen 14443, 18000, 18092, 21481 beschrieben.

Technisch gesehen handelt es sich bei RFID-Karten zum Teil um rein passive Systeme auf denen nur Daten gespeichert werden können. Möglich sind aber auch aktive Systeme also keine reinen Speicher-Chips sondern Embedded Computer, die kontaktlos vom RFID-Lesegerät per Induktionsschleife mit Strom versorgt werden. Ein kleiner Computer auf einer RFID-Karte kann aktiv Hashwerte aus einem geheimen Schlüssel berechnen, und so moderne kryptografische Verfahren unterstützen. Passive Systeme sind trotz Verschlüsselung schon gehackt worden (link Heise myfare- hack http://www.heise.de/security/meldung/Schwaechen-des-RFID-Systems-Mifare-Classic-bestaetigt-191623.html ).

Beim Auslesen eines RFID-Modules wird Energie mittels eines Hochfrequenzfeldes auf den Chip übertragen. Der Chip erzeugt zum Antworten aber nicht etwa ein eigenes Feld sondern schwächt das Feld des Lesegerätes moduliert ab. Diese Abschwächung kann vom Lesegerät, aber auch von einem, mit einem eigenen Empfänger ausgestatteten, potentiellen Angreifer in der Nähe detektiert werden.

Bei Near Field Communication handelt es sich um eine Erweiterung dieser Technologie um die klassische Aufteilung Lesegerät und mehr oder weniger passive Chipkarte aufzubrechen. NFC-fähige Geräte wie z.B. das Samsung Nexus S, das Nexus Galaxy oder auch das neue Samsung S3 Mobiltelefon (und vermutlich auch das zukünftige iPhone 5) können Lese- und Senderolle einnehmen. Die Verschlüsselungsmöglichkeiten und die beschränkte Reichweite lassen zahlreiche Anwendungen für das mobile Bezahlen zu. Die Reichweite von NFC ist auf ca. vier Zentimeter begrenzt um sicheres Payment zu ermöglichen. Neuerdings werden auch Kreditkarten mit NFC-Chips ausgestattet (http://www.heise.de/newsticker/meldung/NFC-Kreditkarten-bereiten-den-Boden-fuer-Handy-Zahlsysteme-1586330.html). NFC ist zu RFID abwärtskompatibel, so das auch alle RFID-Karten per NFC ausgelesen werden können.

Die Vorteile von RFID sind in der Warenwirtschaft und Logistik unbestreitbar, ebenso würden auch die Autoren nur ungerne auf Komfortmerkmale wie z.B. kontaktlose Schließanlagen oder Plastikgeld an einer Kasse verzichten wollen.

Bei allen Vorteilen dieser Technik, ist leider anzumerken, dass der im Gegensatz zu mechanisch oder rein visuell basierten Datenübertragungsverfahren von einem selbst kontrollierten „Sendevorgang“, z.B. durch das freiwillige Vorzeigen einer Karte zum laser-basierten Einscannen, bei der Nutzung von RFID verändert wird in einen dauerhaften latenten „Sendevorgang“, der jederzeit durch ein Lesegerät getriggert werden kann.

RFID-Karten lassen sich aus kurzer Entfernung prinzipiell auch mit üblichen (NFC-fähigen) Smartphones auslesen. Zu solchen Karten gehört übrigens auch der neue Personalausweis (nPA/ePerso).

Ein Material, welches effektiv gegen einen ungewollten Zugriff „von außen“ hilft, ist Aluminium. Da man seinen neuen Personal- oder Dienstausweis oder eine Geldkarte nun nicht unbedingt regelmäßig wie eine Tafel Schokolade ein- und auspacken möchte, gibt es Hersteller, die praktische Schutzhüllen für RFID-basierte Karten anbieten. Wir haben eine solche RFID-Schutzhülle aus Cryptalloy® einmal getestet.

Und so sieht eine solche RFID-Schutzhülle aus:

Zunächst wurden ein Personalausweis und ein Dienstausweis ohne RFID-Schutzhülle mit Hilfe zweier Android-Apps gescannt:

Man sieht: gewisse Daten kommen an. So sollte es sein – zumindest wenn man selbst eine solche Karte benutzen möchte, z.B. weil man Zugang benötigt oder einen Kaffee in der Kantine bezahlen möchte.

Und wenn man danach eine solche Karte wieder in die Hülle zurück steckt…

…sieht man nichts mehr. Hervorragend – das ist „Safer NFC“ wie es sein sollte.

Koautor dieses Artikels ist Andreas Bischoff.

]]>
https://blogs.uni-due.de/zim/2012/06/12/rfidnfc-blocker/feed/ 0
X3DOM – 3D und HTML https://blogs.uni-due.de/zim/2011/10/19/886/ https://blogs.uni-due.de/zim/2011/10/19/886/#respond Wed, 19 Oct 2011 10:03:30 +0000 https://blogs.uni-due.de/zim/?p=886 Weiterlesen ]]> Web-basiertes 3D ist seit den 1990er-Jahren ein Thema, dennoch hat sich diese Technik seit geraumer Zeit nicht in der Fläche durchsetzen können. Die Ursachen dafür sind vielschichtig. Waren es zu Beginn der Kostenpunkt der Hardware, die aufwändige (und damit kostenintensive) Modellierung und eine hohe Gründungs- und leider auch Insolvenzfrequenz von Softwarefirmen, die Rendering engines implementierten, so gibt es mit X3D nunmehr einen Ansatz, der verspricht, ohne proprietäre 3D-Plugins und mit einer XML-basierten Beschreibungssprache, nämlich X3D, diese Technik leichter nutzbar zu machen.

X3DOM (http://www.x3dom.org/) ist ein Open Source Framework und eine Laufzeitumgebung, die es ermöglicht Elemente eines X3D-Szenegraphen in die DOM-Struktur von HTML5 zu integrieren, zu interpretieren und im Browser zu visualisieren.

Seit kurzem unterstützt sogar Firefox als gängiger mobiler Web-Browser WebGL/X3DOM.

Hier nun der 3D-Code (Anm.: falls der Browser X3DOM noch nicht beherrscht, erscheint eine Meldung):

[iframe src=“http://www.uni-due.de/zim/biella/x3demo.xhtml“ width=“100%“ height=“150″]

Im Netz finden sich für viele Browser und die jeweiligen Betriebssysteme Anleitungen, wie ggf. die WebGL-/X3DOM-Unterstützung zu aktivieren ist bzw. mit welchen Parametern ein Browser gestartet werden muss.

Übrigens wurden auch 3D-Daten von Spieleklassikern der 1990er-Jahre bereits auf WebGL portiert (http://media.tojicode.com/q3bsp/)

]]>
https://blogs.uni-due.de/zim/2011/10/19/886/feed/ 0
Mobile App & WebApp Frameworks https://blogs.uni-due.de/zim/2011/08/25/mobile-app-webapp-frameworks/ https://blogs.uni-due.de/zim/2011/08/25/mobile-app-webapp-frameworks/#respond Thu, 25 Aug 2011 19:18:31 +0000 https://blogs.uni-due.de/zim/?p=794 Weiterlesen ]]> Die Anzahl mobiler Endgeräte wächst von Tag zu Tag, und mit ihr der Ruf nach mobilen Anwendungen. Im Blog-Artikel „10 Useful Frameworks To Develop HTML-Based Webapps for Touch Devise„[sic!] stellt A. Lupetti eine Liste aktueller mobiler App- und Webapp-Frameworks vor. Die genannten Frameworks mit Touchscreen-Unterstützung lassen sich bzgl. ihrer Codegenerierung in zwei Gruppen einteilen:

  1. Cross-platform native app frameworks und
  2. Cross-platform native webkit/webapp frameworks.

Zur ersten Gruppe zählen die Werkzeuge Titanium, PhoneGap und Rhodes. Der Vorteil dieser Frameworks liegt im Bereich der nativen mobilen Anwendungen, d.h. von Binärprogrammen, die nativ auf dem Betriebssystem (oder einer sich darauf befindlichen Laufzeitumgebung) des Smartphones ausgeführt werden. Interessanterweise wird u.a. in HTML5, CSS3 und JavaScript entwickelt, bevor aus diesem Codebundle systemabhängige Binaries erzeugt werden. Je nach Framework und Smartphone-OS werden mehr oder weniger viele betriebssystemspezifische APIs unterstützt, zumeist aber mehr Ein-/Ausgabe-Schnittstellen, als die entsprechenden reinen Browser-APIs bedienen (z.B. Kamera, Accelerator, etc.). Hier lohnt sich also ein genauer Blick auf die unterstützten Features, sowohl die des jeweiligen Frameworks, wie auch die der API-Features des Smartphone-Browsers der Zielplattform.

Falls für eine Anwendung der Zugriff auf die Ein-/Ausgabe-Schnittstellen des Smartphones über dessen Browser-APIs ausreichend ist, so lässt sich eine Anwendung auch als reine Web Applikation entwickeln (so genannte WebApp). In diesem Fall übernimmt der Web-Browser des Smartphones die Ausführung und Visualisierung des Programmes. Die Entwicklung erfolgt in HTML5, CSS und JavaScript. Zu diesen Frameworks gehören SensaTouch, Sproutcore Touch, iUI, iWebkit und auch jQueryMobile.

Wie alle Cross-Platform-Ansätze, folgen auch die Frameworks dem Konzept „Code once, deploy many“ und sind daher für Softwareprojekte interessant, die eine möglichst große Breite von mobilen Endgeräteplattformen mit Touch-Unterstützung bedienen wollen bzw. sich diese Flexibilität erhalten möchten.

Fazit: Da sich der Markt für mobile Endgeräte und Smartphone-OS auch im Jahre 2011 noch in einer eher als dynamisch zu bezeichnenden Phase befindet, macht es durchaus Sinn, sich für Softwareprojekte beide Gruppen der Cross-Platform-Frameworks für mobile berührungsgesteuerte Endgeräte einmal anzuschauen.

]]>
https://blogs.uni-due.de/zim/2011/08/25/mobile-app-webapp-frameworks/feed/ 0