so wie das modewort „nachhaltig“ eigentlich nichts anderes als „zukunftsfähig“ bedeutet, sind sogenannte „smart-home“ geräte oder apparate mit dem präfix „smart“ eigentlich eine umschreibung für „vernetzt“. un-smarte geräte sind auch vernetzt, aber lediglich mit dem stromnetz. vom stromnetz werden sie mit schaltern am gerät oder in der nähe des geräts geschaltet und machen dann ihr unvernetztes ding, für das sie gebaut sind.

vernetzte geräte, die sich dank ihrer vernetzung nicht nur durch schalter fernsteuern lassen, sondern durch apps oder sprach-assistenten, sind toll. ich beschäftige mich jetzt seit zwei, drei jahren intensiv mit ihnen. dabei haben sich ein paar eigentlich triviale, aber dennoch zentrale erkenntnisse herausgebildet:

erstens: fernbedienung ist toll, aber wichtiger sind offene, programmierbare schnittstellen
eine lampe mit einer app zu steuern ist vielleicht für ein paar wochen aufregend. danach wünscht man sich schalter oder andere ergonomisch angebrachte steuerelemente, zum beispiel ein touchpad, drehregler oder — seit knapp zwei jahren ganz neu — sprachsteuerung. aber am allermeisten wünscht und fragt man sich, also ich zumindest, wie man das vielleicht alles ein bisschen automatisieren, abkürzen kann — und nicht mehr alles selbst zusammenklicken muss.

zweitens: beware of the cloud
es gibt kaum noch „smarte“ (also vernetzte) geräte zu kaufen, die ohne „cloud“, also mit einer direkten leitung zum hersteller, angeboten werden. gegen die cloud sprechen nicht nur allerlei datenschutz- und privatshären-gründe, sondern auch praktische erwägungen: die cloud hat hohe latenzzeiten und die internet-verbindung ist öfter weg als man denkt, aber noch öfter sind die hersteller die einem das gerät verkauft haben und die cloud am laufen halten, plötzlich vom fenster weg oder werden von arschloch-firmen aufgekauft. geräte die sich nicht auch lokal, vor ort vernetzen lassen, also auch eine lokale API (schnittstelle) anbieten, haben im haus oder der wohnung eigentlich nichts verloren. abhängigkeit von der cloud ist alles andere als „smart“.

worauf ich aber eigentlich heraus will, und weshalb ich den artikel vor ein paar tagen ursprünglich angefangen zu schreiben habe, ist automatisierung. was mich (als frickler), aber (hoffentlich) auch andere haushaltsmitglieder dauerhaft begeistert, sind ausgefeilte automatisierungen.

anfang der woche habe ich die spülmaschine eingeschaltet und 5 sekunden später plärrte es aus meinem lautsprecher: „es sind nur noch wenige geschirrtabs da. ich hab tabs auf die einkaufsliste gesetzt.“

das schöne ist: ohne weiteres zutun hat das auch funktioniert.

die automatisierung die die aktion ausgelöst hat ist alles andere als „smart“ oder wirklich intelligent; eigentlich ist sie sogar trivial:

so trivial diese automatik auch ist, ich habe noch keinen weg gefunden, soetwas mit systemen der grossen player abzubilden, weder mit homekit, bzw. der home-app von apple, noch mit alexa-routinen oder dem google-home gedöns. samsung hat ein cloud-basiertes system namens „smartthings“, mit dem man sowas vielleicht machen könnte, aber das problem, das alle grossen hersteller bisher nicht mal in ansätzen gelöst haben, ist die integration von sensoren und aktoren über herstellergrenzen hinweg.

ansätze dafür gibt es, aber lösungen die über viele herstellergrenzen hinweg funktionieren, sind bisher nur im DIY (do it yourself) bereich zu finden. lösungen wie home assistant, openHAB und viele andere ermöglichen alle möglichen geräte, sensoren, aktoren zusammenzuflanschen und in einem guss zu automatisieren.

zurück zum beispiel: grundlage der bestell-automatik sind natürlich erst mal sensoren, an erster stelle ein sensor der die anzahl verbliebener tabs verzeichnet. die anzahl tabs ist ein abgeleiter sensor. ich leite die zahl der tabs von einem sensor ab, der registriert wenn die spülmschine angeschaltet wird (und wann sie fertig ist). das wiederum leite ich von einem senor ab, der den stromverbrauch der spülmaschine misst und daraus den betriebszustand der spülmaschine ableitet.

