Linux4Tegra with CUDA support on Nvidia Shield TV

The Nvidia Shield TV Box offers 256 CUDA cores delivering over 1 TeraFLOPs of performance for around 200 €. Great value for mobile deep learning experiments – if only a standard linux would run on it. Fortunately some people over at XDA-Developers have figured out a way to do just that. The instructions are however assuming much previous knowledge, which is why I attempted to compile a recipe here with everything in one place.

For some of the cross compiling you will either need a native Ubuntu Trusty x64 machine or a VM. As I don’t have a x64 machine with Ubuntu Trusty, I will go the VM route. I hate Virtual Box and its laggy awkward UI. Fortunately I have revently discovered vagrant, which automates and hides many of those things.

0. Installing and connecting to a Trusty x64 VM is now as easy as:

Unfortunately the memory of the VM is too small for compiling the kernel, so edit the vagrant file to add some more ram and cpus and the ability to capture sdcardreaders:

Further hints for designing filters can be obtained by:

Unmount the sd card reader from the host system and reload vagrant to restart with the new config:

1. Now we can prepare a MicroSD card with the operating system. First identify your sd card reader, init the sd card with ext4 and mount it:

Download the root file system and some additional tegra drivers from Nvidia

Finally, to fix the wifi firmware, download and extract to host ~. The in the vm

Sync the prepared rootfs to the sdcard and unmount the disk:

You can safely remove the micro sd card now and plug it into the back of your nvidia shield tv console.

2. Unlock the bootloader

First install the ADB tools for OS X

or Linux

Enable debugging on the Shield TV

1. Goto Settings
2. Go across to About in Device
3. Go down to Build and click on it 10times until it says you are in development mode

Enable ADB over USB

1. Make sure you have performed the above steps „Enable debugging“
2. Goto Settings
3. Go Across to Developer options
4. Go down to Debugging
5. Toggle USB debugging to On

Now boot into fastboot

– Perform software shutdown on SHIELD by holding Power button for 10 seconds
– Connect USB OTG cable to SHIELD
– Start pressing power button for 3 seconds
– HDMI TV should be always connected to SHIELD

You should now be able to see your shield from your computer by typing:

if not, unplug the device, stop the adb server, add the nvidia vendor id to db_usb.ini and restart the server:

plug the device back in and try add devices again.

Now get some information about the bootloader:

If your bootloader is locked, it must be unlocked first with:

Select ‚Confirm‘ to unlock the bootloader which may take up to 2 hours for the pro device.

Now fastboot getvar all should read:

Now you have to setup Android TV again and activate debug mode again 🙁
Perform a downgrade to firmware 1.3, and root the shield while you are at it.
Register for Nvidia developer account, obtain and unzip the files, bring device into fast boot mode:

3. To build a boot.img download the patched kernel source from GoogleDrive into your host machines vagrant dir. It should be auto mounted to /vagrant. Then extract the sources:

compile the kernel:

and finally make a bootable

4. Put the sd card in Shield TV SD card slot, Plug OTG cable between Shield TV and PC go into fast boot mode

To boot Linux 4 Tegra once run from the VM:

The Nvidia Logo will pop up and go away while ubuntu starts, which may take a good 2 min. Log in with ubuntu/ubunu. If the Ubuntu desktop is too large for your tv screen, you may want to disable overscan in your tv’s settings.

Once that works, you may want to write boot.img into the recovery spot

or even replace Android altogether by:

and then flash the original boot into the recovery spot. SSH into your shield

the password is ‚ubuntu‘.

Then first prevent the Nvidia driver for Tegra X1 being overwritten by apt-get upgrade by:

Add yourself as a new user and copy your public key, install some frequently used packages:

Now lets install the CUDA support. Download and apt-get sources and scp them to your shield.

Finally add the CUDA stuff to the path:

Now you should be able to call the CUDA compiler:

Next, tune the shield to achieve the full performance:

Now you can try out some of the examples in

Anwesenheitsbasierte Heizungssteuerung mit Fhem und Homematic HM-CC-RT-DN

