Server-Monitoring via Pushover/Pushalot

“Wo nur bleibt die Mail, die ich mir vor 10 Minuten habe weiterleiten lassen? SPAM-Folder? Nein. Bei genauerem Hinsehen entdecke ich einen Fehler im Mail-Client, der beim Synchronisieren mit dem privaten Mailserver aufgetreten sei. Man möge es später nochmals versuchen oder sich an seinen Admin wenden orakeln die üblichen Beschwichtigungsversuche. Mist – ausgerechnet heute! Eine erste Prüfung ergibt wenig. DynDNS ist okay, Maschine lebt aber mehr ist von unterwegs vorerst nicht festzustellen. Am Abend dann die Gewissheit: Auf dem Mailserver ist die Platte voll. Mailbox-Database und Log-Files haben ihr Übriges dazu beigetragen – hätte man doch aber eigentlich rechtzeitig mitbekommen können…”

So oder ähnlich kommt man gelegentlich zu der Erkenntnis, dass auch die IT in den eigenen vier Wänden nicht gänzlich wartungsfrei vor sich hin säuselt. Sei es ein Dienst, der sich gerne mal verabschiedet, eine Netzwerk-Komponente die einen kleinen Tritt braucht oder gar der knapp gewordene Speicherplatz.

An denkbaren Lösungen mangelt es heute nicht mehr. So könnte man überlegen, ob ein Nagios, MOM, OpenNMS, WhatsUp, Zabbix, etc. die Mühe wert wäre. Im Funktionsumfang und auch in der Erweiterbarkeit ähneln sich die bekanntesten Vertreter des Server-/Netzwerk-Monitoring schon seit Jahren sehr. Bleibt noch die Qual der Wahl. Und natürlich müsste auch noch eine Datenbank her, eine brauchbare Erstkonfiguration und vielleicht ein Backup aber daran würde es sicher nicht scheitern.
Dennoch bin ich mir sicher, dass zumindest für meinen Hausgebrauch dieser Ansatz völlig am Ziel vorbeigehen würde. Ein Wort trifft es ganz gut: überdimensioniert. So möchte ich doch nur wissen, dass der Speicher nicht voll läuft, hier und dort ein paar für mich spannende Dienste laufen und zwei/drei Webinterfaces erreichbar sind. Theoretisch genügt es auch völlig im Falle eines Fehlers eine kurze Info zu erhalten – ich muss nicht ganz genau wissen seit wann das Problem besteht und Dashboards brauche ich auch nicht.

Die Anforderungen:

  • Keine Middleware: Clients und Server sollen direkt Bescheid sagen, wenn etwas nicht mehr so ist, wie erwartet
  • Kein Aufwand: Einfach und schnell zu konfigurieren
  • Kein SPAM: Statt auf Mails auf Push-Dienste setzen
  • Kein Overhead: “Small memory/resource footprint”

Die Idee zum “PushMonitoring”

Ein simples Kommandozeilen-Tool mit XML-Konfigurationsdatei, welches bei jeder Ausführung die per Konfiguration definierten Prüfungen einmalig ausführt, deren Ergebnisse zusammenfasst und bei Abweichungen vom SOLL per Pushalot oder Pushover informiert. Als Prüf-Typen sollten anfangs Ping, freier Speicher und HTTP-Requests genügen – später vielleicht noch Dienste, TCP, Up-time. Durch den minimalistischen Ansatz bleibt das Tool universell einsetzbar und flexibel. Per geplantem Task genügt beispielsweise eine stündliche oder je nach Aufgabe auch tägliche Ausführung.

Konfiguration

Neben den primären Konfigurationsbereichen wie <sendInterfaces> und <checksToRun> kann zusätzlich per <sendWithoutError> ein Zeitraum festgelegt werden, nachdem man auch ohne Fehlermeldung mal wieder ein Lebenszeichen vom System erhalten möchte. Diese Funktion kann jedoch nur verwendet werden, wenn die Anwendung irgendwo das Logfile (definiert in <logFile>) speichern kann.

Fertig ist das Monitoring für Puristen

PushNotification - Ausführung an der Kommandozeile

PushNotification - Benachrichtigung empfangen

Das Projekt

Die Quellen finden sich auf Github unter roschinsky/PushMonitoring. Wer sich berufen fühlt – das Portieren auf Mono- bzw. CLR Core steht noch aus… ;)

Für alle die gerade kein Visual Studio am Start haben oder nur die Binaries brauchen gibt es natürlich noch die Pre-Build Version, die ich im One-Drive hinterlegt habe:

