Der Heimassi (4)

Es gibt Dinge, die fallen einem erst auf, wenn man genauer drüber nachdenkt. Nach Feierabend kommt man heim, man spricht über den Tag, macht vielleicht ein paar Pläne fürs Wochenende. Danach Abendessen, man legt sich einen Film zurecht, macht eine Flasche Wein auf oder schenkt sich ein Glas guten Scotch ein, die Sofa-Liegepositionen sind eingenommen, man startet den Film…

…und dann brennt da noch dieses lausige grelle Licht an der Decke. Die Fernbedienung für das Licht liegt genau weit genug entfernt, dass sie ohne aufzustehen nicht erreichbar ist, die Motivation dazu liegt aufgrund des vollen Bauchs am unteren Ende der Skala. Das Leben ist ungerecht.

Man stelle sich nun einen Superhelden mit fliegendem Cape und hautengen Kostüm vor, einen „hass-man“ Schriftzug über der breiten Brust. Home Assistant kommt zur Rettung!

Ziel ist also eine Kinoschaltung: Drücke ich auf der Amazon-Fire Fernbedienung auf „Play“, soll das Licht herunterdimmen und die Lichtfarbe wärmer werden. So weit, so gut. Da man an das Amazon-Geraffel so wohl noch nicht herankommt, ist es gut, dass die Fire-Box hier eigentlich nur als Hardware für Kodi missbraucht wird. Und an den kommt man sehr gut heran!

Also ist der Trigger mal kein Problem:

- alias: "Regel 2 - Kodi dimmt Licht bei start"
  hide_entity: True
  trigger:
    - platform: state
      entity_id: media_player.kodi
      to: 'playing'

Also wenn Kodi den Zustand nach „playing“ verändert, wird der Trigger ausgelöst.

Nächster Schritt. Welche Conditions machen Sinn?

 condition:
   - condition: time
     after: '17:00'
     before: '23:00'

Wäre eine Möglichkeit, ist aber zu starr. Also eventuell die selben Conditions wie fürs Einschalten des Lichts? Sunset -0:30? Nein. Es geht einfacher.

 - condition: state
   entity_id: light.Wohnzimmer_Decke
   state: 'on'

Wir sagen einfach: Wenn das Licht denn schon an ist, dann dimmen wir auch. Sonst eben nicht.

Wie bringen wir nun aber der Lampe bei, in welchem Zustand wir sie gerne hätten? Wir schicken ihr als Action einen ganzen Datensatz:

 action:
   service: light.turn_on
   data: 
     entity_id: light.Wohnzimmer_Decke
     color_temp: 453
     brightness: 20
     transition: 5

Nicht perfekt, aber schon sehr angenehm. Das Licht ändert die Farbe und dimmt langsam herunter. Farbtemperatur und Helligkeit gleichzeitig ändern kommt auf die Todo-Liste.

Jetzt ist es ja aber so, dass so ein Film recht lange dauern kann, und zwischendurch ein Bio-break (mmorpg-slang für „Ich muss pinkeln!“) nötig wird. Da hier im schummrigen Licht die Gefahr steigt, den kleinen Zeh an Möbeln oder Türfutter hängen zu lassen, will man keine Kompromisse eingehen: Das Licht muss heller werden!

- alias: "Regel 2/1 - Kodi hellt Licht nach Stop auf"
  hide_entity: True
  trigger:
    - platform: state
      entity_id: media_player.kodi
      to: 'paused'
  condition:
    - condition: state
      entity_id: light.Wohnzimmer_Decke
      state: 'on'
  action:
    service: light.turn_on
    data:
      entity_id: light.Wohnzimmer_Decke
      color_temp: 400
      brightness: 200
      transition: 5

Toll. Man mag es kaum glauben, aber es sind Kleinigkeiten, die einen Film besser machen.

Der Heimassi (3)

Der eigentliche Sinn einer Heimautomation liegt im Erledigen von Aufgaben ohne Zutun des Benutzers. Bisher war Home Assistant hier ja nur eine zugegebenermaßen hübsche Visualisierung verschiedener Teilnehmer. Das ändert sich jetzt.

