Probleme mit den Boxen: Xbox One und/gegen Fritz!Box

Als begeisterter WATCHDOGS 1 Spieler konnte ich nicht widerstehen, als WATCHDOGS 2 herauskam. Allerdings war mit der PS 3 kein Blume(n)topf mehr zu gewinnen. Also habe ich einem Kollegen seine gebrauchte Xbox One angekauft, danke an Jens noch mal! Auch das Spiel wurde schnell geliefert, einem großen Versandhändler sei dank.

Aber das Starten und Laden war ein Graus. Es wurden öfter auch Netzwerkprobleme angezeigt, ich wäre angeblich nicht verbunden. Der Xbox One eigene Punkt „Netzwerkverbindungen testen“ (in Netzwerkeinstellungen) sagte immer „Alles funktioniert“. Für WATCHDOGS 2 wäre aber der Punkt „Multiplayer-Verbindung testen“ besser gewesen. Die Xbox One ist wohl besonders zukunftssicher und verwendet wohl IPv6. Soweit ist das ja gut, aber mit Fritz!Boxen kommt es wohl zu Problemen. Leider habe ich bereits IPv6 in meiner Fritz!Box aktiviert, allerdings über 6to4. Nun will die Xbox One aber Tereodo trotz vorhandener IPv6 verwenden (widerspricht RFC 4380 Abschnitt 5.5) und muss so entsprechend dem verlinkten AVM Artikel behoben werden.

Besonders faszinierend finde ich das ein Microsoft-Mitarbeiter wohl Teredo entwickelt hat (siehe Wikipedia und auch im RFC 4380). Hut ab, das muss man als Firma können ;)

Hinweis (Ergänzt 6.12.2016)

Das Problem betrifft wahrscheinlich auch andere Spiele, die eine Online-Funktion haben. Dies kann ich leider nicht testen.

Open Source Hausautomatisierung im Vergleich

Inzwischen sind alle Heizkörper und auch fast alle Lichter in der heimischen Wohnung über die Weboberfläche der eQ-3 CCU2 fernbedienbar und auch die @Home App funktioniert soweit gut. Die Produktpflege und Dokumentation von eQ3 würde ich vorbildlich nennen: auf der Downloads-Seite findet man sowohl die jeweils aktuelle CCU2 Firmware (inklusive Change Log) als auch die Dokumentation der Schnittstellen (HomeMatic XML-RPC).

Folgende Homematic und Homematic  IP Produkte sind aktuell im Einsatz:

  • HM-CC-RT-DN – Funk-Heizkörperthermostat
  • HM-LC-SW1-FM – Schalt-Aktor 1-fach Unterputz (ohne Taster)
  • HM-LC-SW2-FM – Schalt-Aktor 2-fach Unterputz (ohne Taster)
  • HM-LC-Sw1PBU-FM – Schalt-Aktor 1-fach Unterputz (für Markenschalter)
  • HM-PB-2-WM55 – 2-fach-Funk-Wandtaster
  • HmIP-BSM – Schalt-Aktor 1-fach Unterputz (Homematic IP, für Markenschalter)
  • HMIP-PSM – Schalt- und Messsteckdose (Homematic IP)

Allerdings kann man (ohne Kritik an eQ-3 zu üben) naturgegeben nur deren Produkte verknüpfen und steuern. Weitere bereits vorhandene Geräte sollten ebenso angesprochen werden können:

Zum Glück gibt es ausreichend Softwarelösungen für dieses Problem. Vor dem Aufzählen der Kandidaten sollen allerdings Vergleichskriterien festgelegt werden.

Vergleichskriterien:

  1. Die Software muss quell-offen und frei sein (OpenSource)
  2. Dokumentation auf Englisch bzw. Deutsch und in ausreichenden Qualität und Detailtiefe vorhanden (Dokumentation)
  3. Größe der Community
  4. Support für Komponenten von eQ-3 für Homematic und Homematic IP (Hardware-Unterstützung), da diese bereits vorhanden ist.
  5. Apps für iOS bzw. Android (Apps)
  6. Verwendete Programmiersprachen & Technologien (Technologie)
  7. Die Software muss Graphen zur historischen Analyse von Messwerten bieten (Graphen)
  8. Die Software muss über Regeln erweiterbar sein, z.B. Verknüpfung von Schalter, Reaktion aufs Verlassen der Wohnung (Regeln)

