Der Heimassi (8)

Nachdem viel neues Equipment da ist, soll dieses jetzt vernünftig genutzt werden. Zum Anfang will ich mal eine einfache Boost-Funktion für die Heizkörper einrichten. Und zwar gesteuert per Kalenderevent.

Es gibt hier Räume, die nur selten betreten werden. Dort ist die Heizkurve eine Gerade. 12°C das ganze Jahr. Sollte man sich einmal länger dort aufhalten, dann weiß man das vorher. Man könnte jetzt natürlich eine halbe Stunde vorher rein gehen und das Ventil von Hand aufdrehen – aber das ist ja hier nicht Sinn der Übung.

Zuerst muss die Kalenderkonfiguration optimiert werden. Wir wollen alle Befehle in einem Kalender unterbringen können. In diesem Fall brauchen wir zwei Anweisungen: HeizungMax und HeizungMin. Also:

calendar:
  - platform: caldav
    url: https://mail-dustpuppy.ddns.net/nextcloud/remote.php/dav
    username: [username]
    password: [password]
    custom_calendars:
      - name: 'HeizungMax'
        calendar: 'hasscal'
        search: '.(H|h)eizung.(M|m)ax'
      - name: 'HeizungMin'
        calendar: 'hasscal'
        search: '.(H|h)eizung.(M|m)in'

Damit hat man zwei Sensoren, auf die man triggern kann. Die verwendet man jetzt in der Automation. Die Max! Thermostate haben eine praktische Boost-Funktion, die HA auch ansprechen kann. So muss man sich nicht darum kümmern, den Thermostat wieder herunterzufahren. Er fällt nach einer in der Max!-App voreingestellten Zeit automatisch wieder ins Programm zurück.

- alias: "Regel 6 - Heizung Max auf Kalenderevent"
  trigger:
    platform: state
    entity_id: calendar.hasscal_heizungmax
    to: 'on'
  action:
    service: climate.set_operation_mode
    data:
      entity_id: climate.waescheraum_thermostat_1
      operation_mode: boost

Auf lange Sicht werde ich da aber wohl das Max!-Geraffel loswerden wollen und das komplette Programm im Kalender hinterlegen.

CO2-Bilanz: Ausgerechnet Trump ist der beste Klimaschützer der Welt – WELT

Quelle: CO2-Bilanz: Ausgerechnet Trump ist der beste Klimaschützer der Welt – WELT

Nur um mal wieder unsere Pharisäer im Bundestag und weltweit ins richtige Licht zu rücken – und zu zeigen, dass selbst ein Blindgänger wie Trump eine funktionierende Regierung nicht mal so kurz auf den Kopf stellen kann.

Der Heimassi (7)

DHL war da – und hat viele, viele Dinge mitgebracht. Das sind dann insgesamt 3 Fensterkontakte, 3 Heizkörperthermostate und ein Gateway von Max!, ein Gateway, ein Temperatur-/Feuchte-/Helligkeitssensor, ein wireless Switch, ein smart Plug, ein Fensterkontakt und ein Bewegunsgmelder von Xiaomi.

Das Max! Ökosystem hat früh angefangen, mir auf die Nerven zu gehen. Der Cube ist ausschließlich per Windows oder Mac OS X konfigurierbar. Also Installation auf einem Windows 10 in einer VBox. Die Software kommt ziemlich spartanisch daher – okay, das Zeug ist auch nicht teuer. Also die Thermostate (Gut zu montieren, mit Adaptern für meine Ventile) montiert, eingebunden, und das Heizprogramm angepasst. Das wollte ich als Fallback-Lösung, falls HA mal nicht mitspielen sollte. Gut. Fertig. Kurz darauf habe ich festgestellt, dass HA nicht mit dem Cube sprechen kann, wenn auf Windows noch der Dienst läuft. Diesen händisch beenden, und die Einbindung klappt auch!

In HA sehen die Thermostate folgendermaßen aus:

Wir haben also Ist- und Solltemperatur, sowie ein Switch für Auto-, Manual-, Boost- und Vacation-Betrieb. Es scheint, die Messung würde über Nacht (also zwischen ca. 23.00 Uhr und 2.00 Uhr morgens) nur sehr rudimentär funktionieren. Vielleicht ein Stromspar-feature. Das muss ich noch herausfinden.