“PushMonitoring.zip”

QUELLE: OneDrive

GRÖßE: 0,02 MByte

DATUM: 30.06.2015

Garmin Fenix 2 vs. Microsoft Band

Wie schlägt sich eine semiprofessionelle Multisportuhr gegen einen Alltagsfitnesstracker mit eingebauter Smartwatch? Wer trackt besser? Wo liegen die Stärken und Schwächen in der Aufzeichnung sowie Genauigkeit? Fragen, denen ich gerne mit diesem Beitrag auf den Grund gehen möchte.

Wie man eher vermuten würde, ist es ein wenig als würde man Spielekonsolen mit professionellen Workstations vergleichen und rechnet mit einem tendenziell unausgeglichenen Ergebnis. Dennoch sprechen die Ergebnisse mehr für das Massenmarkt-taugliche Produkt als ich es angenommen hätte.

Um nicht nur die Ergebnisse einer einzelnen Messung gegenüberzustellen, nehmen wir zwei unterschiedliche Touren an unterschiedlichen Tagen über jeweils rund 6km. Eine Runde mit dem Rad und einen Lauf, zu denen ich mir sowohl das Band als auch die Fenix nebst HRM-Run-Gurt umgeschnallt habe. Mit den Gesamtergebnissen und den ermittelten prozentualen Abweichungen starten wir in den ungleichen Kampf:

Garming Fenix vs. Microsoft Band - Biking

Garming Fenix vs. Microsoft Band - Running

Das erste Fazit fällt überraschend gut aus, auch wenn sich an dieser Stelle noch keine Aussage über wahr oder falsch treffen lässt. Besonders beeindruckt war ich von den Ergebnissen bei der Herzfrequenz, da ich hier deutlichere Abweichungen erwartet hätte. Während bei allen Pulsuhren, die ich bislang probieren konnte, stets eine sofortige Reaktion des Herzschlags auf kleinste Aktivitäten festzustellen war, erschien mir die Pulsmessung des Microsoft Band eher träge. Trotzdem sind beim Lauf absolut identische Werte ermittelt worden, was ich tatsächlich nicht erwartet hätte.

Quantität

Der nächste Punkt ist die Menge der Daten, die von beiden Geräten aufgezeichnet werden. Für den direkten Vergleich habe ich lediglich die Werte aufgeführt, die von Fenix und Band gleichermaßen protokolliert werden. In der Anzahl der verschiedenen Messwerte hat die Garmin Fenix hier ohne Frage die Nase vorn. Läuft man mit HRM-Run erhält man neben den gebräuchlichen Angaben auch sehr detaillierte Informationen über die Bewegung beim Laufen. So werden über die gesamte Strecke Vertikale Bewegung und Bodenkontaktzeit aufgezeichnet, welche Aufschluss über Verbesserungspotential in der Bewegung geben.

Doch auch beim Band habe ich Angaben entdeckt, die ich bei Garmin nicht finden konnte: Die verbrauchte Energie wird in verbrannte Kohlenhydrate und Fette unterteilt. Sicher nur eine Aufschlüsselung nach Standardformel aber dennoch interessant.

Qualität

Keinesfalls weniger maßgeblich ist jedoch die Genauigkeit und Verlässlichkeit der Daten. Um wirklich belastbare Zahlen zu erhalten, müsste man zwar noch ein paar mehr Vergleichsreihen anstellen aber auch bei den zwei Tests wird sichtbar, wo es Probleme gibt.
Bei den ermittelten Zahlen würde ich den beim Radfahren auffälligen Ausrutscher der maximalen Herzfrequenz als Zufall bzw. sporadischen Messfehler interpretieren, da der Durchschnittswert über die gesamte Tour sehr dicht an den Wert der Fenix herankommt. Ein klein wenig Rückschluss auf das erwähnte “träge Verhalten” beim Aufzeichnen der Herzfrequenz bringen die Diagramme, die die App zum Band preisgibt. Die Abtastung der Herzrate scheint nicht permanent zu erfolgen sondern in kleinen Häppchen.

Microsoft Band - Dashboard Bike HR  Microsoft Band - Dashboard Run HR