openHAB

openHAB basiert auf Java und OSGi (Equinox) und ist somit auf allen Plattformen lauffähig, auf denen Java angeboten wird (Linux, Windows, OS X,…). Laut Wiki sind auch ARM SBCs ausreichend.

openHAB verwendet intern einen Event Bus, um alle anderen Komponenten zu verbinden. Weitere wichtige Komponenten sind das openHAB Repository, welches den aktuell bekannten Zustand aller bekannten Items vorhält, und die Bindings, die als Abstraktionsschicht zwischen openHAB und den anzubindenden Geräten fungiert.

Über das openHAB Repository werden sowohl die diversen User Interfaces (WebUI, Apps für iOS, Android, Windows Phone, …) als auch die Verarbeitung der Automatisierungsregeln angebunden.

URLhttp://www.openhab.org/
OpenSourcehttps://github.com/openhab/openhab (EPL)
Dokumentationhttps://github.com/openhab/openhab/wiki
Dokumentation ausführlich für alle Module auf Englisch vorhanden, über github Wiki gut erweiterbar.
CommunityHohe Aktivität
Hardware-
Unterstützung
Breite Unterstützung für diverse Hardware und externe Software
Appsverfügbar für iOS, Android, Windows Phone und sogar Pebble
TechnologieJava / OSGi
GraphenCharts sind über Persistenzen für fast alle messbaren Größen möglich.
RegelnopenHAB ist über Regeln steuerbar. Diese sind in einer DSL zu erstellen und integrieren Java.

Home Assistant

Python 3 bildet die Basis für Home Assistant. Entsprechend bietet auch Home Assistant einen breiten Support für die gängigsten Betriebssysteme (Video-Tutorials existieren für Windows 10, OS X und Ubuntu). Auch Hinweise zum Durchführen einer Aktualisierung sind vorhanden. Installationshinweise für Raspberry Pi, Docker, Vagrant und auch Synology NAS sind vorhanden.

Auch Home Assistent nutzt architektonisch einen Bus, um die einzelnen Komponenten zu verbinden, eine Service Registry und eine State Machine zum Verwalten der Zustände der einzelnen Komponenten.

URLhttps://home-assistant.io/
OpenSourcehttps://github.com/home-assistant/home-assistant (MIT)
DokumentationCookbook für Anwender und Dokumentation für Entwickler
CommunitySehr hohe Aktivität
Hardware-Unterstützungüber 470 (Stand Version 0.33.0) verschiedene Komponenten (Hard- und Software), Homematic ist unterstützt, Homematic IP jedoch nicht
Appskeine, iOS App in Vorbereitung
TechnologiePython
GraphenGraphen sind an messenden Objekten vorhanden
Regelnmöglich, können in YAML definiert werden

fhem

fhem wird in Perl entwickelt und schont daher die benötigten Ressourcen  (sogar auf Fritz!Boxen ist ein Betrieb möglich). Eine Installation ist auch hier wieder auf den 3 großen Betriebssystemen möglich.

Für die Freunde eines Handbuchs hält die Community eine ausführliche Einführung bereit.

URLhttp://fhem.de//
OpenSourcehttps://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/ (GPL v2)
DokumentationAusführliches deutschsprachiges PDF, ausführliches gemischtsprachiges Wiki
CommunitySehr hohe Aktivität
Hardware-UnterstützungÜbersicht über unterstützte Hardware HmIP-Geräte noch nicht offiziell gelistet aber laut Forum möglich
Appsu.a. FHEMobile für iOS und andFHEM für Android
TechnologiePerl
GraphenGraphen sind über gnuplot möglich
RegelnRegeln in Perl geschrieben möglich

calaos