Die Regelung an sich funktioniert recht gut, abgesehen davon, dass die Ist-Temperatur immer so ca. 1,5 K über dem liegt, was als Sollwert vorgegeben wird. Hier kann man aber in der Max!-Software einen Offset eingeben. Ich denke, das sollte auch auf dieser Ebene geschehen und nicht in HA. Korrekte Messwerte sollte man voraussetzen können.

Die Fensterkontakte von Max! sind gut drei mal so groß wie die von Xiaomi. Dafür ist in der Schachtel aber auch wirklich alles drin, um die Kontakte passend montieren zu können. Zwei Sätze Gehäuse und Adapterstücke, in cremeweiß und braun. Das ist sehr nützlich, um nicht mit dem Ästhetikempfinden der Gattin zu kollidieren. Die Einrichtung geschieht ebenso über die Windows-Software. Einer der Kontakte spielte bei der Initialisierung nicht richtig mit, ließ sich nach einem Reset dann aber doch einbinden. HA sieht die Fensterkontakte dann schön als binären Sensor, man kann ihn also auch für alle möglichen Dinge verwenden. Alle Max! Komponenten werden mit 2 AAA Zellen versorgt.

Dann also weiter zu Xiaomi. Erfreulich ist die Tatsache, dass das Gateway per WLAN angebunden wird und sich alles per Android-App einrichten lässt. Äh, wie soll das gehen? Gute Frage: Per Bluetooth! Das Gateway funkt also mit drei Standards. Zigbee, Wifi und eben Bluetooth. Nicht schlecht! Abgesehen von der Tatsache, dass die i18n noch nicht wirklich abgeschlossen ist (Um die Geräte anzulernen muss die App auf den Standort China/Mainland konfiguriert werden – die englische Sprache kann zum Glück beibehalten werden) ist das die komfortabelste Einrichtung, die ich bisher gesehen habe. Das Gateway ist recht hübsch, hat einen LED-Ring um das Gehäuse, der sich stufenlos dimmen lässt und wie ich das sehe das volle sichtbare Farbspektrum hergibt.

Das ist sicher recht nett und kann für irgendwas verwendet werden… eventuell als Temperaturanzeige? Keine ganz schlechte Idee eigentlich.

Kommen wir zum Bewegungsmelder. Ausgepackt und misstrauisch beäugt. Das Teil ist winzig. Das kann ja nix taugen.

Das kann aber auch täuschen! Wo vorher ein Tradfri-Bewegungsmelder mehr schlecht als recht das Ganglicht eingeschaltet hat, deckt jetzt der neue Winzling einen 6 Meter langen Gang hervorragend ab. Egal, zu welcher Tür man den Gang betritt, es wird ohne die kleinste Verzögerung geschaltet. Was allerdings negativ auffiel, ist die Rückfallzeit. Der Bewegungsmelder schaltet ein und bleibt dann für 120 Sekunden im Ein-Zustand. Das ist für mich nur semi-ärgerlich, weil 120 Sekunden ohnehin so in etwa die vorgesehene Zeit war. Für andere Anwendungen ist das allerdings zu berücksichtigen. Ein Bewegungsmelder in HA-Sprech sieht dann etwa so aus:

- alias: "Regel 4 - Lampe Gang"
  trigger:
    platform: state
    entity_id: binary_sensor.motion_sensor_158d0001d68bb4
    from: 'off'
    to: 'on'
  condition:
    - condition: or
      conditions:
      - condition: sun
        after: sunset
        after_offset: "-1:00:00"
      - condition: sun
        before: sunrise
        before_offset: "1:00:00"
  action:
    service: homeassistant.turn_on
    entity_id: light.gang

- alias: "Regel 4/1 - Lampe Gang aus"
  trigger:
    platform: state
    entity_id: binary_sensor.motion_sensor_158d0001d68bb4
    from: 'on'
    to: 'off'
  action:
    service: homeassistant.turn_off
    entity_id: light.gang

(Regel 4: Der Bewegungsmelder triggert den Vorgang, sofern er sich im Zeitfenster eine Stunde vor Sonnenuntergang und eine Stunde nach Sonnenaufgang befindet. Regel 4/1: Die Lampe schaltet ab, wenn der Bewegungsmelder die 120 Sekunden (hardcoded?) durchlaufen hat.)