Aber kommen wir zu einem schwerwiegenderen Problem. Die deutlichen Unterschiede bei Energieumsatz/Kalorien und Distanz springen ins Auge, zumal die Abweichungen sowohl beim Lauf als auch auf dem Rad in relativ ähnlicher Intensität zu erkennen sind. Die Kalorien könnte man hierbei noch auf eine abweichende Formel schieben aber bei der Distanz, die bei der Fenix immer länger als zu vermuten ausfällt, bin ich stutzig geworden. Es liegt auf der Hand – einer wird sich irren.
Der genaue Vergleich der Strecken an signifikanten Stellen deckt auf, was man schon ahnen konnte, wenn man an die GPS-Suchzeiten (Band ca. 5 bis 10 Sekunden; Fenix meist mehr als eine Minute) denkt. Die Fenix 2 patzt tatsächlich bei der Ortung und baut zahlreiche Schlenker und Haken ein, die man nie gelaufen ist und dabei dennoch “auf der Uhr” hat.

Garmin Fenix vs. Microsoft Band - GPS-Tracking Fehler - Bike

Garmin Fenix vs. Microsoft Band - GPS-Tracking Fehler - Run

Damit wäre der Grund für die stets längere Strecke geklärt, die bei zunehmender Streckenlänger noch wesentlich mehr ins Gewicht fallen dürfte. Die Auswertung zeigt, dass das Band nicht fehlerfrei, jedoch überraschend gut die Route aufzeichnet, wohingegen die auf dem neusten Stand gepatchte Garmin Fenix 2 mächtig daneben liegt. Ein wenig erschreckend, da ich definitiv das schlechtere Ergebnis vom Band und nicht von einer der namenhaften Größen im Bereich GPS Consumer Elektronik erwartet hätte.
Eine kurze Suche im Netz zeigt auch, dass es mit der Uhr aus dem Hause Garmin offenbar generell Probleme in Sachen GPS-Genauigkeit zu geben scheint:

Fazit

Die Garmin Fenix 2 enttäuscht sehr was den GPS-Empfang und die GPS-Genauigkeit anbelangt. Das Microsoft Band kann sich hingegen mehr als sehen lassen, was Genauigkeit und selbst Anzahl der ermittelten Werte anbelangt.

Build Tour 2015

Build Tour 2015Als ich von dem Event erfuhr, ging mir die Frage “Wie soll man eine 3- bzw. 4-Tages Konferenz mit weit über 100 Sessions sinnvoll in einen Tag mit 3 Sessions packen?” durch den Kopf. Die Antwort liegt auf der Hand – geht nicht, keine Chance, nicht mal ansatzweise. Wenn man sich jedoch vorher nicht aus Versehen zu einer solchen Erwartungshaltung hat hinreißen lassen, ist den Microsofties der Espresso der großen Build durchaus gelungen.

Ursprünglich hatte ich mir überlegt erst nach der Keynote zu erscheinen. Es erwies sich als glückliche Fügung, dass ich mich anders entschieden hatte. Zu meiner Freude war die Eröffnung der Veranstaltung durch Mr. Kevin Gallo alles andere als zäh. Nach den zu erwartenden Statements zur neuen Konzern- und Entwicklungsstrategie, die dem aufmerksamen Developer in den vergangenen Wochen wahrlich nicht entgehen konnten, gab es bereits Demos mit Code im Visual Studio. Einige Pannen vermittelten während der Demos ein recht authentisches Gefühl sowie den Eindruck, dass noch einige Tests laufen müssen, bis ein RC und die Final von Windows 10 zu erwarten sind.

Trotz der knappen Agenda war fast alles mit dabei, was man bereits den Medien tröpfchenweise entnehmen konnte. Die Themen, die kurz beleuchtet wurden, machen definitiv neugierig auf mehr.

Die Stichpunkte, die ich mir von der Build mitgenommen habe:

  • Unified core and app platform
    • UAP – Universal App Platform
    • UWP – Universal Windows Platform
    • Ein Store für alle(s); auch für bestehende Anwendungen auf .NET- oder Win32-Basis
    • App-to-App communication via App Service
    • Visual Studio 2015 – Debugging Tools
  • Edge
    • Performance
    • TypeScript mit ECMA Script 6 in Edge mit dabei
    • Tools (modern.ie)
  • Was noch?
    • IoT mit Windows auf dem Raspberry Pi 2
    • Continuum
    • Azure – App Tracing
    • Design (design.windows.com)

Speziell zur Entwicklung von Windows 10 Apps ist der MVA-Kurs “A Developer’s Guide to Windows 10 Preview” sehr zu empfehlen.

