032217_2130_Programming1.png

Programming Pursday – Excel Turnierplan für 5 oder 7 Spieler im Doppel

Aus gegebenem Anlass habe ich einen kleinen Turnierplan in Excel erstellt.

Download Turnierplan_5_7_Spieler.xlsx

Dabei werden 5 oder 7 Spieler jeweils in Doppeln (in unserem Falle FIFA 17 auf der PS4, aber auch für alles andere nutzbar)

Es gibt insgesamt 3 Varianten:

  • 5 Spieler: jeder mit jedem gegen jeden mit jedem, 15 Spiele
  • 7 Spieler: kurze Variante, 7 Spiele, jeder hat 4 Spiele
  • 7 Spieler: lange Variante, 14 Spiele, jeder hat 8 Spiele (hier sind leider 2 Begegnungen doppelt, ich bin aber auf keine anderen Kombinationen gekommen)

Bei 7 Spielern ist die Anzahl der Kombinationen „jeder mit jedem gegen jeden mit jedem“ etwas zu hoch (insgesamt 105 Begegnungen), daher diese beiden Varianten.

Um das Sheet zu benutzen einfach die Namen in die Zellen I2-I6 bzw. I2-I8 eintragen, das Tableau wird automatisch aktualisiert. Nach Eintragen der Ergebnisse wird auch die Tabelle sofort aktualisiert. Es zählen nur Punkte und Tordifferenz.

In den grün markierten Feldern die Namen eintragen
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.

021717_1338_FotoFridayX3.png

Foto Friday – Xiaomi Yi RAW Photography

Im Dashcam Forum wird (bzw. wurde) viel über die Yi diskutiert, u.a. auch über die Aufnahme von Fotos im RAW Format:

https://dashcamtalk.com/forum/threads/the-definitive-xiaomi-yi-raw-guide.13079/

Es gibt aber einige Dinge zu beachten, die ich einmal zusammentragen möchte. Vor allem als Referenz für mich selbst 😉

Zuerst einmal: was habe ich eigentlich davon? Na, eigentlich alle Vorteile, die das Fotografieren in RAW so mit sich bringt. Wenn du dich damit nicht auskennst, lass es lieber gleich :-)

Leider unterstützt mein Bildbearbeitungsprogramm (DxO Optics Pro) das RAW-Format der Yi nicht, daher hier nur in DaVinci Resolve:

Das ist das Bild als JPG out-of-camera.

So sieht es standardmäßig als RAW aus.

Die Histogramme sehen dazu so aus (links das JPG, rechts das RAW):

Nach Bearbeitung kann das RAW z.B. so aussehen:

Da ist noch mehr Spielraum, als mit dem JPG.

Aktivierung RAW Modus

Generell ist die Aktivierung des RAW Modus relativ einfach. Man erstellt im Root-Verzeichnis seiner Speicherkarte eine Datei namens autoexec.ash. Darein muss eigentlich nur eine Zeile Code:
t app test debug_dump 14
Wichtig ist aber, dass nach dieser Zeile noch ein einfacher Linefeed (LF, nicht CRLF!) folgt (hier mal die Darstellung in Notepad++):

