Digitalstrom in die Wohnung gelegt

Licht aus, Heizung an, auf zentralen Überwachungs-Bildschirmen die Wohnung steuern – das ist Hausautomation. Meine Installation beschreibe ich hier.

Vier Konzepte

Irgendwie müssen die Leuchten und Schalter und Antriebe und Melder verbunden werden. Im Idealfall so, dass von einem Punkt alles eingestellt wird, aber auch jeder Raum für sich alleine werkeln kann. Für die Datenübertragung gibt es vier Konzepte:

  • Zentral zusammenlaufende Leitungen kommen ohne Datenbus aus. Meist geht von jeder Leuchte ein Kabel in den Sicherungskasten, der sogenannten Unterverteilung. Zu den Schaltern führen Klingeldrähte. In den Plattenbauten der DDR waren solche Systeme schon vor Jahrzehnten Standard. Für Erweiterungen werden allerdings ungenutzte Leitungen, Leerrohre oder Zwischendecken benötigt. Mit KNX wird heute noch im Grunde genau so gearbeitet. Um die komplette Schaltungstechnik zu ersetzen, reicht es nämlich, am Sicherungskasten zu schrauben. Flexibler geht es kaum.
  • Datenkabel parallel zu allen Stromkabeln zu ziehen ist das übliche Verfahren in großen Neubauten. Dadurch lassen sich hohe Datenmengen zuverlässig verteilen, etwa um in hunderten Räumen Klimadaten bereitzustellen und abzufragen. Allerdings kann so ein RS485-Bus überall und sogar ungewollt gestört werden. Und dann geht oft im ganzen Haus nichts mehr.
  • Funkverbindungen klingen erst einmal toll. Neben der offensichtlichen Störanfälligkeit haben die aktuellen Systeme noch ein größeres Problem: In den kleinen Controllern ist es heute noch gar nicht möglich, ordentliche Kryptographie zu implementieren. Daher gibt es noch keinen Anbieter, dessen System nicht schon umfangreich von außen manipuliert wurde. Schlimmer noch, wegen Programmierfehlern halten nicht einmal die Zentralen Angriffen über Funk stand.
  • Powerline heißt, die Daten werden über Stromkabel transportiert. Die Abstrahlung ist gering, und zum Stören muss man im selben Raum sein. An den Sicherungen werden die Daten auf einen anderen Bus wie RS485 umgesetzt. Die Installation geht damit auch im Altbau. Leider gibt es für dieses Konzept nur einen Anbieter, nämlich Digitalstrom.

Marketing-Sprech

Digitalstrom weckt erst einmal einen schlechten Eindruck: Das Marketing schreibt hauptsächlich Unsinn. Die Hardware wäre Open Source. Leider stimmt das nicht, sie ist sogar patentiert. Auch die Software ist nicht frei, nicht mal verfügbar. Lediglich für den zentralen Server ist die Firmware offen. Aber auch nur zum Teil, denn nicht mal die Dokumentation darf verbessert werden.

Die Prospekte meinen auch, Digitalstrom wäre für Dritt-Anbieter nützlich. Von denen wird aber verlangt, die Original-„Modems“ von Digitalstrom einzubauen. In diese Abhängigkeit begibt sich natürlich kein Hersteller.

Powerline

Das Marketing versucht mit allen Mitteln, den gebrandmarkten Begriff Powerline zu vermeiden. Statt dessen ist von Modifikationen der Sinus-Welle die Rede. Ich habe den Support darauf angesprochen und versucht, die ausgehenden Störungen und das Spektrum der Oberwellen zu erfahren. Auch hier wurde nur gemauert.

Dass Digitalstrom so niederfrequent sendet wie behauptet, kann ich mir nicht vorstellen. Irgendwann werde ich das mal messen. Auch ob der zentrale Filter nur die verwendeten Frequenzen von Störungen frei hält oder wirklich das Signal blockiert, ist mir unklar.

Die Software-Dokumentation spricht ganz selbstverständlich von Powerline, erklärt aber natürlich die Spektren nicht.

Ich könnte mir vorstellen, dass Digitalstrom-Kabel erheblich abstrahlen und auch der Filter nicht das volle Spektrum der Störungen absaugt. Für die Funktionsfähigkeit von Digitalstrom reicht es schließlich, wenn der Filter nur die Frequenzen entstört, auf denen die Empfänger empfindlich sind und weitere Aussendungen geschehen lässt. Das hieße, dass Digitalstrom mit seiner riesigen Antenne ein Störsender und eine Datenschleuder ist.

Installation