Auch wenn es bisher für einen Dezember noch recht mild ist, hier ein Kochrezept für eine anwesenheitsbasierte Heizungssteuerung mit Fhem und dem Homematic Thermostat HM-CC-RT-DN. Die Lösung ist zwar nicht ganz so intelligent wie ein Google Nest schont aber den Geldbeutel.

Bei der Inbetriebnahme des HM-CC-RT-DN zeigt dieses kurz die Firmware an. Gegebenenfalls sollte nach dem Pairing ein Update der Firmware auf Version 1.4 durchgeführt werden.

Zuerst muss das Thermostat mit Fhem gepaart werden. Dazu die CUL oder besser VCCU in den Pairingmodus versetzen:

Auf dem HM-CC-RT-DN die „Boost“-Taste für 3 Sekunden gedrückt gehalten. Beim Pairing ist es wichtig einen Abstand von ca. 1,5-2 m zum CUL zu haben. Falls das Pairing erfolgreich war sollte das Display ein „ACC“ anzeigen. Wichtig ist dass danach ein PairedTo 0x123456 Reading existiert, sonst ist es nicht gepaired.

Nun sollte die korrekte Einrichtung des HM-CC-RT-DN Thermostats mit dem Tool HMInfo überprüft werden.

Für jedes Thermostat sollte das automatische Register auslesen aktiviert werden:

Falls ein Firmwareupdate auf Version 1.4 durchgeführt werden soll kann dies nun geschehen. Das Pairing geht dabei nicht verloren. Zuerst ist die neue Firmware im Fhem-Rootverzeichnis bereitzustellen:

Dann ist das HM-CC-RT-DN in den Bootloadermodus bringen. Dazu die Batterien aus dem Thermostat entnehmen und beim Wiedereinlegen der Batterien die Linke und Rechte Bedientaste am Gerät gedrückt halten, bis „FUP“ im Display erscheint. Nun kann in Fhem das update angestossen werden:

Nun können per HMInfo Temperaturprofile für verschiedene Anwesenheitsmodi gesetzt werden. Standardmäßig liegen diese im Fhem root in Form einer tempList.cfg vor und könnten folgendermaßen aussehen:

R_0_tempListSat>06:00 17.0 22:00 23.0 24:00 17.0
R_1_tempListSun>06:00 17.0 22:00 23.0 24:00 17.0
R_2_tempListMon>06:00 17.0 22:00 23.0 24:00 17.0
R_3_tempListTue>06:00 17.0 22:00 23.0 24:00 17.0
R_4_tempListWed>06:00 17.0 22:00 23.0 24:00 17.0
R_5_tempListThu>06:00 17.0 22:00 23.0 24:00 17.0
R_6_tempListFri>06:00 17.0 22:00 23.0 24:00 17.0

Unter entities sind die Thermostate aufgeführt für die das Temperaturprofil gültig sein soll.
Das Profil an sich:
06:00 17.0 22:00 23.0 24:00 17.0
bedeutet jeweils:
06:00 17.0 : 00:00 bis 06:00 = 17.0
22:00 23.0 : 06:00 bis 22:00 = 23.0
24:00 17.0 : 22:00 bis 24:00 = 17.0

Da für eine anwesenheitsgesteuerte Heizung Temperaturprofile für jeden Anwesenheitszustand vorgehalten werden müssen, empfiehlt es sich die Temperaturprofile in einem separaten Ordner, bei mir „Temperaturprofile“, zu speichern. Der BasePath kann per:

gesetzt werden. Zur Anlage der entsprechenden Temperaturprofile ziehen wir uns erstmal das aktuelle Temperaturprofil von den Thermostaten:

Dieses kann dann nach Gusto kopiert und verändert werden. Dabei stellt sich sofort die Frage:

Was ist die ideale Schlafzimmertemperatur?

Es darf nicht so kalt sein, dass der Körper im Schlaf gegen Unterkühlung ankämpfen und sich dabei verkrampft. Aber es darf auch nicht zu warm sein, denn dann schwitzt man leicht und deckt sich ab, was wiederum Verkühlungen und Muskelverspannungen nach sich ziehen kann. Im Allgemeinen wird eine Schlafzimmertemperatur von 16 – 18° C empfohlen.