Am besten also eine fertige ASH herunterladen und modifizieren, oder den Xiaomi Yi Configurator (XYC, von http://www.tawbaware.com/xiaomiyi.htm bzw. https://github.com/alex-agency/XYC) benutzen.

Legt man die Speicherkarte nun in die Kamera ein und macht ein Foto, so wird automatisch eine RAW-Datei zusätzlich zum JPG erzeugt.

Zum Deaktivieren einfach die Datei wieder löschen oder auskommentieren (eine Raute/Hashtag am Zeilenanfang setzen).

Welche Bildmodi möglich und welche nicht möglich ist

Man sollte beachten, dass man der Kamera nach einem Bild genügend Zeit gibt um die Daten auf die Karte zu schreiben. Das dauert meist ein paar Sekunden. Vor allem also nach dem letzten Bild etwas warten bis man die Kamera ausschaltet.

Was die Nutzung der verschiedenen Fotomodi angeht, so habe ich das mal getestet, da nicht alle Modi ein brauchbares RAW erzeugen:

  • Einzelfoto: funktioniert sowohl per Kamera als auch aus der Android App per WLAN
  • Timer: funktioniert sowohl per Kamera als auch aus der Android App per WLAN
  • Burst: braucht mehr Zeit als man ausgewählt hat (sehr schön in der App nachzuverfolgen), produziert aber keine brauchbaren RAW-Dateien (sowohl aus der App als auch bei der Auslösung an der Kamera)
  • Timelapse: bei kurzen Intervallen braucht mehr Zeit als man ausgewählt hat, produziert aber keine brauchbaren RAW-Dateien (sowohl aus der App als auch bei der Auslösung an der Kamera); hierfür gibt es aber einen Workaround, s.u.

Woran erkenne ich brauchbare RAW-Dateien?

Der Einzelfotomodus und der Timermodus produzieren RAW-Dateien, die 31.104 KB groß sind, die anderen beiden Modi produzieren 13.176 KB große Dateien (also rund 31 MB gegen 13 MB). Die 13 MB großen Dateien sind leider bisher nicht so umwandelbar, dass sie weiterverarbeitet werden können. Die sind wohl komprimiert und die Community hat bisher noch nicht herausgefunden mit welchem Verfahren, bzw. wie diese brauchbar gemacht werden können.

Zur Konvertierung der RAW Dateien gibt es nächste Woche einen eigenen Post.

Timelapse in RAW – Workaround

Jetzt erstmal zum Workaround um doch noch RAWs in einem Timelapse zu bekommen. Dazu muss man sich wieder des Skripting bedienen und die autoexec.ash etwas erweitern.

Der beste Anlaufpunkt für Skripte rund um die Yi ist wohl http://nutseynuts.blogspot.de/2015/06/xiaomi-yi-action-cam-custom-scripts.html.

Dort gibt es nicht nur Skripte für HDR-Belichtungen und Timelapse, sondern auch diverse Skripte um die Videoqualität zu verbessern.

Eines davon ist aber RAW LAPSE. Dieses erstellt standardmäßig Belichtungen von 8s im Abstand von weiteren 8s. Einfach herunterladen und die autoexec.ash auf die Kamera kopieren. Wichtig ist noch zu erwähnen, dass die Kamera im Foto-Modus starten muss und nicht im Videomodus (kann in der App über Geräteeinstellungen konfiguriert werden)! Das Skript ist hauptsächlich für Nachtfotos geeignet aufgrund der langen Belichtung. Man kann aber die Belichtung und das Intervall anpassen. Dazu sind zwei Zeilen im Skript relevant:

In Zeile 12 wird die Belichtungszeit eingestellt, in Zeile 21 die Wartezeit (das Intervall in dem aufgenommen werden soll plus die Belichtungszeit).

Die Belichtungszeit ist die 1 am Ende der Zeile und steht für 8s (bzw. 7.9). Folgende Übersicht gibt alle gültigen Werte für die Belichtungszeit aus:

Belichtungszeiten Yi (links Wert, rechts Zeit in Sekunden)
Belichtungszeiten (links Wert, rechts Belichtungszeit in Sekunden)

Die Wartezeit wird in Sekunden angegeben sollte mindestens so lang wie die Belichtungszeit plus 8 Sekunden sein, damit die Kamera genug Zeit hat die RAW-Daten auf die Speicherkarte zu schreiben. Länger kann sie ruhig sein. Kürzer habe ich nicht getestet, wenn es aber mit einer kürzeren Wartezeit nicht funktioniert, einfach mal einen höheren Wert nutzen.

Ich habe z.B. erfolgreich mit einer Belichtung von 1/1002 (Wert 1660) und einer Wartezeit von 8 Sekunden getestet.

Das Problem bei diesem Vorgehen ist, dass man das Skript einmal konfigurieren und auf die Karte kopieren muss und die Aufnahme des Timelapse startet sofort beim Einschalten der Kamera. Man hat keine Möglichkeit nachträglich die Belichtung anzupassen. Man kann sich allerdings per App mit WLAN mit der Kamera verbinden (bei Timeout einfach nochmal versuchen, das WLAN braucht eine Weile bis es fertig ist, da die Kamera ja erstmal ausgelastet ist mit Aufnahmen, je nach Intervall und Belichtungszeit) und so zumindest das Resultat kontrollieren.

Ist nur die Frage: was machen, wenn die Belichtung nicht gut ist?

  1. Der ISO-Wert ist im Skript fest auf 100 eingestellt. Eine Möglichkeit ist also einen anderen Wert oder Auto-ISO einzustellen. Allerdings ist dann auch das Bildrauschen ggf. höher.
  2. Verschiedene Skripte nutzen. Dazu hat man wiederum mehrere Möglichkeiten:
    1. Mehrere SD-Karten (naja, nicht wirklich praktisch)
    2. XIMODE: Diese Skriptsammlung ermöglicht es beim Starten der Kamera ein Skript zu wählen nur durch die Kamera-eigenen Tasten. Mehr dazu im Abschnitt unten.
    3. Zur Laufzeit? Unter https://dashcamtalk.com/forum/threads/yi-plus-a-mod-for-switching-capture-and-recording-modes.14110/ ist mit dem Programm yi_plus eine Möglichkeit beschrieben zur Laufzeit den Aufnahmemodus zu wählen (nicht nur zwischen Foto und Video, sondern auch zwischen Foto-Timelapse oder verschiedenen Video-Modi). Ggf ist es so auch möglich verschiedene andere Dinge zu tun? Da das Programm aber ein C++ ist, dessen Source nicht veröffentlich sind, ist das wohl eher keine Möglichkeit. Aber als Referenz zu yi_plus gibt es hier wohl die verschiedenen Einstellungmöglichkeiten: https://github.com/luckylz2git/Ponerine/blob/master/camerasetting.py

XIMODE

Ist ein wirklich praktisches Tool, das einem erlaubt beim Einschalten der Kamera auszuwählen, welches autoexec.ash-Skript man benutzen möchte. Erhältlich ist es gegen ein Like auf Facebook, Twitter, Googe+ oder eine kleine Spende über Paypal auf https://xs-sol.com/ximode-xiaomi-yi-modes-superview-protune/.

Einige Hinweise von mir dazu:

  • Den Nightlapse Modus finde ich nicht besonders hilfreich, da er nur ein paar Voreinstellungen macht, den Timelapse selbst muss man dann über die App auslösen (oder schon vorher die Kamera so eingestellt haben, dass sie im Foto-Timelapse Modus startet).
  • Im Nightlapse Modus wird auch die RAW Aufnahme aktiviert, was aber zu unbrauchbaren RAWs führt, da nicht die Methode von RAW LAPSE genutzt wird (Schleife im Skript) sondern wie oben beschrieben der interne Timelapse Modus.
  • Custom Skript: Man kann sich lt. Website zwei Custom Skripte anlegen, allerdings ist in der neuesten Version eines davon bereits mit YiMAX Pro (ebenfalls von nutsey) belegt.
  • Generell kann man aber eigentlich jedes Skript mit einem Custom Skript ersetzen indem man das Beispiel Custom Skript kopiert und die jeweiligen voreingestellten überschreibt (Namen belassen, so muss man nichts anderes anpassen).

XIMODE für Timelapse – Möglichkeit 1

Man kann sich dieses Tool auch für Timelapses umbauen, indem man sich einfach verschiedene Eintstellungen (ISO, Belichtungszeit, Intervall) vordefiniert.

So kann man sich auch verschiedene Belichtungen anlegen und per WLAN kontrollieren ob einem die Belichtung gefällt. Da gibt es auch wiederum mehrere Möglichkeiten:

  1. Einfach das normale RAW LAPSE mit verschiedenen Einstellungen in die anderen Skripte kopieren
  2. Eine weitere Möglichkeit wäre sich noch „Prüf-Modi“ anzulegen, in denen man erstmal nicht die Schleife startet, sondern nur ein Foto mit den Einstellungen machen lässt. Dazu kopiert man einfach das normale Skript und kommentiert folgende Zeilen aus (Hastag/Raute):

    So wird ein einziges Bild gemacht und man kann sich dann per App auf die Kamera verbinden und sich dieses ansehen.

XIMODE für Timelapse – Möglichkeit 2

Ein weiteres Feature von XIMODE ist, dass die Möglichkeit gegeben ist direkt auf der Kamera den XYC auszuführen und so eine Konfiguration quasi vom Telefon aus anzulegen / zu verändern. Das habe ich allerdings nicht ausprobiert, da man dafür Telnet auf seinem Handy installieren muss. Dazu hatte ich bisher keine Lust.

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.

wpid-wp-1489252324591.jpg

Foto Friday – Import, Ordnerstruktur und Processing

Im Grunde habe ich zwei Kameras, die ich regelmäßig nutze. Natürlich meine Olympus OM-D E-M10 II. Damit fotografiere ich sowohl in RAW als auch in JPG. Außerdem nehme ich damit Videos auf. Die zweite ist meine Action Cam Xiaomi Yi HD. Die erzeugt hauptsächlich natürlich Videodateien, wird aber auch für z.B. Timelapses genutzt. Dafür speichert sie auch sowohl JPGs, als auch ggf. RAW-Dateien (gehe ich im nächsten Post näher drauf ein, ist nicht Standard).

Die Ordnerstrukturen, die ich für Standardprojekte (z.B: Urlaub) immer wieder anlege sind seit längerem dieselben. Folgende Ordner lege ich in einem thematisch benannten Ordner mit Zeitstempel (z.B. 2016-04-10 Sonnenuntergang Balkon) an:

  • OOC: Hier kommen die JPEGs „Out of camera“ rein. Falls es mal schnell gehen muss habe ich die dann sofort zur Hand.
  • RAW: Hier kommen die RAW-Dateien (bei Olympus heißen die ORF) rein.
  • Video: Na, was wohl? Videodateien natürlich.
  • DxO: In den Ordner kommen die fertigen Bilder, die ich mit DxO exportiere.
  • HDR_Input: Input für die Erstellung von HDRs z.B. TIFs für die Nutzung in der Google Nik Collection, wie in einem vorherigen Beitrag schonmal beschrieben
  • HDR_Output: Hier kommen dann fertige HDRs rein.
  • Pano_Input: wie HDR, nur für Panoramas
  • Pano_Output: wie HDR, nur für Panoramas
  • Temp: hierein kommen ggf. temporäre Dateien

Bisher habe ich Video-Projekte und Foto-Projekte noch getrennt, aber ich überlege, ob ich das weiterhin so strikt trenne, da ich immer öfter auch Fotos in den Video-Projekten nutze (z.B: Timelapses oder einfach normale Fotos in einem Urlaubsvideo). Dann würden wohl noch zusätzliche Ordner hinzukommen. Bisher habe ich pro Kamera einen Unterordner angelegt, wenn ich mit mehreren Kameras aufgenommen habe. Wenn die Shoots von mehreren Karten kommen dann lege ich darunter jeweils noch z.B. Tagesordner an. Aber generell würde das wohl bedeuten, dass folgende Ordner noch hinzukommen würden:

  • Audio: Im Projekt genutzte Audio-Dateien (z.B. Musikuntermalung, bei meinen Band-Auftritten auch gerne mal ein Mitschnitt)
  • Video_Project: Die Projekt-Dateien (bei Sony Vegas sind das .veg-Dateien. Bei DaVinci Resolve wird das in einer Datenbank gesichert. Da muss ich nochmal schauen, wie man das sichern kann)
  • Video_Input: Würde den normalen Video-Ordner ersetzen und entsprechende Unterordner besitzen
  • Video_Output: Hier kommen die fertig gerenderten Videos rein

Meine Idee ist eigentlich das Ganze zu automatisieren, da es doch etwas aufwändig ist. Was man natürlich schlecht automatisieren kann ist der HDR- und Pano-Input. Aber das Aufteilen in die Ordner OOC, RAW und Video ist doch etwas mühselig. Für die Yi Cam ist weiterhin ein weiteres Processing der RAW-Bilder notwendig um sie nutzen zu können (zumindest in DaVinci Resolve kann ich sie dann nutzen, DxO Optics Pro unterstützt das Format leider nicht). Das könnte man auch gleich erledigen.

Was den automatisierten Import etwas erschwert ist die Tatsache, dass ich nicht immer alle Fotos von der Karte importieren möchte oder auch mal mehrere verschiedene Themenordner anlegen will. Das schreit also nach einem User Interface, mit dem ich das automatisieren kann.

Ich gehe erstmal davon aus, dass ich Fotos eines Tages auch zusammen verarbeiten will. Für den Sonderfall, dass an einem Tag mehrere Themen anfallen würde ich das manuell wieder auseinander dröseln. Also sollte mir das Interface erstmal die Bilder in einer Übersicht nach Tagen anzeigen. Dann möchte ich neue Projektordner anlegen und benennen können. Es fehlt dann nur noch die Zuordnung des Shooting-Tages zum Projekt und dann sollen automatisch alle Dateien in die entsprechenden Unterordner im Projektordner kopiert oder verschoben werden (auswählbar). Allerdings muss ich mir noch überlegen, was ich mit Projekten mache, die aus mehreren Kameras aufgenommen wurden. Ggf. noch Unterordner in den OOC- und RAW-Ordnern

Der Timestamp im Ordnernamen des Projektes soll automatisch angelegt werden: bei einem Tag soll nur der eine Tag genommen werden, z.B. 2017-02-15. Wenn mehrere Tage abgedeckt sind, soll der Monat genutzt werden, z.B. 2017-02).