calaos ist ein französisches Projekt und setzt für die Steuerung auf KNX und DMX. Als Hardware wird hauptsächlich Wago unterstützt. Leider ist die Dokumentation hauptsächlich in Französisch und auch das Datum des letzten Eintrags aus dem Entwickler-Blog aus dem Februar 2015 lässt nichts gutes hoffen.

URLhttps://calaos.fr
OpenSourcehttps://github.com/calaos (GPL v3)
Dokumentationfranzösischsprachiges Forum, Wiki in Französisch und Englisch
Communitymoderate Aktivität
Hardware-UnterstützungEingeschränkt, lediglich WAGO, OneWire Komponenten, Zibase, GPIO und IoT Devices werden unterstützt (Quelle)
AppsCalaos Mobile für iOS, Calaos Home für Android
TechnologieC/C++
Graphenunbekannt
Regelnintegrierter LUA Support

domoticz

domoticz ist in C/C++ geschrieben und nativ verfügbar für Raspberry Pis, Windows, Linux, OS X und für einige NAS-Syteme. Als Scripting-Engine wird Lua verwendet, über die mit Blockly die Automatisierung vorgenommen wird. Leider Homematic nicht unterstützt, jedoch ist die Liste an unterstützter Hardware recht umfangreich.

URLhttps://domoticz.com/
OpenSourcehttps://github.com/domoticz/domoticz (GPL v3)
Dokumentationenglischsprachiges Handbuch und Wiki
Communityhohe Aktivität
Hardware-UnterstützungModerat, leider kein Homematic (Quelle)
AppsImperiHome für iOS und Android
TechnologieC/C++
GraphenJa, als Log in der UI
Regelnintegrierter Support für LUA, Bash, Perl, PHP und Python, Support für Blockly

openmotics

openmotics vereint ein Angebot von Soft- und Hardware, die unter eine OpenSource Lizenz gestellt wurde. Die Hardware wird auch im Shop verkauft. Allerdings existieren nur Module zum Einbau in Schaltschränke auf Hutschienen. openmotics eignet sich somit kaum zum nachträglichen Einbau sondern eher für Neubauten. Aber auch dann ist keine Integration weitere, fremder Komponenten vorgesehen.

URLhttps://www.openmotics.com/
OpenSourcehttps://github.com/openmotics (MIT)
Dokumentationenglischsprachiges Wiki
Communitykeine Aktivität (Quelle)
Hardware-Unterstützungnur spezielle openmotics Hardware (siehe Shop)
Appskeine bekannt
TechnologiePython
GraphenJa
RegelnJa

freedomotic

freedomotic bezeichnet sich als Open Iot Framework, versteht sich also nicht nur zur Heimautomatisierung, sondern versucht weiter zu gehen. Technologisch ist wie bei openHAB in Java Grundlage, es wird aber wohl auf OSGi verzichtet. Die verfügbaren Plugins sind im Marketplace verzeichnet.

Installationsanleitungen sind leider bisher nicht wirklich vorhanden, lediglich eine kurze Seite zum Raspberry Pi und Docker (Zugang über guest/guest, nur REST API) enthalten Text.

Der Einsatz von 2 getrennten Messaging Bussen ermöglicht hier zusätzlich noch das Clustering mehrerer freedomotic-Instanzen. Die verschiedenen Hardwaretypen und externen Services werden über Module angebunden.

URLhttp://freedomotic.com/
OpenSourcehttps://github.com/freedomotic/freedomotic (GPL v2)
Dokumentationenglischsprachiges Benutzerhandbuch
Communityunbekannt (Quelle)
Hardware-Unterstützungdiverse Hardware (siehe Shop), keine Hinweise auf Homematic
Appsunbekannt
TechnologieJava
Graphenunbekannt
RegelnÜber XML möglich

Bewertung

Eine abschließende Bewertung fällt schwer, jedoch werde ich freedomotic (fehlende Unterstützung für Homematic), openmotics (nur spezielle Hardware), domoticz (fehlende Unterstützung für Homematic, verwendete Programmiersprache) und calaos (stark eingeschränkte Hardwareunterstützung) aus den jeweilig genannten Gründen nicht weiter verfolgen.