So weit mal die Lobeshymnen auf Xiaomi. Jetzt das negative: Das Gateway und natürlich auch der Smartplug vom Steckertyp I, was den Mitteleuropäer naturgemäß nur bedingt glücklich macht. Für das Gateway habe ich einen Adapter besorgt. Das geht auch, da habe ich keine Sorgen. Für den Smartplug bräuchte man aber zwei Adapter. Einen von Steckertyp F auf I, und den zweiten von I auf F. Angesichts der Tatsache, dass da eine Waschmaschine dran soll, und die gerne mal 2 KW an Leistung ziehen, ist mir das dann aber doch zu gruselig. Darum wird die Steckdose dann wohl doch von Max! kommen.

Der Multifunktionssensor von Xiaomi ist eine recht kleine Pille, die man überall unauffällig anbringen kann. Tut, was er soll. Misst die Temperatur, den Lichtstrom und die Luftfeuchte.

Den Fensterkontakt von Xiaomi konnte ich bisher nicht anbringen, das war dann zeitlich nicht mehr drin. Es bleibt für mich auf jeden Fall interessant.

Der Heimassi (6)

Wegen Inkompetenz liegt die Einbindung des Google Assistant immer noch auf Eis. Lieferungen von Amazon (Heizkörperthermostate, Fensterkontakte und Gateway) und Gearbest (Xiaomi Set) stehen noch aus. Also runden wir die bestehende Konfiguration mit einem Kalender und Notifications ab.

Fangen wir mit den Notifications an. Pushbullet habe ich vor Jahren mal verwendet und in keiner besonders guten Erinnerung. Zur Zeit benutze ich Wire als Messenger. Für den gibt es (noch) keine Schnittstelle. Telegram gäbe es, aber deswegen werde ich mit Sicherheit den Messenger nicht wechseln. Was bleibt? Wie wäre es denn mit der guten, alten Email? Clients auf allen Geräten? Check! Push Benachrichtigungen wegen zeitnah und so? Check! Einbindung von Anhängen möglich? Check!

Also mal los. Im ersten Schritt muss HA beigebracht werden, wie mit dem Mailserver kommuniziert wird. Den Account habe ich vorher auf dem Server angelegt.

configuration.yaml

notify:
  - platform: smtp
    name: smtp
    server: mail-dustpuppy.ddns.net
    port: 25
    timeout: 15
    sender: hass@dustpuppy.ddns.net
    encryption: starttls
    username: login
    password: pass
    recipient:
      - thodre@dustpuppy.ddns.net
    sender_name: My Home Assistant

HA weiß also was zu tun ist, sollte notify.smtp gecallt werden. Also los:

automations.yaml

- alias: "Regel 3 - CHEMTRAILWARNER!!!!!111einself"
    hide_entity: True
    trigger:
      - platform: event
        event_type: opensky_entry
    action:
      service: notify.smtp
      data:
        message: "Flugzeug fliegt ein, Fenster zu!"
        title: "Luftverkehr"

Diesen Codeschnipsel sollte man tunlichst vermeiden, wenn man unter 50km von einem der größeren Flughäfen Deutschlands entfernt wohnt…

Die Funktion ist damit aber erfolgreich getestet.

Kommen wir zum zweiten Teil. Einbindung eines Kalenders. Wozu sollte man das brauchen? Ich weiss es bisher nicht. Aber manchmal muss man auch etwas tun, weil man es eben kann. Ich könnte mir vorstellen, dass eine Heizungssteuerung per Kalenderevent eigentlich ganz komfortabel sein kann.

Aber welchen Kalender verwenden? Schauen wir mal, was es da so gibt.

Gleich der Treffer matcht hervorragend mit meiner Infrastruktur. CalDav gibbet hier auf dem Nextcloud Server. Zum Testen legen wir einen neuen Kalender ‚hasscal‘ an.

configuration.yaml

calendar:
  - platform: caldav
    url: https://mail-dustpuppy.ddns.net/nextcloud/remote.php/dav
    username: login
    password: pass
    calendars:
      - hasscal

Und da erscheint er auch schon.

