OSRAM Smart+ Classic E27 Multicolor für Apple HomeKit zurücksetzen

Als weiteres Testobjekt neben dem Koogeek DW1 besitze ich seit heute eine OSRAM Smart+ Classic E27 Multicolor für mein Projekt homekit_python.

Aus Erfahrung weiß ich, wie wichtig es ist, ein HomeKit Accessory während der Entwicklung auf Werkseinstellungen zurück setzen zu können.

Beim Koogeek DW1 drückt man dazu eine Taste für 10s, das Gerät quittiert es mit einer grünen LED und man ist fertig. Diese Information steht auch so im beigelegten Handbüchlein.

Bei der OSRAM Smart+ Classic E27 Multicolor hingegen liegt keine Dokumentation außer einem Zettel mit einigen Grafiken und dem Pairing Code bei. Kein Hinweis auf das Prozedere zum Zurücksetzen. Dieses findet man nur im Internet, leider an unterschiedlichen Stellen und in unterschiedlichen Sprachen (Deutsch und Englisch). Folgendes sagt die deutsche Seite und funktioniert (siehe Link Deutsch Punkt 3.4.b):

schalte sie fünfmal hintereinander für jeweils 3 Sekunden EIN und für 5 Sekunden AUS

Klingt kompliziert, man will aber auch nicht, dass die Lampe aus versehen auf Werkseinstellungen zurück gesetzt wird. Allerdings ist das für Experimente beim Ansteuern via Python eher hinderlich. Gut das wir das über eine vorhandene HomeKit-fähige Schaltsteckdose (Koogeek P1EU) erledigen können:

#!/usr/bin/env bash

python3 -m homekit.put_characteristic -f controller.json\
  -a koogeek -c 1.8 Off
sleep 5

python3 -m homekit.put_characteristic -f controller.json\
  -a koogeek -c 1.8 On
sleep 3

python3 -m homekit.put_characteristic -f controller.json\
  -a koogeek -c 1.8 Off
sleep 5

python3 -m homekit.put_characteristic -f controller.json\
  -a koogeek -c 1.8 On
sleep 3

python3 -m homekit.put_characteristic -f controller.json\
  -a koogeek -c 1.8 Off
sleep 5

python3 -m homekit.put_characteristic -f controller.json\
  -a koogeek -c 1.8 On
sleep 3

python3 -m homekit.put_characteristic -f controller.json\
  -a koogeek -c 1.8 Off
sleep 5

python3 -m homekit.put_characteristic -f controller.json\
  -a koogeek -c 1.8 On
sleep 3

python3 -m homekit.put_characteristic -f controller.json\
  -a koogeek -c 1.8 Off
sleep 5

python3 -m homekit.put_characteristic -f controller.json\
  -a koogeek -c 1.8 On
sleep 3

Schon ist auch diese Aufgabe erledigt und das Testen geht weiter…

‘git grep’ oder wie finde ich nochmal, was ich noch tun muss?

In meinem laufenden Projekt homekit_python haben sich inzwischen doch 2 oder 3 TODOs angesammelt. Wie findet man am schnellsten die TODOs die sich in Dateien befinden, die von git verwaltet werden?

Die Antwort ist einfacher, wie ich zunächst annahm: git bietet mit dem Kommando git grep bereits alles was ich benötige:

git grep TODO

Die Ausgabe umfasst in dieser einfachsten Form wie von grep gewohnt alle Treffer:

Weitere git-Kommandos findet man im git Reference Manual.

Python 3: Profiling von Skripten

Auf GitHub habe ich in einem Issue die Anfrage bekommen, die Software sei langsam. Ja, gefühlt ist die Software nicht die schnellste. Aber wie langsam genau? Und für die Optimierung wichtiger,  wo geht die Zeit verloren?

Das kann mit Profiling herausfinden. Ich will hier eine Lösung beschreiben, die ich für elegant und schnell halte, wobei es sich besseres/schöneres/… gibt.