YAML ist eine recht einfach zu erlernende Markup Language. Alle Konfigurationsdateien von HA sind in yaml gehalten. Ich hatte bisher relativ wenig Berührungspunkte, aber die Konfiguration fühlt sich rasch intuitiv an. Nach den ersten zwei, drei mal Einrückregeln missachten wird man vorsichtiger und achtet gewissenhaft auf solche Dinge.

Was will man also automatisieren? Alles, was unter normalen Umständen lästig ist. Also erst mal was einfaches. Abends Licht an. Man will ja nicht immer die Fernbedienung mit sich herumtragen. Da tut sich die Frage auf: Ab wann braucht man Licht? Logischerweise wenn die Sonne untergeht. Es ist ja aber schon vorher dunkel! Macht nix, dazu kann man einen negativen Offset einbauen. Praktisch!

automations.yaml

- alias: "Regel 1 - Licht an abends"
  hide_entity: True
  trigger:
    - platform: sun
      event: sunset
      offset: '-00:30:00'

30 Minuten scheinen mir da ganz in Ordnung zu sein. Was aber, wenn niemand daheim ist? Oha, das hatte ich nicht bedacht. Bewegungsmelder? Müsste man dann ja in jeden Raum einbauen. Blöde Geschichte. Man müsste sowas wie ein Gerät dabei haben, das sich meldet, wenn man daheim ist. Vielleicht mit bluetooth, nfc oder so… oder wifi…

Ja, kein Scheiß. Das waren wirklich meine Gedanken. Auf die naheliegende Lösung, dass heute jeder ein Handy in der Tasche hat, bin ich erst nach mehreren Minuten gekommen. Aber da waren wir beim nächsten Problem. Router unterstützt HA zwar viele, aber da ich Tomato als Router OS verwende, habe ich da nicht wirklich mit Unterstützung gerechnet. Weit gefehlt. HA kann das. Also los!

configuration.yaml

device_tracker:
  - platform: tomato
    host: 192.168.1.1
    username: '******'
    password: '*********'
    http_id: (im Quelltext des Routerinterface nach "http_id" suchen)
automations.yaml

condition:
  condition: and
  conditions:
    - condition: time
      after: '17:00'
      before: '23:00'
    - condition: or
      conditions: 
        - condition: state
          entity_id: device_tracker.thuhuongsiPhone
          state: 'home'
        - condition: state
          entity_id: device_tracker.galaxynote8
          state: 'home'

Edit: Hier hat sich ein Fehler eingeschlichen. In der vorherigen Version waren die Konditionen nicht passend verknüpft. Richtig ist natürlich „Zeit und eines der beiden Telefone“.

Aber moment mal! Sollte jetzt niemand daheim sein, aber später dann heim kommen, wäre der Trigger ’sunset -30′ ja verstrichen und es würde sich nichts tun. Das ist unschön. Also wird das Heimkommen der beiden Telefone noch als zweiter Trigger angehängt.

automations.yaml

- platform: state
  entity_id: device_tracker.thuhuongsiPhone
  entity_id: device_tracker.galaxynote8
  to: 'home'

Dann muss HA noch der Schaltbefehl, also die „action“ mitgeteilt werden.

automations.yaml
 
action:
  service: homeassistant.turn_on
  entity_id: light.Wohnzimmer_Decke

Läuft. Klasse! Die nächste Automatisierung sollte etwas anspruchsvoller sein.

Der Heimassi (2)

Nachdem jetzt der Server für das Wochenende vorbereitet war, konnte die eigentliche Arbeit beginnen. Diverse Lampen und ein Gateway warteten darauf, eingebunden zu werden – neben anderen Dingen, von denen ich noch gar nichts wusste…

Um die Lampen ins Tradfri Gateway einzubinden ist zumindest eine Fernbedienung und ein Smartphone nötig.

Alles funktionierte wie beschrieben und ist somit auch für Nicht-Techniker wohl nicht so die große Hürde. In meinem Fall wurden also vier Lampen und zwei Fernbedienungen eingebunden, was auch gut funktionierte.