Wer nun Lust auf mehr bekommen hat, der wird fündig auf der Channel9-Seite zum Event mit allen Sessions sowie auch den Slides. Mit Hilfe des PowerShell-Scripts von Peter Schmidt in der TechNet Code-Gallery lassen sich bei Bedarf auch Videos und/oder Slides gesammelt herunterladen.

Was fehlte? Ganz klar – die Microsoft HoloLens zum Bestaunen und vielleicht sogar zum Ausprobieren. Schön wären auch ausreichend Tour-Shirts der Größe M gewesen, die leider bereits nach wenigen Minuten vergriffen waren. Macht aber nix – dafür habe ich jetzt ein neues Nightshirt. :D

Ansonsten war der Tag gestern am Westhafen in Berlin eine schöne Zusammenfassung dessen, worauf sich .NET-Developer in naher Zukunft freuen dürfen. Herzlichen Dank auch an den Caterer – das Essen war ganz ausgezeichnet! Ein Tipp noch am Rande: Club Mate an der Getränke-Bar wäre eine clevere Alternative zu Wasser, Cola und Saft gewesen…

Microsoft Band importiert…

…, ausgepackt und vorerst für praktisch befunden – alles andere wird sich auf kurz oder lang zeigen. Einen kleinen Erlebnisbericht zur Inbetriebnahme kann ich mir dennoch nicht verkneifen.

Rund ein halbes Jahr ist seit Vorstellung von Microsoft Band ins Land gegangen und noch immer ist kein Start auf dem hiesigen Markt absehbar. Schade gleichermaßen, dass einerseits der Versuchsballon des Hybriden aus Fitness-Tracker und Smart Watch deutlich zu knapp dimensioniert wurde und es zweitens keine wirklich brauchbare Alternative für Windows Phone gibt – speziell was die Smart Watch Funktionalität anbelangt. Zum Glück gibt es alternative Bezugsmöglichkeiten. Meine Wahl fiel auf Amazon.co.uk. Nach Bestellung am Wochenende ging heute das Paket bei mir nieder.

Microsoft Band - Box

Ein Unboxing-Video spare ich mir, da es mehr als reichlich Material im Netz zum Thema gibt.

Für sein Geld bekommt man also ein kleines, quadratisches Kästchen, was das Band, ein Ladekabel (Stecker mit Magnet-Kupplung auf USB) und einen Quickstart-Guide enthält. Wie meist bei elektronischem Gerät ist der erste Schritt der Anschluss ans Stromnetz.

Kurz drauf meldet sich auch gleich das Armband und weist per Display auf die App “Microsoft Health” hin, die offenbar zur Inbetriebnahme benötigt wird. Da ich mir vor einer Weile die App bereits aus dem englischsprachigen Store installiert habe, kann ich nicht genau sagen, ob die App inzwischen direkt über den Deutschen Store installiert werden kann. Falls nicht genügt es, die regionalen Einstellungen kurz auf en-US umzustellen, anschließend die App zu installieren und danach wieder auf de-de zurückzusetzen.

Microsoft Band - Box opened

Microsoft Band - unboxed

Der Verbindungsvorgang ist denkbar einfach. Das Band geht nach Aktivierung automatisch in den Bluetooth Pairing-Mode. Über Einstellungen wird die Verbindung wie mit jedem anderen Bluetooth-Gerät hergestellt und anschließend kann die App gestartet werden. Nach einigen Angaben zu Gewicht und Größe werden Band und Handy miteinander verknüpft. Hat die App das Band erkannt, wird nach Updates gesucht – bei mir gab es auch prompt eins, was ca. nach 3 Minuten installiert war. Abschließend werden noch einige Fragen zur Personalisierung (Name des Bands, Hintergrundbild und -farbe) gestellt und es ist fertig eingerichtet.

Microsoft Band - loading

Über die App kann man noch eine ganze Menge einstellen – beispielsweise habe ich mir das Benachrichtigungscenter ins Menü gepackt, ein paar Kacheln entfernt, andere hinzugefügt und neu sortiert. Die Sprache am Gerät kann man leider nicht auf Deutsch umstellen aber über die zusätzliche App “Pimp my band” ist auch das problemlos möglich.

Fazit: Inzwischen trage ich das gute Stück den Abend lang am Arm und habe daran vermutlich etwas mehr als das was man unter “regulärer Benutzung” versteht herumgespielt – der Akku ist dennoch voll und hat nicht einen Pixel in der Ladezustandsanzeige verloren. Der Formfaktor ist etwas gewöhnungsbedürftig, was den Tragekomfort nicht einschränkt. Das Gewicht ist ebenfalls unproblematisch und bislang funktioniert alles so, wie ich es mir vorgestellt habe.