Zunächst installiert man gprof2dot und dot:

pip3 install --user gprof2dot
sudo apt install dot

python3 bietet mit cProfile bereits ein Modul an, welches das Profiling eines Python-Skripts übernimmt. Mit folgendem Kommando startet man das Profilen des Skripts put_characteristic.py (mit dessen Parametern). Für das Module cProfile wird nur der Parameter -o genutzt, der die Ausgabedatei festlegt.

python3 -m cProfile -o profile.pstats \
        homekit/put_characteristic.py -f koogeek.json -c 1.8 -v false

Anschließend verwendet man gprof2dot und dot um eine mehr oder weniger übersichtliche Grafik zu erzeugen, welche aufzeigt, wo die meiste Zeit “liegen bleibt”. Das Ergebnis sieht in unserem Beispiel wie folgt aus:

Ergebnis eines Profilinglaufs

Allerdings muss man auch hier berücksichtigen, dass die Ergebnisse eines einzelnen Laufs nicht repräsentativ sind. Hier sollten mehrere Durchläufe hintereinander geprofiled werden. Allerdings kann man auch bei einem Durchlauf erkennen, das hier Zeroconf zum Auffinden des HomeKit Geräts und das Erstellen der Sessionkeys viel Zeit verbrauchen.

Docker.io in der Praxis – OpenVPN Server

Nach dem ersten Artikel zu Docker nun ein weiterer Post zum Thema.

Diesmal direkt mit dem Erstellen eines eigenen Images. Es geht um OpenVPN, ein open-source VPN, welches eine Vielzahl von Plattformen (Windows, OS X, Linux, Android und iOS) unterstützt.

Veröffentlicht habe ich das ganze unter github.Die zentrale Datei ist die Datei Dockerfile, welche den Build des Images steuert.

FROM debian

MAINTAINER Joachim Lusiardi

RUN apt-get update; \
    apt-get -y install openvpn ;

ADD start.sh /start.sh

RUN chmod +x /start.sh

VOLUME ["/etc/openvpn"]
VOLUME ["/var/log/openvpn"]

EXPOSE 1194/udp
EXPOSE 1194/tcp

ENTRYPOINT /start.sh

FROM legt ein Basis-Image fest, hier die neuste Version von Debian.
MAINTAINER gibt den Betreuer des Images an.
RUN führt Befehle innerhalb des Images aus. Hier das Updaten der Packet-Quellen, Installieren von OpenVPN und dem Ausführbarmachen des start-Skripts.
ADD fügt eine Datei dem Image hinzu.
VOLUME gibt an, das ein Verzeichnis des Images beim Ausführen auf ein Verzeichnis des Hosts gelegt werden kann.
EXPOSE definiert welche Ports von ausserhalb des Images erreichbar sein sollen. Diese sind nicht automatisch beim Starten des Images auf eine öffentliche IP gebunden.
ENTRYPOINT gibt an, welches Kommando ausgeführt werden soll.

Weitere Detail auf github und auch unter https://registry.hub.docker.com/u/shing19m/docker-openvpn-server/.

Python 3.3.0 auf Pogoplug: Watcher.py portiert

Watcher ist ein Dienstprogramm, welche analog zu incrond auf Änderungen in Verzeichnissen reagieren kann. Im Gegensatz zu incrond kann Watcher (im Original von Greggory Hernandez, geforked von Andreas Gohr) jedoch auch Verzeichnisse rekursiv betrachten.

Auf meinem Pogoplug die neuste Version von github per zip-Datei geladen, aber es funktionierte nicht. Grund: Python 2.7.x vs. Python 3.3.0.

Nach einigen Anpassungen funktioniert das Skript nun, und ich habe einen weiteren Fork angelegt, der diese Änderungen beinhaltet. Dank der github-OS X-Software war es auf für git Neulinge einfach, die Änderungen hoch zu laden.

Weitere Verbesserungen könnten eventuell folgen.