Die Hardware einzubauen funktionierte bei mir perfekt. Die Anleitungen sind kurz und aus Elektriker-Sicht ausreichend. Die Gehäuse haben eine gute Qualität. Sowohl im Sicherungskasten als auch in den Leuchten und Lichtschaltern gab es keine Probleme.

Im Bad ließ sich das Licht nur aus-, aber nicht einschalten. Vom Server aus ging die Beleuchtung problemlos. Das Problem war, dass der Taster seinen Strom von der Leuchte bekam und bei ausgeschalteter Beleuchtung tot war. Mehr Fehlersuche gab es nicht. Digitalstrom funktioniert seit Jahren zuverlässig.

Leider musste schließlich doch wieder alles auseinander gebaut werden, siehe Abschnitt Qualitäts-Probleme.

Konzept mit Räumen und Szenen

Bei der Konfiguration von Digitalstrom ist die wichtigste Gruppierung von Geräten der Raum, englisch zone. Die Installation wird also zuerst in Räume unterteilt. Da die meisten Befehle nur innerhalb von Räumen relevant sind, ist diese Aufteilung für die Einsparung von Traffic, Steigerung der Zuverlässigkeit und die Übersichtlichkeit eine super Sache.

Dann wurde allerdings der Fehler gemacht, für die Räume verschiedene Szenen vorzusehen. Aus – Gemütlich – Essen – Fernsehen. So ein Konzept mag im Theater funktionieren, für flexibel genutzte Räume ergeben Szenen keinen Sinn. Digitalstrom versucht als Notbehelf, kleine Bereiche in Räumen zu schaffen und Gruppen über mehrere Räume zu definieren. Auch das klappt nicht. Selbst für die Beispiel-Installation im Handbuch erfüllten die Vorschläge, wie Bereiche genutzt werden können, nicht die selbst gegebenen Anforderungen.

Digitalstrom hätte lieber kleine Logiken erlauben sollen: „Wenn Essen und Lesen aktiv ist, mach den Tisch und das Sofa hell.“ Als Notbehelf kann man bei Digitalstrom jede denkbare Logik als App in den Server programmieren. Damit macht man sich allerdings vom Server abhängig, verursacht erheblichen Traffic und schafft einen Fremdkörper, mit dem andere Steuerungen wiederum schlecht zusammenarbeiten.

Konfiguration

Der Server im Sicherungskasten steckt per Ethernet am Switch. Der Webserver zur Konfiguration ist sofort per HTTPS erreichbar. Zur Kontrolle, ob mein Rechner wirklich mit dem Server verbunden ist, erwarte ich, dass irgendwo der SSL-Fingerprint abgedruckt ist. Das war aber nicht der Fall. Statt dessen empfiehlt das Handbuch, gar nicht weiter darauf zu achten, ob man wirklich mit dem Server verbunden ist. Zuverlässigkeit geht anders, so ergibt HTTPS keinen Sinn.

Die Web-Oberfläche ist mäßig hässlich. Das Konzept ist anfangs schwer zu begreifen. Nach der Einarbeitung geht die Bedienung allerdings erstaunlich gut. Es ist nicht gerade offensichtlich, welchen Datenstand man gerade bearbeitet und wie aktuell die angezeigten Werte sind.

Schön ist auf jeden Fall, dass die Einstellungen direkt in den Geräten landen. Wenn der Server und die Hälfte der Räume ausfallen, arbeitet die andere Hälfte weiterhin.

Zur Liste der softwareseitigen Zuverlässigkeits-Probleme gehört, dass die Konfiguration-Seite unnötigerweise Flash enthält.

Bedienung

An den Lichtschaltern funktioniert die Bedienung perfekt, wenn man mit den Szenen auskommt. Die Apps sehen aus wie eine selbstgebastelte Katastrophe. Sie sind nicht zu gebrauchen, aber auch nicht nötig. Schlimmer und für ein angeblich benutzerfertiges Komplettsystem unakzeptabel ist, dass eine Web-Oberfläche fürs Tägliche fehlt. Ohne weiterer Installationen sollte man mit dem Handy die Wohnung steuern können.

Erstaunlich gut und halbwegs brauchbar dokumentiert ist allerdings die JSon-API vom Server. Darüber lassen sich Oberflächen selbst bauen, zum Beispiel Bedienpanel oder schicke Webseiten fürs Handy. Zu meinen Problemen damit gehört:

  • Zur Kontrolle der SSL-Fingerprints gibt es keine Hilfestellung.
  • Keine Verschlüsselung der jSon-Daten innerhalb der HTTP-Verbindung.
  • Keine Websockets oder andere asynchrone Kommunikation dokumentiert, Daten können also nur per Polling aktuell gehalten werden.
  • Keine Benutzerverwaltung dokumentiert, jeder kann unbeabsichtigt Geräte für zigtausend Euro zerstören.
  • Die API sendet Cross-Domain Cookies.
  • Session läuft nach Untätigkeit oder Netzwerk-Disconnect ab und muss per Login neu aufgebaut werden.