Für die nächsten Wochen steht dann noch der Test des Microsoft Band SDK an… wenn es nur annähernd so einen guten Eindruck wie die Hardware macht, werde ich sicher darüber berichten.

Microsoft Band SDK - Update

Ausgerechnet heute gab es doch auch gleich noch ein Update des SDKs, welches man sich via NuGet Package Manager…

PM> Install-Package Microsoft.Band

…herunterladen kann. Die Dokumentation sowie auch der Design-Guide dazu sind als PDF verfügbar.

Update 02. Mai: Laufzeit Akku

Inzwischen hat das Band seinen ersten Boxenstopp am Ladekabel hinter sich. Ich habe es mal auf ein technisches K.O. durch “Strom-alle” ankommen lassen und das Betteln und Flehen, es zum betanken an den Strom anzuschließen, ignoriert. Daraus resultiert eine Laufzeit mit 2x GPS-Tracking für jeweils ~7km Radfahren von 47,5 Stunden.

HomeMatic mal ausprobiert – ein Erfahrungsbericht

HomeMatic APIDie Idee einer heimischen Steuerzentrale hat mich zugegebenermaßen schon einige Jahre lang fasziniert – selbst damals, als das “UI” noch aus Tastern und Lämpchen bestand. Mit den heute verfügbaren, modularen und fertig aufgebauten Systemen ist die Einstiegshürde deutlich gesunken, hätte man sich früher alle Komponenten selbst löten müssen. Profan gesprochen sind es zwar nur ein paar fernsteuerbare Lichtschalter aber die Vorteile eines solchen Systems sowie die damit verbundenen Möglichkeiten lassen sich gewiss nicht nur dem Technikbegeisterten erklären.

Bei den Überlegungen zu Sinn und Unsinn einer Heimautomatisierung lief mir HomeMatic schon vor zwei/drei Jahren mal über den Weg. Die Entscheidung dem System der eQ-3 AG nun doch eine Chance zu geben, ging im Wesentlichen auf zwei Ereignisse zurück: Die Erkenntnis, dass HomeMatic einen Webservice zur umfangreichen Ansteuerung der Anlage mitbringt, zusammen mit einer guten Empfehlung, sowie einen kleinen “Sicherheitsvorfall” an der Wohnungstür. Rein zufällig war es gerade draußen auch noch kalt und das zeitgesteuerte Heizungsthermostat im Bad hatte schon lange seine Programmierung vergessen… Zeit also für ein Starterpaket!

Einer der Vorteile des Systems sind die zahlreichen Geräte, mit denen man das System fortwährend ausbauen und erweitern kann. So gibt es vom Fensterkontakt über das Heizungsventil bis zum Wassersensor eigentlich nichts, was es nicht gibt. Einen guten Überblick über Sensoren und Aktoren kann man sich auf den Seiten des Anbieters verschaffen.

Die bidirektionale Kommunikation zwischen den Geräten und der Zentrale erfolgt per Funk auf 868 MHz über das proprietäre Funkprotokoll BidCoS.
Jedoch auch bei einem auf den ersten Blick recht stimmig umgesetzten Gesamtsystem, finden sich bei genauerem Hinsehen bereits einige konzeptionelle Schwächen. So zum Beispiel wird neben der bidirektionalen Kommunikation auf eine Absicherung der Übertragung per AES gesetzt – leider gilt dies offenbar nur für ein Challenge-Response-Verfahren, welches zur Authentifizierung des Senders gegenüber dem Empfänger bei Schaltvorgängen genutzt wird und nicht für die Absicherung der gesamten Übertragung.

Inbetriebnahme und Konfiguration

HomeMatic  - Installation Unterputz 2-Fach Aktor und AnsteuerungDie Steuereinheit/Zentrale (im HomeMatic-Slang CCU genannt) ist das Herzstück der Anlage. Das nicht besonders ansprechende und aus UX-Sicht an einigen Stellen mehr als fragwürdige Frontend der CCU ist inhaltlich durchdacht und mit umfangreichen Funktionen ausgestattet. So kann hier mit wenigen Klicks das Bekanntmachen (Anlernen) und Einrichten von Sensoren sowie Aktoren erfolgen. Neben einer Art Workflow-Engine, mit der sich kleine Skripte für individuelle Steuerungsabläufe entwerfen lassen, ist hier ebenfalls ein Ansteuern der eingerichteten Geräte möglich. Darüber hinaus lassen sich direkte Steuerungsverknüpfungen einrichten, was die autarke Kopplung von einzelnen Sensoren und Aktoren ermöglicht.