Das Programm soll bestenfalls automatisch starten, wenn eine entsprechende SD-Karte eingelegt wird. Das ließe sich z.B. an der Ordnerstruktur erkennen, zudem auch aus den EXIF Daten der Bilder. Wird wohl eine Kombination von beiden werden.

Bei den Yi-Daten soll dann auch automatisch das Post-Processing stattfinden.

Klingt eigentlich nach einem machbaren Projekt, oder? Ich werde zusehen, was ich erreiche und dann hier ein Update geben.

022517_1401_TinkeringTu5.jpg

Tinkering Tuesday – DIY Lichter / Dinge mit Philips Hue verbinden – einfache und komplizierte Möglichkeiten

Wie schon angekündigt möchte ich die LED Strips für die Beleuchtung unserer Nachtkonsolen mit Philips Hue verbinden. Die Original-Strips sind leider zu breit. Nun möchte ich mal die Varianten beschreiben, die so möglich sind um Dinge ins Hue-Ökosystem zu bringen. Erst geht es um Dinge zur Steuerung, dann Dinge, die gesteuert werden sollen (das viel interessantere).

Aktoren

Hier geht es erstmal darum einen Knopf, Sensor oder irgendwas in der Art zu benutzen um das Licht zu schalten. Dazu findet man so einiges im Netz, daher hier nur mal ein paar Anregungen:

  1. Natürlich alles Aktoren, die Philips selbst anbietet (Dimming Switch, Tap, Bewegungsmelder)
  2. Diverse Third-Party Lösungen (Amazon Echo, Logitech Harmony, Nest,…)
  3. Diverse Smartphone Apps, z.B. all4hue, meine App der Wahl
  4. Über die Hue API (also generell über alles, was einen Netzwerkzugang zur Bridge hat): https://developers.meethue.com/
  5. Im Speziellen von einem Arduino aus (per Ethernet Shield): http://commentfr.xyz/diy/3477-wie-steuern-philips-hue-lichter-von-einem-arduino.html
  6. Via Amazon Dash Button Hack: (hierzu gab es beim letzten Programming Pursday einen Post von mir)
  7. Kodi Media Center mit Hue als Ambilight: http://stadt-bremerhaven.de/philips-hue-und-kodi-zur-ambilight-zentrale-verknuepfen/
  8. Raspberry Pi, ohne Bridge, via Raspbee Shield: https://raspberry.tips/hausautomatisierung/raspberry-pi-lichsteuerung/

