Kategorie: Handwerk!

Gegeben war ein Dell Precision aus dem Jahr 2009. Intel Xeon W3520, 4GByte RAM und 300GByte 15k rpm HDD. Die Idee war, einen Server für private Zwecke zu bauen.

Was muss man sich überlegen? Grundsätzlich erst einmal die Frage, wie laut der Rechner letztendlich sein wird, da er sich in der Wohnung befindet. Der Lüfter läuft ständig, ist aber dank niedriger Frequenz von der Geräuschentwicklung her recht angenehm. Check!

 

Der Stromverbrauch. Hier will man natürlich einen möglichst niedrigen Wert erreichen. Die an dieser Stelle gemessenen Zahlen wirken sich unmittelbar auf die Betriebskosten aus. Es lohnt sich also eventuell, hier etwas mehr Geld in die Hand zu nehmen um letztendlich zu sparen.

Erste Messungen waren ernüchternd. Im Leerlauf flossen konstant 120 Watt durch das Netzkabel. Das wären über 300€ Stromkosten im Jahr. Darum werden wir uns kümmern müssen. Aber an welchen Schrauben könnte man hier drehen? Im Gegensatz zur augenblicklichen Umweltpolitik nehmen wir uns anstatt den kleinsten Problemen die größten vor: Den Prozessor und die Festplatte.

Um eine vernünftige Plattform zu bekommen, arbeiten wir von einem Live Linux aus. Meine Wahl fiel auf EndeavourOS – es ist eine ganz neue Distribution die auf Arch Linux basiert und ich wollte sie ohnehin einmal ausprobieren.

Bei der Orientierung im neuen System stellte ich fest, dass alle vier Kerne des Prozessors mit 2,66 GHz, also der maximalen Frequenz getaktet waren. Das ist durchaus positiv. Nach einem kurzen Ausflug ins BIOS und der Einstellung des passenden Governors mittels cpupower takten die Kerne im Leerlauf auf 1,6 GHz herunter und die Leistungsaufnahme des Systems sinkt auf 100 Watt. Ein Viertel weniger. Yay!

Nun haben wir noch einen zweiten Kandidaten. Die Festplatte. Kurze Nachforschungen brachten zutage, dass die als „Dell“ gelabelte Platte tatsächlich eine Fujitsu ist. Sie soll laut Datenblatt im Leerlauf ca. 12-13 Watt benötigen. Also rasch ausgesteckt. Hoppla! Aus mir immer noch nicht ganz nachvollziehbaren Gründen braucht das System jetzt noch 75 Watt. Die HDD hat also ca. doppelt so viel Strom verbraten, als Fujitsu zugibt. Und ‚verbraten‘ ist hier übrigens genau das richtige Wort: Die Platte wurde sehr, sehr warm – trotz gut belüftetem Gehäuse.

 

Hier gab es dann die erste Investition: 40€ für eine 250 GByte SSD. Die ist erstens erheblich schneller und zweitens auch wesentlich genügsamer als die HDD. 76 Watt sagte das Messgerät nach dem Einbau. Damit könnte man zur Not leben.

 

Kommen wir zum Prozessor. Es ist recht einfach, einem Datenblatt die TDP für einen Prozessor zu entnehmen. Der Durchschnittsverbrauch im Leerlauf ist jedoch eine ganz andere Geschichte. Ich habe mich etwas eingelesen und festgestellt, dass es passend für den Sockel 1366 verschiedene vielversprechende Kandidaten gibt, deren TDP niedriger als die des verbaueten W3520 liegt. Der hat eine TDP von 130 Watt. Das ist viel. Der Logik nach würde also beispielsweise ein X5670 trotz zwei Kernen mehr und 12 statt 8 Mbyte Cache bei einer TDP von nur 95 Watt auch etwas weniger Strom verbrauchen. Richtig?

Auf ebay gab es gebrauchte X5670 um 20€ – also schnell geordert und ein paar Tage später war er da.

 

Begeistert und in der Hoffnung einen großen Sprung zu machen den alten durch den neuen Prozessor ersetzt…

 

 

 

 

Kühlkörper wieder drauf, verschraubt, eingeschaltet – und der Bildschirm blieb schwarz. Damit war zu rechnen. Das Motherboard des T3500 verdaut den X5670 nur mit der neuesten BIOS Version. Also wieder die alte CPU rein, ein neues BIOS (A17) geflasht, neue CPU, reboot – es tut sich was! EndeavourOS bootet, alles scheint zu funktionieren… aber der Stromverbrauch hat sich nicht verbessert. Genau genommen ist er um 2 Watt gestiegen! Damit war nicht zu rechnen. Die TDP ist also nicht mal ansatzweise ein Indikator für den Durchschnittsverbrauch im Leerlauf. Ich wusste das zwar, hatte aber die Hoffnung, dass bei solch deutlichen Unterschieden zumindest eine leichte Verbesserung eintreten sollte. Hinterher ist man immer schlauer…