Eventuell macht es auch Sinn, mehrere Kalender für verschiedene Aufgaben einzubinden, aber das muss erst noch durchdacht werden. Sowie meine Heizkörperthermostate eintreffen (mit etwas Glück morgen) wird das Kapitel dann wieder interessant.

Der Heimassi (5)

Da Ikea mir zuerst wegen ausbleibender Lieferung und danach aufgrund Lieferung untauglicher Komponenten einen Strich durch die Rechnung machte, wird jetzt improvisiert.

Als endlich der DHL-Mann seinen üblichen hit-and-run Stunt (Paket vor die Tür legen, klingeln und wegrennen. Manchmal bin ich schnell genug, noch eine rot-gelbe Jacke die Treppe hinunterhüpfen zu sehen) abgezogen hatte, ging es ans Auspacken. Diverse Lampen und ein Bewegungsmelder. Im Nachhinein muss ich sagen: Zum Glück nur einen!

Natürlich ist man zu einem gewissen Teil selbst schuld, wenn man sich vor dem Einkauf nicht informiert. Das hat mich jetzt eben 18€ gekostet. Warum? Weil das Teil nichts taugt. Der Erfassungswinkel ist bescheiden, die Reichweite auch, und aus unerfindlichen Gründen gibt es eine mal mehr und mal weniger lange Verzögerung, bis er reagiert. Das für mich mit Abstand nervigste Detail ist allerdings, dass das Teil HA nur den Batteriestand zeigt. Es besteht im Moment keine Möglichkeit, an die eigentliche Funktion heranzukommen. Das alles hätte man natürlich vorher recherchieren können. Haken wir es unter Lehrgeld ab.

Mein Gedanke war jetzt, die Beleuchtung teilweise per Sprache zu steuern. Welche Möglichkeiten bietet HA denn da so? Oh. Einiges!

Da Google ohnehin schon mithört, fiel die Wahl auf den Assistant. Blöde Idee. Das weiß ich jetzt auch. Ein paar Tage zuvor aber nicht. Das ist tragisch, aber man lernt ja auch aus Fehlern.

Also muss HA von außen erreichbar werden. Mein Setup hat schon einen Server (Mail/Nextcloud) im Netz. Es gibt also schon einen DDNS Eintrag und Zertifikate von Letsencrypt dazu. Faulheit siegt! Also geben wir dem bisherigen Server eine Genehmigung, mit key per ssh auf den HA zuzugreifen

/etc/ssh/sshd.conf

PermitRootLogin without-password

Der Mailserver erstellt dann einen Schlüssel, der zum HA in

/root/.ssh/authorized_keys

kopiert wird. Das kann man mit

ssh-copy-id -i key user@zielhost

Auch etwas einfacher haben.

Bei jedem ‚certbot renew‘, wenn also die Zertifikate auf dem Mailserver verlängert werden, kopieren wir einfach per scp privkey.pem und fullchain.pem in die gefertigten Verzeichnisse. Weniger Aufwand geht nicht.

scp -i /root/rootkey /etc/letsencrypt/live/Mailserver/fullchain.pem root@192.168.1.39:/etc/letsencrypt/live/Mailserver/fullchain.pem

Jetzt muss HA noch zu den Dateien finden:

http:
  api_password: secret
  ssl_certificate: /etc/letsencrypt/live/Mailserver/fullchain.pem
  ssl_key: /etc/letsencrypt/live/Mailserver/privkey.pem
  base_url: <URL>

Damit ist der erste Schritt getan und man kann auch mal ohne VPN auf das Interface zugreifen. Bei der Verbindung mit Google Assistant habe ich bisher allerdings kläglich versagt. Nur mal vorneweg so viel: Wer Pandoras Büchse öffnet, hat den Inhalt verdient. Ich Depp!

Microsoft vs. FinFisher: Windows Defender ist gegen den Staatstrojaner gewappnet | heise Security

Quelle: Microsoft vs. FinFisher: Windows Defender ist gegen den Staatstrojaner gewappnet | heise Security

Darauf muss man erst mal kommen: Microsoft schützt Bürger vor schnüffelndem Staat. Generell sollte uns der Staat vor schnüffelnden Konzernen beschützen. Wahrscheinlich wieder alternative Fakten.

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…