Auf dieser Seite ist Philips also sehr offen was die Hackability des Systems angeht. Auf der anderen Seite sieht es schon schlechter aus:

Reaktoren

Hier gibt es natürlich die Standard-Wege.

  1. Alles was eine Lampenfassung hat kann natürlich mit den kompatiblen Lampen (Philips Hue, Osram Lightify, Innr, GE Link) ausgestattet werden. Dann natürlich die Standalone Lampen und LED Strips (z.B. Hue Bloom, Hue Iris, Hue Go, Hue Lightstrip+, Osram Lightify LEDs)
  2. Für alles was einen Stecker hat und nur ein an/aus Signal braucht kann man den Osram Lightify Plug nutzen

Wenn es darüber hinaus geht wird es schon spannender:

  1. Mit allem was einen Netzwerkanschluss zur Bridge hat kann man die Hue Bridge über die API abfragen (Polling), z.B. https://github.com/jbonachera/hue-dimmers-poller oder https://www.npmjs.com/package/homebridge-hue (hat den Nachteil, dass in regelmäßigen Abständen abgefragt werden muss, was zu Zeitverzögerungen und verpassten Events führen kann)
  2. Man kann auch die Steuerung z.B. eines LED-Lightstrips+ abfangen und einen eigenen LED Strip anschließen (Spezifikationen beachten, 24V, 24 Watt Netzteil im Standard, hier kann man mit entsprechenden Bastellösungen bestimmt auch noch weiter gehen indem man z.B: eine größere oder weitere Stromversorgung einhängt)
  3. Es gibt mittlerweile eine Serie von Geräten einer deutschen Firma (Dresden Elektronik), die unter anderem Vorschaltgeräte für LED Strips beinhaltet, die mit Hue kompatibel sind: https://www.dresden-elektronik.de/funktechnik/solutions/wireless-light-control/ Hier z.B. auf Amazon: Vorschaltgerät für RGB/RGBW.
  4. Dann gibt es noch die ultimative Bastellösung von Peter aus den Niederlanden (alias PeeVeeOne), der eine Innr Leuchte geöffnet und einen Dump der Firmware des darin enthaltenen Chips NXP JN5168 gemacht hat und so einen Weg gefunden hat einen MeshBee bzw. einen „nackten“ JN5168 zu einem von Hue erkennbaren Device zu machen. Das Ganze hat er auch auf GitHub verfügbar gemacht.