Qualitäts-Probleme

Direkt nach der Montage stellte sich heraus, dass manche gelben „Lüsterklemmen“ von Digitalstrom wahnsinnig brummen. Nicht nur, wenn man das Ohr ranhält, nicht nur, wenn man das Ohr an den Schalter mit der Klemme dahinter hält, nicht nur, wenn man ruhig sitzt. Das stört schon auf einige Meter Entfernung beim Betreten des Raumes. Ich verstehe nicht, wie solche Krachteile durch die Qualitätskontrolle kommen konnten. Gerade da das Brumm-Problem seit Jahren am Image von Digitalstrom nagt.

Nach einigen Tests war klar: Alle Leistungsschalter brummen, auch die Tast-Dimmer in den Wänden und die Schnurdimmer. Wirklich übel sind aber nur die sechs Lüsterklemmen. Ein Anruf beim Hersteller ergab, dass das Problem doch eigentlich längst behoben ist. Unkompliziert bekam ich einen Satz Tasterklemmen GE-TKM210 in einer neuen Bauform und Lichtklemmen GE-KM200. Sie hatten den selben Fehler. Nach der zweiten Reklamation machte ich mich auf Fehlersuche. Wenn man die Tastklemmen zusammendrückt, werden manche leiser. Die neuen Gehäuse sind also auch wieder Fehlkonstruktionen, und schlimmer, sie werden vom Werk nicht geprüft. Digitalstrom brummt weiterhin durch Unterputz-Taster und Einbauleuchten.

Auth-Problem

Es gibt kein Rechte-Management bei der jSon-API, keine Benutzerverwaltung im Server. Angeschlossene Touch-Displays und verbundene Automations-Systeme müssen alle Admin-Zugang bekommen. Auch die offiziellen Digitalstrom-Apps für Mitarbeiter oder die Famile sind betroffen. Das Passwort wird mit schwacher Verschlüsselung zum Server übertragen. Ob überhaupt mit dem Server kommuniziert wird, ist nicht prüfbar, da der Fingerprint unbekannt bleibt. Digitalstrom hätte z.B. eine schnelle symmetrische Verschlüsselung für jeden Token innerhalb der HTTP-Verbindung einbauen können, das wurde versäumt. Alleine durch diesen Mangel kann Digitalstrom nicht als zuverlässige Hausautomation betrachtet werden.

Empfehlung?

Bei mir funktioniert Digitalstrom zuverlässig. Die Flexibilität ist grandios, dass an jeder Stelle mit Stromanschluss ein Lichtschalter oder eine Leuchte installiert werden kann. Der Server wird im Betrieb nicht zwingend gebraucht, und selbst wenn komplette Räume ausfallen, lässt sich der Rest weiter bedienen. Ein schlechtes Gefühl habe ich bei der Internet-Anbindung des Servers und der Abstrahlung/Abschottung der Leitungen. Zu beidem gibt es keine belastbaren Tests.

Um sich langfristig auf die Verfügbarkeit Digitalstrom zu verlassen, wäre ein breiteres Angebot von unabhängigen Herstellern notwendig. Fünfstellige Summen würde ich wegen dieser Unsicherheit nicht in das System stecken. Für meine kleine Wohnung gehe ich das Risiko von gut 2000 Euro ein.

Die erschreckenden Sicherheitsprobleme vom Server zeugen von mangeldem Qualitätsanspruch. Bastler können damit leben. Einen fremden Kunden würde ich vor der ungewissen Zuverlässigkeit von Digitalstrom warnen.

Bei umfangreichen Sanierungen und Neubau werden die Leitungen so verlegt, wie es die geplante Hausautomation braucht. Sich hier auf Digitalstrom zu setzen, stellt ein Risiko dar, denn keine andere Hausautomation braucht genau so eine Verkabelung wie Digitalstrom. Eine Installation von KNX ist wesentlich flexibler, wenn Hersteller gewechselt werden. Oder es werden alle Leitungen in Rohren zur Unterverteilung gelegt, dann können sowohl KNX als auch Digitalstrom eingesetzt werden.

Morsen mit Stützrädern

