052117_1850_TinkeringTu1.jpg

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.

UPDATE

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 😉

 

Links

http://faire-ca-soi-meme.fr/domotique/2017/05/09/test-xiaomi-power-socket/

http://faire-ca-soi-meme.fr/hack/2017/04/24/hack-xiaomi-mi-smarthome-decouverte-de-clef/

http://faire-ca-soi-meme.fr/domotique/2017/04/15/test-xiaomi-mijia-6-in-1-smart-home/

http://faire-ca-soi-meme.fr/domotique/2017/04/04/detournement-capteur-de-mouvement-xiaomi/

http://faire-ca-soi-meme.fr/domotique/2017/03/13/hack-xiaomi-mi-smarthome-zigbee-sniffer/

http://faire-ca-soi-meme.fr/domotique/2017/02/27/hack-xiaomi-mi-smart-temperature-and-humidity-sensor/

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

050317_1802_TinkeringTu1.jpg

Tinkering Tuesday – HUEify – PWM to RGB LED strip driver Board

Today I want to show you the board that I created in order to drive 4 RGB LED strips from 16 PWM outputs of the Arduino Mega. It is not the best design as this is my first board and I began without really knowing how to connect the strips in the end 😉 This board connected to the Arduino Mega controlled by the output of the JN5168 will then be the final solution to integrate light in to our nightstands.

I built the design in fritzing so let’s have a look at it:

  • J3, J5, J7, J9 are the connectors (male pin headers) for the PWM pins from the Arduino Mega
  • J2, J4, J6, J8 are also male pin headers to connect the RGB strips
  • J1 ist the input for the external power source (5V in my case) also as male pin headers
  • J22 are additional ground pins to connect the ground from the Arduino (I connected three because you never know…)
  • Q1 – Q12 are MOSFETs, in my case BUZ11

On the board I put all ground connections to the second PCB side (orange) so the connections are clear.

When I had already started soldering the board I thought about how I wanted to connect the RGB strips in the final setup and I decided to go with commonly available 4 wire RGB strip cable (can be found on ebay) and connect it via screw terminals. I was not able to change the design I already started so I just added another board (in the end I had enough space on the same board) which had four 4-pin headers again directly connected to four 4-output (okay, it’s eight 2-output) screw terminals:

I did not put much effort in making the fritzing pretty so the schematic view is a real mess and in the breadboard view I just used perfboard without any wire connections. So essentially just use the PCB view. It should be obvious. Anyway I would modify the board to make direct connections to the screw terminals if you want to use it. But it is working now and it is my first completely self designed and soldered board J

You can download the fritzing file here: 16PWMIn_4RGBOut

This is the progress with the first working module (I already showed a work in progress version in the previous post):

This is the final board including all terminals and pin headers. I even have space to include the logic level converter (LLC) that I need for the JN5168. This way I can directly connect the grounds all on this board. This is not yet soldered because I ran out of solder wire.

This is the board connected to the Arduino and currently directly from the pin headers to the RGB strips.

I put together a small sketch that activates the colors one after the other on all 4 strips. You can download it here: Arduino_Mega_4_RGB_Strip_Color_Test

This is a video of the Arduino Mega controlling all 4 strips via PWM signals from 16 pins:

Next task is to solder the LLC and reconnect the JN5168. Then I have to prepare the wires to connect from the screw terminals to the RGB strip (needs a little soldering and heat shrink tubing). This will then suffice to control all 4 strips with the same setting (one endpoint) but the final piece will then be to create 4 endpoints on the JN5168 to control the 4 strips independently.

042117_1148_TinkeringTu2.jpg

Tinkering Tuesday – HUEify – JN5168 to Arduino Mega PWM extension

The JN5168 chip itself has only 5 PWM outputs and thus is not able to control more than one RGB LED strip. To overcome this I want to connect an Arduino Mega to the JN5168. The Mega has 15 PWM outputs so up to 5 RGB strips can be connected. To connect the two devices I chose to use the standard UART serial interface that is activated by default in the NXP demos. In this post I will describe how to connect the two devices and what to do to make the Arduino understand commands from the JN5168.

Hardware serial connection from JN5168 to the Arduino

As the Arduino is using 5V level on the serial connection and the JN5168 is using 3.3V a logic level converter (LLC) has to be used. This little device connects the two serial interfaces shifting from 5V to 3.3V. The connection can be seen in the following image (to drive the JN5168 from the Arduino connect an additional wire from the 3V3 pin of the Arduino to PIN 17 of the JN5168):

Connecting the JN5168 to the Arduino Mega via logic level converter
Connecting the JN5168 to the Arduino Mega via logic level converter

Software serial connection from JN5168 to the Arduino (JN5168 program)

I used the default UART port of the JN5168 because of two reasons:

  1. It is activated by default and the demos are already making use of the output
  2. I didn’t connect any additional wires than the ones that need to be connected to flash the chip and use the PWM output and the default UART is also used to flash the firmware

To have a more stable connection to the Arduino I reduced the baud rate from 115600, which is the default rate, to 9600 which the Arduino can handle better. To do this in the file app_start_light.c go to the function vAppMain() and search for the line :

DBG_vUartInit(DBG_E_UART_0, DBG_E_UART_BAUD_RATE_115200);

and change it to:

DBG_vUartInit(DBG_E_UART_0, DBG_E_UART_BAUD_RATE_9600);

Do the same in the function vInitialiseApp() in the same file.

I tried two different approaches to send output to the arduino:

  1. Use the debug output of the TRACE_LIGHT_TASK / DEBUG_LIGHT_TASK
  2. Define a custom debug flag to directly output the PWM signal.

As I didn’t have success yet creating multiple RGB endpoints and am waiting for PeeVeeOne to publish his work on multiple endpoints, I first went with option 2 which is currently not able to hand over an identifier for the endpoint which the option 1 is able to. The second option has the advantage that it handles smooth transitions, which the other one doesn’t. Once I am able to create more endpoints I may create another output. I will describe both solutions anyway:

Option 1: TRACE_LIGHT_TASK

First, activate the debug flag in the Makefile:

CFLAGS += -DDEBUG_LIGHT_TASK

Then go to the file app_zcl_light_task.c and search for