Also auf wieder zum Home Assistant. Muss ja auch installiert werden. Ich war versucht die Version aus dem AUR zu verwenden, doch hätte man da viele Abhängigkeiten händisch nachinstallieren müssen. Also dann eben

sudo pacman -S python3 python-pip

sudo pip3 install homeassistant

Der Nachteil dieser Vorgehensweise ist der, dass der dedizierte User nicht mit angelegt wird. Also händisch einen User ohne shell anlegen mit dessen Rechten HA zukünftig ausgeführt wird. Der Systemd Service muss folgerichtig auch mit der Hand am Arm geschrieben werden. Ist das alles erledigt, kann HA gestartet werden. Ich startete den Server erst mal direkt auf der Konsole. Mal sehen, was da so an Meldungen ausgeworfen wird. Es kam eine Menge Zeug, unter anderem erkannte HA schon beim Starten das tradfri Gateway. Allerdings blieb er dort dann auch hängen. Interessant. Nach kurzer Lektüre fand ich heraus, dass das Paket DTLSSocket benötigt wird. Also händisch nachinstallieren.

sudo pip3 install DTLSSocket

Es war spät, und ich wollte ins Bett, darum kann ich nicht sagen, wie lange der kleine Rechner da jetzt compiliert hat, aber es war auf jeden Fall mehr als 15 Minuten. Am nächsten Morgen war er dann fertig und es konnte weitergehen.

Nach dem ersten Start waren auf der Oberfläche bereits zu sehen: Die Tradfri-Lampen (Leider in Gruppen und einzeln, dazu später mehr) und eine Sonnenauf/-untergang Platform. Grundlegende Einstellungen wie Standort etc. können in der Konfigurationsdatei configuration.yaml hinterlegt werden.

HA hat aus Tradfri die mit der Android-App angelegten Gruppen übernommen, konnte diese aber nur dimmen. Es gab keine Möglichkeit, die Lichtfarbe zu verändern. In der Community wurde das schon behandelt und es gibt dafür neben der Konfigurationsdatei noch eine zusätzliche Datei namens customize.yaml, in der diese speziellen Anforderungen untergebracht werden können.

light.tradfri_group:
  hidden: true
light.gruppe_2:
  hidden: true
light.verschiedenes:
  hidden: true

Die einfachere Möglichkeit

tradfri:
  allow_tradfri_groups: false

hat zumindest hier jetzt nicht funktioniert. Da ersteres auch zum Ziel führt, kann man damit ja leben. Jetzt lassen sich die einzelnen Lampen sauber bedienen, ohne die nutzlosen Gruppen in der Übersicht zu haben. Das Ansprechverhalten auf Befehle liegt im Zehntelsekunden-Bereich.

Neben den Zeiten für Sonnenauf und -untergang sind natürlich auch Wetterdaten für eine Automation durchaus relevant. Dafür kann man sich beispielsweise einen API-key bei Openweathermap holen, und diese mit einbinden. Auf der Übersicht sieht das hübsch aus und man hat Daten, um darauf zurückzugreifen, was besonders in der Heizperiode sinnvoll ist.

Der nächste Kandidat war ein Kodi, der sich da auf dem Amazon Fire TV versteckt. Die Einbindung erwies sich als sehr geschmeidig. Der Samsung Fernseher war allerdings nur mit Mühe davon zu überzeugen, überhaupt ein Lebenszeichen von sich zu geben. Das tut er nun zwar, aber sehr verzögert.

Nachdem jetzt alles notwendige auf dem Server liegt (dachte ich), kann ich ja mit den Automationen beginnen. To be continued…

Der Heimassi (1)

Nach anfänglichem Desinteresse und danach langem Abwarten auf vernünftige Standards wurde im Hause Dreher beschlossen, sich mit Gebäudeautomation zu beschäftigen. Nicht, weil man das jetzt unbedingt brauchen würde – aber inzwischen jucken die Finger, wenn ich darüber lese.