Morsen habe ich mal gelernt, habe es dann wieder vergessen, habe es wieder gelernt, wieder vergessen, und dann das gleiche noch ein drittes Mal. Es ist nicht so schwierig, sich ein paar Wochen täglich hinzusetzen und das Gehör zu trainieren, möglichst schnell und fehlerfrei die Zeichen zu erkennen. Nur hält der Erfolg ohne regelmäßiger Praxis nicht lange an.

Beim vierten Anlauf gehe ich dank moderner Technik einen anderen Weg: Ich starte direkt mit den realen Funkverbindungen, bis zu denen ich es bei den bisherigen Anläufen nie geschafft habe. Zur Unterstützung schließe ich einen Rechner ans Funkgerät an, der alle empfangenen Zeichen anzeigt, und in den ich meine Antworten direkt eintippe. Wenn ich ein Zeichen nicht schnell genug verstehe, ist das nicht schlimm, denn der Computer schreibt mit. Das Gehör wird gleichzeitig trotzdem geschult.

Zur Abwicklung der Verbindungen verwende ich das bewährte Programm fldigi von W1HJK. Seit 2014 hat es einen Bayesischen Morse-Decoder von AG1LE.

Am Rechner steckt ein Sound-Adapter mit USB-Anschluss. Fldigi verwendet Line In zum Decodieren und sendet zum Senden einen Sinus an Line Out, hier ist nicht einmal eine besondere Konfiguration nötig.

Schaltplan

Schaltplan im Gschem-Format

An den Sound-Adapter habe ich einen Adapter zum Funkgerät angeschlossen, der von N4SPP sehr gut dokumentiert wurde. Zur galvanischen Trennung gibt es zwei Übertrager: Das empfangene Signal geht durch einen 1:1 Übertrager SV1-500A direkt an den Soundchip. Der Morsetasten-Sinus von fldigi geht durch einen 1:2 Übertrager SV1-501A, der die Spannung verdoppelt.

Hinter dem Übertrager laden zwei Schottky-Dioden 1N5711 die 470nF-Kondensatoren auf. Der 10nF nimmt vielleicht etwas HF aus dem Signal.

Weiter geht es mit den Widerständen. N4SPP schlägt hier zweimal 10k vor. Ich habe den oberen 10k durch 1k5 ersetzt, um eine höhere Spannung an der Transistor-Basis zu bekommen.

Die beiden Dioden 1N914 dienen nur dem Schutz des Transistors und spielen im normalen Betrieb keine Rolle. Der Transistor 2N2222A ist sehr robust, hat aber eine geringe Stromverstärkung. An der Basis konnte ich nur 0,5V bei voll aufgedrehtem Sound-Ausgang messen. Wenigstens ist diese Spannung relativ unabhängig von der Frequenz und auch noch fast genau so hoch, wenn nur ein Kanal den Sinus sendet.

Der Ausgang ist ein offener Kollektor. Eigentlich alle Funkgeräte haben am Eingang für die Morsetaste eine Spannung von um die +5V. Sobald ein Strom fließt, also die Taste gedrückt ist, beginnen sie zu senden.

Diese Schaltung sollte also mit allen Funkgeräten funktionieren und tat es auch mit meinen auf 40m und 20m.

Raspberry Pi zur Anzeige von Bildern und Webseiten

Der Mini-Computer Raspberry Pi ist stromsparend und billig. Zum Surfen reicht die CPU nicht, aber selbstgebaute Webseiten können so einfach gehalten werden, dass sie sich anzeigen lassen und für einen digitalen Bilderrahmen funktionieren. Wird eine Maus oder ein Touch-Screen angeschlossen, sind Links zu weiterführenden Informationen möglich. Dieser Artikel gilt sowohl für den Raspberry Pi 1 als auch 2, denn das Betriebssystem Raspbian ist bei beiden identisch.

Betriebssystem

Zuerst wird das Standard-Betriebssystem Raspbian heruntergeladen und installiert. Raspbian ist weit verbreitet und perfekt dokumentiert. Zum Beispiel funktionieren viele Touchscreens ohne weiterer Einrichtung.

SSH-Server

Der SSH-Server ist schon installiert. Damit lassen sich übers Netzwerk Datei-Transfers und eine Konsole nutzen. Wegen dieser Schnittstelle sollte mit passwd das Passwort des Benutzers pi geändert werden. Der Root-User hat kein Passwort, mit ihm kann man sich nicht anmelden. Wer einen öffentlichen SSH-Key hat, kopiert ihn in /home/pi/.ssh/authorized_keys. Dann ist der Login ganz ohne Passwort möglich.