Für

  • openHAB,
  • Home Assistant und
  • fhem

wird es weitere Artikel geben. Diese werden dann von hier verlinkt.

Cubieboard 3 und HDMI

Nachdem ich mein Cubieboard 3 aka Cubietruck noch mal an meinen TV per HDMI anschließen wollte, habe ich fest gestellt, dass zwar auf dem VGA Port ein Bild ausgegeben wurde, nicht aber auf dem HDMI Port.

Nach ein bisschen Suchen im Internet nach „cubietruck hdmi not working“ findet man recht schnell eine Seite mit Informationen zum Cubietruck und der Bildausgabe. Die genauen Werte für die Aktivierung des HDMI Ports findet man im FEX Guide.

Installiert werden die benötigten Tools bin2fex und fex2bin unter Debian mit

apt-get install sunxi-tools

Anschließend kann man mit

bin2fex /boot/script.bin > /root/script.fex

die .bin Datei in eine les- und editbare .fex-Datei umwandeln. Nun kann man die Datei nach den eigenen Wünschen und Bedürfnissen angepasst werden. In meinem Fall wird mit screen1_output_type=1 und screen1_output_mode=10 die Bildausgabe per HDMI in 1080p60 aktiviert:

[disp_init]
disp_init_enable = 1
disp_mode = 1
screen0_output_type = 4
screen0_output_mode = 4
screen1_output_type = 3
screen1_output_mode = 10

Anschließend mit

fex2bin /root/script.fex > /boot/script.bin

die .bin-Datei mit den Änderungen neu erzeugen und neu starten. Nun sollte das Bild per HDMI dargestellt werden.

Probleme mit Windows Update KB3033929 (SHA2 Einführung)

Auch bei meinem Desktop hat KB3033929 zu Problemen geführt. Windows 7 befindet sich auf der ersten Festplatte, Linux auf der zweiten. Natürlich wird Grub zum Booten verwendet. Leider befand sich kein Windows Boot Loader mehr auf keiner der beiden Platten.

Woher bekommt man jetzt wieder ein direkt bootfähiges Windows 7?

  1. Die meisten Webseiten empfehlen die Windows 7 Installations Medien zu verwenden um das System zu reparieren. Gut, müsste man suchen und die richtigen Medien erwischen. Meine war „inkompatibel“.
  2. Diverse Linux-Tools wie install-mbr führten auch nicht zum Erfolg.
  3. Zum Glück konnte ich das Windows noch starten und das Programm EasyBCD installieren. Wie auf der Hersteller Web-Seite beschrieben, kann das Tool einen Windows 7 MBR schreiben.

Nach dem Anwenden von EasyBCD kann das Windows wieder nativ von der ersten Festplatte gestartet werden und ebenso von der zweiten Festplatte via Grub.

Problem gelöst!

Erfahrungen mit FRITZ!WLAN Repeater DVB-C

golem.de und das Magazin LinuxUser berichteten positiv über das Produkt von AVM. Mein TV-Gerät steht leider im Wohnzimmer. Manchmal möchte man aber auch in anderen Räumen TV sehen ohne auf Streams der Sender zurück zu greifen. Eventuell gibt es auch keine kostenfreien Streams mehr (siehe F1 bei RTL).

AVM verspricht für das Produkt auf der entsprechenden Webseite folgende Features:

  • WLAN im 2.4 und 5 GHz Band
  • Dual DVB-C Tuner
  • GBit Ethernet
  • Eine unverbindliche Preisempfehlung von 99€

Den Ausschlag gab die positive Berichterstattung. Also flugs bestellt. Alles notwendige Zubehör ist beigelegt:

  • Der Repeater natürlich
  • Ein TV-Kabel
  • Ein T-Stück um sowohl TV als auch den Repeater mit dem DVB-C Signalen zu versorgen.
  • Ein flaches Ethernetkabel (habe ich nicht verwendet)