die aktoren sind schon etwas komplexer. es gibt derzeit keinen weg der bring.app einkäufe hinzuzufügen — ausser über die app oder über alexa. bring hält es für unnötig hier eine öffentlich zugängliche API zur verfügung zu stellen. über die alexa-integration, die selbstverständlich auf einer (geschlossenen) API basiert, zu der nur amazon und bring selbst zugang haben, kann ich mich aber trotzdem einklinken.

der dienst bespoken.io erlaubt es mir statt alexa ein komando zuzurufen, alexa ein kommando per rest-schnittstelle zu übermitteln. obwohl ich keinen echo-lauschsprecher mehr in betrieb habe, kann ich so mit alexa-skills kommunizieren die mit meinem amazon-konto verknüpft sind.

shell_command:
  ask_alexa: >-
      /usr/bin/curl -X PUT -G 'https://virtual-device.bespoken.io/process' --data-urlencode 'message={{message}}' --data-urlencode user_id=alexa-xxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx --data-urlencode language_code=de-DE -H 'content-length: 0' -o /Users/ix/.homeassistant/scripts/alexa_response.json

wenn ich bespoken programmatisch bitte die nachricht „öfffne bring und füge geschirrtabs hinzu“ an mein alexa-amazon konto zu senden, hat das die gleiche wirkung als würde ich das in ein amazon-echo-mikrofon sprechen. die antwort des bring-skills liefert bespoken freundlicherweise auch gleich mit, so dass ich den auch wieder ausgeben kann — ganz ohne echo dot. (ein weiterer vorteil der lösung über snips ist übrigens auch, dass ich jetzt einfach sagen kann: „wir brauchen milch“, wohingegen mich die alexa-lösung dazu zwingt einen quatsch-satz zu sagen wie: „öffne bring und füge milch zu meiner liste hinzu“)

der zweite aktor macht nichts anderes als snips zu bitten eine tts (text to speech) nachricht in der küche abzuspielen: „es sind nur noch wenige geschirrtabs da. ich hab tabs auf die einkaufsliste gesetzt.“

aufmerksame leser bemerken jetzt natürlich einen widerspruch: ich nutze die cloud für unseren einkaufszettel und um diesen zu füllen. wichtig ist (mir) aber ein prinzip, von dem ich zuerst im architekturstudium gehört habe, und dem ich später in der programmierung und webseitengestaltung wiederbegegnet bin: das prinzip der würdevollen fehlfunktion („degrade in grace“). beim studium ging es eigentlich um materialien „die würdevoll altern“, aber egal ob es sich um material, code oder eine benutzerschnittstelle handelt, alle sollten bei fehlfunktion die würde und ihr gesicht wahren. wenn der eintrag nicht in der einkaufsliste auftaucht, weil die cloudanbindung nicht funktioniert: halb so schlimm, mich hat zumindest die nachricht erreicht, dass nur noch wenige tabs da sind. vielleicht habe ich das auch schon so gesehen. wichtiger ist mir hingegen die zahl der spülzyklen zu erfassen (und daraus den strom und spülmittelverbrauch abzuleiten und gegebenenfalls auszuwerten). das funktioniert auch ohne internet verbindung und diese sensor-daten bleiben in der wohnung. sollte das lokale netzwerk ausfallen ist es zwar schade, dass dann die laufzeiten nicht erfasst werden und ich keine spülmaschine-ist-fertig-nachricht mehr auf mein handy bekomme, aber immerhin funktioniert die spülmaschine noch. fällt der strom aus, kann ich immer noch wasser mit dem gasherd aufkochen und mit der hand spülen. ohne gas ist es dann aber aus mit der wohnwürde.

dieser schichtweise aufbau der technik-funktionen ist meiner meinung nach bei der konzipierung aller aspekte der heimautomatisierung essentiell. die äusserste schicht, die cloud, auf die ich den wenigsten einfluss und kaum kontrolle habe, sollte, wenn überhaupt, nur für komfort-/luxusfunktionen dienen. alles was essentiell ist, licht, wärme, schlösser, geräuschquellen sollten mindestens zwei ebenen tiefer liegen und möglichst eine optionale manuelle steuerung bieten.

tl;dr: weder vernetzung, noch fernbedienung oder automatisierung verdienen im heim wirklich das label „smart“. aber die automatisierung von (am besten lokal) vernetzten, fernbedienbaren geräten macht wirklich spass und befriedigt (wenns funktioniert) tief.