Die letzte ist für mich die interessanteste, da flexibelste Lösung. Allerdings auch die mit den größten Herausforderungen. Zum ersten: Woher einen MeshBee bekommen? In Deutschland schonmal nicht so einfach. Auch beim Hersteller SeeedStudio selbst ist er nicht mehr verfügbar. Einen Shop habe ich gefunden, der nach Deutschland liefert robotshop.com, allerdings kommen da zu den knapp 22 Euro pro Modul nochmal 18 Euro Versand drauf. Das ist happig. Zusätzlich wird überall empfohlen den UartSBee V5 zur Programmierung zu benutzen, der nochmal mit 20 Euro zu Buche schlägt.

PeeVeeOne hat mit einem „nackten“ JN5168 und einem entsprechenden Breakoutboard weiter gearbeitet. Leider ist auch dieses Breakoutboard in Deutschland nicht zu bekommen. Also mal einen guten Bekannten gefragt, was man da machen kann und eigentlich müsste man den JN5168 doch auch ohne Breakoutboard bzw. mit einem selbstgebauten PCB betreiben können. So kompliziert ist das Ding nicht. Also mal einen über amazon bestellt: RF MOD, IEEE802.15.4, STD PWR, INT ANT JN5168-001-M00Z By NXP.

Zur Programmierung sollte auch ein normaler FTDI USB zu Seriell Adapter funktionieren, daher habe ich mal den hier bestellt: FT232RL 3/5V FTDI USB zu auf TTL Serial Adapter Modul Arduino Mini Port DETE203.

Der Plan ist, dass ich damit dann direkt meinen LED Strip in den Nachtkonsolen ansteuern kann und ggf. sogar noch mehr möglich ist (nicht nur die Ansteuerung von LED Strips per PWM, sondern auch anderer toller Dinge (die ich noch nicht weiß, aber die Möglichkeit ist geil!).

In der nächsten Woche gibt es dann das Hands-On mit dem JN5168. Das wird fein. 

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.