Die Herausforderung besteht natürlich darin alles so gut zu machen, dass auch die Frau der Ansicht ist, ich verschwende nicht nur meine Zeit. Der Super-GAU wäre demzufolge der Server steht und sie kriegt das Licht nicht an. Also muss eine komfortable Handebene für alle relevanten Teilnehmer vorhanden sein. Wobei diese dann auch mehr können muss, als  Licht an/aus – sonst verbaut man ja nur teure Lampen. Mein Ziel ist eine komplette Bedienbarkeit der Wohnung von einem zentralen Server aus. Heizung, Licht, Medien etc. – alles muss da auflaufen und verknüpft werden können. Zudem kommt noch (begründetes) Misstrauen gegenüber allen „Cloud-Lösungen“, die irgendwelche Hersteller da so hingefrickelt haben. Die Logik der ganzen Geschichte muss auf dem Server daheim liegen – und der hat quelloffen zu sein.

Mit einheitlichen Protokollen tun sich die Hersteller der smarten Geräte leider immer noch recht schwer. So bleibt also als Lösungsansatz nur ein Server, der viele Sprachen spricht. So etwas gibt es zum Glück. Nach ein Bisschen Recherche hielt ich fhem für die alleinseligmachende Lösung. Doch so kurz vor Beginn der Experimente wurde ich mit der Nase auf eine modernere Lösung gestoßen. Home Assistant ist ein in Python3 programmierter Server, der quelloffen ist, eine sehr lebendige Community hat und sich rasch weiterentwickelt. Mein Heimautomatisierungspapst, der kommunikationsfördernd im selben Betrieb arbeitet, kannte den HA auch noch nicht, sah ihn aber grundsätzlich als interessant an. Damit war auch die Entscheidung zur Software getroffen.

Die Auswahl der Hardware gestaltete sich zumindest im Bereich Server sehr einfach. Die XU4 von Odroid kenne ich von früheren Projekten. Die haben mehr Leistung als nötig und sind in Verbindung mit dem richtigen OS ein Traum. Wo wir schon bei OS sind… hier fiel meine Wahl auf Arch Linux, weil ich eben fast alles mit Arch mache. Es fühlt sich einfach gut an.

Also XU4, Arch, HA…. was fehlt noch? Ah, klar, man braucht auch was, was man automatisieren kann! Gut. Also fangen wir mal mit Licht an. Das klingt einfach. Wifi-Lampen? Will ich eigentlich nicht. Erstens brauche ich keine 100Mbit an ner Lampe, zweitens ist Wifi ein Stromfresser. Dabei geht es nicht um die eine oder andere Kilowattstunde pro Jahr, sondern um batteriebetriebene Geräte im Verbund. Ich will nicht alle zwei Monate Batterien tauschen müssen. Also Recherche. Es gibt da ein paar ganz brauchbare Protokolle. Meine Wahl fiel auf Zigbee. Interessant ist hier, dass jedes angeschlossene Gerät auch als Repeater dient. Die Reichweite sollte also bei entsprechender Gerätedichte enorm sein.

Nach etwas Recherche und abermaliger Konsultation meines Heimautomatisierungspapsts kam ich zum Schluss, dass zu den Leuchtmitteln auch das Zigbee-Gateway des selben Herstellers anzuschaffen ist. Zwar sind auch beispielsweise Ikea Tradfri Komponenten über Philips Hue Gateways bedienbar – aber ich habe auf Ebay zu viele 5€-Gesuche „Möchte das Tradfri Gateway zum Update meiner Komponenten auleihen“ gesehen, um mir diesen Schuh anzuziehen. Ikea sagt aber leider, dass das Gateway um 29,90€ zur Zeit nicht online verfügbar ist. Andere Anbieter verlangen für das selbe Gerät mindestens 50€, Amazon liegt bei 57€. Verfügbar wäre es beim Ikea in Ulm. Aber das sind insgesamt 240 km. Verdammt. Der Zufall wollte es, dass ich auf eben diesem Ebay auch ein Angebot über 2 Fernbedienungen (Handebene – hrhr), einem Gateway und diverse Lampen gefunden habe. 80€ für Komponenten, die gut 150€ gekostet haben. Damit kann ich leben.

