Der Heimassi (10)

Nachdem sich der aus dem Powerline-Disaster entstandene Blutdruck wieder normalisiert hat, kommen wir zur Mosquitto-Server. MQTT ist ein offenes Protokoll, das sehr gut für M2M geeignet ist. Auch bei hohen Latenzen können Telemetriedaten vernünftig übertragen werden.

Der Mosquitto ist relativ einfach aufzusetzen. Hier ist ein vernünftiges Howto. Worauf zu achten ist, ist die Verwendung von Logins und die Absicherung via TLS. Es ist ratsam, hierfür die Zertifikate von Letsencrypt zu verwenden. Ist alles aufgesetzt, lässt sich die Funktion prüfen, indem man einfach mal alle Topics abonniert:

mosquitto_sub -u <user> -P <secret> -t "#"

Mit Hilfe von mosquitto_pub lässt sich eine Meldung publizieren. Man gibt in einer zweiten shell ein:

mosquitto_pub -h 127.0.0.1 -p 8883 -u <user> -P <secret> -t home/garage/sonoff_kanal1 -m ein

mosquitto_sub sollte nun ein einfaches „ein“ in einer neuen Zeile ausgeben. Damit wissen wir, dass der Server wie gewünscht funktioniert. Jetzt muss er noch mit Standortdaten gefüttert werden, damit HA bestimmen kann, wer sich wo befindet.

Hierzu verwende ich Owntracks. Die App ist sowohl für Android als auch für IOS erhältlich und open source – was bei personenbezogenen Daten wie Standorten ein wichtiges Merkmal ist.

Die Einrichtung verläuft relativ einfach. Unter „Einstellungen“ erstellt man eine „MQTT Privat“ Verbindung, verwendet das im Server hinterlegte Login und aktiviert TLS. Erfahrungsgemäß sind in der Standortbestimmung Verzögerungen von ein paar Minuten möglich. Das lässt sich per Einstellung in Owntracks tweaken – aber da wir jetzt keine sehr schnelle Reaktion brauchen und auch die Batterie des Telefons schonen wollen, bleiben wir da sehr zurückhaltend.

Jetzt bringen wir HA noch bei, diese Daten zu verwenden. Zum Einen müssen wir HA den Mosquitto bekannt machen:

mqtt:
  broker: 127.0.0.1
  port: 8883
  username: <user>
  password: <secret>

Zum Anderen muss HA wissen, wie er mit den Daten umzugehen hat:

device_tracker:
  - platform: owntracks
    mqtt_topic: "owntracks/#"
    max_gps_accuracy: 200
    waypoints: True

Um nun festzustellen, ob sich jemand vom Haus entfernt, verwendet man Zoning. Praktischerweise hat HA die Heimzone schon fertig eingerichtet. Die ist aber in der Grundkonfiguration schon recht groß und schließt in meinem Fall den Supermarkt mit ein – den man aufgrund von Großeinkäufen von SWMBO auch öfters mal mit dem Auto besucht. Das ist unpraktisch, weil dieser Punkt schon als „nicht daheim“ registriert werden soll. Also macht man die Zone manuell etwas kleiner.

zone:
  - name: work
    latitude: <lat>
    longitude: <lon>
    radius: 150
    icon: mdi:worker
  - name: Home
    latitude: <lat>
    longitude: <lon>
    radius: 150
    icon: mdi:account-multiple

Wird die Heimzone manuell konfiguriert, überschreibt sie die automatisch angelegte. Jetzt haben wir eine Standortplattform, auf deren Basis Bewegungen als Trigger oder Conditions verwendet werden können.

Im nächsten Kapitel schauen wir uns die Sonoff-Relais an. Sie brauchen eine alternative Software, die mqtt spricht.

 

 

 

 

Powerline…

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.

Der Heimassi (9)

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.

Google: Chrome-Browser scannt lokale Dateien auf Windows-PCs | heise online

Quelle: Google: Chrome-Browser scannt lokale Dateien auf Windows-PCs | heise online

Einfach nur NEIN. Jetzt investiert Google also auch in Scheinsicherheit. Ich hoffe, mich da zu täuschen, aber wenn Google in die Richtung weiterentwickelt, muss man wohl davon ausgehen, dass hier eine Übernahme von Innen vonstatten gehen soll. Spinnt man die Geschichte etwas weiter, kann das tatsächlich Sinn machen – zumindest für Google. Chrome wird zum OS aufgeblasen, das dann quasi Windows nur noch als Hostsystem nutzt. Nur: Wer will das?

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.

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!