Qualitätssicherung XING Karriere

Wenn der Spezialist seinen "Werkzeugkoffer" erweitert…

… und die Arbeit mit nach Hause nimmt. Daniel vernetzt den heimischen Saugroboter im Smarthome.

Mittlerweile habe ich mein zweijähriges Jubiläum in der profi.com AG hinter mir. Gestartet als Trainee konnte ich bei unseren Kunden im Bereich Quality als UFT-Experte mit der Erweiterung Mobile Center meine Erfahrungen sammeln. Auch die typischen Fähigkeiten als Consultant: Recherche, Vergleichen, Bewerten, Empfehlungen aussprechen und Umsetzung konnte ich in den letzten Monaten schärfen.

Nun war es an der Zeit, das Repertoire zu erweitern um vielseitiger und flexibler zu werden. Weiterhin im Quality-Bereich tätig, lag es nahe, dass ich mit dem Thema Last & Performance mit MicroFocus LoadRunner (ehemals HPE) beschäftige.

Essentiell ein Unterschied, Skripte nicht mehr in VB-Sprache zu schreiben, sondern in C. Also was heißt schreiben, eher zu lesen, denn LoadRunner speichert jegliche Anfragen vom Browser und Antworten vom Server. Eine Flut an Datensätzen, die es zu interpretieren und gegebenenfalls zu modifizieren gilt. Denn das Hauptaugenmerk bei der Modifikation der Skripte liegt darauf, bestimmte Datensätze zu parametrisieren wie z.B. Session-IDs und Tokens.

Während UFT einen Browser öffnet und beispielsweise in einem Webshop einen Link klinkt – um zu prüfen ob danach die korrekte Seite geladen wird -, schickt LR "nur" den blanken Request (Anfrage) an den Server und misst, wie schnell dieser antwortet.

Ist der Saugroboter per Google Assist steuerbar?
Von diesen Fähigkeiten und Wissen mache ich nun auch in meinem privaten Bereich Gebrauch. Während ich vor circa acht Jahren meine Android-Geräte nur nach Anleitung gerootet habe und Custom-ROMs (modifizierte Betriebssysteme) aufgespielt habe ohne wirklich zu verstehen was ich da wirklich tue, gehe ich bei solchen Sachen nun viel gewissenhafter heran und möchte diese auch verstehen.

Derzeit ist bei mir das Thema Smarthome aktuell. Alles irgendwie vernetzen und automatisieren – auch Geräte, die eigentlich nicht kompatibel sind. Was nicht passt, wird passend gemacht, denn "we make IT work". Sicher gibt es dafür auch Anleitungen und zahlreiche YouTube-Tutorials, an denen ich mich auch orientiert habe, doch meist müssen diese angepasst werden. Also auch hier wieder Recherche, Vergleiche und auf die Situation des Kunden (in dem Falle bin ich das selber) anpassen.

Mittels eines "iobrokers" (ein Web-Service, welcher verschiedene Adapter zum Einbinden unterschiedlichster Geräte anbietet), der auf einem Raspberry Pi betrieben werden kann, konnte ich nun meinen Saugroboter auch per Google Assistent bedienen. Hier kamen also meine LoadRunner- und UFT-Kenntnisse zum Einsatz.

Hier kommt der Flow
Die meisten kennen den bekannten Satz "OK Google…" und danach kommt ein Befehl. Zum Einschalten meines Saugroboters wählte ich folgenden Satz: "OK Google: Sag Nono er soll die Wohnung saugen." Wie sollte der Google Assistent aber mit einem Befehl umgehen, der gar nicht bekannt war. Meistens kam hier die Antwort: "Tut mir leid, dass verstehe ich nicht."

Hier kommt nun IFTTT zum Einsatz. IFTTT ist ein Dienstanbieter für die individuelle Verknüpfung von Webanwendungen (Wikipedia). Auf dieser Plattform kann man den Google Assistent (mit dem individuellen Befehl) mit einem "Webhook" verknüpfen, welcher einen Request versendet. In diesem Request hinterlegt man seinen persönlichen iobroker-Token, wo wir wieder beim Thema LoadRunner wären. IFTTT sendet also einen WebRequest an meinen iobroker zu Hause mit dem Wert "nono an" im JSON-Format. Da dort der Adapter für den IFTTT und den Saugroboter hinterlegt worden sind, mussten auch diese miteinander verknüpft werden. Denn was bringt der Request, wenn er nicht verarbeitet wird. Da kamen meinen UFT-Kenntnisse ins Spiel. Via der Skriptart "Blockly" (JavaScript) setze ich folgenden Befehl in den iobroker: Wenn der IFTTT-Wert sich aktualisiert, prüfe diesen. Hat dieser Wert "nono an", dann setze den Wert "Power on" von dem Sauger auf "wahr".

Nun kann ich den Sauger nutzen, ohne die Hersteller-App zu öffnen. Denn diese Apps machen im Grunde nichts anderes, als einen Befehl an den Hauptserver des Herstellers zu schicken. Und dieser sendet einen Request an das heimische Gerät.

Meine Freunde und Familie schütteln meistens nur lächelnd mit dem Kopf mit dem Kommentar "unser Technik-Nerd". Aber ich muss ehrlich zugeben, dass ich meine Kenntnisse zu Linux, JavaScript, JSON und WebRequests im Allgemeinen so verinnerlichen konnte.

Euer Daniel

Autor

Daniel Martin IT-Consultant
Daniel Martin