Was ist die ideale Wohnzimmertemperatur?

Die empfohlene Wohnzimmertemperatur liegt zwischen 21 – 23° Celsius.

Folgende Profile sollten angelegt und auf individuelle Schlaf- und Wohnzimmerbenutzung angepasst worden sein:


Sie können nun jeweils per HMInfo gesetzt werden:

Selbstverständlich sollten diese Temperaturprofile abhängig von der Anwesenheit der Bewohner automatisch gesetzt werden. Dazu werden einfach entsprechende Watchdogs definiert:

Es kann sein dass beim restoren der Temperaturprofile der Fehler: „tempList not verified“ auftritt.
Das kann daran liegen dass das Schreiben des Temperaturprofils noch nicht von Fhem verifiziert wurde um Sicherzustellen dass die Übertragung auch fehlerfrei geklappt hat. Das restobren kann ohne Burst modus bis zu 3 Sendezyklen à 3 Minuten dauern. Wenn man dann also direkt nach dem restore ein verify macht, bekommt man eine Fehlermeldung da das Temperaturprofil ja unter Umständen noch nicht vollständig in die Register des Thermostats geschrieben wurden.

Plex on Radxa Rock

Plex is a great home media server with clients for iOS, OS X, Windows, web and even some TV sets. For my Radxa Rock home server, an ARM V7 build of Plex server is needed. Fortunately Plex has recently started to offer an ARM V7 build for some Synology NAS devices, which can be repackaged to work on other ARM V7 devices such as the Radxa Rock and the Raspberry Pi 2. I won’t go more into detail here as an excellent guide for installing Plex Home Server on Debian Jessie based distros can be found at htpcguide.

To make your Plex server available on the go, you can either use UPNP to let it configure itself or forward some ports manually. I prefer the latter option, as I don’t like the idea of basically anything being able to expose hosts on my networks. Here are some hints for a FritzBox:


Create Clonezilla USB Stick on OS X

Clonezilla is a great open source tool for cloning whole operating systems. Here is a short recipe how to get a bootable Clonezilla USB Stick on OS X. First get a current iso from here.

Control FHEM with Siri

Apple has recently introduced their HomeKit framework to allow control of home automation appliances with Siri. Unfortunately only very few devices are supported right now. Fortunately Alex Skalozub has reverse engineered the HomeKit protocol and KhaosT has built a HomeKit Accessory Server HAP-NodeJS from it. Nick Farina has then built the homebridge server upon it which can be used to bridge a plethora of devices to HomeKit, such as Phillip’s Hues, Sono’s speakers etc. Andre has contributed a FHEM shim to homebridge, enabling many FHEM devices to be controllable via HomeKit and thus Siri. Here are some hints how to get it working:

and edit config.json such that your FHEM platform is correctly defined.

On the FHEM side, only the genericDeviceTypes switch, outlet, light, blind, speaker, thermostat have to be added to the global user attributes list:

Don’t just overwrite the global user attributes list, append at the end. Then start the homebridge server for the first time:

To run homebridge as a service and start it with the system, install this service file:

Description=Start homebridge server

into /etc/systemd/system/homebridge.service . You can download a template with wget and adapt your username:

Then enable & start the service in systemctl:

Check if it is running correctly:

Now install the Elgato Eve app on your iDevice. If homebridge is running correctly, the accessories defined there should be visible in the Eve app. The default pin code for all HomeBridge accessories is 03145154. If you have to delete some device, you will manually have to remove the corresponding file in ~/homebridge/persist. To figure out which file to remove, have a look at the debug http server http://yourip:8080/persist.

Now you can finally order Siri to turn on the TV light. Here is a list of possible commands from Apple’s website

„Turn on the lights“ or „Turn off the lights.“
„Dim the lights“ or „Set the brightness to 50%.“
„Set the temperature to 68 degrees.“
„Turn on the coffee maker.“

If you set up homes, zones, rooms, or scenes, you can use also commands like this:

„Turn on the upstairs lights.“
„Turn off Chloe’s light.“
„Turn down the kitchen lights“
„Dim the lights in the dining room to 50%.“
„Make the living room lights the brightest.“
„Set the Tahoe house to 72 degrees.“
„Set the thermostat downstairs to 70.“
„Turn on the printer in the office.“
„Set up for a party, Siri.“
„Set the dinner scene.“
„Set my bedtime scene.“

Or their German counterparts:

„Schalte das Licht ein.“ oder „Schalte das Licht aus.“
„Dimme das Licht.“ oder „Dimme das Licht auf 50 %.“
„Stelle die Temperatur auf 20 °C ein.“
„Schalte die Kaffeemaschine ein.“

Mit Befehlen wie den folgenden können Sie Einstellungen für Wohnbereiche, Zimmer oder Umgebungen zusammenfassen:

„Schalte alle Lampen im Obergeschoss ein.“
„Schalte Chloes Licht aus.“
„Dimme das Licht in der Küche.“
„Dimme das Licht im Esszimmer auf 50 %.“
„Stelle das Licht in der Küche am hellsten ein.“
„Stelle die Temperatur im Tahoe-Haus auf 22 °C ein.“
„Stelle das Thermostat im Erdgeschoss auf 21 °C ein.
„Schalte den Drucker im Büro ein.“
„Siri, bereite alles für eine Party vor.“
„Bereite das Ambiente fürs Abendessen vor.“
„Aktiviere den Nachtruhemodus.“

AirPlay to Sonos Speakers

If you happen to own some Apple devices and some Sonos speakers, you may have expected to be able to airplay directly from the devices to the speakers or at least that Sonos will enable that functionality with a firmware update in near future. Unfortunately this hasn’t happened so far and Sonos owner are stuck with the clumsy Sonos Controller software 🙁

Anyway, there has been a way to bridge AirPlay and Sonos for quite some time, called airsonos, but it stopped working with OS X El Capitan and iOS 9 because Apple switched to ALAC encoding their AirPlay streams. Fortunately, thanks to @microadam, nodetunes now supports ALAC decoding and airsonos works again. Here is a short recipe how to install airsonos on a linux box and how to use your Sonos speakers like they should have been usable in the first place:

Now you can see if it starts up correctly and finds your Sonos speakers:

In case everything worked out okay, you can run airsonos as a service and start it automatically when booting. To do this, first create a new file /etc/systemd/system/airsonos.service

with the following content:

Description=Start airsonos server

Enable the newly created service:

Start the service:

Check it status with:

FHEM HomeMatic Konfiguration mit HMinfo überprüfen

Immer wenn neue HomeMatic Geräte angelernt wurden sollte die Konfiguration per HMinfo configCheck überprüft werden. Dazu muss zuerst eine entsprechende HMinfo Instanz definiert werden.

Das Ergebnis vom configCheck kann dann z.B. so aussehen:

configCheck done:

missing register list
CUL_HM_HM_WDS40_TH_I_1FC99C: RegL_00:

peer list incomplete. Use getConfig to read it.
incomplete: CUL_HM_HM_WDS40_TH_I_1FC99C:

PairedTo missing/unknown

Leider sind diese Fehlermeldungen für den Einsteiger wenig hilfreich und auch die Wikieinträge bringen es nicht auf den Punkt. Daher hier der Versuch einer einfacheren Erklärung und Lösungsvorschlägen:

missing register list

Ursache: Die Registerlisten des Gerätes liegen noch nicht in FHEM vor. Sie müssen erst vom Gerät geholt werden.
Lösung: set deviceName getConfig
und dann den Anlernbutton des Geräts kurz drücken. Die die Befehle in der Warteschlange protCmdPend sollten dann abgearbeitet werden. Die Registerlisten können auch zeitverzögert und im Hintergrund geladen und aktualisiert werden (um nicht das Funkbudget zu überlasten) indem man in den Devices (nicht im Channel!)
attr deviceName autoReadReg 5_readMissing
setzt. Wenn getConfig keine Ergebnisse liefert, dann neu pairen.