Jetzt bin ich soweit erst mal mit meinem Latein am Ende und fange an, den Server ins Heimnetz einzubinden. Die erste Herausforderung wird eine Nextcloud. Das wäre an sich kein großer Deal, wenn es die nicht schon geben würde – sie läuft auf einem Odroid XU4. Der ist auch ein Grund, warum ich den Server brauche. Für eine gut genutzte Cloud kommt der ARM Prozessor einfach an seine Grenzen. Das wird dann aber ein anderes Thema.

Ein kurzer Ausflug aus dem Thema Home Assistant. Ich möchte hier kurz und prägnant meine Erfahrungen mit Powerline erörtern:

Nein, ich möchte nicht darüber reden. Auch nicht mit einem Therapeuten.

Nach langer Zeit mal wieder ein kleines Projekt: Es kommt bei uns immer mal wieder vor, dass vergessen wird, das Garagentor zu schließen. Das führt direkt auf einen öffentlichen Weg, der kaum einsehbar ist. Ohne Mitbürgern jetzt etwas unterstellen zu wollen lädt so eine Situation ja geradezu ein, sich in der Garage nach Brauchbarem umzusehen. Die Lösung ist aus verschiedenen Gründen nicht ganz einfach.

Bestandsaufnahme: Die Garage ist ca. 20 Meter vom Haus entfernt. Stromversorgung ist da, Netzwerk leider nicht. Auf dem Weg befindet sich keine Möglichkeit, einen aktiven Repeater zu installieren. Damit scheidet Zigbee schon mal aus. Was haben wir noch? Wifi! Wird auch nix – selbst im Freien neben der Garage ist der Empfang erfahrungsgemäß eher mau. Dann bleibt nur noch Erdkabel oder Powerline – aus naheliegenden Gründen wird Letzterem der Vorzug gegeben.

Was wollen wir erreichen? Steht das Garagentor offen und entfernt sich der Fahrer, soll er eine Erinnerung aufs Mobiltelefon bekommen. Dann soll er in der Lage sein, das Tor aus der Ferne zu schließen. Über eine Kamera in der Garage kann vorher geprüft werden, dass das Tor sicher geschlossen werden kann und durch nichts blockiert ist.

Wie stellen wir fest, dass sich der Fahrer entfernt? Dazu müssen wir uns mit Zonen beschäftigen. Für die Standortbestimmung soll natürlich keine Cloudlösung verwendet werden. Die Wahl ist auf Owntracks im Zusammenspiel mit Mosquitto (mqtt-Server) gefallen.

Der vorhandene Garagentorantrieb kann zusätzlich zur üblicherweise verwendeten Fernbedienung auch über einen potentialfreien Kontakt gesteuert werden – also muss ein Relais her.

Einkaufsliste: Powerline-Adapter, Kamera, Türkontakt, Relais.

Mangels Erfahrung habe ich mir einfach die FRITZ!-Adapter geholt. Mit den Wifi-Repeatern von AVM habe ich schon recht gute Erfahrungen gemacht, darum gehe ich davon aus, hier auch keinen Schrott zu bekommen. Das Set bestehend aus 540E und 510E geht für ca. 70€ über die Theke.

Als Kamera kommt eine günstige Foscam C1 für ca. 50€ zum Einsatz. 720p reichen aus, um zu sehen ob jemand im Torbereich steht.

Ich hatte noch einen Xiaomi Türkontakt auf Halde, für den muss ich dann eben noch ein zusätzliches Zigbee-GW installieren. Kostenpunkt Türkontakt: 8€ – für das Gateway sind dann nochmal 30€ fällig.

Zum Schalten brauchen wir jetzt noch ein Relais. Leider gibt es solche nicht gerade wie Sand am Meer. Eine längere Recherche ergab, dass die Sonoff-Geräte zwar gut und günstig sind, aber out-of-the-box nicht von HA unterstützt werden. Es gibt aber zum Glück Menschen mit Plan, die da richtig gute Arbeit geleistet haben. Es gibt für diese Geräte eine alternative Software, die sich über einen mqtt-Server ansprechen lässt. Da wir diesen ja ohnehin für die Standortbestimmung brauchen, trifft sich das gut.

Im nächsten Kapitel wird der Mosquitto-Server aufgesetzt, abgesichert und getestet, die Mobiltelefone mit Owntracks bespielt und die Standortbestimmung in HA eingerichtet.

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.

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.

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.

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!

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…