Tinkering Tuesday – HUEify – JN5169 Xiaomi Smart Button – Part 1 – Making a connection

This is a side project to the original HUEify series on connecting a custom light to the HUE ecosystem. On the site http://faire-ca-soi-meme.fr/ there are some articles about what’s inside the Smart Home Gadgets of Xiaomi (at the end of this I provide all the links currently available). Every single piece is taken apart and detailed pictures were taken describing all the identifiable parts. With my little bit french from school even I can read through it. But maybe Google Translator may help others.

I decided to order two pieces because they were very cheap at Gearbest at that time and they would make a perfect match to the nightpanel lights I am currently building and replace the currently used Amazon Dash button. And because they just arrived and I am waiting for PeeVeeOne to publish his solution for the Multiple Endpoint RGB lights on the JN5168, I will now try my luck with the Xiaomi button to see whether I can get it to communicate with Hue.

On faire-ca-soi-meme there are several detailed images of the button and also the pinout from the test pins. Unfortunately these are pogo pins and my tries to solder a wire to them were not very successful. I was successful though with using jumper wires to connect 3.3V and GND to the battery connector, hot-glueing two jumper wires together in the right spacing and forcing it to the pogo pin connectors for RX and TX with a soldering hand. The fifth pin that is required is only temporary and is the SPIMISO pin next to RX/TX. Just shortly connect a ground wire to it when connecting the power (even with my shaky hand that works).

If that is done right you can open the Device Info in NXP Beyond Studio (use 1000000 Baud and the correct COM Port):

I then compiled the Controller_OnOffSensor Demo app from NXP although in the documentation it is only described to work with the JN5168 demo hardware. I used the compile flag for the JN5169 and it compiled successfully. There is an error when flashing the firmware with the flash utility from BeyondStudio but this is only the validation after flashing. The reason is that the chip was read-protected from Xiaomi in order to make reengineering their firmware impossible (or not-so-easy). So the flashing was successful which can be seen from the serial monitor after rebooting:

APP: Switch Power Up...........................(several dots more)
Heap size at step 1 is 11412 bytes (start=04003fe4 end=04006c78)
APP: Watchdog timer has reset device!
Heap size at step 2a is 11412 bytes (start=04003fe4 end=04006c78)
Heap size at step 3 is 11412 bytes (start=04003fe4 end=04006c78)
Heap size at step 4 is 11412 bytes (start=04003fe4 end=04006c78)
Heap size at step 5 is 8216 bytes (start=04004c60 end=04006c78)
Heap size at step 6 is 8216 bytes (start=04004c60 end=04006c78)
Starting Touch Interface...

This ouput is repeated from the timer resetting the device. There seems to be something wrong. The last output message can be found and after that the drivers eTouchInit method is called. I added some debug output and commented out the first for loop (is this a delay or what is that for?):

This results in the following output (the BWE was added because I wanted to be sure I have the correct call):

APP: Switch Power Up...........................(several dots more)
Heap size at step 1 is 11428 bytes (start=04003fd4 end=04006c78)
APP: Watchdog timer has reset device!
Heap size at step 2a is 11428 bytes (start=04003fd4 end=04006c78)
Heap size at step 3 is 11428 bytes (start=04003fd4 end=04006c78)
Heap size at step 4 is 11428 bytes (start=04003fd4 end=04006c78)
Heap size at step 5 is 8232 bytes (start=04004c50 end=04006c78)
Heap size at step 6 is 8232 bytes (start=04004c50 end=04006c78)
Starting Touch Interface...BWE
Starting vTouchInitHardware
Stoping vTouchInitHardware

So there seems to be something wrong with the for-loop. Maybe it tries to read from a wrong pin (because it was made for the JN5168). I will have to take a closer look at the driver and see what I can do. I think I have to understand how it is working first (it is build for a remote control with several buttons so I guess a more simple solution has to be found). I also have to see which DIO pin the buttons are connected to…

In parallel there are also some comments from lucac81 on peeveeone.com about using the JN5169 and Peter also wrote that he ordered some, so maybe the master is faster than me 😀 lucac81 had trouble even installing the light firmware compiled for the JN5169 so maybe I will even try flashing that on the chip to see what happens with the button (just to see if it works, of course I will not use a button to make a light…). I also remember a comment asking about using the chip as a switch for HUE. So maybe someone else is also making progress on this end. I am open for any discussion/help/input.

To be continued sooner or later.