Display

Nach der Wahl der grafischen Oberfläche bei der Installation hat der Bildschirm aus dubiosen Gründen schwarze Ränder. Deshalb wird ein Terminal geöffnet und in einer Konfigurations-Datei eine Zeile aktiviert:

sudo nano /boot/config.txt
disable_overscan=1

Da wir Fotos anzeigen wollen und dafür HDMI mit 24bit Farbtiefe wollen und nicht die krisseligen voreingestellten 16bit, geben wir auch das ein und zwingen die Ausgabe nebenbei noch zu Full HD.

hdmi_group=2 DMT
hdmi_mode=82 1080p, 60Hz
framebuffer_depth=24

Bildschirmschoner

Um den Bildschirmschoner zu deaktivieren, habe ich ein Konfigurations-Tool installiert, gestartet und die Einstellung vorgenommen.

sudo apt-get install xscreensaver
xscreensaver

Webserver

Wenn die Webseite direkt auf dem Raspberry Pi gespeichert werden soll, bietet es sich an, einen kleinen Webserver zu installieren. Anschließend werden HTML-Dateien, Bilder und so weiter in /var/www gespeichert.

sudo apt-get install lighttpd
sudo chown pi:pi /var/www

Browser

Etwas komplizierter ist die Installation eines Browsers, der ausreichend schnell ist und im Vollbild arbeitet. Chromium ist gut geeignet.

sudo apt-get install chromium-browser

Man muss sich einmal abmelden und zum Window-Manager LXDE wechseln. Denn in dessen Start-Script werden zwei Befehle angehängt. Der erste sagt Chromium, er soll nicht meckern, wenn er nicht ordentlich heruntergefahren wurde. Der zweite startet den Browser. Kiosk-Modus bedeutet dabei, dass man die Benutzer mit der Maus oder dem Touchscreen wirklich alleine lassen kann. Ohne Tastatur lässt sich Chromium nicht beenden.

sudo nano /etc/xdg/lxsession/LXDE/autostart
@sed -i -e 's/"exited_cleanly": false/"exited_cleanly": true/g' /home/pi/.config/chromium/Default/Preference
@chromium-browser --kiosk http://localhost

Fazit

Der Raspberry Pi lässt sich für eine riesige Palette an Aufgaben einsetzen. Trotzdem ist es erstaunlich, mit wie wenig Handgriffen dieses Problem solide gelöst werden kann, als ob Raspbian extra dafür geschaffen wäre. Nebenbei steht die komplette Hard- und Software zur Verfügung, um bei Bedarf in jede Richtung Erweiterungen zu schaffen.

Synthese von Morse-Zeichen im Browser mit morseSynth

Die Geschichte des Telegrafie-Unterrichts ist so lang wie die des Morse-Codes. Im 19. Jahrhundert prägten sich die Telegrafisten die Bilder für jedes einzelne Morsezeichen ein. „·−“ hieß A, „’−···“ war ein B. Die Zeichen wurden auf eine schmale Rolle Papier gedruckt. Schnell wurde klar, dass der Melodie des Druckers zu hören viel einfacher war, als Punkte und Striche abzuzählen. Auf das Papier wurde bald verzichtet. Dafür konnte die Geschwindigkeit erhöht werden, so dass Dits und Dahs verschwammen. Die Telegrafisten achteten nur noch auf die Melodie der Zeichen oder ganzen Wörter. Morsen ist halt eine Sprache, die man zwar nicht sprechen, aber nur durch Hören lernen kann.

Es dauerte Jahrzehnte, bis Wissenschafter diese Erkenntnisse auch für die Lehre vorschlugen. Der Psychologe Ludwig Koch empfahl schließlich 1936, Morsezeichen von Anfang an mit hoher Geschwindigkeit zu lernen. Statt zu zählen kommt es auf den Klang eines Zeichens an, und den hört man nur, wenn ein Dit, also ein Punkt, weniger als 50ms dauert. Nach einigen Stunden Übung lassen sich so pro Minute bereits 25 Wörter aufnehmen, das entspricht etwa 150 Zeichen.

Zum Üben brauchte man immer seltener einen Kurs zu besuchen, denn es erschienen Schallplatten, Kassetten, CDs und Computer-Programme mit Übungen nach der Koch-Methode. Die letzte große Neuerung war mit LCWO der Online-Morse-Trainer. Man kann sich einfach an den Rechner setzen und sofort anfangen zu üben. Der Rechner kontrolliert die Ergebnisse, erstellt Statistiken und Rangfolgen. Nur eines gab es schon lange in keinem Morse-Kurs mehr: abgedruckte Morsezeichen.