Die HomeMatic-Endgeräte sind meist ohne besonderen Aufwand zu montieren. So gibt es einfache Zwischensteckdosen, mit denen beispielsweise Schaltvorgänge und Strom(-verbrauchs-)messungen realisiert werden können. Bei manchen Sensoren sind minimale handwerkliche Skills von Nöten – jedoch jeder, der es vermag einen Schraubenzieher seiner Bestimmung gemäß zu verwenden, sollte ohne Probleme zurechtkommen.

Für die Installation einiger Geräte, wie beispielsweise die für die Unterputz-Montage konzipierten, sind Grundkenntnisse der Elektrotechnik sinnvoll. Auch hier jedoch kann man wenig falsch machen, da Beschriftungen und Anleitung keine Frage offen lassen. HomeMatic  - Installation Unterputz SchaltaktorFür die optimale Integration in die bestehende Haustechnik werden Unterputz-Schaltaktoren angeboten, welche mit Hilfe von Adaptern an die gängigen Systemblenden angepasst werden können – so kann man die ursprüngliche Wippe des alten Schalters verwenden, während hinter dem Schalter lediglich die funkende, neue Technik in der Wand versteckt wird.

Webservices und XML-RPC

Bereits mit der Inbetriebnahme der Steuereinheit gingen auch die ersten Überlegungen einher, wie man denn am besten programmatisch an das neue Spielzeug herankommen könnte. Mit einer ersten Google-Anfrage zum Thema gelangt man zielsicher zur HomeMatic-eigenen Webschnittstelle, basierend auf dem bereits etwas in die Jahre gekommenen XML-RPC-Protokoll.

Auf der Hersteller-Webseite im Download-Bereich findet man detaillierte und verständliche Informationen, wie die Spezifikation der HomeMatic XML-RPC-Schnittstelle. Darin werden das grundlegende Prinzip der Schnittstellenfunktion sowie eine Referenz der verfügbaren Methoden beschrieben.
Weitere Recherchen im Netz führen relativ schnell zu einer C# Bibliothek auf SourceForge mit Beispiel-Implementierung, welche neben der HomeMatic-Bibliothek selbst einen XML-RPC-Server für die Event-basierte Logik als auch einen Client zum Auslesen und Ansprechen des Systems enthält.

Mit dem Wissen aus der Referenz zur XML-RPC-Schnittstelle und der HMRemoting-Bibliothek ließ sich in kurzer Zeit eine für meinen Geschmack ansprechendere Webanwendung als die Systemeigene zusammenbasteln, mit welcher man sich die interessanten Geräte in einer Übersicht darstellen lassen und die schaltbaren Aktoren bedienen kann.

HMC_internal

Analog zum Home Access Center hatte ich im neuen “HomeMatic Center” wieder eine Trennung zwischen externem Netz, DMZ und internem Netz implementiert, so dass per Konfiguration definiert werden kann, wer von wo was sehen und bedienen darf.

Da die Übersicht und Bedienung des Systems nur die halbe Miete ist, folgte unmittelbar darauf ein Benachrichtigungsdienst für den Service Pushalot, welcher bei Statusänderung Bescheid geben sollte. Hier fingen meine Probleme mit der XML-RPC Schnittstelle der HomeMatic an…

Bei der Logik-Schicht kann man sich mit Hilfe der init-Methode mit einem XML-RPC-Server registrieren und sich bei Statusänderungen direkt von der CCU auf dem Laufenden halten lassen. Die mitgelieferte Beispiel-Implementierung funktionierte auf den ersten Blick, so dass ich unmittelbar eine eigene Version umsetzte. Hier überraschte, dass kurz nach Start (zwischen 30 Sekunden und 2 Minuten) des Dienstes keine Events mehr registriert wurden. Nach einigen Versuchen und Grübeln konnte ich das Problem zu allem Unglück ebenfalls mit der eigentlich für gut befundenen Beispiel-Implementierung nachstellen.

HomeMatic - XmlRpc Transport Error

Nachdem ich verschiedenste Threads in einschlägigen HomeMatic-Foren inhalierte, wurde schnell klar, dass es hier wohl ein allgemeineres Problem gibt. Ein Blick in /var/log/messages direkt auf der CCU verschaffte nochmals Gewissheit: Sowohl mein Code als auch der Beispiel-Code verursachten fehlerhafte XML-RPC Aufrufe, die emsig vom System protokolliert wurden.