Die WLAN Funktion ist als Erstes dran. Beim Einrichten wurde der Repeater in die Betriebsart „LAN-Brücke“ gesetzt. Somit wird der Repeater quasi zum Access-Point und bietet die Möglichkeit 2 Funknetze (2.4 GHz Band und 5 GHz Band) aufzuspannen. Dadurch kann man auch ins hier absolut leere 5 GHz Band ausweichen und dort wesentlich schneller Verbindungen nutzen.

Fazit bisher: WLAN deutlich verbessert! (war aber auch bei einer Fritz!Box 7270 nicht so schwer)

Nun zum DVB-C. Auf der Oberfläche des Repeaters können mit VLC zu öffnende Links gefunden werden und schon kann TV geschaut werden. Radioempfang ist ebenso möglich. Eine Senderliste für VLC kann ebenfalls herunter geladen werden.

Die iOS App kann auf einem iPhone4 zwar installiert werden, die Resultate sind allerdings nicht unbedingt berauschend. Aber das ältere Telefone eventuell Schwierigkeiten haben, schreibt auch der LinuxUser.

Fazit: DVB-C funktioniert ebenso.

Zum Thema „Recording„:

Ein Ziel war neben dem Betrachten von Live-TV auch die Aufzeichnung von Sendungen. Auf dem Repeater kann in der Web-Oberfläche eine Senderliste im offenen M3U Format heruntergeladen werden. Mit ffmpeg kann mit folgendem Kommando aufgezeichnet werden:

ffmpeg -i "$IN" -acodec copy -vcodec copy "$OUT"

$IN ist hierbei ein Eintrag aus der M3U-Datei, $OUT die Zieldatei. Die Aufnahme stellt keine hohen Anforderungen an die Hardware. Ein CubieBoard3 ist stark genug um auf eine per SATA angebundene Festplatte aufzuzeichnen.

Symlinks für Geräte mit udev erstellen

USB Geräte, die in irgendeiner Form RS232 sprechen oder so tun als ob, bekommen normalerweise Einträge im dev-Verzeichnis wie

  • /dev/ttyUSB* oder
  • /dev/ttyACM*

Leider ist eine eindeutige Zuordnung (Gerät X bekommt immer /dev/ttyACM5 o.ä.) nicht gegeben. Man musst also immer erst einmal „nachsehen“ (dmesg oder lsusb).

Eine Alternative bietet udev an. Dazu erstellt man udev-Regeln, am besten in einer eigenen Datei im Verzeichnis /etc/udev/rules.d.

Beispiel für einen Adapter USB auf RS232 mit einem pl2302 von Prolific Technology Inc. Dieser hat Vendor-ID 067b und Product-ID 2303.

SUBSYSTEM=="tty",ATTRS{idVendor}=="067b",ATTRS{idProduct}=="2303",SYMLINK+="pl2303"

Man erhält mit einem ls -hal /dev/ folgende Ausgabe:

lrwxrwxrwx 1 root root 7 Nov 21 18:19 /dev/pl2303 -> ttyUSB1

Man kann nun statt /dev/ttyUSB1 (wechselndes Device) immer den Symlink /dev/pl2302 (konstant) verwenden. Das lästige Suchen entfällt somit.

(Dieser Beitrag basiert auf diesem Blog und wurde natürlich angepasst)

Programme mit tmux beim Systemstart automatisch starten

Da ich für das neuste Projekt (ClimateRecording) für den Linux-Client auf der Arietta Hardware erstmal noch kein Init-Script wollte, musste eine alternative Lösung gefunden werden.

Nachdem der Client bisher manuell in tmux gestartet wurde, bot sich als Lösung die Skriptbarkeit von tmux an:

tmux new-session -d -s client_tmux
tmux select-pane -t client_tmux
tmux send-keys "cd /$PATH/ClimateRecording/linuxClient" C-m
tmux send-keys "/$PATH/ClimateRecording/linuxClient/client.py" C-m

Trägt man diese Zeilen in der Datei /etc/rc.local ein, so wird bei jedem Systemstart eine Session für tmux gestartet und darin der Linux-Client ausgeführt.

Mit

tmux a -t client_tmux

kann man dann nach Login auf der Arietta die tmux-Session aktivieren.