Gestern kam alles an. Also erst mal Lampentausch. Aha. 980 Lumen sind richtig hell. Kurz die Fernbedienungen angelernt. Mit denen kann man ziemlich komfortabel Lichttemperatur und Leuchtstärke verändern. Hübsch. Frau ist amüsiert. 15 Minuten.

OS auf den Odroid installieren. Schon oft gemacht, maximal 15 Minuten. Genau genommen kopiert man ein image auf eine SD-Karte, stumpf nach Anleitung, das funktioniert einfach.

Danach 30 Minuten Anpassungen fürs Wohlfühlen. Editor, Shell, Zeitabgleich, Locale, frequency scaling, Netdata etc.

Unverständlicherweise habe ich in der Hektik nicht bemerkt, dass ein Update nicht duchlief, weil ein file bereits von einem anderen Paket vorhanden war. Leider war der Paketmanager schon auf einer neueren Version, die ohne dieses Update dann nicht mehr wollte. Nach kurzem Abwägen wurde beschlossen, nochmal mit dem Image zu beginnen, und dieses mal besser aufzupassen. Und wie es meistens so ist… kaum macht man’s richtig, tut’s dann auch. Also ca. 45 Minuten kaputt gemacht.

Nachdem also ein nagelneuer Rechenknecht nun bereit war seinen Dienst zu tun, konnte ja alles losgehen. To be continued….

AfD: Die Rechtspopulisten und der nationale Sozialismus – Kolumne – SPIEGEL ONLINE

Die AfD dürfte künftig auf einen Politikmix setzen, der in der deutschen Geschichte schon einmal furchtbar erfolgreich war: Rassismus plus Sozialstaat. Dann droht der Aufstieg der Rechten zur Massenbewegung.

Quelle: AfD: Die Rechtspopulisten und der nationale Sozialismus – Kolumne – SPIEGEL ONLINE

Man muss nicht mögen, was Augstein schreibt – aber das hier ist einfach nur brillant analysiert. Anstatt allerdings selbst mal zu analysieren schachern unsere GROKO-Granden um Ministerposten. Die AfD ist nicht einfach aus dem Nichts gewirbelt. Sie wurde gemacht. Von denen, die uns heute erzählen, wie gefährlich sie ist.

Bundesbank-Vorstand: Regulierung von Bitcoins nur Frage der Zeit | heise online

Quelle: Bundesbank-Vorstand: Regulierung von Bitcoins nur Frage der Zeit | heise online

Unter dem Vorwand „Man muss die Leute doch vor sich selbst schützen!“ wird wieder eine gute Sache kaputt gemacht, nur um Branchen zu schützen. Geschäfte an der Terminbörse sind mindestens genau so gefährlich wie Bitcoin-Trading – aber die Banken verdienen ja daran mit. Dann muss natürlich niemand geschützt werden. So hat man schon mit Uber (das an sich eine tolle Idee ist und in anderen Ländern perfekt funktioniert) eine neue Technologie, die fast nur Vorteile hat, im Ansatz erstickt. Und darum zahlen wir Deppen weiterhin 20€ für ein paar Meter mit dem Taxi.

Große Koalition zu Klimaschutz: Union und SPD wollen Ziel 2020 aufgeben – SPIEGEL ONLINE

Es war einer der Jamaika-Knackpunkte – nun haben Union und SPD das deutsche Klimaschutzziel gleich zu Beginn der Koalitionsgespräche gekippt. Eine Verringerung des CO2-Ausstoßes um 40 Prozent bis 2020 sei unerreichbar.

Quelle: Große Koalition zu Klimaschutz: Union und SPD wollen Ziel 2020 aufgeben – SPIEGEL ONLINE

 

Pharisäertum erklärt:

„USA erklären Austritt aus Pariser Klimaabkommen.“

 

„Union und SPD wollen Klimaziele aufgeben.“

Sowas kann man sich nicht ausdenken…