Mit der Hoffnung auf eine schnelle Lösung des Problems, reifte die fixe Idee, den Dienst auf ein aktives System umzubauen. Statt der Registrierung auf ein Event, sollte der Dienst nun als Client in geringem Versatz (alle 3 Sekunden) ausgewählte Statuszustände bei der CCU abfragen. Das bescherte mir zwar vorerst ein funktionierendes Benachrichtigungssystem – jedoch nur in Form eines wenig eleganten Workarounds, der sich leider ebenfalls als Sackgasse entpuppte. Nach einem Tag Betrieb des Dienstes fielen mir gehäuft temporäre Verbindungsstörungen der HomeMatic-Komponenten auf. Die Service-Meldungen waren permanent voll mit Störungswarnungen und am dritten Tag waren plötzlich die wenige Wochen zuvor eingesetzten Akkus des Rauchmelders leer, so dass ich den Dienst wieder deaktivierte und mich grundsätzlich nach einer anderen Art zum Abfragen des Systems umschaute…

Webservices und das XML-API Addon

Nach einem weiteren guten Tipp kam ich dazu mein erstes Addon auf der CCU zu installieren: XML-API, welches direkt auf der Zentrale XML-Dateien deutlich schneller und mit deutlich mehr Informationen generierte, als ich es von der XML-RPC Schnittstelle des Herstellers kannte. Zwar verfügt das Addon nicht über die Möglichkeit sich Ereignis-basiert zu registrieren – dafür aber stimmen Performance und Last-Verhalten der CCU auch bei schnell aufeinanderfolgenden Zugriffen.
Und damit nicht genug – der Zugriff auf das System-Log und System-Variablen ist problemfrei möglich, was mir zumindest bei der XML-RPC Schnittstelle nicht gelungen ist.

Getrieben von der Idee den Benachrichtigungsdienst sowie auch das HomeMatic Center auf XML-API umzustellen, habe ich begonnen einen kleinen .NET Wrapper für die Verwendung der XML-API zu schreiben. Das Projekt ist mit ersten, einfachen Funktionen bei GitHub unter dem Namen HomeMatic-XmlApi-Lib zu finden. Ich bemühe mich neuere Versionen von Zeit zu Zeit in das Repo zu synchronisieren. Über Anregungen, Forks und Pull Requests freue ich mich.

Fazit

HomeMatic ist vermutlich nicht die ultimative Lösung für alle Fragen und Probleme zum Thema Home Automation. Dennoch ist es ein insgesamt solides und durchdachtes System mit kleineren Macken, die man getrost ignorieren kann, wenn man nicht ein bis in die letzte Ecke professionelles oder absolut perfektes System erwartet, was mit Sicherheit ein Vielfaches der Ausgaben für eine HomeMatic in Anspruch nehmen würde.

Web server in a PowerShell

Ein minimalistischer Webserver ohne viel Ballast, ohne Installation und für eine begrenzte Anzahl an Zugriffen macht sich gut für diverse kleine Aufgaben.

Auch, wenn es auf den ersten Blick etwas umständlich anmuten mag, lassen sich einige Einsatzmöglichkeiten finden. So möglicherweise, um schnell ein lokales Logfile auszuliefern, an welches man nicht ohne weiteren Aufwand heran kommt, um Systemeigenschaften anzuzeigen oder um Web Requests zu analysieren.
Denkbar wäre es auch, mit dieser Variante eines leichtgewichtigen Webservers, Kommandos von einer entfernten Maschine an einen Host abzusetzen, der sich bis auf wenige Ausnahmen, wie beispielsweise HTTP, gut hinter einer Firewall versteckt, und sich anschließend die Ausgabe anzeigen zu lassen.

Der Webserver bedient sich lediglich des System.Net.HttpListener, der im .NET Framework enthalten ist und den Standardfunktionen der PowerShell

Mit wenigen Zeilen Code ist ein solcher Server fix realisiert. Hier im Beispiel werden lediglich einige Details zu den verarbeiteten Web Requests ausgegeben…

Das Script ist relativ kompakt, so dass man es mit dürftiger Formatierung direkt per Copy’n Paste in die Shell einfügen kann…

Webserver in a PowerShell

Im Browser sieht das Beispiel dann so aus…

Webserver in a PowerShell - Chrome und IE

Home Access Center