DBG_vPrintf(TRACE_LIGHT_TASK

I modified the first appearance (in APP_ZCL_cbEndpointCallback) of the function, where it outputs a new line and the RGBL (Red, Green, Blue, Level) values to include an identifiying symbol (§) and the endpoint:

DBG_vPrintf(TRACE_LIGHT_TASK, "\n§ EP %d R %d G %d B %d L %d ",
psEvent->u8EndPoint, u8Red, u8Green, u8Blue, sLight.sLevelControlServerCluster.u8CurrentLevel);

There is a second appearance in the same file and the same function (APP_ZCL_cbEndpointCallback ) where I did the same thing again.

In the file App_Light_ColorLight.c there are two other usages of the function which handle the identification effect. In the function APP_vHandleIdentify() there is currently no handle for the endpoint available so I didn’t modify this one. In the vIdEffectTick() there is an endpoint reference available so I added this similar to the function call above.

DBG_vPrintf(TRACE_LIGHT_TASK, "§ EP %d R %d G %d B %d L %d Hue %d Sat %d\n",
u8Endpoint,
u8Red,
u8Green,
u8Blue,
sLight.sLevelControlServerCluster.u8CurrentLevel,
sLight.sColourControlServerCluster.u8CurrentHue,
sLight.sColourControlServerCluster.u8CurrentSaturation);

In the end the Arduino will receive a message will look like this:

§ EP 10 R 255 G 227 B 139 L 147 Hue 0 Sat 0 X 24939 Y 24701 M 1 On 1 OnTime 0 OffTime 0

This one call will result in 10 PWM changes in the JN5168 to have a nice transition. This is why I currently go with the second option:

Option 2: TRACE_PWM

First, I defined and enabled a new debug flag in the Makefile:

CFLAGS += -DDEBUG_PWM

Then in the file DriverBulb_JN516X_RGB.c I added the following to the definition section at the beginning:

#ifdef DEBUG_PWM
#define TRACE_PWM TRUE
#else
#define TRACE_PWM FALSE
#endif

Then, in the function DriverBulb_vOutput() I added the following after the calls to vAHI_TimerStartRepeat at the end:

#if TRACE_PWM
DBG_vPrintf(TRACE_PWM, "\n# EP %d On %d R %d G %d B %d L %d",
(uint8)10,
bIsOn,
u8Red,
u8Green,
u8Blue,
u8CurrLevel
);
#endif

Together with the first option this will result in the following output (as I said it produces a smooth transition):

§ EP 10 R 255 G 227 B 139 L 147 Hue 0 Sat 0 X 24939 Y 24701 M 1 On 1 OnTime 0 OffTime 0
# EP 10 On 1 R 170 G 151 B 92 L 170
# EP 10 On 1 R 167 G 148 B 91 L 167
# EP 10 On 1 R 165 G 146 B 89 L 165
# EP 10 On 1 R 162 G 144 B 88 L 162
# EP 10 On 1 R 160 G 142 B 87 L 160
# EP 10 On 1 R 157 G 139 B 85 L 157
# EP 10 On 1 R 154 G 137 B 83 L 154
# EP 10 On 1 R 152 G 135 B 82 L 152
# EP 10 On 1 R 149 G 132 B 81 L 149
# EP 10 On 1 R 147 G 130 B 80 L 147

You can also see that the RGB values changed. This is according to the level value. The calculation is:

/* Scale colour for brightness level */
u8Red = (uint8)(((uint32)u8CurrRed * (uint32)u8CurrLevel) / (uint32)255);
u8Green = (uint8)(((uint32)u8CurrGreen * (uint32)u8CurrLevel) / (uint32)255);
u8Blue = (uint8)(((uint32)u8CurrBlue * (uint32)u8CurrLevel) / (uint32)255);

The level is not really necessary in the output because the RGB values are already adjusted. I kept them anyway.

Software serial connection from JN5168 to the Arduino (Arduino program)

For the Arduino part I first setup the serial connection (I connected it to Serial2) and read the input. Based on the first character (§ or # are the relevant ones for the two options) the program decides whether the whole line is relevant.

Then it parses the input line using the function strtok(). Then I set the PWM using analogWrite(pin, value).

The serial input is lagging sometimes (though I think this is only the case when using the serial output to the other serial port) so garbage is getting read as a line. In case of not set values I checked whether the value is correctly set. Otherwise the old value is used. This may lead to wrong values but better than nothing.

My currently used Arduino sketch (using only one PWM output) can be downloaded here:

SerialReadPWMFromJN5168

Conclusion

This may not be the best way of communication (SPI may be better) but it is the easiest to setup. To command 4 separate endpoints I may have to use option 1 and go without transitions or implement them myself on the arduino. The bottle neck seems to be the serial connection as the arduino seems to be too slow to process the serial input fast enough. This is another argument for option 1 as it sends fewer lines. Although it is sending more than one line for a simple light change, too. Maybe the app itself also sends several commands to have a nice transition. I may check this later on. In any case I recommend disabling all other debug outputs to make better use of the serial communication and loose fewer lines.

Currently I am also building a board to connect everything together. It will not be very professional (as I will be using many jumper wires instead of connecting everything directly but I want to be flexible) but should work for me. It will be hidden away anyway. The board connected to the Arduino and the serial connection to the JN5168 can be seen in the upper left with one temporarily connected RGB strip. In the final version they will be connected with screw terminals. The LLC will also go from the breadboard to the custom board.

The completed serial connection from JN5168 to Arduino Mega and custom PWM to RGB LED adapter board
The completed serial connection from JN5168 to Arduino Mega and custom PWM to RGB LED adapter board

This is the current progress with connections ready for two RGB strips.

Custom PWM to RGB LED strip adapter board (work in progress)
Custom PWM to RGB LED strip adapter board (work in progress)

There will be 4 RGB connections in the final version to be connected with screw terminals, the LLC and a connection for an external power source. This is all still work in progress so I will publih the final schematics when I am ready and know that everything is working as expected. And of course I hope that the weather will be getting better here so I can disassemble our night desks and get them to my workbench (actually my balcony which is why I am hoping for good weather 😉

Working_Prototype

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

***********************************************
LIGHT NODE RESET
***********************************************
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:

***********************************************
LIGHT NODE RESET
***********************************************
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 );
vTryNwkJoin();
}

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.

031317_2050_TinkeringTu9.jpg

Tinkering Tuesday – HUEify RGB Strips mit dem NXP JN5168

Wie schon angekündigt soll unsere Nachtkonsolenbeleuchtung mittels eines ZigBee Light Link kompatiblen Chips, dem NXP JN5168, an das Philips Hue System angeschlossen werden. Peter Visser, alias PeeVeeOne (www.peeveeone.com) hat da eine super Vorarbeit geleistet.

Die benötigten Teile sind mittlerweile da. Das ist zum einen der Chip selbst (Amazon: RF MOD, IEEE802.15.4, STD PWR, INT ANT JN5168-001-M00Z By NXP) und dann ein relativ beliebiger FTDI zu USB Serial Converter.

JN5168 anlöten und neue Firmware aufspielen

Da sich meine Lötkünste schon im normalen Bereich, also einem Rastermaß von 2,54mm eher so in Grenzen halten, war ich mit dem Breakout der Pins vom JN5168 maßlos überfordert. Coolerweise war auch mein Lehrmeister in Sachen Elektronik (www.doktor-andy.de) begeistert von dem Projekt, sodass er sofort bereit war mir das anzulöten. Mit einem Schluck Bier und daraus folgender ruhiger Hand am Montagabend wurden dann mit dünnem Kupferdraht die benötigten PINs herausgeführt:

Andy mein Lötmeister! Er sei gepriesen!
Die erste Kupferleitung ist angelötet

Wirklich notwendig für das Projekt sind:

  1. Pin 3 (SPIMISO): der muss auf GND gelegt werden um den Chip programmieren zu können
  2. PIN 17 (VDD): 3,3V (wichtig, am FTDI nicht vergessen von 5V auf 3,3V umzustellen)
  3. PIN 18 (GND): Ground
  4. Pins 19, 20, 21 (DIO 11-13): dies sind die PWM Pins, die für die Ansteuerung des RGB-Strips benötigt werden

Wir haben zusätzlich noch Pin 22, den Reset-Pin, herausgeführt, aber letztlich garnicht benutzt. Kurz stromlos stellen geht auch.

20170306_190156
Kleine Spinnenbeine aus Kupfer

 

Mit blieben dann nur kleine Zuarbeiten, wie etwa das Auftrennen der Streifenrasterplatine in der Mitte:

20170306_190222
HiWi Boris bei der Arbeit

Auf dem Breadboard mit dem FTDI verbunden (Rx an Tx und umgekehrt…):

Die Programmierung ging nach Anleitung von www.peeveeone.com beim ersten Versuch gleich durch. Erst den EEEPROM löschen:

Dann die neue Firmware aufspielen:

Freudig erregt bin ich nach Hause gefahren und hab die Philips Hue App angeschmissen und die Bridge auf die Suche nach dem neuen Lichtlein geschickt. Wichtig ist erst die Suche zu starten, dann den Strom am JN5168 anschließen. Und wer hätte es gedacht: Sofort erkannt!

Angezeigt wird sie als „Color Light 1“

Also auf zum nächsten Schritt, den RGB-Strip ansteuern.

RGB-Strip an Arduino betreiben

Damit ich mir den JN5168 nicht gleich verbrate, weil ich irgendwas nicht korrekt angeschlossen hab, wird erstmal mit dem Arduino die Verkabelung getestet. Dazu nutze ich im Grunde das Anschlussdiagramm von Adafruit aus dem RGB-Strip-Tutorial. Ich habe mich für die Nutzung von MOSFETs entschieden und habe bei Conrad den BUZ11 besorgt. Davon 3 angeschlossen und den Beispiel-Code von Adafruit aufgespielt bringt das gewünschte Ergebnis:

Das einzige was auffällt ist, dass der RGB-Strip nicht korrekt beschriftet ist. Die Pins sind wie folgt gekennzeichnet: + – R – G – B allerdings ist die eigentliche Belegung + – R – B – G. Naja, zum Glück ist wenigstens der + Pin richtig…

Nun gut, dann geht es ans Eingemachte. Die PWM-Pins wurden an den JN5168 angeschlossen, GND entsprechend mit an GND vom Arduino angeschlossen und auch der 3,3V Anschluss vom Arduino an den VDD vom JN5168 angeschlossen. Hier ein Video vom ersten anschalten:

Mehr gab es beim ersten Mal leider nicht zu bewundern, da der Empfang in meinem Arbeitszimmer so schlecht war, dass die meiste Zeit nichts passiert ist. Am nächsten Abend habe ich die Schaltung ins Wohnzimmer rübergebracht. Dabei hatte ich einige Kabel abgemacht um es separat zu tragen. Danach habe ich erstmal 1,5h damit verbracht das Ganze wieder zusammenzusetzen und herauszufinden warum „genau der gleiche Aufbau“ einfach nicht funktioniert. Weder am Arduino noch am JN5168 hat der Strip geleuchtet. Bis ich dann am Abend gemerkt habe, dass ich ein GND-Kabel auf der anderen Seite des Breadboard Siderails angeschlossen habe und nicht bedacht habe, dass die in der Mitte nochmal getrennt sind (im Bild mit rot gekennzeichnet und dann auch mit einem Jumper-Kabel überbrückt)…

Am Wochenende wurde dann alles nochmal richtig getestet und verkabelt und siehe da, es wird Licht und die Farben ändern sich. Allerdings leider nicht ganz so wie erhofft. Grün geht, blau geht, rot irgendwie nicht so richtig und das wichtigste: der Strip lässt sich nicht ausschalten sondern wird dann einfach komplett hell. Spricht eigentlich ja dafür, dass da was mit Common Anode / Common Cathode LED verkehrt läuft, aber eigentlich sollte das alles korrekt sein. Hier mal als Video:

Als erstes habe ich dann den Strip nochmal an den Arduino angeschlossen und geschaut, ob ich bei direkter Ansteuerung jeweils einer Farbe die entsprechenden LEDs zum Leuchten bringen kann. Das funktioniert.

Das erste was ich nun tun werde ist mir nun die Verkabelung am JN5168 nochmal zu Gemüte führen (also mal nur jeweils einen Kanal des Strips anschließen und schauen wie sich die jeweilige LED verhält). Dazu wird dann die Entwicklungsumgebung von NXP installiert und dort etwas geforscht. Das ist da wo der eigentliche Spaß beginnt! Der Doku kann man entnehmen, dass man mehrere Endpoints (also mehrere Lampen) auf einem Chip konfigurieren kann. Außerdem kann man den Chip auch als Aktor (also als Lichtschalter / Dimmer Switch) konfigurieren. Nicht ganz eindeutig ist, ob man auch einen Mischbetrieb fahren kann. Wenn ich richtig lese, dann nicht. Aber das werde ich trotzdem ausprobieren. Aber dafür muss erstmal wieder Zeit her.

Amazon Dash Button zur Philips Hue Steuerung

Programming Pursday – Amazon Dash Button Hack auf einem QNAP NAS um Phillips Hue zu steuern

Wenn man im Netz auf die Suche geht um einen günstigen Weg zu finden Philips Hue Lichter zu steuern, trifft man unter anderem auf den Amazon Dash Button. Also habe ich mir auch mal einen besorgt, da ich eh gerade neue Geschirrspültabs brauchte. Heute mal als Programming Pursday und nicht als Tinkering Tuesday, da es eigentlich alles rein Software-seitig abläuft und hauptsächlich ein bisschen Skripting in Python ist.

Einrichtung

Erstmal bin ich der normalen Einrichtung über die Amazon Shopping App gefolgt und habe mir die Tabs bestellt um meine 4,99 Euro wieder zu bekommen. Hat super geklappt. Danach geht man wieder in die App und wählt unter „Mein Konto“, „Dash Geräte“, „Geräte verwalten“ seinen Dash Button aus und deaktiviert ihn. Danach kann man ihn direkt neu einrichten (selbes Prozedere), bricht aber im letzten Schritt, wo man ein Produkt auswählen soll mit dem X in der rechten oberen Ecke ab. Die Sicherheitsabfrage bestätigt man und sieht dann in der Geräteverwaltung auch den Warnhinweis:

Warnhinweis bei unvollständiger Einrichtung
Warnhinweis bei unvollständiger Einrichtung

Beim ersten Drücken bekommt man auch in der App einen Hinweis, dass der Button nicht korrekt eingerichtet ist.

Zusätzlich kann man sicherheitshalber noch den Button im Router für die Kommunikation nach außen sperren (z.B. über die Kindersicherung der Fritz.Box).

Dash Button Knopfdruck auf dem QNAP erkennen

Da es im Netz widersprüchliche Anleitungen und diverseste Wege gibt um den Amazon Dash Button für andere Zwecke zu nutzen. Die Anleitung unter https://blog.thesen.eu/aktuellen-dash-button-oder-ariel-etc-von-amazon-jk29lp-mit-dem-raspberry-pi-nutzen-hacken/ ist auf den deutschen Button ausgelegt, also genau richtig für meine Zwecke. Allerdings wird da beschrieben, dass man ein Produkt auswählen muss. Das ist aber nicht richtig, wenn man den Schritten oben folgt.

Um den Dash Button für andere Zwecke zu nutzen braucht man ein Gerät, das ständig den Netzwerkverkehr auf entsprechende Pakete überwacht. Im Fall von Dash sind das UDP-Pakete, die der Button beim Anmelden im WLAN aussendet. In meinem Fall soll das mein QNAP NAS sein, das eh immer an ist und über ein Python Programm. Über das App Center auf dem QNAP hatte ich bereits Python 2.7.3 installiert.

Das Python-Skript in der Anleitung benutzt zusätzliche 2 Pakete:

  • Scapy
  • Tcpdump

Scapy habe ich nicht so einfach installiert bekommen, dazu habe ich erst den Python Installer pip installiert. Eine gute Anleitung hierzu findet man unter http://gleenders.blogspot.de/2014/04/install-python-pip-on-qnap-nas.html. Dabei muss man beachten, dass man in den Befehlen „MD0_DATA“ durch den Namen seines Volumes (in meinem Fall „CACHEDEV1_DATA“) ersetzt.

Danach ganz einfach in der SSH-Konsole den folgenden Befehl ausführen:

pip install scapy

TCPDump ist über entware-ng ganz normal über den Befehl opgk zu installieren (hatte ich schonmal gemacht, Anleitung gibt es unten auf der Seite):

opkg update
opkg install tcpdump

Das Skript aus der Anleitung habe ich in einen separaten Freigabeordner „Skripting/AmazonDash“ gelegt, den ich mir extra dafür angelegt habe. Allerdings gab es beim ersten Drücken des Buttons einen Fehler:

Fehler im Skript
Fehler im Skript

Ein bisschen Recherche im Internet und ich habe das Skript etwas angepasst (ich habe auch den Aufruf von FHEM rausgenommen, da ich das nicht nutze, sondern ja später Philips Hue direkt ansprechen möchte). Hier mein Skript:

from datetime import datetime
import logging
# Constants
timespan_threshhold = 3
# Globals
lastpress = datetime(1970,1,1)
logging.getLogger("scapy.runtime").setLevel(logging.ERROR)
from scapy.all import *
def button_pressed_dash1():
global lastpress
thistime = datetime.now()
timespan = thistime - lastpress
if timespan.total_seconds() > timespan_threshhold:
current_time = datetime.strftime(thistime, '%Y-%m-%d %H:%M:%S')
print 'Dash button pressed at ' + current_time
lastpress = thistime
def udp_filter(pkt):
options = pkt[DHCP].options
for option in options:
if isinstance(option, tuple):
if 'requested_addr' in option:
# we've found the IP address, which means its the second and final UDP request, so we can trigger our action
mac_to_action[pkt.src]()
break
mac_to_action = {'ac:63:be:ac:23:1c' : button_pressed_dash1}
mac_id_list = list(mac_to_action.keys())
print "Waiting for a button press..."
sniff(prn=udp_filter, store=0, filter="udp", lfilter=lambda d: d.src in mac_id_list)
if __name__ == "__main__":
main()

Das funktionierte dann wunderbar:

Erfolgreiche Erkennung des Dash Buttons
Erfolgreiche Erkennung des Dash Buttons

Philips Hue aus Python ansprechen

Nun also der nächste Schritt, Philips Hue ansprechen. Bei mir soll der Button auf dem Nachttisch dazu dienen das Licht an- oder auszuschalten. Also muss ich mir erstmal die Szene besorgen.

Dazu habe ich mich für eine Python Library namens Qhue entschieden. Die machte einen ganz guten Eindruck. Installiert wird die Library mittels

pip install qhue

Dann erstmal das Skript qhue_example.py aus dem GitHub auf das QNAP gebracht, die IP-Adresse meiner Bridge eingefügt und mittels

python ./qhue_example.py

Ausgeführt. Man wird aufgefordert den Button auf der Bridge zu drücken und dann die Entertaste zu betätigen. Hat funktioniert, danach hat man eine Text-Datei im gleichen Ordner mit dem Usernamen für die Bridge, den man braucht. Außerdem werden einem alle Lampen in einem langen String ausgegeben.

Mit ein bisschen rumspielen und z.B. den Befehlen

print bridge.groups()
print bridge.scenes()

Findet man die IDs seiner Gruppen und Szenen. Ich bin an der Gruppe „Schlafzimmer“ und der Szene „SZ Standard“ interessiert. Für die Szene sucht man nach dem Namen und findet so etwas:

u'EMeSZzszX2OssE9': {u'picture': u'', u'locked': True, u'name': u'SZ Standard'

Interessant ist hier die ID ‚EMeSZzszX2OssE9′, die braucht man um die Szene zu aktivieren. Die Gruppe findet man auch, in meinem Fall:

u'7': {u'name': u'Schlafzimmer ', u'lights': [u'3', u'5', u'6'], u'state': {u'any_on': False, u'all_on': False}

Hier interessiert mich die ID 7, man sieht, dass die Lichter mit den IDs 3, 5 und 6 enthalten sind und das Attribut any_on sieht auch schon vielversprechend aus.

Der Plan

Wenn der Dash Button gedrückt wird, soll er erkennen, ob eine Lampe in der Gruppe „Schlafzimmer“ an ist. Wenn das der Fall ist, soll er das Licht im gesamten Schlafzimmer ausschalten, wenn keines an ist, soll die Szene „SZ Standard“ aktiviert werden.

Das Skript für den Dash Button habe ich also wie folgt angepasst:

from datetime import datetime
from os import path
from qhue import Bridge, QhueException, create_new_username
import logging
# Constants
###########
timespan_threshhold = 3
# the IP address of your bridge
BRIDGE_IP = "192.168.178.23"
# the path for the username credentials file
CRED_FILE_PATH = "qhue_username.txt"
# Globals
###########
lastpress = datetime(1970,1,1)
bridge = None
logging.getLogger("scapy.runtime").setLevel(logging.ERROR)
from scapy.all import *
def button_pressed_dash1():
global lastpress
global bridge
thistime = datetime.now()
timespan = thistime - lastpress
if timespan.total_seconds() > timespan_threshhold:
current_time = datetime.strftime(thistime, '%Y-%m-%d %H:%M:%S')
print 'Dash button pressed at ' + current_time
sfind = "uany_on: True"
st = str(bridge.groups[7]())
sgroup = st.replace("'", "")
if sfind in sgroup:
# print sgroup
print "deactivate scene"
bridge.groups[7].action(on=False)
else:
# print sgroup
print "activate scene"
bridge.groups[7].action(scene='EMeSZzszX2OssE9')
lastpress = thistime
def udp_filter(pkt):
options = pkt[DHCP].options
for option in options:
if isinstance(option, tuple):
if 'requested_addr' in option:
# we've found the IP address, which means its the second and final UDP request, so we can trigger our action
mac_to_action[pkt.src]()
break
#Dash Buttons
mac_to_action = {'ac:63:be:96:36:52' : button_pressed_dash1}
mac_id_list = list(mac_to_action.keys())
def main():
# check for a credential file
if not path.exists(CRED_FILE_PATH):
while True:
try:
username = create_new_username(BRIDGE_IP)
break
except QhueException as err:
print "Error occurred while creating a new username: {}".format(err)
# store the username in a credential file
with open(CRED_FILE_PATH, "w") as cred_file:
cred_file.write(username)
else:
with open(CRED_FILE_PATH, "r") as cred_file:
username = cred_file.read()
# create the bridge resource, passing the captured username
global bridge
bridge = Bridge(BRIDGE_IP, username)
print "Waiting for a button press..."
sniff(prn=udp_filter, store=0, filter="udp", lfilter=lambda d: d.src in mac_id_list)
if __name__ == "__main__":
main()

Autorun auf dem QNAP

Startet man das Python-Skript per SSH läuft es standardmäßig erstmal nur so lange, wie die SSH Session auch offen ist. Das soll natürlich nicht so. Daher soll ein Autorun her.

Ich habe das Skript von https://forum.qnapclub.de/thread/33522-ts-231-autorun-sh/ genutzt um das Config-Device des QNAP zu mounten und dann dort wie beschrieben eine autorun.sh anzulegen mit dem folgenden Inhalt:

#!/bin/sh
</span>cd /share/CACHEDEV1_DATA/Skripting/AmazonDash/
python dash_hue.py &

Startet man nun das NAS neu, so sollte das Skript im Hintergrund laufen. Tut es aber leider nicht. Da muss ich nochmal weiter forschen. Bis dahin behelfe ich mir damit das Skript manuell per SSH per screen zu starten:

Skript auf dem QNAP manuell im Hintergrund laufen lassen

screen
cd /share/CACHEDEV1_DATA/Skripting/AmazonDash/
python dash_hue.py

Dann Strg-A und D drücken um die Session in den Hintergrund zu schicken.

Nun kann man sich getrost aus der SSH-Session ausloggen (Putty schließen) und das Skript läuft trotzdem weiter im Hintergrund. Mit dem Befehl screen –r kann man sich auch wieder in die Session einloggen, man muss nur die richtige finden:

Screen Session im Hintergrund
Screen Session im Hintergrund

So kann man dann auch das Log sehen (es wird jeder Button Press auf die Konsole geschrieben) und das Skript beenden.

022517_1401_TinkeringTu5.jpg

Tinkering Tuesday – Philips Hue und DIY Beleuchtung unseres neuen Bettes

Philips Hue

Ich bin schon seit einiger Zeit Fan des Philips Hue Ökosystems und hab mit bei diversen Angeboten bei www.notebooksbilliger.de und www.amazon.de oder über Käufe von Bekannten schon einiges zugelegt:

Zur Steuerung und Einrichtung nutze ich hauptsächlich die App all4hue, da diese eine erweiterte Belegung der Dimming Switches ermöglicht (man kann jeden der 4 Knöpfe neu belegen und auch Funktionen für „Taste gedrückt halten“ vergeben).

Aufgeteilt sind die Lampen im Wohnzimmer und im Schlafzimmer mit jeweils einem Dimmer Switch zu steuern (das erhöht den WAF, women acceptance factor, um 100%).

Unser neues Bett

Unser neues Bett im Möbelgeschäft mit Nachtkonsolenbeleuchtung
Unser neues Bett im Möbelgeschäft mit Nachtkonsolenbeleuchtung

Nun haben wir uns allerdings ein neues Bett gekauft. Dieses hat eingebaute Nachtschränke mit Glasrückwand. Auf dem folgenden Foto sieht man, dass diese auch beleuchtet werden können. Allerdings sind die Preise dafür ziemlich unverschämt. Für die weiße Beleuchtung werden schon 316 Euro fällig, für die Version mit Farbwechsler stolze 585 Euro.

Das war es uns natürlich nicht wert für so ein bisschen LED Licht (das natürlich nicht mal mit Hue kompatibel ist).

Glücklicherweise haben die Monteure beim Aufbau des Bettes vergessen die Abschlussleisten bei den Nachtkommoden zu montieren, sodass man einen guten Blick ins Innere werfen konnte. Dort ist ganz einfach zwischen der Befestigung für den eigentlichen Schrank und den Glasrückwänden ein wenig Platz, in den dann die LEDs hineingeschoben werden können. Zusätzlich ist noch ein kleiner Ausschnitt für die Elektronik mit Loch für die Kabeldurchführung auf der Rückseite:

Platz für LED Strips in der Nachtkonsole
Platz für LED Strips in der Nachtkonsole
Auslass für Kabel hinten an der Nachtkonsole
Auslass für Kabel hinten an der Nachtkonsole

DIY Nachtschrankbeleuchtung

Erster Gedanke: Hue Lightstrip rein und gut. Leider sind die zu breit. Das Glas ist gerade mal knapp 12mm stark, daher ist der Lightstrip mit seinen 13mm zu breit. Auch die Höhe ist mit knapp 2,5mm nicht sonderlich großzügig bemessen. Im Internet recherchiert und mal den Osram Lightify LED Strip bestellt, der sollte genau 12mm breit sein. Er ist aber etwas breiter, deswegen passt auch dieser nicht.

Also hab ich mich schonmal von dem Gedanken verabschiedet das Hue Kompatibel hinzubekommen (das bleibt aber nicht so! Dazu mehr im nächsten Beitrag) und mir im Blitzangebot bei Amazon einen LED Strip von Yorbay besorgt, der eigentlich als TV Hintergrundbeleuchtung gedacht ist. Dieser hat vordergründig erstmal 3 Vorteile:

  1. Er ist nur 10mm breit, sodass er in den Schrank passt
  2. Es sind insgesamt 4 Teilstücke von jeweils 30cm enthalten inkl. Verbindungsstücken und -kabeln, was bei einer Nachttischlänge von 60cm perfekt ist (2 für oben, 2 für unten)
  3. Er hat eine integrierte Schaltung, die per IR Fernbedienung gesteuert werden kann. IR Fernbedienungen durch einen Raspberry oder Arduino zu ersetzen ist kein Problem
Yorbay LED TV Hintergrundbeleuchtung
Yorbay LED TV Hintergrundbeleuchtung

Leider ist die Höhe der vorgesehenen Schlitze im Nachttisch nicht gleichmäßig, weswegen ich ihn nochmal auseinander bauen werde um ein wenig Material vom Pressspan abzutragen. Im Moment geht der Strip aufgrund der Höhe nur an der linken Seite oben halb rein und auf der rechten Seite unten vollständig. Wegen der Verkabelung muss ich die Nachttische aber eh nochmal vom Bett abbauen, dann kann ich auch die Rückseite nochmal abnehmen.

Aber die Lichtausbeute sieht als Akzent und dezente Nachts-aufs-Klo-geh-Beleuchtung ganz gut aus:

Yorbay LED TV Hintergrundbeleuchtung unten in der Nachtkonsole
Yorbay LED TV Hintergrundbeleuchtung unten in der Nachtkonsole
Yorbay LED TV Hintergrundbeleuchtung oben in der Nachtkonsole (nur zur Hälfte)
Yorbay LED TV Hintergrundbeleuchtung oben in der Nachtkonsole (nur zur Hälfte)

Nun habe ich also zwei von diesen Sets, die beide per IR Fernbedienung gesteuert werden. Das ist als Nachttischschalter natürlich erstmal blöd. Also zunächst mal geschaut, wie man einen RGB-Strip per Arduino steuern kann. Da es sich um einen Strip mit Common Anode handelt, kann man allen Anleitungen folgen, die einen Strip (mit nicht einzeln ansteuerbaren LEDs) ansteuern, z.B. https://learn.adafruit.com/rgb-led-strips/usage. Da es sich um einen 5V Strip handelt könnte man ihn sogar direkt vom Arduino mit Strom versorgen. Ist mir bei insgesamt 2,4m aber wahrscheinlich etwas zu heiß. Außerdem sind ja entsprechende Netzteile dabei, die man nutzen kann und damit ggf. sogar den Arduino betreiben kann.

Die Stromaufnahme habe ich testweise mal mit 3 AA Batterien, also 4,5V durchgemessen (ich bin noch etwas unsicher mit dem Multimeter und wollte mir keinen USB-Port oder ein Netzteil zerschießen, daher lieber Batterien) und komme bei voller Helligkeit aller 3 Farben auf 57mA für einen 30cm Strip. Macht also wenn man es stupf aufaddiert schon rund 450mA für alle Strips. Die USB-Versorgung eines Arduinos ist ja meist bei 500mA max, daher werde ich das auf jeden Fall mit einem zusätzlichen Stromkreis lösen, so wie z.B. unter http://www.jerome-bernard.com/blog/2013/01/12/rgb-led-strip-controlled-by-an-arduino/ beschrieben. Dazu müssen aber auch noch die entsprechenden Transistoren oder MOSFETs her. Da wird ein Besuch im örtlichen Conrad fällig. Nach unserem Umzug leider nicht mehr direkt um die Ecke.

Unter http://musicdiver.com/wordpress/2013/11/rgb-led-ketten-mit-arduino-web-gui-steuern/ gibt es übrigens auch einen Post über ein Ähnliches Vorhaben mit dem 12V 5m LED Strip von Yorbay. Auch absolut lesenswert.

Der Hue Lightstrip ist übrigens stattdessen hinter dem Bett gelandet und macht sich da ganz gut zusammen mit dem auf dem Pax-Schrank und dem Bloom in der Ecke (der war über und kommt wahrscheinlich noch woanders hin).

Alles steuerbar über den Dimmer Switch, der direkt über dem Lichtschalter angebracht ist:

Philips Hue Dimmer Switch über normalem Lichtschalter
Philips Hue Dimmer Switch über normalem Lichtschalter

Außerdem gibt es seit neuestem auch einen Amazon Dash Button, der auf dem Nachttisch liegt und das Licht im Schlafzimmer schalten kann. Dazu gibt es am Donnerstag mal wieder einen Programming Pursday.

Amazon Dash Button zur Philips Hue Steuerung
Amazon Dash Button zur Philips Hue Steuerung

Am nächsten Tinkering Tuesday geht es dann erstmal um die verschiedenen Möglichkeiten das Ganze (bzw. generell Licht oder andere Dinge) doch noch an das Hue System anzubinden. Da gibt es so einige Wege, die ich zumindest einmal anreißen möchte, bevor ich dann eine (wahrscheinlich die komplizierteste) ausprobieren werde. Dafür müssen aber erstmal die Teile ankommen. Es wird natürlich noch einen weiteren Beitrag geben, wie die Strips dann letztlich im Bett landen, dazu muss ich aber mal die Muße haben die Konsolen auseinander zu schrauben. Dazu muss es draußen wieder wärmer werden, damit ich mir beim Schleifen nicht die Finger abfriere.

021417_1740_TinkeringTu1.png

Tinkering Tuesday – Speicherplatzerweiterung Teil 2 – Einrichtung

Letztes Mal habe ich beschrieben, wofür ich mich entschieden habe. Heute geht es dann darum, was ich damit mache und wie ich das NAS einrichte. Dabei werde ich nicht jeden einzelnen Schritt des Einrichtungsassistenten dokumentieren, ich denke dazu gibt es genug Anleitungen im Netz und der Assistent an sich ist auch relativ selbst erklärend.

Hier nochmal meine Zielarchitektur:

Das NAS wird letztlich wohl im Wohnzimmer stehen, da dort der Router und der Anschluss ans Internet sind (das dLAN hat manchml unerklärliche Aussetzer, daher will ich nicht riskieren unterwegs mal nicht drauf zugreifen zu können, weil sich die Adapter nicht mehr finden). Ich hoffe, dass der Lautstärkepegel sich in Grenzen hält, sodass auf der WAF (women acceptance factor) eingehalten wird. Zur Einrichtung wird das Ding aber erstmal an einen Switch im Büro gehängt, damit die Einrichtung leichter von der Hand geht und ich nicht immer rüber rennen muss um zu sehen, was das Ding gerade macht. Außerdem geht so das erste Kopieren der Daten schneller.

Einrichtung

Der Assistent führt einen sehr schnell durch die erste Einrichtung. Ich hab mich für ein RAID1, also die redundante Speicherung der Daten entschieden. Dadurch habe ich zwar trotz zwei 4TB-Platten keine 8, sondern nur 4TB zur Verfügung, aber die Sicherheit meiner Daten soll endlich mal im Vordergrund stehen… Immerhin: bisher ist mir tatsächlich noch nie eine Festplatte so kaputt gegangen, dass ich Daten verloren habe. Da ich mich aber vorher nicht wirklich informiert habe über die verschiedenen Volume-Typen, habe ich einfach ein statisches Volume eingerichtet. Besser ist wohl ein Thick- oder Thin-Volume. Sollte für mich aber eigentlich nicht von Interesse sein, da ich weder Festplatten hinzufügen kann noch meine Volumes irgendwie aufteilen will. Wenn das Ding mal voll ist, muss eh ein neues her.

An der Seite findet man einen CloudKey, wenn man den bei start.qnap.com eingibt, sich ein cloud-Konto einrichtet, kommt man automatisch in die Einrichtung. Ein Tipp von mir: nicht unbedingt die „Suche nach fehlerhaften Blöcken“ am Anfang auswählen. Das hat bei mir die ganze Nacht gedauert. Bis dahin ist das NAS nicht so wirklich weiter benutzbar.

Auch sollte man sich die verschiedenen Passwörter (cloud-Konto, admin-Konto, etc.) bestenfalls mit einem Passwortmanager merken. Auch die dazugehörigen Adressen (cloud-Adresse, IP) sollte man sich merken.

Wenn man aus dem Netz auf seine Daten zugreifen möchte, sollte man erstmal den CloudLink aktivieren und installieren (die obige Meldung bekommt man, wenn man sich in sein myQNAPcloud-Konto einloggt und das entsprechende Paket noch nicht aktiviert hat. Das macht man in der QNAP Systemsteuerung mit dem Admin-Nutzer. Dort ruft man einfach das AppCenter auf und sucht nach „CloudLink“.

Zusätzlich habe ich mir einen neuen Benutzer für den Internetzugriff eingerichtet, der eingeschränkte Rechte bekommt. Zusätzlich gibt es einen für den Zugriff vom PC aus. Das macht man in der QNAP-Systemsteuerung. Etwas umständlich ist es, dass der Benutzer erstmal für alle möglichen Dienste berechtigt ist, die man so eingerichtet hat. Unter anderem hat jeder Nutzer lesenden Zugriff auf den Multimedia-Ordner und auch auf den Public-Ordner hat jeder erstmal Lese- und sogar Schreibrechte. Das finde ich nicht ganz so cool, daher wird das erstmal deaktiviert. Will man Kontingente für einzelne Nutzer oder Gruppen einrichten, so muss man erstmal ein Standard-Kontingent anlegen, dass für jeden gilt, dann kann man in der Benutzerverwaltung das wiederum für jeden einzeln anpassen. Eine gute Einführung in Benutzer und Rechte findet man bei Bulaland.

Was mich definitiv nervt bei dem NAS ist das ständige Gepiepe. Das kann man für einige Aktionen ausschalten, aber es piept auf jeden Fall immer beim Hochfahren und zu anderen Gelegenheiten auch mal. Das hat mich in der ersten Nacht (du erinnerst dich, die Suche nach fehlerhaften Blöcken) echt Nerven gekostet.

Ordnerstruktur

Im Auslieferungszustand finden sich so einige Ordner im NAS:

Dabei ist „home“ nur ein Link zum jeweiligen Benutzer-Verzeichnis im „homes“-Verzeichnis. „Public“ ist der von jedem Benutzer standardmäßig beschreibbare Ordner, Multimedia kann jeder erstmal ansehen, dazu gibt es noch weitere Ordner, die wahrscheinlich den entsprechend aktivierten Diensten geschuldet sind.

Ich hab mich dazu entschlossen die Default-Ordner nicht wirklich zu nutzen, sondern eine eigene Struktur anzulegen. Dazu sollte man dann auch die erweiterten Ordnerzugriffsrechte aktivieren:

Folgende Ordner lege ich an:

  • Archiv: hierhin kommen meine Datenbestände, die nicht mehr auf meinem PC vorhanden sind. Hier bekommt nur der PC-Nutzer Zugriff.
  • Backup: hier wird mein automatisches Backup der Daten vom PC, sowie vom Handy hingesichert. Hier bekommt nur der PC-Nutzer Zugriff.
  • Multimedia: der Ordner ist Standard, den werde ich wohl nutzen. Mal sehen.
  • SharingBox: das wird der Dropbox-Ersatz. Hier bekommt nur der Internet-Nutzer Zugriff. Hier ist Qsync aktiviert.

In die SharingBox kommt dann auch noch ein weiterer Ordner, „CameraUploads“. Darin wiederum gibt es für mich und meine Frau einen Unterordner in den automatisch alle Bilder vom Handy synchronisiert werden. Dabei sollte man aufpassen, dass man nicht unbedingt „Alle Fotos und Videos“ auswählt. Dann nimmt das Ding wirklichen jeden Schund mit. Das Synchronisieren funktioniert mit der Android App „Qfile“ recht einfach. In den Einstellungen den Punkt „Fotos aus der Fotogalerie automatisch hochladen“ wählen und dem Assistenten für das NAS folgen. Dort kann man dann genau auswählen, was alles hochgeladen werden soll und wohin. Dort habe ich auch die Option „Nur Wi-Fi“ unter „Richtlinie zum Hoch- und Herunterladen von Dateien“ aktiviert, damit das Datenvolumen nicht so stark genutzt wird. Auch die Auto-Anmeldung ist dort zu finden, die man aktivieren sollte, wenn man seine Fotos automatisch synchronisiert haben möchte. Für die Erst-Synchronisation hätte ich allerdings das NAS lieber schon an den Router angeschlossen… Naja, hinterher ist man immer schlauer.

In Windows direkt werden sowohl das Archiv, als auch der Backup-Ordner per Netzwerklaufwerk eingebunden. Den DLNA-Server, der auf den Ordner „Multimedia“ zugreift, findet er automatisch:

Hier sieht man, dass mein NAS auf der IP mit der Endung 21 läuft. Im Router (oder im NAS selbst) sollte man einstellen, dass das auch immer der Fall ist:

Da ich auch mit anderen Leuten Dateien und Ordner teile, war mein erster Gedanke das wie in der Dropbox zu machen: einfach einen Unterordner in meiner SharingBox anlegen und darauf dann Berechtigungen geben. Das funktioniert leider nicht. Qsync und Qfile gehen wohl immer vom Root aus und zeigen einen Unterordner nicht an, wenn auf den übergeordneten Ordner keine Berechtigungen existieren. Das heißt, ich müsste zumindest Leserechte auf den Ordner SharingBox vergeben, damit die anderen auch auf den jeweiligen Unterordner Zugriff haben. Ich will aber natürlich nicht, dass jeder meine CameraUploads sieht. Hieße, ich müsste bei jedem Unterordner wiederum die Berechtigung explizit verweigern. Das ist umständlich und fehleranfällig, wenn neue Nutzer hinzukommen.

Die nächste Idee war zusätzlich einen neuen Freigabeordner im Root einzurichten, der einfach auf den Unterordner in der SharingBox zeigt. Das funktioniert auch erstmal. Die Berechtigungen kann man auf beiden „Ordnern“ separat einrichten. Bei beiden habe ich Lese-/Schreibrechte vergeben, allerdings greift wohl irgendwie trotzdem die Berechtigung des Ordners SharingBox. Zumindest irgendwie, denn angezeigt werden alle Dateien im FileExplorer, aber weder geöffnet, noch umbenannt werden kann man sie.

Letztlich habe ich dann halt doch einen eigenen Freigabeordner im root erstellt und darauf die Benutzergruppe berechtigt. Nun funktioniert alles, das blöde ist aber, dass ich die Ordner dann nicht mit meiner Sammel-Ordnersynchronisation im Ordner SharingBox automatisch auf meinen PC gesynct bekomme, sondern jeden so eingerichteten Ordner auch in mein Qsync auf dem PC aufnehmen muss. Naja, werde ich verschmerzen.

Performance

In meiner Ersteinrichtung habe ich wie gesagt das NAS an einem Switch (100 Mbit) in meinem Arbeitszimmer angeschlossen. Daran hängt auch direkt der PC. Beim Kopieren meines Videoarchivs wird das auch fast komplett ausgenutzt:

Das ist aber natürlich für 730 GB trotzdem noch recht langsam: mit knapp 11MB/s hat es tatsächlich ca. 18 Stunden gedauert:

Für den zweiten Test habe ich das NAS dann an seinen neuen Bestimmungsort gebracht und direkt an den Router angeschlossen. Der unterstützt zwar genau wie das NAS und auch der PC Gigabit, aber hier ist dann das dLAN der Flaschenhals (zugegeben, hier werden auch kleinere Dateien verschoben, aber selbst bei Videodateien ist der Datenstrom nicht über 30Mbit und knapp 3 MB/s gekommen):

Das ist ja auch das Ergebnis, das ich über diverse Internet-Speedtests vom PC aus schon bekommen habe. Letztlich muss ich also abwägen: Höhere Geschwindigkeit vom PC aus (hier wäre wohl sogar Gigabit möglich…) oder schnelle und stabile Erreichbarkeit aus dem Internet (hier müssten dann sogar die vollen 100 Mbit Downstream und 20 Mbit Upstream meiner Internetleitung ausgenutzt werden können.

Zukunftsaussicht / Alternativer Anschluss

Ein paar Ideen habe ich allerdings noch um mehr Geschwindigkeit an den PC zu bringen:

  1. NAS per eigenem WLAN über einen AC Repeater an den PC

Da das NAS ja zwei LAN-Ports hat könnte ich das NAS bei uns in den Flur stellen und mit einem langen LAN-Kabel an den Router anschließen. Zusätzlich kann ich dort noch meinen WLAN-Repeater anschließen, der im Gegensatz zu meiner Fritzbox nicht nur WLAN N mit bis zu 300 Mbit unterstützt sondern WLAN AC mit bis zu 1300 Mbit. Außerdem wäre der Repeater im Flur näher am Arbeitszimmer.

Zum einen brauch ich dann noch einen vernünftigen WLAN-Empfänger für den PC (USB 3.0 oder PCIe mit externer Antenne, damit ich aus meiner PC-Ecke herauskomme…), zum anderen hoffe ich, dass der PC dann mit den zwei Netzwerkverbindungen klar kommt. Sollte ja aber kein Problem sein, oder?

Würde dann in etwa so aussehen:

  1. WLAN AC über Repeater statt WLAN N im Router

Das bringt mich auf die Idee überhaupt mal zu versuchen ob ich den WLAN-Empfang im Arbeitszimmer mit dem Repeater verbessern kann. Hieße den Repeater endlich mal als Repeater zu nutzen. Als Einsatzort bietet sich aber entweder das Wohnzimmer an (was standortmäßig keinen Vorteil bringt, allerdings per WLAN AC ggf. trotzdem einen Geschwindigkeitsvorteil) oder eben wie in Alternative 1 der Flur.

Das bringt dann noch weitere Möglichkeiten mit sich. Zum einen den Repeater in seiner eigentlichen Bestimmung als Repeater zu nutzen:

Hat allerdings den Nachteil, dass der Router weiterhin nur max WLAN N mit 300Mbit unterstützt und so schonmal Durchsatz verloren geht. Außerdem ist mit einem Repeater immer Verlustleistung verbunden. Besser wäre wohl den Repeater per LAN-Kabel am Router anschließen. Hat den Vorteil, dass es keine Verluste durch das WLAN gibt und die volle Gigabit Geschwindigkeit vorhanden sein sollte.

In beiden Lösungsmöglichkeiten sollte dann hoffentlich die Geschwindigkeit sogar besser sein als über die Powerline und somit könnte das sogar obsolet werden. Wenn ich es recht bedenke kann ich das NAS dann sogar am Router lassen, sodass die zukünftige Lösung so aussehen könnte (der WLAN Stick ist schon bestellt…):

Allerdings habe ich dann nicht mehr die Möglichkeit weitere LAN-Ports per Switch im Büro zu nutzen. Derzeit ist da öfter der Raspberry Pi mit dran. Auch der TV aus dem Schlafzimmer ist mittlerweile im Büro gelandet, da wir einerseits eine neue Schlafzimmereinrichtung haben, wo der Fernseher keinen Platz mehr findet (deswegen ist auch der Repeater jetzt nicht mehr im Einsatz) zum anderen haben wir im Büro nun auch ein Sofa. Perspektivisch wird der TV noch über dem Schreibtisch als dritter Monitor vor allem für Videobearbeitung montiert. Die Wandhalterung habe ich schon, allerdings will ich mir noch einen Aufsatz für den Schreibtisch beschaffen oder selbst bauen. Deswegen weiß ich die Höhe derzeit noch nicht.

013117_1838_TinkeringTu10.jpg

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
STORAGE_DEV=“sda1″
STORAGE_MOUNT_POINT=“/media/storage“
CARD_DEV=“sdb1″
CARD_MOUNT_POINT=“/media/card“

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
print
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 😉


Besser!

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.

MiniDLNA

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 😉

Case

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:

http://www.thingiverse.com/thing:1103101

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:
https://chiselapp.com/user/dmpop/repository/little-backup-box/home

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:
https://raspberry.tips/faq/raspberry-pi-usb-festplatte-ohne-eigene-stromversorgung/

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.