morseSynth

Seit kurzem ist es mit der Web Audio API möglich geworden, Morsezeichen direkt im Browser herzustellen. Man kann in JavaScript die Wellenform, Frequenz, Lautstärke, Anstiegszeiten und sogar Störungen einstellen, die dann auf den Rechnern der Besucher synthetisiert werden. Auch verschiedene Signale gleichzeitig, wie sie bei hohem Andrang oft vorkommen, sind kein Problem. Um die Programmierung zu vereinfachen, habe ich die Bibliothek morseSynth geschrieben. Sie versteht sich mit reinem JavaScript genau so wie jQuery und anderen Frameworks. Im HTML muss nur die Bibliothek eingebunden werden, schon lassen sich Buttons zum Abspielen oder Anhalten auf der Seite verteilen. Das Signal lässt sich mit vielen Parametern einstellen.

Mir fallen einige Anwendungsmöglichkeiten ein. Ein Morsekurs liegt nahe. Man kann aber auch einfach auf einer Amateurfunk-Seite einen „geheimen“ Witz unterbringen oder besondere Bedingungen im Funkverkehr veranschaulichen. Es lassen sich ganze Bücher wiedergeben und dabei nur den Speicherbedarf der reinen Textdateien benötigen. Ich bin gespannt, ob die Bibliothek irgendwo mal genutzt wird.

Dokumentation und Download von morseSynth

Android-Chrome unter Ubuntu debuggen

Leider zeigen die Android-Browser ihre Konsolen nicht an. Man muss die Entwickler-Werkzeuge auf dem PC über USB nutzen. Unter Ubuntu 13.10 und Android 4.4 geht das so:

Die Pakete android-tools-adb und chromium-browser installieren. Im Android-Gerät unter Einstellungen – Über das Telefon siebenmal auf Build-Nummer tippen, dann erscheint die Nachricht, dass man Entwickler ist. Anschließend in Einstellungen – Entwickleroptionen die Option USB-Debugging aktivieren.

Jetzt das Mobilgerät an den PC stecken. Es sollte ein Hinweis auf USB-Debugging erscheinen. Chromium starten und die Adresse chrome:inspect eingeben. Hier sollte das Phone mit allen geöffneten Webseiten zu sehen sein, selbst wenn Chrome for Android gerade nur im Hintergrund läuft.

Diese Lösung ist so einfach und für mich viel besser als eine Konsole auf dem Android-Gerät. Man kann übrigens auch mit „adb forward tcp:9222 localabstract:chrome_devtools_remote“ eine Webseite unter localhost:9222 einrichten. Darauf kann man auch im Firefox und jedem anderen Browser die Konsole von Chrome for Android bearbeiten. Bei mir funktioniert das allerdings nicht richtig.

Beleuchtungsstärke messen mit FS20-Hausautomatisierung

Zu einer elektronisch gesteuerten Beleuchtung gehört in der Regel die Messung des verfügbaren Tageslichtes. Ich beschränkte mich beim FS20-System auf die Messung mit einem einzelnen Sensor. Aufwändigere Installationen haben einen pro Himmelsrichtung. Von ELV gibt es für diese Aufgabe den Dämmerungssender FS20 SD. Wie der Regensensor FS20 SR, der Bodenfeuchte-Sensor FS20 BF und viele andere sendet er nur Daten, wenn sich der Zustand ändert, also typischerweise zweimal am Tag. Da FS20 recht unzuverlässig ist, reicht das nicht, um wirklich zu wissen, ob es draußen hell oder dunkel ist. Man könnte ja einen Datensatz verpasst haben. Außerdem muss man die Schwellen am Sensor eingeben, was funktioniert, aber nicht besonders komfortabel ist.

Ich habe den Temperatur-Sensor HMS 100 T zu einem Beleuchtungsstärke-Messgerät umgebaut. Er sendet alle fünf Minuten einen Messwert. Da er nichts empfängt und nicht konfiguriert werden kann, ist der Betrieb sehr einfach. Batterien einlegen und fertig.

Empfangen kann man ihn wie alle HMS-Geräte nicht mit den üblichen Aktoren wie z.B. Dimmern. Eine Zentrale muss die Helligkeit empfangen und auswerten. Bei mir ist es der CUL-Adapter von Busware an einem Rechner (Raspberry Pi oder Atom-PC) mit CUL_FS20 unter node.js.