I flashed the JN5169 binary provided by Peter on the Xiaomi SmartHome button but it didn’t join. Unfortunately the debug output on that build doesn’t provide much information.
I build a new one from the demo application with all debugs enabled and the keys in place as I did with the JN5168 but I am getting the same output I had when not correctly putting the keys in place the first time with the JN5168 (see my post http://www.boriswerner.eu/tinkering-tuesday-hueify-making-the-custom-binary-and-the-demo-app-work-on-the-jn5168/):

Try To join 6a075d40c86781e on Ch 11
Try join status 00
Join failed ad

I already researched the error code „ad“ before:

ZPS_APL_APS_E_SECURITY_FAIL: An APSDE-DATA.request requesting security has resulted in an error during the corresponding security processing.

Which definitely hints to a key problem. So the general function is there and it even tries to connect to the bridge but get’s a bad response. That can’t be everything here 😉









JN5169 discussion on https://peeveeone.com/?p=187&


Tinkering Tuesday – HUEify – Making the custom binary and the demo app work on the JN5168

Today I will describe my progress on the development of my own Hue connected lights. Because other people developing with the JN5168 are not necessarily german speakers I will continue my project (which I call HUEify) in english. There is some discussion going on at the latest post from PeeVeeOne.

As I had some trouble with the build provided by PeeVeeOne (lights not turning off, dimming and red not working properly) I had to go through the proecss of building my own binary. This was planned anyways because I have some other plans on top. This post is all about my troubles getting the demo app and a custom build project to work. This should be seen as an additional detailed description to the information that can be found at PeeVeeOne’s website and github repository. So far it is all his work that I am just setting to work on my device. The general setup of the developing environment BeyondStudio and the demo application is described in this post by PeeVeeOne.

Building the binaries

First of all I had some trouble building the binaries from both the NXP demo and the github project PeeVeeOne supplied. Both were not joining the Hue bridge and were not giving any debug information, though the binary directly downloaded from PeeVeeOne was doing both without any issues.

The build of the NXP Demo Application (JN-AN-1171) is defaulted to create a binary for the JN5169. To change this I changed the default in the Makefile (Common_Light/Build) to 5168:

But that is not enough as the builder is getting the command additionally (mind the configuration in the dropdown at the top of the window) In the project properties you have to change the Build command:

Now the correct binary will be build.

Sometimes I had the binary not correctly rebuild after changes as it didn’t recognize any changes (nothing new to build). Then it helped not to use the normal „Build“ but the „Build selected“ and choosing the options „Clean selected configurations“ and „Build selected configurations“:

Debugging the Demo Application and making it work

To trace the startup and the connection you can leave the USB serial converter (FT232) wired to the chip after flashing the binary. It will send debug information which you can read at your PC. I use the serial monitor from the Arduino IDE (you have to close the monitor before flashing the binary because it will lock the serial connection and you get an access error).

In the default of the demo application and the PeeVeeOne github rep the debugs are not enabled. To do this, just uncomment the options in the Makefile (you don’t need all of them, actually I use only some from the first block, check the source code for the relevant ones):

It will show something like this:

This is the debug output when starting the device with no search for new devices from the Hue bridge. It goes through all channels serching for something to connect to.

With a search from the bridge started instead of

Disc st 0 c 1 sel 255
Pan 6a075d40c856781e Ch 11 RCap 3 PJoin 0 Sfpl 2 ZBVer 2
No more nwks to try

I got the following output from the demo application:

Disc st 0 c 1 sel 0
Pan 6a075d40c856781e Ch 11 RCap 1 PJoin 1 Sfpl 2 ZBVer 2
Try To join 6a075d40c86781e on Ch 11
Try join status 00
Join failed ad
No more nwks to try

So it seems like 6a075d40c856781e is the ID of my bridge. When not searching for devices it recognizes it but is not trying to join. When searching for devices it is trying but it is not successful.

This was all from my office room which is located at the other end of our appartment. Moving closer to the bridge the original binary from PeeVeeOne successfully joined and I get the following output:

Discover on ch 11
disc status 00
Disc st 0 c 1 sel 0
Pan 6a075d40c856781e Ch 11 RCap 2 PJoin 2 Sfpl 2 ZBVer 2
Try To join 6a075d40c856781e on Ch 11
Try join status 00
Joined as Router

I was searching the error message and found the lines in the code that output it:

if (sStackEvent.eType == ZPS_EVENT_NWK_FAILED_TO_JOIN) {
DBG_vPrintf(TRACE_CLASSIC, "Join failed %02x\n", sStackEvent.uEvent.sNwkJoinFailedEvent.u8Status );

Having a closer look at the error message in the output it gave the two letters „ad“ after the „Join failed“. This was actually an error code. In the User Guide of the ZigBee PRO Stack (JN-UG-3101) I was able to find the code (9.2.2 APS Codes):

ZPS_APL_APS_E_SECURITY_FAIL: An APSDE-DATA.request requesting security has resulted in an error during the corresponding security processing.

This made me think of a post at PeeVeeOne’s about Keys. And voila, using the keys in the right places (zpr_light_node.c and app_light_commission_task.c) it successfully joined. Sometimes it’s just careful reading. 

Custom Build from PeeVeeOne

I also applied the debugging to the repository from PeeVeeOne’s github and was moving closer to the bridge so it finally joined my hue bridge. The problems I described in my last post (dimming and the color red not properly working and turning of the light not working) was caused by the inverting of the PWM signal PeeVeeOne was applying. I already had that in mind when turning of the light in the App caused the lights to turn bright. So switching the signal did the trick. In the file DriverBulb_JN516X_RGB.c go to line 57 and modify the value from TRUE to FALSE:

The final outcome can be seen in this youtube video:

Next steps

Until now it was all about the initial setup. But this is where the fun begins. Now I can program the device to my likes and I already have something in mind. I hope to find the time to try it soon. There are some more blog posts about the development, based on PeeVeeOne’s findings, e.g. SevenWatt hacking a SmartPlug from Innr. I am looking forward to see the other projects.

My goal is to use the JN5168 with multiple endpoints configured to act as not only one light to the hue bridge but as several (e.g. to separately control all 4 parts of our nightstands). PeeVeeOne is also working in this direction with controlling 4 dimmable lights with one module. I have some other ideas I first have to check for feasibility and then there will be updates here.


Tinkering Tuesday – Raspberry Pi Mobile Photo Backup Box – Part 2

So. Weiter geht es. Das USB-Y-Kabel ist da, angeschlossen und: Power LED leuchtet aber kein Ton von der HDD. Nochmal ohne Y-Kabel versucht, siehe da. Sie funktioniert! Ich hab keine Ahnung warum, aber ich lebe erstmal damit.

Schlussendlich werde ich wohl sowieso mit dem RPi2 gehen, weil der weniger Strom verbrauchen soll und ich mit dem Y-Kabel sowieso nicht weit kommen würde, da ich am RPi1 nur 2 USB-Slots habe und ja auch noch der SD-Kartenleser ran muss. Sowas fällt einem dann aber erst nach der Impuls-Bestellung ein. Aber die 2,50 Euro werde ich verschmerzen können.

Ich mache jetzt trotzdem erstmal mit dem 1er weiter, dann kann ich zum einen evtl. noch einen Geschwindigkeitsvergleich machen (wenn der Strom doch ausreicht um die HDD auch zu beschreiben), zum anderen hab ich das jetzt hier schon verkabelt.

Wenn man sich das Backup-Skript einmal genauer ansieht, stellt man fest, dass es zwei Mountpoints anlegt. Einen für das Backup-Device, einen für die SD-Karte.

# Specify devices and their mount points

Also schauen wir mal, ob das funktioniert.

Dafür wird erstmal eine Test-Datei auf die USB-HDD geschrieben und diese angeschlossen. Dann schau ich per putty, ob ich die Datei an der entsprechenden Stelle finde:

Interessanterweise zeigt mir der Pi eine alte Partition auf der HDD an (ja, war mal die Boot-Partition eines Laptops und dann als FritzNAS aufgesetzt). Soviel zur Formatierung in Windows.

Der Befehl lsblk sagt auch, dass es noch zwei Partitionen gibt, leider ist die falsche am Mount Point eingebunden:

Es wird also immer die erste Partition eingebunden. Gut zu wissen. Ich könnte natürlich einfach das Skript ändern, damit sda2 gemounted wird, aber ich will die HDD ja auch mal sauber haben.

Also erstmal gparted installiert.

sudo apt-get install gparted

Dann werden erstmal die existierenden Partitionen sauber weggelöscht:

sudo parted
rm 1
rm 2
Die neue exFAT Partition habe ich dann in Windows erstellt, weil ich dann doch keine Lust mehr hatte zu schauen, wie das in parted geht 😉


Nach dem Anschluss des SD-Kartenlesers (da war das Y-Kabel doch noch zu was nutze, der Kartenleser ist so unförmig, dass er nicht an den zweiten USB-Port passt; das Y-Kabel ist aber auch als einfache USB-Verlängerung zu benutzen, da ich aus Versehen die Variante mit USB-Anschluss bestellt hatte und nicht mit einem Mikro-USB-Stecker; hab ich auch erst beim Auspacken bemerkt) konnte ich noch kurz lsblk nochmal aufrufen und sehen, dass er die Karte erkannt hat, dann fuhr der Pi runter.

Erst dachte ich, dass das der hohen Stromaufnahme geschuldet sein könnte, aber dann hab ich mich erinnert, dass ja das Skript nach erfolgreichem Kopieren der Dateien genau das tun soll. Den Pi herunterfahren. Also HDD an den PC angeschlossen und voila:

Die Ordnerstruktur ist schonmal angelegt, die Metadateien waren auch da (39911448 ist übrigens die ID der SD-Karte, sodass man verschiedene Karten sichern kann, ohne dass sich das System in die Quere kommt. Jede Karte bekommt seinen eigenen Unterordner). Nun das Ganze nochmal mit Photos und einem Video testen.

Alles wieder hochgefahren und angeschlossen. Da ging aber dann doch die Stromaufnahme der Platte wohl zu hoch. Vor dem Anschluss des Kartenlesers war noch alles in Ordnung, dann aber wieder das typische „ich hab zu wenig Strom“-Geräusch der Platte.

Dann muss nun doch der Pi2 herhalten.

Also wieder Raspbian Lite installiert, Little Backup Box installiert, neu gestartet.
USB-HDD angeschlossen, SD-Kartenleser angeschlossen. Lsblk sieht schonmal gut aus:

Und nach kurzem Arbeiten der Festplatte fährt der Pi herunter und der schaltet im Gegensatz zum RPi1 sogar die HDD stromlos.

Ein kurzer Blick auf die Festplatte zeigt: alle Dateien kopiert! Sowohl JPG, ORF (Olympus Raw) als auch MOV-Datei sind da. Also nichts mit USB-Festplatten würden nicht funktionieren. Läuft einwandfrei. Und ich musste nichtmal die Stromzufuhr auf den Anschlüssen des RPi2 erhöhen.

Test 1: Performance

Ich kann leider keinen Vergleich zum RPi1 machen, aber ich möchte trotzdem wissen, wie schnell der RPi2 die Daten kopiert. Also habe ich mal ein ganzes Urlaubs-Shooting auf die SD-Karte gepackt.

Das Kopieren der JPGs hat schonmal 23 Minuten auf dem Windows-PC gebraucht, die RAWs nochmal 45 Minuten (ich habe bewusst den gleichen SD-Kartenleser genutzt, der USB 3.0 Leser braucht nicht so lange).

Dann per SSH wieder auf den Pi verbunden und mittels date die aktuelle Zeit ausgeben lassen. Gleichzeitig den SD-Kartenleser angeschlossen und gewartet bis der Pi herunterfährt. Die Shutdown-Nachricht wird mit Zeitstempel ausgegeben, so hatte ich dann folgende Werte:

Start um 17:27

Shutdown um 20:12

Macht also eine Laufzeit von gut 2:45. Nicht besonders schnell, aber naja 😉

Test 2: Betrieb mit Powerbank/Akkupack

Das ist dann der ultimative Mobilitätstest: kann ich das Setup auch unterwegs mit dem Akkupack betreiben?

Als Testgerät hat mein Anker PowerCore 20100mAh hergehalten (http://amzn.to/2kelkU7). Der stellt max. 2.4A pro Port zur Verfügung, sollte also reichen. Der RPi fährt hoch, ist per SSH erreichbar, allerdings gibt die USB-HDD mal wieder keinen Mucks von sich. Auch ein Erhöhen des Stroms per max_usb_current=1 in der /boot/config.txt hilft nichts. Aber wozu hab ich denn das USB-Y-Kabel gekauft. Ich hab zwar nicht damit gerechnet, aber lustigerweise funktioniert es in diesem Setup:

Das fertige mobile Setup
Das fertige mobile Setup

Den zweiten Anschluss habe ich direkt an den zweiten Port des Ankers angeschlossen, hat allerdings zur Folge, dass die Festplatte nach dem Herunterfahren weiter Strom hat und entsprechend auch verbraucht. Mit beiden Steckern am Pi funktioniert es aber wieder nicht. Könnte im Prinzip sogar sein, dass dieses Setup auch am Pi1 funktionieren würde, ich hab aber keine Lust mehr das zu testen 😉

Hier nochmal der Performance-Test, diesmal aufgrund der Zeit eine kleine Datenmenge. 138 JPGs mit insgesamt 1 GB in knapp 5 Minuten:

Test 3: Vertauschen der Medien

Damit ich im Urlaub nicht böse Überraschungen erlebe noch ein weiterer Test. Was passiert, wenn man erst den Kartenleser anschließt und dann die HDD? Im schlechtesten Fall müsste er ja andersherum synchronisieren. Und genau das tut er auch, wie man schon im System erkennen kann:

Man hat also hinterher die Daten der Festplatte auf der SD-Karte. Daher noch der folgende Test:

Test 4: Volles Medium

Was passiert, wenn das Backup nicht mehr auf das Medium passt?

Getestet habe ich mit einer 128 MegaByte großen SD-Karte (das waren noch Zeiten, nun habe ich eine 128 GigaByte große Karte, die auch noch winzig ist, also MicroSD) und Dateien auf der Festplatte, die nicht auf der SD-Karte sind. Dann vertauscht angeschlossen, sodass von der Festplatte auf die winzige SD-Karte synchronisiert wird.

Das Ergebnis ist eigentlich recht plausibel. Er synchronisiert so viel er kann (bis also die Karte voll ist) und fährt dann den Pi herunter. Was soll er auch sonst tun? Warnen kann er ja so erstmal nicht (kein Display, kein Speaker, maximal eine hektisch blinkende LED, die man eh nicht wahrnehmen würde).

Zwei Szenarien sind dabei aber zu beachten:

  1. Mit der SD-Karte fotografiert und Medien vertauscht (siehe Test 3). Das Programm schreibt alle Daten von der Festplatte nochmal auf die SD-Karte. Die Karte ist im schlimmsten Fall voll und man hat seine Daten noch nicht auf der Platte gesichert. Sichert man danach nochmal andersherum, werden die eben fälschlicherweise kopierten Daten nochmal wieder auf die Festplatte zurückgeschrieben, da die Ordnerstruktur unterschiedlich ist und er die Daten als neu erkennt. Man müllt sich also die Festplatte voll, sodass man im schlimmsten Fall eine doppelte Sicherung hat aber, wenn die Platte voll ist, seine neuen Fotos nicht. Also bestenfalls die Medien nicht vertauschen!
  2. Backup-Festplatte voll: Hier sollte man ein Gefühl dafür haben, wie viel man bereits auf der Platte gesichert hat. Wenn man sich nicht sicher ist, sollte man die SD-Karte besser nicht formatieren, da schlimmstenfalls nicht alle Fotos auf der Platte gelandet sind. Das merkt man aber eben nicht, da der Pi sich gleich verhält, egal ob das Backup vollständig ist oder nicht. Ich werde also bestenfalls die HDD nur als zusätzliche Sicherung nutzen und nicht als Draufkopieren und SD-Karte formatieren. Das ist mir dann doch zu unsicher.


Was noch auffällt ist, dass das Installationsskript noch den MiniDLNA-Server auf dem Pi installiert und den Medienordner auf den Mountpoint der USB-Quelle setzt. Auch eine gute Idee. In Windows taucht der RPi auch gleich im Explorer auf:

Allerdings habe ich auch mit manuellem Update keine Dateien zur Anzeige bringen können. Wer es braucht muss sich da wohl selbst intensiver mit beschäftigen 😉


Um das Ganze noch etwas cooler zu machen habe ich einen guten Freund mit einem 3D Drucker gebeten (schaut mal bei ihm vorbei: www.doktor-andy.de) mir ein Case zu drucken:


Case im 3D Druck
Case im 3D Druck

Leider ist das noch nicht fertig, ein Bild vom fertigen Setup wird aber nachgereicht, genaso wie dann Erfahrungen aus dem Praxiseinsatz.

Pi Backup Box

Tinkering Tuesday – Raspberry Pi Mobile Photo Backup Box – Part 1

Im Sommer geht es nach Island, da will ich natürlich auch ordentlich photographieren. Normalerweise gehe ich immer davon aus, dass eine SD-Karte reicht und damit schon nichts passiert. Aber da ich gleichzeitig auch Videos machen will und diesmal auf Nummer sicher gehen will, habe ich mich mal mit dem Thema Photo Backup unterwegs beschäftigt.

Eine Lösung auf die man natürlich trifft, sind spezielle externe Festplatten mit eingebautem Kartenleser. Viel zu teuer für meine Zwecke.

Nächste Lösung wäre einen Kartenleser für das Smartphone oder Tablet zu besorgen (Stichwort OTG). Auch nicht viel besser, da mein Speicher notorisch überfüllt ist…
Auch irgendeine Kopierlösung auf eine andere SD-Karte fällt weg, da damit das Speicherplatzproblem auch nicht wirklich gelöst wird und es nur unübersichtlicher wird.

Also mal Google angeworfen und folgende Seite gefunden:

Die LITTLE BACKUP BOX (LBB) ist ein einfaches Skript für den Raspberry Pi. Das simple Prinzip:
Raspberry Pi booten, Backup Device anschließen, Kartenleser mit SD-Karte anschließen und warten bis der Pi herunterfährt.

Das klingt nach nem Plan. Eine externe 2,5″ HDD habe ich auch noch (ist eine alte Laptop-Festplatte in einem 5€ USB Case). Und einen kleinen Kartenleser habe ich noch von der Eye-Fi Karte (von meinem Photobooth, dann war es vielleicht doch kein völliger Fehlkauf).

Also erstmal den alten RPi (das erste Model B, sollte für die Zwecke reichen und frisst weniger Strom) rausgekramt und ein frisches Raspbian Lite draufgezogen. Dann den Installationsbefehl per SSH ausgeführt:
cd ~ && wget https://chiselapp.com/user/dmpop/repository/little-backup-box/tarball/little-backup-box.tar.gz && tar xzvf little-backup-box.tar.gz && cd little-backup-box && chmod +x install-little-backup-box.sh && ./install-little-backup-box.sh

Zwischendurch hat er mal ein Changelog von moz://a (das schreibt man jetzt so…) angezeigt. Das muss man dann mit q beenden, damit er fortfährt. Ist wahrscheinlich nicht immer so, aber weil die Installationsroutine erstmal ein Systemupdate macht, war da wohl noch einiges offen nach der frischen Installation. Entsprechend dauerte das Prozedere auch eine Weile.

In der Zwischenzeit habe ich mal die Festplatte neu formatiert. Eine Partition 150GB, exFAT. Im Ticketsystem von der LBB liest man leider, dass das Skript Probleme mit externen Festplatten hat und nichts drauf kopiert. Das wird sich schon irgendwie lösen lassen. Mal sehen was passiert.

Den ersten Dämpfer bekam ich allerdings schon beim ersten Anschluss der HDD. Der Pi liefert nicht genug Strom…. Hmpf.

Für alle Pi ab Model B+ gibt es wohl einen Parameter mit dem man das Steuern kann:

Für meinen Pi der ersten Generation allerdings nicht. Meinen Pi 2 will ich nicht dafür benutzen, daher gehen wir jetzt den harten Weg 😉

Außerdem will ich schlussendlich keinen Powered USB Hub oder so mitschleppen, deswegen wird erstmal ein USB-Y-Kabel bestellt:

Goobay USB 3.0 Y-USB-Kabel externe HDD/SSD

Wenn das da ist gibt es den nächsten Teil.


Tinkering Tuesday – Photobooth im Selbstbau Teil 3 – In der Praxis

So, diese Woche gibt es dann endlich den fertigen Kasten. Ich hatte mir vorab eine grobe Skizze gemacht, wie das Ding auszusehen hat und ohne große Umwege hier einmal das Ergebnis:

Da ich den Drucker gerade verlegt habe sind die Bilder alle ohne den Fotodrucker. Dieser wird aber ganz normal per USB-Kabel angeschlossen, das, genau wie das Stromkabel, dann zurück in den Kasten geführt wird. Also denkt euch einfach noch ein paar mehr Kabel dazu.

Der Monitor ist wie schon erwähnt ein alter 17 Zoll Monitor. Darüber sieht man die Öffnung für die Kamera. Ich hatte da noch eine Holzverkleidung drum, aber die ist wieder abgefallen. Schlecht geklebt… Dadrüber wiederum ist der Blitzdiffusor. Hier hab ich die ganz günstige Version genommen: Ein normales Blatt 80g DIN A4-Papier. Reicht auf die Distanz. Immerhin hab ich mir bei der Verkleidung des Randes Mühe gegeben und ein Plastikprofil zurecht geschnitten.

Der obere Teil steht etwas hervor, das liegt daran, dass dieser Teil abnehmbar ist. Mittels 4 Schrauben aus dem Inneren zu lösen, kann man den Teil theoretisch austauschen und mit verschiedenen Designs ausstatten. Fand ich wohl irgendwie eine gute Idee, als ich den Kasten konzipiert hab. Ehrlich gesagt habe ich keine Ahnung, warum ich das so gebaut hab. Irgendwie hatte ich gedacht, dass ich sonst das Beziehen (weißes Kunstleder übrigens! Hatte ich noch von meinem Sofa-Umbau übrig, den gibt es vielleicht auch demnächst mal hier). Sieht auf jeden Fall etwas „aufgesetzt“ aus. Heute würde ich es anders machen, aber immerhin kann ich so theoretisch das Design komplett anpassen 😉

Auf dem rechten Bild sieht man dann den eingeschalteten Kasten mit der Slideshow. Es gibt einen einzigen Stecker, der zur Steckdose führt und den Schalter, der mittels Mono-Cinch-Kabel angeschlossen ist (ich bin Fan von Cinch-Kabeln, wird man später noch sehen 😉

Die Rückseite habe ich auch ganz ansehnlich mit einer Schranktür (aus der Max Bahr Insolvenz damals), die ich weiß lackiert habe, gelöst. Mit zwei Scharnieren angebracht voll funktional. Unten ein kleiner Spalt, der zum Einen der Breite der verwendeten Holzleisten unten und oben geschuldet ist, zum Anderen aber natürlich komplett absichtlich für die Durchführung der Kabel so gelassen wurde:

Hier dann das geöfnete Türchen mit all seinem Chaos dahinter. Es kann alles im Kasten zum Transport verstaut werden. Mehr oder weniger sicher. Man sieht unten den Platz für den Monitor und den Laptop. Daneben eine angeschraubte Steckdosenleiste mit genau 4 Steckplätzen: für Monitor, Laptop, Kamera und (der freie) für den Drucker. Oben dann der Platz für die Kamera und dort auch die restlichen Komponenten.


Ab jetzt ein paar mehr Details. Hier sieht man die Kamera-Ebene von unten. Eine einfache A4-Bastelspanplatte auf einfachen Holzlatten am Rahmen festgeschraubt. Darunter erkenn man zum Einen die Stativ-Schraube zur Fixierung der Kamera (die war etwas lang, daher ein „paar“ Unterlegscheiben). Zum Anderen sieht man die improvisierte Monitorhalterung. Ich musste den Standfuß abnehmen und ohne kippt der Monitor schnell. Außerdem muss er fest an seinem Platz sitzen. Also Latte angeschraubt, Metallplatte als Stütze, fertig ist die Laube.


Oben dann die Kamera vor dem Diffusor. Links daneben die angeschlossene TV-Karte (der Adapter für die TV-Karte hat einige Anschlüsse und die für die Kamera auch, daher das Gewirr). Mit den roten Cinch-Verbindern angeschlossen ist der Kamera-Auslöser (wie gesagt, ich mag Cinch-Verbindner, so kann man die Länge der Leitung beliebig anpassen). Die Schaltung für den Auslöser sieht man recht unten auf dem linken Bild. Der Experte wird einen Drehpoti entdecken. Der war nachträglich dran gebaut, da ich Probleme hatte den Auslöser zum Laufen zu bekommen. Letztlich war allerdings ein Tausch der Verbindung zum Cinch-Stecker zielführend… „Natürlich hab ich die Kabel richtig rum angeschlossen“… für’n Ar…

Hier dann noch der Arduino mit der Verbindung zur Kameraschaltung und zum Auslöse-Schalter. Der Schalter ist ein einfacher Baumarkt-Unterputzschalter (auch aus der Max Bahr Insolvenz). Den habe ich in einen selbstgebastelten Holzkasten eingesetzt, der ebenfalls mit weißem Kunstleder verkleidet ist.


Und nun, das worauf jeder wartet, ein Video indem ich das Ganze vorführe und wo es dämliche Bilder von mir zu sehen gibt 😉

Es startet mit der Slideshow. Nach drücken des Schalters startet das Livebild und der Countdown. Ich schaue eigentlich die ganze Zeit in die Kamera. Bei der Aufnahme des letzten Bilds sieht man aber mal den Unterschied von „in die Kamera schauen“ und „auf den Monitor schauen“. Das ist auch leider ein Problem gewesen, viele haben halt die ganze Zeit auf den Monitor geschaut. Beim nächsten Mal würde ich das Live-Bild eher ausblenden und irgendwie einen Hinweis oder sonstiges machen, wo das Vögelchen kommt.

Nach den 4 Aufnahmen startet wieder die Slideshow, zunächst ohne die neue Collage. Den Neustart der Slideshow erkennt man, als für kurze Zeit der Mauszeiger oben links auftaucht. Normalerweise schiebe ich den immer aus dem Bild, aber hier war er ganz hilfreich um das zu demonstrieren. Dann setzt die Slideshow wieder per Zufall ein und das Bild wird dann auch am Ende des Videos angezeigt.

Ich muss zugeben, ich hab mir relativ wenig Mühe mit dem Video gegeben. Zu merken an der schlechten Ausleuchtung, dem schiefen Bild, dem fehlenden Ton (Youtube lässt einen den Ton ersetzen, was ganz praktisch war 😉 Vlogger werde ich wohl in absehbarer Zukunft eher nicht…

Letzten Endes gab es als ich den Kasten nach längerem Rumstehen für die Doku hier wieder reaktiviert habe noch ein kleines „Ochnöö…“:

Das ist leider kein cooles Hintergrundbild. Allerdings funktioniert alles noch, sogar der Touchscreen-Touch. Und ich habe ja vorne den Monitor noch im Kasten…


Tinkering Tuesday – TV over IP Teil 2 – Fritz!WLAN DVB-C mit dem Raspberry Pi und Kodi

Wie aus dem letzten Tinkering Tuesday Post hervorgeht, habe ich mein TV-Signal mit Hilfe des Fritz!WLAN Repeater DVB-Cs ins Netzwerk gebracht um auch im Wohnzimmer TV-Empfang zu haben ohne Kabel durch die (Miet-)Wohnung ziehen zu müssen. Dafür ist allerdings wie schon erwähnt ein irgendwie geartetes Empfangsgerät am Fernseher notwendig. Das ganze muss frauenfreundlich für nicht technik-affine Menschen geeignet sein, also am besten irgendwas Media Center mäßiges mit möglichst einfacher Steuerung.

Da ich einen Raspberry Pi Model B mein eigen nenne, ist das natürlich die erste Anlaufstelle. Vor allem da ich schonmal damit ein bisschen rumprobiert habe und durch Zufall mal bemerkt habe, dass der Pi auch die Fernbedienungssignale meines Samsung Fernsehers per HDMI-CEC verarbeitet. Frauenkompatibilität Bedienungskomfort: 1A.

Nachfolgend also meine Erfahrungen mit dem Raspberry Pi (1 und 2, dazu später mehr) in Verbindung mit dem TV-Signal, dass der Fritz!WLAN DVB-C ins Heimnetzwerk einspeist. Wie man auch im Folgenden sieht, werde ich keine Anleitungen von anderen Seiten ausführlichst kopieren, wenn das nicht notwendig ist, wer also eine bebilderte Anleitung will, möge bitte dem jeweiligen Link folgen oder wenn das nicht reicht auch gerne fragen 😉

Kodi-Distributionen auf dem Raspberry

Das generelle Vorgehen ist stets das selbe:

Da AVM selbst eine Anleitung für Kodi anbietet und auch den Raspberry Pi als geeignet ansieht hab ich mich für auch dafür entschieden. Die jeweilige Distribution installiert und den SSH Zugriff aktiviert (wird bei der Ersteinrichtung abgefragt). Bei der Ersteinrichtung hatte ich im Übrigen auch schon Probleme bei OpenELEC 6… Beim ersten Start blieb der Bildschirm blau (das Hintergrundbild), beim zweiten Start kam ich schon in den Home-Screen, bekam aber keinen Einrichtungsassistenten angezeigt und konnte auch die OpenELEC Settings nicht manuell starten, erst beim dritten Start wurde der Assistent angezeigt.

Per HDMI verbunden funktionierte meine Samsung TV-Fernbedienung per CEC auf Anhieb. Ich brauchte also nicht einmal eine Maus oder Tastatur für die Einrichtung anschließen. Sehr gut.

Der Anleitung unter http://avm.de/service/fritzwlan/fritzwlan-repeater-dvb-c/wissensdatenbank/publication/show/1608_TV-Programm-mit-Kodi-wiedergeben/ folgend habe ich mir die Senderlisten aus dem Repeater-Menü unter http://fritz.repeater heruntergeladen, sortiert und HD und SD-Sender zusammengeführt. Dann per WinSCP die Datei in den Home-Pfad des Raspberry Pi laden.

Auch bei AVM beschrieben ist die Einrichtung des PVR IPTV Simple Client, der in den Addons aktiviert und konfiguriert werden kann (in der Konfiguration „Lokaler Pfad (einschließlich lokales Netzwerk)“ auswählen und den Pfad zur M3U-Datei angeben).

Den Eintrag „LiveTV“ muss man noch in den Optionen (Live TV -> Allgemein) aktivieren. Dort kann man auch einstellen, dass beim Start von Kodi automatisch der letzte Sender im Vordergrund wiedergegeben werden soll (also sofort TV-Bild – noch ein Pluspunkt bei der Benutzerfreundlichkeit).

OpenELEC 6.0.0 auf Raspberry Pi 1 Model B

Nun also zu den Erfahrungen, die ich so gemacht habe. Wie beginnt man: indem man sich die neueste Version holt und loslegt. Ich hab mir also die aktuellste OpenELEC -Version für den RPi, 6.0.0, heruntergeladen und nach obiger Anleitung installiert.

TV gestartet: Leider ruckelt es…


Mein erster Optimierungsansatz: war der hier gefundene: http://www.kodinerds.net/index.php/Thread/42268-IPTV-Simple-PVR-Addon-und-FRITZ-WLAN-Repeater-DVB-C/

Also in der advancedsettings.xml folgendes hinzugefügt:

<buffermode>1</buffermode> <!– Comment: Default is 1 –>
<cachemembuffersize>0</cachemembuffersize> <!– Comment: Default is 20971520 bytes or 20 MB –>
<readbufferfactor>10.0</readbufferfactor> <!– Comment: Default is 1.0 –>

Leider keine Besserung.

Ein Blick in die Systeminfo bescheinigt auch bei laufendem TV-Bild eine CPU-Auslastung von 100%. Was macht man da? Übertakten, richtig!

Ein moderates overclocking nach dieser Anleitung http://www.htpcbeginner.com/overclock-raspberry-pi-openelec/ hat aber leider auch nichts gebracht.

OpenELEC 6.0.0 auf Raspberry Pi 2 Model B

Also hab ich mir erst einmal einen Rapsberry Pi 2 ausgeliehen. Siehe da, damit funktioniert es ruckelfrei mit OpenELEC 6.0.0. Allerdings zeigt auch hier die Systeminfo eine Auslastung von 70%. Da muss doch noch was gehen. Ich gebe nicht so leicht auf.

OpenELEC 5.0.8 auf Raspberry Pi 1 Model B

Nächster Schritt ist also meinen Pi erster Generation mal mit der alten OpenELEC-Version 5.0.8 laufen zu lassen. Ohne Overclocking schon deutlich flüssiger, allerdings immer noch bei 100% Auslastung und nicht zufriedenstellend.

Also wird auch hier nochmal übertaktet. Nehmen wir mal die nächsthöhere Übertaktungsstufe „Medium“. Das Ergebnis ist, dass die HD-Sender einwandfrei laufen, es sei denn das Menü wird zusätzlich eingeblendet, dann ruckelt es. Die SD-Sender laufen leider immer noch nicht. Komisch, ich hätte es eher andersherum erwartet. Scheint was mit der Skalierung zu tun zu haben?! Keine Ahnung.

XBian (2016.01.02) auf Raspberry Pi 1 Model B

Einen letzten Versuch, da ich gehört habe, dass es generell performanter laufen soll als OpenELEC, starte ich mit XBian. Allerdings lief damit schon das Menü derart hakelig (trotz automatisch eingestellter Übertaktung), dass es keinen Spaß macht. Trotzdem alles wie vorher konfiguriert und, wer hätte es anders erwartet, das TV-Bild startet nicht einmal wirklich.

Fazit – OpenELEC 5.0.8 auf Raspberry Pi 2 Model B

Letztendlich wird also ein Raspberry Pi 2 sein Werk verrichten. Der Test mit OpenELEC 5.0.8 bescheinigt das beste Ergebnis. Alles läuft flüssig bei gerade einmal 10-15% CPU Auslastung.

HDMI-CEC Raspberry Pi – Samsung Anynet+

Wie schon geschrieben funktioniert die Samsung-Fernbedienung auf Anhieb. Allerdings haben sich schon einige Unzulänglichkeiten herausgestellt. Diese werde ich bei Gelegenheit noch einmal näher verfolgen. Beim LiveTV funktionieren die ChannelUp- und ChannelDown-Tasten manchmal ganz gut, manchmal führen sie aber wohl auch zu einem Absturz von Kodi. Es wird zumindest der Kodi-Splashscreen angezeigt, dann wieder in das Menü gesprungen und (zumindest, wenn man wie oben beschrieben eingestellt hat, dass bei Start der letzte Sender angezeigt werden soll) LiveTV mit dem gewechselten Sender angezeigt. Letztlich also das richtige Ergebnis, allerdings mit einer Umschaltzeit von ca. 30-45 Sekunden ziemlich inakzeptabel.


Tinkering Tuesday – Blogging Workflow – Word Publishing

Wie letzte Woche versprochen gibt es heute meinen Blogging Workflow. Da ich viel am PC mache, muss es natürlich darauf ausgelegt sein dort möglichst effizient Screenshots einzubinden. Als ich mich auf die Suche gemacht hab, hat sich sehr schnell Microsoft Word als eine mögliche Lösung dargestellt.

Da gibt es allerdings zwei Wege, die ich ausprobieren möchte. Zum einen direktes Publizieren aus Word heraus und zum anderen die Konvertierung mittels eines Plugins.


Beim ersten Programming Pursday hab ich ja schon ein bisschen was zu meinem Workflow erklärt, ich nutze Greenshot für die Screenshots. Das habe ich für den jetzigen Workflow etwas umkonfiguriert, sodass es nicht mehr den Dateipfad des Screenshots in die Zwischenablage kopiert, sondern das Bild direkt. So kann ich es ganz einfach in das Word Dokument einfügen.

Trotzdem lasse ich die Bilder sicherheitshalber in den Standardpfad speichern. Manchmal muss es doch eben schnell gehen und schon ist die Zwischenablage überschrieben und das Bild futsch.

Publishing direkt aus Word

Heute zunächst das direkte Publishing. Dazu öffnet man Word, wählt im Datei-Menü „Neu“ und dann „Blogbeitrag“.

Beim ersten Einrichten wird man gefragt, welchen Blog man einrichten möchte. In meinem Fall ist das WordPress

Dann nur noch Kontoinformationen und URL eingeben. Schon fertig.

Dann kann man seinen Blogbeitrag schreiben, inkl. Bildern.

Eine Kategorie kann man auch auswählen, nachdem man einmal auf den Button „Kategorie einfügen“ geklickt hat.

Dann kann man direkt Veröffentlichen, oder so wie ich erstmal als Entwurf.

Das Ergebnis kann sich sehen lassen. Die Überschriften sind als HTML-Überschriften <h#> umgesetzt, die Bilder direkt eingebettet. Da bin ich mir noch nicht ganz sicher, wie ich die gerne formatiert hätte. In meinen beiden vorherigen Posts hatte ich sie als Vorschau angezeigt und dann per Klick die Datei in einem neuen Tab geöffnet. Wenn ich mir recht überlege aber eigentlich blöd. Das nervt mich auch immer beim Lesen, wenn ich erst drauf klicken muss und dann auch noch den neuen Tab wieder zumachen muss um wieder zum Artikel zu kommen.

Weitere Tests habe ich für Links und für für verschiedene Formatierungen, vor allem von Programmiercode, gemacht. Das Ergebnis sieht folgendermaßen aus:

Leider nicht ganz, was ich mir erhofft hatte. Der Link wurde umgesetzt, der Quelltext ist aber nicht sonderlich schön geworden. Im Quellcode sieht man dann, dass er lediglich die Schriftart übernommen hat. Naja. Irgendwie auch verständlich. Da muss ich mir also noch etwas anderes ausdenken bzw. mal geeignete WordPress Code-Formatting Plugins googlen.

Leider lässt sich auch kein Beitragsbild festlegen, welches ich gerne nutze. Und verschlagworten lässt sich der Beitrag auch nicht.

Was mich bei der ganzen Angelegenheit auch etwas unsicher macht ist der Dialog der angezeigt wird, wenn man sich zum Blog verbindet:

Das ist nicht gerade vertrauenserweckend und eine kurze Recherche hat auch ergeben, dass das XML-RPC Verfahren nicht gerade das sicherste ist.


  • Ein bisschen mehr WYSIWYG als Notepad durch direktes Einfügen von Bildern
  • Nicht so umständliches Einfügen von Bildern wie direkt in WordPress
  • Nur Überschriften und Standardformatierungen ohne Probleme möglich
  • Kein Beitragsbild
  • Keine Schlagworte
  • Unsicherer Übertragungsweg