Mittlerweile beherbergt man, nicht mal mehr nur in “nerdigen” Behausungen, eine Vielzahl von Geräten, die am Netz hängen. Viele davon ebenfalls mit einer irgend gearteten Web-Oberfläche: NAS, Router, Fernseher, Notebook, Netzwerk-Player, Drucker, WLAN-Lampe, usw. – unter IT-Volk gerne auch Server bzw. VMs für Basteleien.

In den seltensten Fällen passt alles perfekt zusammen und eine zentrale Anlaufstelle, die einen flotten Überblick über die Netzwelt in den eigenen vier Wänden erlaubt, sucht man vergebens. Unter den Media Center Lösungen dieser Welt wird gerne versucht dies mit Hilfe von UPnP zusammenzutragen aber auch hier hört es oft dort auf, wo keine Multimedia-Daten mehr zum Abspielen gefunden werden…

Natürlich könnte man sich in einem Intranet mit wenigen Handgriffen eine solche “Zentrale” zusammenklicken. Ein Intranet für zu Hause – egal ob als Entwicklungsumgebung oder tatsächlich um seine Daten zu organisieren keine außergewöhnliche Idee mehr. Aber nur dafür ein Intranet aufsetzen? Eigentlich Quatsch, wenn man nicht zufälligerweise bereits eins zur Hand hat.

Diese Gedanken und eine leere IIS-Willkommensseite, die mir omnipräsent auf all meinen VMs begegnete, trieben mich vor ein/zwei Jahren dazu, ein kleine, flexible und für sich allein stehende Seite zu basteln, die nichts weiter tut, als genau diesen Zweck zu erfüllen. Das “Home Access Center” war geboren…

Home Access Control - Intern

Meine damals wichtigsten Anforderungen:

  • Klein/flexibel mit wenig Overhead (keine Datenbank, keine dickes Backend, so “plain” wie möglich)
  • Konfigurierbar
  • Sowohl von extern als auch von intern (bei mir DMZ und LAN) zu erreichen
  • Anzeige von Menü-Einträgen in Abhängigkeit der Quelle des Zugriffs
  • Differenzierung der Ziel-Links von Menü-Einträgen in Abhängigkeit der Quelle des Zugriffs
  • Anzeige der Erreichbarkeit (Host up / Host down via Ping)
  • Einigermaßen ansprechend sowie sowohl für mobile und stationäre Endgeräte brauchbar

Wie schon oben angedeutet, ergab sich eine Frage zum Hosting der Seite nicht, da in meinem Fall 24/7 ein IIS läuft. Grundsätzlich wäre ein RasPi mit Mono ebenfalls ein geeigneter Host für die Seite. Es handelt sich insgesamt lediglich um eine aspx-Seite nebst Code-Behind, CSS-Dateien/Webfonts, ein paar Bilder für den Hintergrund sowie die XML-Konfiguration.

Die fast wichtigste Funktion ist die Unterscheidung zwischen den Zugriffszonen und die davon abhängig ausgegebenen Ziel-Links. So ist es relativ einfach, intern die Geräte direkt anzusprechen und für den externen Zugriff beispielsweise auf ein Port-Mapping zurückzugreifen.

Home Access Control - Zugriffsschema

Natürlich möchte man nicht auf einer externen Seite den Online-Status seiner sensibelsten Technik offenbaren, selbst wenn die Hyperlinks darauf nicht funktionieren würden, wenn dies nicht entsprechend konfiguriert ist. Mit Hilfe der Unterscheidung zwischen verschiedenen Ziel-Pfaden ist es ebenfalls möglich, ausgewählte Geräte nicht in allen Zugriffszonen zur Verfügung zu stehen, so dass sich externen Gäste oder Besuchern in der DMZ unter gleicher URL ein ähnliches aber doch anderes Bild bietet:

Home Access Control - Extern

Die Konfiguration erfolgt derzeit denkbar einfach über eine XML-Datei, in welcher die einzelnen Endgeräte mit Anzeigenamen bzw. Kürzel, Beschreibung, Host (für den Ping) und den Zugriffspfaden aufgelistet werden.

HAC_Config

Ich freue mich, falls ich hier oder dort jemanden auf eine Idee gebracht habe. Den Code dazu plane ich auf einer der gängigen Open Source Plattformen zu veröffentlichen; falls jemand unmittelbar damit starten möchte, sprecht mich bitte an.

Folgen

Erhalte jeden neuen Beitrag in deinen Posteingang.

Schließe dich 140 Followern an