Der Sensor sendet einen Datensatz, der mit H beginnt. Normalerweise senden die FS20-Sensoren etwas mit F am Anfang, und das erwarten auch die Aktoren. Daten mit H sind Messwerte. So ein Datensatz sieht z.B. so aus:

H1403017104000D

Das H heißt, dass ein Messwert folgt. Die nächsten vier Zeichen sind die Adresse. Sie unterscheiden sich damit von den üblichen FS20-Adressen, die vier Zeichen Hauscode und zwei Zeichen Adresse senden. Dazu kommt, dass der Sensor beim Stromverlust seine Adresse vergisst. Nach dem Batteriewechsel muss sich die Zentrale an eine neue Adresse gewöhnen. Die letzten zwei Zeichen sind die Checksumme. Es bleiben acht Zeichen für Nutzdaten.

H8F97012103001D
H = prefix
 8F97: device address (changes after battery loss)
     0: status bits
      1: 1=on (seems useless)
       21 3: Temperatur
         0 00: Feuchtigkeit
             1D: checksum

Die Status-Bits sind unter anderem 0=OK, 2=leer, 4=replaced, 8=negative Temperatur. Man sieht, dass die Adresse erst 1403 ist und später 8F97. Keine Ahnung, wie man mehrere Sensoren auseinanderhalten soll. Anscheinend muss man bei jedem Batteriewechsel in der Zentrale die neue Adresse eingeben.

Bei der Temperatur ist erst die zweite, dann die dritte und dann die erste Dezimalstelle angegeben, wobei die dritte eine Nachkommastelle ist. Im Beispiel haben wir 32.1°C. Bei der Feuchte ist erst die dritte, dann die erste und dann die zweite Stelle angegeben, wieder mit einer Nachkommastelle.

Weitere Informationen zu den Daten der HMS-Sensoren befinden sich im FHEM-Projekt in der Datei FHEM/12_HMS.pl.

Umbau zum Beleuchtungsstärke-Messgerät

Ich habe einfach den Heißleiter vom Kabel abgeknipst und statt dessen verschiedene feste Widerstände angeschlossen. Die gesendeten Temperaturen schrieb ich als Kiloohm/Gradcelsius-Paare, in folgende Datei „Temperatur über Widerstand“:

47.8,  4.5
20.2,  12
4.8,   22.5
-4.4,  33.3
-27.6, 99
-33.2, 132
-40.4, 270

Mit folgendem Gnuplot-Script erhielt ich daraus einen Graphen:

set output './Temperatur über Widerstand.png'
set terminal png size 900,600
set datafile separator ","
set ylabel "R/kΩ"
set xlabel "Temp/°C von HMS 100 T gemessen"
set logscale y
set xtics "10"
plot 'Temperatur über Widerstand' w lp

Nun ersetzte ich die Messwiderstände mit dem Fotowiderstand

A1060 und 2,2kΩ Reihenwiderstand. Damit wird die Helligkeit in einem Bereich von -40,4°C bis ca. 60°C dargestellt. In dunklen Situationen löst der Sensor sehr hoch auf. Leichte Dämmerung bringt das Signal von -40°C auf -20°C. Durch den Reihenwiderstand fehlt diese Dynamik allerdings im oberen Bereich. Direkte Besonnung lässt sich nur schwer erkennen. Ist dies gewünscht, sollte vor den Photowiderstand ein Filter gesetzt werden.

FS20-Hausautomatisierung mit CUL_FS20 statt FHEM

Um Leuchten oder Heizungen elektronisch zu steuern werden im einfachsten Fall Insel-Lösungen verwendet. Dies sind z.B. Leuchten mit Bewegungsmelder, Steckdosen mit Funkfernbedienung, Hausnummernbeleuchtungen mit Dämmerungssensor oder Termostate für Heizungen. Deutlich flexibler sind die System-Lösungen, bei denen sich mehrere Sensoren und Aktoren kombinieren lassen. FS20 von ELV ist eines dieser Systeme. Hier lassen sich beliebig viele Fernbedienungen, Dimmer, Schalter oder Ventile miteinander verbinden. Alles, was Befehle sendet, wird dabei Sender genannt. Alle Geräte, die Befehle ausführen, heißen Empfänger. Sender und Empfänger werden direkt miteinander verbunden. Drückt man eine Taste, geht z.B. das Licht im ganzen Raum an. In den Sendern werden alle Befehle programmiert und die Empfänger darauf angelernt. Für komplexere Zusammenhänge wird meistens eine Zentrale benötigt, die alle Schaltzustände kennt und damit flexibler die Empfänger steuern kann.

Zentrale