peer list incomplete

Ursache: Die Liste der Peers ist nicht vollständig.
Lösung: set deviceName getConfig

Peer not verified. Check that peer is set on both sides

Ursache: Das Peering ist nicht von Sensor nach Aktor UND von Aktor nach Sensor eingetragen.
Lösung: Peering wiederholen set sensorName peerChan 0 actorChannel single
oder die peerList manuell editieren.

trigger sent to unpeered device

Ursache: Der Kanal triggert Peers welche nicht in seiner peerList definiert sind.
Lösung: Peering wiederholen oder peerList manuell editieren.

trigger sent to undefined device

Ursache: Der Kanal triggert Peers welche noch nicht in FHEM definiert sind.
Lösung: Entsprechenden Peer in FHEM definieren

PairedTo mismatch to IODev

Ursache: Im device ist nicht die gleiche hmId hinterlegt wie im IO device
Lösung: set deviceName regSet pairCentral hmId

PairedTo missing/unknown

Ursache: Von dem Device ist nicht bekannt es bereits erfolgreich mit FHEM gepairt ist. Wahrscheinlich fehlt noch die Registerliste 0, s.o.
Lösung: set deviceName getConfig oder neu pairen.

Fhem CUL Hilferuf CUL_0, help me!

Sollten in eurem FHEM log Einträge wie:

2015.08.24 11:00:01 3: CUL_0: Unknown code A0FD086102E9BE30000000A88EF080000::-46.5:CUL_0, help me!
2015.08.24 11:02:43 3: CUL_0: Unknown code A0FD186102E9BE30000000A88EF080000::-46.5:CUL_0, help me!
2015.08.24 11:05:11 3: CUL_0: Unknown code A0FD286102E9BE30000000A88EF080000::-46.5:CUL_0, help me!
2015.08.24 11:07:24 3: CUL_0: Unknown code A0FD386102E9BE30000000A88EF080000::-46.5:CUL_0, help me!
2015.08.24 11:10:27 3: CUL_0: Unknown code A0FD486102E9BE30000000A88EF080000::-46.5:CUL_0, help me!
2015.08.24 11:13:16 3: CUL_0: Unknown code A0FD586102E9BE30000000A88ED080000::-45.5:CUL_0, help me!

auftauchen, bedeutet das soviel wie dass euer CUL eine Nachricht empfangen hat, für die es in FHEM noch keinen Empfänger gibt. In diesem Fall handelt es sich wohl um ein HM-CC-RT-DN eines Nachbars mit HmId 2E9BE3. Die Lösung besteht darin eine virtueller Controller Unit (VCCU) anzulegen, welche sich um diese Nachrichten kümmert. Eine VCCU benötigt wie alle HM Devices eine eindeutige Adresse im CUL_HM Addressbereich. Nach Möglichkeit sollte dafür die sechsstellige hexadezimale HMId eures CUL/CUNO/HMLAN verwendet werden.

Dies sollte bereits reichen um die nervigen Logeinträge zu beseitigen. Die angelegte VCCU kann aber noch viel mehr, zum Beispiel mehrere IODevices per IOList verwalten:

Neue Homematic Geräte sollten nun direkt mit den VCCUs gepairt werden:

Für sicherheitskritische Geräte kann nun ein bevorzugtes IODevice definiert werden

Damit wird CUL_0 bevorzugt genutzt, andernfalls werden die IODevices in der IOList der VCCU durchprobiert.

Für mobile Geräte wie z.B. Fernbedienungen bietet sich die dynamische Auswahl des IODevices aus der IOList des VCCU nach Empfangsstärke an:

Raspberry Pi Wlan Issues

Chances are you have an Edimax EW-7811Un wlan adapter that uses overly aggressive power management. This can be fixed easily by

and adding the following line to disable the power management

options 8192cu rtw_power_mgnt=0 rtw_enusbss=0

after a reboot, your plan should be much more stable.

How unique and trackable is your browser?

Find out how unique your browser’s footprint and thus how trackable it really is with Panopticlick by the Electronic Frontier Foundation (EFF). You may be surprised …