Für FS20 gibt es die FHZ-Zentralen. An einem angeschlossenen PC mit Windows-Programm stellt man ein, wie die Zentrale auf Eingänge reagieren soll. Die größten Probleme sind dabei erstens das Windows-Programm und zweitens, dass man für immer bei FS20 bleiben muss.

Mit dem USB CUL-Adapter kann jeder Rechner FS20-Signale empfangen und senden. Sehr gut geht das mit einem Raspberry Pi oder einem kleinen Server. Als Software wird in der Regel FHEM verwendet. Es handelt sich um extrem aufwändige Perl-Scripte, die massenweise Hausautomatisierungs-Systeme kennen und verbinden können. Auf Konfigurierbarkeit und Benutzerfreundlichkeit im täglichen Einsatz wurde dabei kaum Wert gelegt.

CUL_FS20

Als Ersatz für FHEM entwickelte ich CUL_FS20. Dies ist lediglich eine Klasse für node.js, die über den CUL-Adapter mit FS20-Geräten spricht. Ein kleines Script kann die Sender und Empfänger beliebig verknüpfen. Eine Webseite und weitere Funktionen lassen sich einfach ergänzen, denn dafür ist node.js gedacht. Ich habe mich dabei für Meteor entschieden, aber es geht auch genauso mit ExpressJS oder ohne Framework direkt in node.

github.com/netAction/CUL_FS20

Samsung schneller laden als erlaubt

Nach der Logik von Samsung sollte ein Handy nicht nur nach zehn Stunden leer sein, sondern auch das Laden dauert so lange. Zumindest am Rechner über USB. Falls das Gerät nur am Computer geladen wird, sollte es also mindestens 14 Stunden pro Tag eingesteckt bleiben. Ob es da nicht Abhilfe gibt, wollte ich vom Support wissen.

Wie kann ich das Laden über USB beschleunigen? Braucht das Ladekabel dafür eine bestimmte Beschaltung oder Spannung? Im Netz kursieren einige Schaltpläne mit Drahtbrücken und Widerständen. Allerdings weiß ich nicht, welche davon funktionieren und hätte gerne offizielle Spezifikationen.

Die Antwort kam schnell und inhaltsfrei:

Gern können Sie in regelmäßigen Abständen unter www.samsungzubehoer.de prüfen, ob leistungsfähigere Akkus oder alternative Lademöglichkeiten zur Produktpalette hinzugefügt worden sind.

Merkwürdig, immerhin haben andere bereits Lösungen gefunden. Tatsächlich lässt sich die Strombegrenzung leicht aufheben. Dafür baute ich einen Adapterstecker, der auf der Seite zum Rechner nur den Strom über USB holt, die Datenleitungen sind offen. Die Buchse zum Ladekabel wird mit den ankommenden 5V versorgt, zusätlich sind die beiden Datenleitungen kurzgeschlossen.

Nach USB-2.0-Spezifikation ist diese Methode nicht erlaubt. Das Handy darf erst geladen werden, wenn es sich über USB angemeldet hat, und auch dann ist der Strom begrenzt. Mit der Norm für Laden über USB und der USB-3.0-Spezifikation wird die Sache noch unübersichtlicher. Dieser Adapter ignoriert alle Normen. Es handelt sich nicht mehr um USB, sondern der Rechner ist eine simple Spannungsquelle. Der Benutzer muss selbst sicherstellen, dass der Ladestrom keinen Schaden anrichtet.




Update

Ich habe mal mein Galaxy S3 unter CyanogenMod 9 für ein paar Stunden außer Reichweite gelegt und die Stromfresser WLan, Bluetooth sowie GPS ausgeschaltet. Mails und Instant Messages kamen über das Handynetz weiterhin an, wie man auf dem Bild sieht. Resultat: 4% Entleerung in acht Stunden. Hochgerechnet hält der Akku über eine Woche!

Wenn man also eine Laufzeit wie beim alten Knochen von Nokia haben will, muss man das Handy auch so behandeln und einfach mal nichts machen. Im Betrieb als Spielekonsole mit hellem Display und 3D-Beschleunigung gehen nur vier Stunden, auch das ist verhältnismäßig sparsam. Immerhin habe ich mit 8Wh den dünnsten Akku, und von dem kostet ein zweiter zum Wechseln 14€.

Amateurfunk

Nun habe ich die Amateurfunklizenz in der Tasche. Wenn mal was ist, kann es nicht schaden etwas vorweisen zu können. Gerade in diesen Zeiten. Da ist die höchste Klasse eine wichtige Qualifikation. Man kann ja nie wissen, besser man hat vorgesorgt.