Wir haben bei uns in der Wohnung zwei Klimaanlagen von Panasonic im Einsatz. Beides sind eigenständige Split-Geräte.

Im Schlafzimmer ist ein Kit (Innen CS-Z20VKEW und Außen CU-Z20VKE) verbaut.
Im Wohnbereich ist ein Kit (Innen CS-XZ42ZKEW-H und Außen CU-Z42ZKE) verbaut.

Beide Klimaanlagen möchte ich mit SmartHomeNG ansteuern.

1. Ansatz: Anbindung an KNX

Eine Möglichkeit ist der Einsatz von jeweils einem INTESIS INKNXPAN001I000 KNX-Klima-Gateway, um eine Verbindung der Klimaanlagen zu meinem KNX Bus herzustellen. Diese Lösung setzt voraus, dass in der Nähe der Klimaanlagen ein grünes Buskabel liegt. Außerdem ist die Lösung nicht gerade preiswert. Der offizielle Katalogpreis im Panasonic Katalog liegt über 500 Euro. Der günstigste Preis den ich gefunden habe, liegt immer noch bei 260 Euro je Stück.

Da bei einer Klimaanlage kein Buskabel in der Nähe ist (und aufgrund der hohen Kosten), fiel diese Lösung aus.

2. Ansatz: Eingebautes WLAN Interface

In den Klimaanlagen ist serienmäßig zwar ein WLAN Interface verbaut, dieses kann jedoch nur eine Verbindung zur Panasonic Comfort Cloud aufbauen und nicht lokal angesteuert werden.

Auf pypi.org fand ich ein Python Package, welches die Kommunikation mit der Panasonic Comfort Cloud ermöglichte. Dieses Package setzt auf dem API auf, welches die Panasonic App auf iOS und Android nutzt. Allerdings ist dieses API von Panasonic nicht veröffentlicht, so dass das Package per Reverse-Engineering des API entstand.

Nach Anlaufproblemen, da die Comfort Cloud gerade das Login Verfahren geändert hat und ich auf eine neue Version des Python Packages warten musste, verliefen die ersten Tests vielversprechend. Alle Aspekte der Klimaanlagen waren steuerbar.

Ich habe daraufhin in den sauren Apfel gebissen, die Nutzungs-Daten der Klimaanlagen einer Cloud anzuvertrauen und begonnen ein Plugin für SmartHomeNG zu entwickeln. Das Plugin hat auch einen nutzbaren Status erreicht, aber dann begannen für mich die Probleme. Die Panasonic Comfort Cloud hatte mehrere Störungen und war Stunden- bzw. Tageweise nicht zu erreichen. In diesen Zeiten konnten die Klimaanlagen über SmartHomeNG nicht gesteuert werden und die Infrarot-Fernbedienungen der Klimaanlagen mussten wieder ausgepackt werden. Im Internet fand ich diverse Beiträge von Usern, die sich über die störanfällige Panasonic Comfort Cloud ausliessen. Diese Beiträge waren zum teil aktuell, zum Teil jedoch bereits Jahre alt. Das war ein Zeichen, dass Panasonic anscheinend nicht an der Zuverlässigkeit der Comfort Cloud arbeitet. 

Da wir mit der Cloud Lösung nicht zufrieden waren:

• Daten auf Systemen, bei denen ich keine Kontrolle über den Zugriff habe
• Möglichkeit die Klimaanlagen durch jemand zu steuern, der sich Zugang zur Cloud verschafft
• Störungsanfälligkeit der Panasonic Comfort Cloud
• Durch dass nicht veröffentlichte API jederzeit der Ausfall des Zugriffs auf die Cloud möglich war (wie zuletzt bei der Änderung des Login-Verfahrens)

fiel diese Lösung bei uns auch aus.

3. Suche nach einer anderen Lösung

Die Panasonic Klimaanlagen verfügen über zwei Möglichkeiten sie ohne Cloud zu steuern:

• Infrarot Fernbedienung
  
• Gateways (z.B. das INTESIS KNX-Klima-Gateway), die an den CN-CNT Anschluß der Klimaanlage angeschlossen werden. 
  
  

  CN-CNT Anschluß

Der erste Ansatz (ein Device zu bauen, welches die IR Codes der Fernbedienung aussendet) hat einen entscheidenden Nachteil: Die Kommunikation ist uni-direktional. Das bedeutet, dass SmartHomeNG keine Veränderungen am Status der Klimaanlage mitbekommt, die z.B. durch die Fernbedienung oder durch Unterbrechung der Stromzufuhr herbeigeführt wurden.

Deshalb ist es besser eine Lösung zu suchen, die über den CN-CNT Anschluß mit der Klimaanlage kommuniziert, da hierbei eine bi-direktionale Kommunikation möglich ist.

Ich bin daraufhin längere Zeit tief im Internet verschwunden und habe nach einer Lösung gesucht, die über den CN-CNT Anschluß kommuniziert.

Bei der Suche bin ich auf eine Lösung gestoßen, die auf einer dafür designten Platine mit einem ESP32-C3 Mini Platine, einer selbst zu erstellenden Platine und der ESPHome Software besteht. Diese Lösung wird allerdings seit September 2023 nicht mehr als Fertiggerät angeboten. Es besteht dort ein Link zu einer Selbstbau-Anleitung, bei der allerdings die Platine selbst geätzt (oder bei PCBway in Auftrag gegeben) werden müsste. Die Platine ist nötig, um eine 3.3V zu 5V Wandlung durchzuführen. Das war mir doch zu viel Eigenarbeit, so dass ich auf Basis der hier gefundenen Informationen weiter gesucht habe.

Bei der Suche bin ich auf einen Forenbeitrag gestoßen, der beschrieb, dass die 3.3V zu 5V Wandlung nur für den ESP8266 notwendig ist, da die GPIO Anschlüsse des ESP32 Prozessors 5V tolerant sind. Das senkt den Aufwand deutlich.

Ich habe mir also ein Kabel mit dem Stecker für den CN-CNT, ein ESP32-C3 Supermini und ein Gehäuse besorgt und angefangen.

Bauteile

Meine gesammelten Erfahrungen und der Weg zur fertigen Lösung beschreibe ich in einem seperaten Beitrag.

Ausgangspunkt

Basis meines Setups ist SmartHomeNG in neuster Version, dazu die SmartVISU 2.9. Vorgeschaltet ist NGINX als ReverseProxy wie einst in https://www.smarthomeng.de/nginx-als-reverseproxy beschrieben. Auf dem Tablet selber testete ich mich erneut durch diverseste Anleitungen zum automatischen Einschalten via Bewegungserkennung. Die Anleitungen basierten auf den Apps / Kombinationen der Apps MacroDroid, Tasker und Motion Detector. Ein Teil dieser Apps ist kostenpflichtig. Via Tasker und Motion Detector konnte ich das Ganze zumindest für 24 Stunden lauffähig bekommen. Allerdings stellte ich fest, dass oft eine der Apps wegen CPU Überlastung des Geräts beendet wurde. Auch landete ich regelmäßig in einem Zustand, in dem das Display des Tablets einfach nicht mehr ausgehen wollte, was sogar in leichtem Einbrenneffekt im OLED resultierte. Auch die Einrichtung des Ganzen war alles andere als einfach…

Frustriert wollte ich schon aufgeben, da bin ich auf die App „Fully Kiosk Browser & App Lockdown“ (bzw. https://www.fully-kiosk.com/de/) gestoßen. Vom Namen her klang das ganze etwas etwas seltsam, stellte sich im Nachhinein aber als praktikable und super einfache Lösung heraus.
In der Basisversion ist die App kostenlos. Für das was ich vorhatte (Authentifizierung via Clientzertifikaten + Bewegungserkennung) musste ich leider die volle Version für stolze 6.90 € (pro Gerät) freischalten.

Setup

Nach dem Download aus dem Playstore und der kostenpflichtigen Freischaltung der vollen Features, geht man in der App erstmal über die linke Randleiste in den Bereich „Settings“.

Unter „Web Content Settings“ muss als erstes die Start URL auf den DynDNS HTTPS-Einstiegspunkt für die smartVISU gelegt werden. Später habe ich die Start-URL hier noch angepasst, da ich ein 3-spaltiges Layout in die smartVISU implementiert habe, um die volle Breite des Tablets optimal zu nutzen.

Die Authentifizierung wird als nächstes im Bereich „Advanced Web Settings“ eingerichtet.

Relativ weit unten kann man mit der kostenpflichtigen PLUS Version der App das „Client Certificate File“ angeben. Über „PICK A FILE“ kann hier der volle Pfad auf die p12 Zertifikatsdatei ausgewählt werden, welche auf dem Gerät abliegen muss. Da das Clientzertifikat mit Passwort geschützt ist, muss dieses im darunterliegenden Punkt „Client Certificate Password“ gesetzt werden.

Würde man keine Clientzertifikate verwenden oder möchte man nicht für die PLUS Version zahlen, könnte man auch unter „Web Content Settings“ einfach den User und das Passwort für eine Basic Authentication hinterlegen.

Schließt man die Konfiguration nun, kann man links unter „Goto Start URL“ bereits den Zugriff testen.

Motion Detection

Der „Fully Kiosk Browser“ verfügt über eine integrierte Bewegungserkennung, die sich in meinen Tests robust und wenig CPU-lastig erwiesen hat. Auch im Dauerbetrieb gibt es hier keinerlei Probleme und die Bewegungserkennung zum Einschalten des Displays funktioniert einwandfrei, so lange der Browser die aktive Anwendung ist.

Die Einstellungen könnt ihr ebenfalls unter „Settings“ und dann „Motion Detection (PLUS)“ setzen. Die Bewegungserkennung gibt es – genauso wie die Clientzertifikate – nur in der Vollversion. Die gesetzten Einstellungen sind unten zu sehen. Sicher kann man je nach räumlicher Situation auch an der Detector Sensitivity und der Detector Frame Rate noch Feintuning betreiben.

Nach diesen Einstellungen konnte ich das Ganz erfolgreich in Betrieb nehmen. Mit einem dreispaltigen Layout kommt die smartVISU hier zudem voll zur Geltung. Das dreispaltige Layout habe ich mit einem einfachen <div class=“block“ style=“width: 33%;„> in den „block“ DIVs erreicht.

Funktionsweise von KNX-Szenen

Um Szenen in KNX nutzen zu können, müssen Aktoren verwendet werden, die Szenen unterstützen. Diese Aktoren verfügen über ein Kommunikationsobjekt, über welches Szenen angesteuert werden können. Szenen werden ausgelöst, indem auf die Gruppenadresse (GA) die mit diesem Kommunikationsobjekt verbunden ist, ein numerischer 8-Bit Wert gesendet wird. Gültige Werte sind hierfür 0 bis 63. Über eine Szene können also nur Aktoren angesteuert werden, die mit der selben Gruppenadresse verbunden sind.

Auf welche Werte (Szenennummern) der jeweilige Aktor reagiert, muss mit der ETS konfiguriert werden. In der ETS wird auch festgelegt, welchen Zustand der Aktor einnehmen soll, wenn über die Gruppenadresse eine Szene angesteuert wird.

Optional kann in der ETS eingestellt werden, dass Aktoren die Zustände die zu einer Szene gehören lernen kann. Das geschieht folgendermaßen: Die Aktoren werden manuell in den Zustand gebracht, den sie für eine Szene einnehmen sollen. Anschließend wird auf die Guppenadresse der Wert Szenennummer+128 (also 128 bis 191) gesendet. Dadurch werden die Aktoren, bei denen das „Lernen“ aktiviert ist veranlasst, sich den aktuellen Zustand als Zustand für die entsprechende Szene zu merken.

Ansteuerung von KNX-Szenen aus SmartHomeNG

Um KNX-Szenen aus SmartHomeNG anzusteuern, muss ein numerisches Item angelegt werden und es muss den Wert auf die Gruppenadresse senden, die zur Szenensteuerung verwendet wird:

meine_items:
    knx_szenen:
        name: Beispiel für KNX-Szenen
        type: num
        enforce_updates: True
        knx_dpt: 5
        knx_send: 0/0/3

enforce_updates muss auf True gesetzt werden, damit wenn mehrfach hintereinander die selbe Szene angesteuert werden soll, der Wert auch auf den KNX Bus geschrieben wird.
Der knx_dpt Wert 5 (8 Bit 0-255) ist die ursprüngliche Art Szenen in KNX Anzusteuern. Hier werden die Szenen über Werte von 0 bis 63 angesteuert.

Es gibt inzwischen in KNX eigene DPT Werte um Szene anzusteuern (DPT 17 und 18). Bei diesen DPTs werden die Szenen von 1 bis 64 nummeriert. Es ist zu beachten, dass ganz alte KNX Aktoren diese DPTs eventuell nicht kennen (weshalb ich mir angewöhnt habe immer DPT 5 zu verwenden).

Szenen in SmartHomeNG

Szenen in SmartHomeNG funktionieren nach dem gleichen Prinzip wie KNX-Szenen. Damit SmartHomeNG erkennt, dass ein Item die Ansteuerung einer Szene bewirken soll, muss der Item-Type scene gewählt werden. Ein Szenen Item für SmartHomeNG Szenen sieht somit folgendermaßen aus:

meine_items:
    szenen:
        name: Beispiel für SmartHomeNG-Szenen
        type: scene
        enforce_updates: True

Die Festlegungen, welche Items auf die Szene reagieren sollen und welchen Zustand sie einnehmen sollen (was bei KNX in der ETS festgelegt wird), erfolgt im Verzeichnis ../scenes in einer YAML Datei, die den Namen des Szenen-Items trägt. Im obigen Beispiel also meine_items.szenen.yaml. Detals zum Aufbau dieser Datei sind in der Anwender Dokumentation in der Beschreibung der Konfigurationsdateien zu finiden.

Die Ansteuerung der Szenen erfolgt analog zur Ansteuerung von KNX-Szenen durch Zuweisung eines Wertes zwischen 0 und 63 zum Abruf (und 128 bis 191 zum speichern) von Szenen.

Gemischte Szenen in SmartHomeNG und KNX

Es ist auch möglich, Szenen zwischen SmartHomeNG und KNX zu mischen, ohne die Items der KNX Aktoren in die SmartHome Szenen Definition im ../scenes Verzeichnis aufnehmen zu müssen. Es kann dabei auf die KNX Funktionalität zurück gegriffen werden. Dazu muss das Szenen Item einer SmartHomeNG Szene nur um die KNX Attribute erweitert werden:

meine_items:
    szenen:
        name: Beispiel für gemischte Szenen
        type: num
        enforce_updates: True
        knx_dpt: 5
        knx_send: 0/0/3

Wenn die Szenen Ansteuerung auch aus dem KNX Bus heraus erfolgen soll, also z.B. über einen Tastsensor der Szenen abruft oder speichert, muss das Beispiel nur noch um den KNX Listen-Befehl auf die Szenen-GA erweitert werden:

meine_items:
    szenen:
        name: Beispiel für gemischte Szenen
        type: num
        enforce_updates: True
        knx_dpt: 5
        knx_send: 0/0/3
        knx_listen: 0/0/3

Nun bewirkt ein Szenen Abruf durch einen KNX Taster, dass auch die Items der SmartHomeNG Szene mit angesteuert werden.

Beispiel Implementierung

Im folgenden wird die Implementierung der Lichtsteuerung gezeigt, bei der fast alle Leuchten über KNX-Szenen gesteuert werden. Allerdings soll eine Philips HUE Leuchte mit angesteuert werden, welche aus SmartHomeNG heraus mit dem hue Plugin gesteuert wird.

Das Szenen Item wird azu folgendermaßen definiert:

wohnung:
    buero:
        szenen_knx:
            comment: 0=aus, 1=Ambiente, 2=hell, 3=Putzen, 4=Party
            name: Beleuchtungsszenen Büro
            type: scene
            enforce_updates: 'on'
            knx_dpt: 5
            knx_send: 1/0/16
            knx_listen: 1/0/16

Die KNX Aktoren (Dimmer) sind entsprechend konfiguriert, dass sie auf der GA 1/0/16 auf die Szenennummern 0 bis 4 (gemäß KNX Definition Szenen 1 bis 5) reagieren und dass sie für die Szenennummern 1 und 2 das lernen zulassen.

Die SmartHomeNG Szene ist im Verzeichnis ../scenes in der Datei wohnung.buero.szenen_knx.yaml folgendermaßen definiert:

0:
    name: Aus
    # Leuchte Dreieckschrank ausschalten, falls die Schreibtischleuchte nicht eingeschaltet ist, sonst level 126 setzen
    actions:
        - {item: wohnung.buero.dreieckschrank.level, value: 0 if (sh.wohnung.buero.schreibtischleuchte.status() < 2) else 126}
        - {item: wohnung.buero.dreieckschrank.ct, value: 345, learn: false}
        - {item: wohnung.buero.dreieckschrank.onoff, value: False if (sh.wohnung.buero.schreibtischleuchte.status() < 2) else True}

1:
    name: Ambiente
    actions:
        - {item: wohnung.buero.dreieckschrank.level, value: sh...dreieckschrank.ambiente_level()+3, learn: false}
        - {item: wohnung.buero.dreieckschrank.ct, value: 345, learn: true}
        - {item: wohnung.buero.dreieckschrank.onoff, value: True, learn: true}

2:
    name: Hell
    actions:
        - {item: wohnung.buero.dreieckschrank.level, value: 126, learn: true}
        - {item: wohnung.buero.dreieckschrank.ct, value: 345, learn: true}

3:
    name: Putzen
    actions:
        - {item: wohnung.buero.dreieckschrank.onoff, value: True, learn: false}
        - {item: wohnung.buero.dreieckschrank.level, value: 255, learn: false}
        - {item: wohnung.buero.dreieckschrank.ct, value: 345, learn: false}

4:
    name: Party
    actions:
        - {item: wohnung.buero.dreieckschrank.level, value: 200, learn: false}
        - {item: wohnung.buero.dreieckschrank.hue, value: 59635, learn: false}
        - {item: wohnung.buero.dreieckschrank.sat, value: 230, learn: false}
        - {item: wohnung.buero.dreieckschrank.onoff, value: True, learn: false}

Zur Ansteuerung der Hue Leuchte über die Szene werden 3 Items gesteuert, welche die Leuchte ein- und ausschalten, den Dimmwert und die Farbe setzen.

Für jede der Szenen (0 bis 4) wird über value für diese Werte ein Wert gesetzt (der bei Abruf der Szene eingestellt werden soll) und über learn wird festgelegt, ob andere Werte gelernt werden können/dürfen. Für value können dabei nicht nur konstante Werte festgelegt werden, sondern auch eval Ausdrücke. Wenn ein eval Ausdruck angegeben wird, ist learn zwangsweise false. In diesem Fall können also keine Szenen Zustände gelernt werden.

Ein Beispiel für die Nutzung von eval Ausdrücken in Szenen ist bei Szene Nummer 0 zu finden, welche die Beleuchtung ausschalten soll. Falls im Büro die Schreibtisch Leuchte (die nicht Teil der Szenen ist) eingeschaltet ist, wird die HUE Leuchte jedoch nicht ausgeschaltet, sondern als Hintergrund Beleuchtung in einem gedimmten warmen Weiss eingeschaltet.

Bei Szene Nummer 1 wird eine andere eval Nutzung mit Anwendung relativer Item Adressierung gezeigt. Hier wird der Wert auf den Wert eines anderen Items plus 3 gesetzt. Hier kann nur der Weisston und Ein/Aus über die Szene gelernt werden.

Bei Szene Nummer 4 wird eine vorgewählte Farbe und Helligkeit der HUE Leuchte eingestellt, die bewusst nicht durch „Lernen“ geändert werden kann.

Ansteuerung der Szenen über smartVISU

Die Ansteuerung der Szenen kann am besten über Buttons in der smartVISU erfolgen. Für das obige Beispiel wird die folgende Definition für die Autogenerierung verwendet:

wohnung:
    buero:
        sv_page: room
        name: Büro
        sv_img: scene_office.svg

        visu:
            szenen_beleuchtung:
                name: Szenen Beleuchtung

                sv_widget: 'Szenen abrufen:
                    <span data-role="controlgroup" data-type="horizontal">
                    {{ basic.button(''szenen_buero0'', ''wohnung.buero.szenen_knx'', ''Aus'', icon0~"control_standby.svg", ''0'', ''midi'') }}
                    {{ basic.button(''szenen_buero1'', ''wohnung.buero.szenen_knx'', ''Ambiente'', icon0~"light_light_dim_00.svg", ''1'', ''midi'') }}
                    {{ basic.button(''szenen_buero2'', ''wohnung.buero.szenen_knx'', ''Hell'', icon0~"light_ceiling_light.svg", ''2'', ''midi'') }}
                    {{ basic.button(''szenen_buero3'', ''wohnung.buero.szenen_knx'', ''Putzen'', icon0~"scene_cleaning.svg", ''3'', ''midi'') }}
                    {{ basic.button(''szenen_buero6'', ''wohnung.buero.szenen_knx'', ''Party'', icon0~"light_party.svg", ''4'', ''midi'') }}
                    </span><br>
                    <div style="line-height: 30%;">
                         <br>br>
                    </div>
                    <div>Szenen speichern:<br>
                    <span data-role="controlgroup" data-type="horizontal">
                    {{ basic.button(''szenen_bueroS0'', ''wohnung.buero.szenen_knx'', ''Aus'', icon0~''control_standby.svg'', ''128'', ''midi'', ''#4176a9'') }} 
                    {{ basic.button(''szenen_bueroS1'', ''wohnung.buero.szenen_knx'', ''Ambiente'', icon0~"light_light_dim_00.svg", ''129'', ''midi'', ''#4176a9'') }} 
                    {{ basic.button(''szenen_bueroS2'', ''wohnung.buero.szenen_knx'', ''Hell'', icon0~''light_ceiling_light.svg'', ''130'', ''midi'', ''#4176a9'') }} 
                    {{ basic.button(''szenen_bueroS3'', ''wohnung.buero.szenen_knx'', ''Putzen'', icon0~''scene_cleaning.svg'', ''131'', ''midi'', ''#4176a9'') }} 
                    {{ basic.button(''szenen_bueroS6'', ''wohnung.buero.szenen_knx'', ''Party'', icon0~''light_party.svg'', ''132'', ''midi'', ''#4176a9'') }} 
                    </span></div>

Das erzeugt in der Visu:

• eine Seite „Büro“ in der normalen Raum-Navigation.
• auf dieser Seite einen Block mit dem Namen ‚Szenen Beleuchtung‘
• in diesem Block erzeuge ich zwei Button Reihen zur Szenen Steuerung: Der obere Block zum Abruf der Szenen, der untere Block zum Speichern von Szenen

Das sieht dann so aus:

Das ursprüngliche Item dessen Maximalwert ich speichern hat folgenden Aufbau.

Wetterstation:
    Temperatur:
        type: num
        visu_acl: ro

Um jetzt zusätzlich zum aktuellen Messwert den maximalen Messwert zu speichern habe ich das Item etwas angepasst:

Wetterstation:
    Temperatur:
        Aktuell:
            type: num
            visu_acl: ro
        Maximum_Heute:
            type: num
            visu_acl: ro

Für Wetterstation.Tempertatur.Maximum_Heute müssen jetzt noch folgende Dinge hinzufefügt werden:

• Überprüfen auf Änderungen
  Immer wenn sich der Wert von Wetterstation.Temperatur.Aktuell ändert, soll überprüft werden, ob Wetterstation.Temperatur.Maximum_Heute aktualisiert werden muss.
• Aktualisieren des Wertes
  Wenn bei dieser Überprüfung der aktuelle Wert höher ist als der bisher in Wetterstation.Temperatur.Maxiumum_Heute gespeicherte Wert, soll der Wert aktualisiert werden.
• Zurücksetzen des Wertes
  Einmal am Tag muss Wetterstation.Temperatur.Maximum_Heute zurückgesetzt werden.

Überprüfen auf Änderungen

Das überprüfen, ob sich die aktuelle Temperatur ändert, geht ganz einfach indem man Wetterstation.Temperatur.Maximum_Heute einen eval_trigger auf das Item Wetterstation.Temperatur.Aktuell hinzufügt. Seit SmartHomeNG kann man das Item auch relativ angeben: ..Aktuell.
es entsteht also folgender eval_trigger:

eval_trigger: ..Aktuell

Aktualisieren des Wertes

Wenn bei der Überprüfung der aktuelle Wert höher ist als der bisher in Wetterstation.Temperatur.Maxiumum_Heute gespeicherte Wert, soll der Wert aktualisiert werden.
Das geht über ein eval:

eval: sh...Aktuell() if float(sh..self()) > sh...Aktuell() else sh..self.property.value

Zurücksetzen des Wertes

Der Wert soll einmal pro Tag und bei einem Neustart zurückgesetzt werden. Das wird über ein crontab und ein Magic Value (99.9) erledigt. Es wird davon ausgegangen, dass ein Temperaturwert von 99.9 nie vorkommt und deshalb zum Zurücksetzen verwendet werden kann.

Verzögerung bei der Initialisierung: Meine Wetterstation liefert nur alle 5 Minuten (alle 300 Sekunden) einen neuen Temperaturwert. Das heisst nach einem Neustart von SmartHomeNG steht also für maximal 5 Minuten kein aktueller Messwert in Wetterstation.Temperatur.Aktuell sondern 0.0. Deshalb wird nach 5 Minuten und 10 Sekunden Wetterstation.Temperatur.Maximum_Heute auf die aktuelle Temperatur zurückgesetzt.

crontab:
 -init+310 = 99.9
 -0 0 * *  = 99.9

Auch der eval Ausdruck muss für das Zurücksetzen erweitert werden:

eval: sh...Aktuell() if value == 99.9 or float(sh..self()) > sh...Aktuell() else sh..self.property.value

Natürlich kann dieses Prinzip Minimal-Werte angewendet werden. Dafür muss nur der Vergleich im eval Ausdruck angepasst werden.

Das endgültige Item sieht dann so aus:

Wetterstation:
    Temperatur:
        Aktuell:
            type: num
            visu_acl: ro
        Maximum_Heute:
            type: num
            visu_acl: ro
            eval: sh...Aktuell() if value == 99.9 or float(sh..self()) < sh...Aktuell() else sh..self.property.value
            eval_trigger: ..Aktuell
            # Reset am Ende des Tages durch "MagicValue" 99.9. Es wird angenommen, 
            # dass dieser Temperaturwert in der Praxis niemals auftritt. 
            crontab: 
             - 0 3 * * = 99.9
             # +310 weil die Wetterstation mindestens alle 300 Sekunden einen aktualisierten Temperatur Wert sendet
             # dadurch wird sichergestellt, dass nach einem Neustart von SmartHomeNG in ..Aktuell auf jeden Fall ein gültiger Wert steht. 
             - init+310 = 99.9

Wenn etwas anderes als Temperaturwerte gespeichert werden sollen, kann es auch sein, dass als Magic Value eine andere Zahl verwendet werden muss.

Structs aus Plugins

Die „struct“ Vorlagen ermöglichen es zum einen, vorgegebene Item-Strukturen aus Plugins zu integrieren, zum anderen aber auch, eigene Vorlagen für immer wiederkehrende Item-Bäume bereitzustellen.

Bei gleichen Gerätetypen ist die Struktur oft sehr ähnlich, was zu sehr vielen gleich aufgebauten Item-Definitionen führt. Leuchten, Jalousien, Bewegungsmelder können dabei ähnlich leicht vereinfacht werden wie Sollwerte, Vorgaben für Zustände des stateengine Plugins und vieles mehr. Zuerst ein Beispiel, wie mit nur einer Zeile ein Zeitschalt-Unteritem aus dem UZSU Plugin eingefügt werden kann. Da diese Vorlage bereits mit dem Plugin mitgeliefert wird, ist nichts weiter zu tun, also mittels struct Attribug darauf zuzugreifen. Welche Vorlagen von welchen Plugins bereitgestellt werden, ist zum einen in den jeweiligen plugin.yaml Dateien, zum anderen im Admin Tool einzusehen.

    # item.yaml
    item:
        struct: uzsu.child

Durch diese Angabe entsteht beim Start von SmartHomeNG folgende Struktur, die zuvor noch bei jedem Item, das die Zeitschaltuhr nutzt, manuell angegeben werden musste:

  # item.yaml
  item:
        uzsu:
            type: dict
            uzsu_item: ..
            cache: True
            visu_acl: rw
            
            active:
                type: bool
                eval: sh...activate(value)
                visu_acl: rw

Eigene Vorlagen

Folgendes Beispiel zeigt, wie Vorlagen selbst in der Datei etc/struct.yaml hinterlegt werden können. Generell bedarf es keinerlei besonderer Syntax. Strukturen werden dort genauso angelegt wie normale Item-Bäume. Die jeweils oberste Hierarchieebene definiert den Namen der Vorlage. Und genau auf dieses Item wird dann in der eigentlichen item.yaml Datei durch das Attribut struct verwiesen. Zuerst der Inhalt der struct.yaml für ein dimmbares Licht mit einigen Zusatzfunktionen:

    # struct.yaml
    dimmervorlage:
        name: Vorlage für dimmbare Leuchten
	knx_dpt: 1
	visu_acl: rw
	type: bool
        knx_send: 0/0/0
        knx_cache: 0/0/0

	bwm:
		knx_dpt: 1
		visu_acl: rw
		type: bool

	zwangvalue:
		knx_dpt: 5001
		visu_acl: rw
		type: num
		cache: True

		zwangsstellung:
			knx_dpt: 2
			visu_acl: rw
			type: list
			enforce_updates: yes

	dimmen:
		knx_dpt: 5001
		visu_acl: rw
		type: num
		database: yes
		influxdb: yes
		sim: track

		sollwert:
			knx_dpt: 5001
			visu_acl: rw
			type: num
			enforce_updates: yes
			cache: True

Und hier die Einbindung in die yaml Datei im items Verzeichnis für ein Licht mit separaten warm- und kaltweißen Leuchtmitteln:

# item.yaml
licht1:
    warm:
        struct: dimmervorlage
	knx_send: 3/0/21
	knx_cache: 3/0/27

	bwm:
		knx_send: 3/3/67
		knx_cache: 3/3/67

	zwangvalue:
		zwangsstellung:
			knx_send: 3/0/50
			knx_cache: 3/0/50

	dimmen:
		knx_send: 3/0/23
		knx_cache: 3/0/28

		sollwert:
			knx_send: 3/3/53

    kalt:
        struct: dimmervorlage
	knx_send: 3/0/24
	knx_cache: 3/0/29

	bwm:
		knx_send: 3/3/68
		knx_cache: 3/3/68

	zwangvalue:
		zwangsstellung:
			knx_send: 3/0/51
			knx_cache: 3/0/51

	dimmen:
		knx_send: 3/0/26
		knx_cache: 3/0/30

		sollwert:
			knx_send: 3/3/54

Was passiert hier? Es wird jeweils zuerst die Vorlage geladen, in der die Grundinformationen zu den Items verankert ist. Also Infos zu Typ, Cache, KNX DPT, Visu, Datenbank, etc. Diese Vorlage wird nun im tatsächlichen Item nur noch durch die KNX Adressen ergänzt. Etwaige gleich benannte Attribute werden dabei überschrieben (im Beispiel knx_send: 0/0/0).

In der Version 1.6.0 ist zu beachten, dass auch tatsächlich alle bereits definierten Attribute überschrieben werden, also beispielsweise auch Listeneinträge für eval_trigger. Möchte man also verschiedene Vorlagen mit verschiedenen eval_trigger Einträgen miteinander kombinieren, muss das Attribut nach den struct Einträgen manuell mit allen gewünschten Listeneinträgen überschrieben werden.

Zum Abschluss noch ein weiteres Beispiel, das neben einer klassischen Schaltfunktion für das entsprechende Item auch die Einschaltdauer über die Datenbankeinträge evaluiert. Dank relativer Item-Angaben können somit komplexere Konfigurationsblöcke problemlos wiederverwendet werden. Zum einen erleichtert dieser Ansatz ein Aktualisieren und Erweitern von Itemconfigs ungemein, zum anderen bleibt in den yaml Files die Übersicht bewahrt (auch wenn Letzteres Dank Admin Tool zukünftig weniger Relevanz haben wird). Folgend zwei separate Vorlagen:

#struct.yaml
schaltervorlage:
    name: einfache Vorlage für Schalter
    sa:
        knx_dpt: 1
        visu_acl: rw
        type: bool
        database: yes
        cache: yes

    sperren:
        knx_dpt: 1
        visu_acl: rw
        type: bool

laufzeitvorlage:
    name: Vorlage für Laufzeitmessung
    laufzeit_1w:
        type: num
        visu_acl: ro
        crontab: init
        eval: (sh...sa.db('on', '1w') or 0) * 10080
        eval_trigger:
          - ..sa

    laufzeit_24h:
        type: num
        visu_acl: ro
        crontab: init
        eval: (sh...sa.db('on', '24h') or 0) * 1440
        eval_trigger:
          - ..sa

Die tatsächlichen Items benötigen schließlich wieder nur eine Angabe der KNX Adressen, alle anderen Funktionalitäten und Definition werden über die Vorlage eingebunden:

#item.yaml
schalter1:
    struct: schaltervorlage
    sa: 
        knx_send: 1/1/1
    sperren:
        knx_send: 1/1/2

schalter2:
    struct: 
      - schaltervorlage
      - laufzeitvorlage

    sa: 
        knx_send: 1/1/3

    sperren:
        knx_send: 1/1/4

    laufzeit_1w:
        eval_trigger:
          - ..sa
          - ..sperren

schalter3:
    struct: schaltervorlage

    laufzeit:
          struct: laufzeitvorlage

Schalter1 greift ledigilich auf eine Vorlage (schaltervorlage) zurück, während Schalter2 mehrere Vorlagen als Liste miteinander kombiniert. Für Schalter2 existieren also auch die Einträge laufzeit_1w und laufzeit_24h, die eben die Einschaltdauer während der letzten Woche bzw. 24 Stunden von der Datenbank auslesen. Die Triggerung der laufzeit_1w soll in diesem Fall auch vom Sperritem erfolgen, während dies bei Schalter3 lediglich durch das in der Vorlage angegebene Schaltitem geschieht. Da Schalter3 keine Angaben zu den KNX Gruppenadressen macht, handelt es sich hier auch nicht um einen KNX Schalter, sondern z.B. ein Item, das nur über eine Logik oder die Visu geschalten werden kann/soll. Das schalter3 Beispiel zeigt auch, dass die Structs auf jeder beliebigen Hierarchieebene eingebunden werden können.

Limitierungen

Aktuell (inkl. Version 1.9) ist es nicht möglich, structs beliebig zu verschachteln. Das Einbeziehen von anderen structs in einem selbst kreierten struct ist nur auf Rootebene möglich, also beispielsweise so:

    # struct.yaml
    beispielstruct1:
        test1:
            type: bool
            initial_value: True

    beispielstruct2:
        test2:
            type: bool
            initial_value: False

    combinedstruct:
        struct:
          - beispielstruct1
          - beispielstruct2

Debugging

Im Admin Interface sind alle structs, sowohl die von den aktiven Plugins als auch die selbst erstellten einsehbar. Hier lässt sich somit auch prüfen, wie die Structs miteinander kombiniert wurden. Ob und wie der Merge mit Attributen aus den Items geklappt hat, lässt sich am besten im Item Baum nachvollziehen.

Somit war der Grundstein für die Logik gelegt, die möglichst flexibel, für unterschiedliche Anwendungen, konfigurierbar sein soll.

Funktion:

Gesteuert wird die Logik über ein control-item, welches zugleich in der Logik Konfiguration als watch-item dient. Wir das control-item auf True gesetzt, so läuft die Logik. False stoppt die Blinkroutine.

blink_cycles setzt Initial den Countdown, der mit jedem Aufruf um 1 nach unten zählt. Bei 0 stoppt die Logik und setzt zudem das control-item auf False. 

blink_interval bestimmt die Blinkabstand in Sekunden. 

Mit items_cyclic und items_anticyclic werden die Items übergeben, die blinken sollen. Antizyklische Items werden immer dann aus/an wenn die zyklischen Items an/aus sind. 

Bevor die items zum blinken gebracht werden, sichert die Logik die ursprünglichen Werte, die auch am Ende wieder hergestellt werden.

Um die Routine ohne aktives schalten der Items testen zu können, wurde noch dry_run aufgenommen.

Zusammengefasst ergibt sich folgende Beispiel-Konfiguration für ../etc/logic.yaml:

visual_alarm:
    filename: blinker.py
    watch_item: HOME.alarm.action.blinkinglight
    set_items_cyclic:
        - AUSSEN.south.light.outer
        - AUSSEN.west.light.outer
    set_items_anticyclic:
        - AUSSEN.south.light.inner
        - AUSSEN.east.light.door
        - AUSSEN.west.light.nested
    set_blink_cycles: 4 # -1 for endless loop 
    set_blink_interval: 4
    dry_run: 1

Alle items müssen vom Typ boolean sein, da nur einfache Schaltoperationen durchgeführt werden.

Die Logik lässt sich relativ einfach nutzen, indem das im watch_item verbundene Item, also im Beispiel HOME.alarm.action.blinkinglight, auf True gesetzt wird. Die Logik ruft sich selbst solange auf, bis set_blink_cycles erreicht ist oder vorher das watch_item auf False gesetzt wurde. Am Ende wird das watch_item auf von der Logik auf False gesetzt.

Die Logik selbst ist in ../logics/blinker.py:

#!/usr/bin/env python3
# vim: tabstop=2 softtabstop=2 shiftwidth=2 expandtab

# Logic blinker.py

# LOGIC config
# -------------------------------------------------------
# visual_alarm:
#   filename: blinker.py
#   watch_item: HOME.alarm.action.blinkinglight
#   set_items_cyclic:
#     - AUSSEN.south.light.outer
#     - AUSSEN.west.light.outer
#   set_items_anticyclic: 
#     - AUSSEN.south.light.inner
#     - AUSSEN.east.light.door 
#     - AUSSEN.west.light.nested
#   set_blink_cycles: -1 " -1: endless 
#   set_blink_interval: 2
#   dry_run: 0 

control_item_name = trigger['source'] 
control_item = sh.return_item(control_item_name)
triggered_by = trigger['by'] 


if control_item is not None:
  logger.info("LOGIC blinker.py: {0} triggered from source {1} by {2}".format(logic.name, control_item_name, triggered_by))

  # control_item_active = trigger['value']
  control_item_active = control_item()

  # set parameters from logic config
  if hasattr(logic, 'set_items_cyclic'):
    blink_items_cyclic = logic.set_items_cyclic

  if hasattr(logic, 'set_items_anticyclic'):
    blink_items_anticyclic = logic.set_items_anticyclic

  if hasattr(logic, 'set_blink_cycles'):
    blink_cycles = int(logic.set_blink_cycles)
  else:
    blink_cycles = 2
    logger.info("LOGIC blinker.py: no blink cycles set, setting to default: {2}".format(blink_cycles))

  if hasattr(logic, 'set_blink_interval'):
    blink_interval = int(logic.set_blink_interval)
  else:
    blink_interval = 2
    logger.info("LOGIC blinker.py: no blink interval set, setting to default: {2}".format(blink_interval))

  if hasattr(logic, 'dry_run'):
    dry_run = (int(logic.dry_run) > 0)
  else:
    dry_run = False

  if control_item_active == True:

    # first call?
    if not hasattr(logic, 'blink_init'):
      logger.info("LOGIC blinker.py: initiating {0} blinks for {1} cyclic and {2} anti-cyclic items".format(blink_cycles, len(blink_items_cyclic), len(blink_items_anticyclic)))
      logic.blink_init = True

      blink_items = blink_items_cyclic + blink_items_anticyclic
      if len(blink_items) > 0:
        # SAVE item states
        logic.saved_items = {}
        for item_name in blink_items:
          item = sh.return_item(item_name)
          logic.saved_items[item_name] = item()
          logger.info("LOGIC blinker.py: save {0} = {1}".format(item_name, item()))

      if dry_run == True:
        logger.warn("LOGIC blinker.py: test mode, dry run active")

      else:
        logger.warn("LOGIC blinker.py: no blink items set")
 

    # prepare blink
    if hasattr(logic, 'blink_value'):
      logic.blink_value = not logic.blink_value
    else:
      logic.blink_value = True

    if hasattr(logic, 'blink_countdown'):
      logic.blink_countdown -= 1
    else:
      logic.blink_countdown = blink_cycles
     
    # any blinks left?
    if logic.blink_countdown > 0 or blink_cycles == -1:
      if blink_cycles == -1:
        logger.info("LOGIC blinker.py BLINK (endless)")
      else:
        logger.info("LOGIC blinker.py BLINK ({0} cycles remaining)".format(logic.blink_countdown))

      # set all cyclic items
      for item_name in blink_items_cyclic:
        item = sh.return_item(item_name)
        logger.info("LOGIC blinker.py SET {item} to {value})".format(item=item_name, value=logic.blink_value))
        if dry_run == False:
          item(logic.blink_value)

      # set all anti-cyclic items
      for item_name in blink_items_anticyclic:
        item = sh.return_item(item_name)
        logger.info("LOGIC blinker.py SET {item} to {value})".format(item=item_name, value=(not logic.blink_value)))
        if dry_run == False:
          item(not logic.blink_value)

      sh.trigger("logics.{0}".format(logic.name), by=trigger['by'], source=trigger['source'], value=trigger['value'], dt=sh.now() + datetime.timedelta(seconds=blink_interval))

    else:
      logger.info("LOGIC blinker.py countdown finished, set control item to False")
      control_item(False) # this triggers logic again!

  else:
    logger.info("LOGIC blinker.py control item set to false: stop blink logic, restore saved item values")

    # RESTORE item states
    if hasattr(logic, 'saved_items'):
      for item_name in logic.saved_items:
        item = sh.return_item(item_name)
        value = logic.saved_items[item_name]
        logger.info("LOGIC blinker.py: restore {0} = {1}".format(item_name, item()))
        if dry_run == False:
          item(value)
      
    # reset persistent values
    if hasattr(logic, 'saved_items'):
      delattr(logic, 'saved_items')  
    if hasattr(logic, 'blink_countdown'):
      delattr(logic, 'blink_countdown')  
    if hasattr(logic, 'blink_value'):
      delattr(logic, 'blink_value')  
    if hasattr(logic, 'blink_init'):
      delattr(logic, 'blink_init')  
    
else:
  logger.info("LOGIC blinker.py triggered without source... ignoring...")

Überarbeitung im Januar 2021:

Diese Logik wurde aufgrund weitere Anforderungen im Januar 2021 ergänzt. (siehe Thread im Forum) Die folgende Version vom 18. Januar 2021 blinkt mit einem oder zwei Items:

#!/usr/bin/env python3
# vim: tabstop=4 softtabstop=4 shiftwidth=4 expandtab

# Logic blinker2.py

# LOGIC config
# -------------------------------------------------------
# visual_alarm:
#     filename: blinker2.py
#     watch_item: HOME.alarm.action.blinkinglight
#     set_items_cyclic:
#         - AUSSEN.south.light.outer
#         - AUSSEN.west.light.outer
#     set_items_anticyclic:
#         - AUSSEN.south.light.inner
#         - AUSSEN.east.light.door
#         - AUSSEN.west.light.nested
#     set_blink_cycles: -1 ' -1: endless
#     set_blink_interval: 2
#     dry_run: 0

control_item_name = trigger['source']
control_item = sh.return_item(control_item_name)
triggered_by = trigger['by']

if control_item is not None:
    logger.info(f'LOGIC blinker.py: {logic.name} triggered from source {control_item_name} by {triggered_by}')

    # control_item_active = trigger['value']
    control_item_active = control_item()

    # set parameters from logic config
    blink_items_cyclic = []
    if hasattr(logic, 'set_items_cyclic'):
        blink_items_cyclic = logic.set_items_cyclic
    if blink_items_cyclic == 'None':
        blink_items_cyclic = []
    if isinstance(blink_items_cyclic, str):
        blink_items_cyclic = [blink_items_cyclic, ]

    # do we have blink items?
    if not isinstance(blink_items_cyclic, list) or len(blink_items_cyclic) == 0:
        logger.info('LOGIC blinker.py: error, no cyclic blink items set. Aborting')
    else:

        blink_items_anticyclic = []
        if hasattr(logic, 'set_items_anticyclic'):
            blink_items_anticyclic = logic.set_items_anticyclic
        if blink_items_anticyclic == 'None':
            blink_items_anticyclic = []
        elif isinstance(blink_items_anticyclic, str):
            blink_items_anticyclic = [blink_items_anticyclic, ]

        # did we get strange data?
        if not isinstance(blink_items_anticyclic, list):
            blink_items_anticyclic = []

        if hasattr(logic, 'set_blink_cycles'):
            blink_cycles = int(logic.set_blink_cycles)
        else:
            blink_cycles = 2
            logger.info(f'LOGIC blinker.py: no blink cycles set, setting to default: {blink_cycles}')

        if hasattr(logic, 'set_blink_interval'):
            blink_interval = int(logic.set_blink_interval)
        else:
            blink_interval = 2
            logger.info(f'LOGIC blinker.py: no blink interval set, setting to default: {blink_interval}')

        if hasattr(logic, 'dry_run'):
            dry_run = (int(logic.dry_run) > 0)
        else:
            dry_run = False

        if control_item_active:

            # first call?
            if not hasattr(logic, 'blink_init'):
                logger.info(f'LOGIC blinker.py: initiating {blink_cycles} blinks for {len(blink_items_cyclic)} cyclic and {len(blink_items_anticyclic)} anti-cyclic items')
                logic.blink_init = True

                blink_items = blink_items_cyclic + blink_items_anticyclic
                if len(blink_items) > 0:
                    # SAVE item states
                    logic.saved_items = {}
                    for item_name in blink_items:
                        item = sh.return_item(item_name)
                        if item:
                            logic.saved_items[item_name] = item()
                            logger.info(f'LOGIC blinker.py: save {item_name} = {item()}')

                    if dry_run:
                        logger.warn('LOGIC blinker.py: test mode, dry run active')

                else:
                    logger.warn('LOGIC blinker.py: no blink items set')

            # prepare blink
            if hasattr(logic, 'blink_value'):
                logic.blink_value = not logic.blink_value
            else:
                logic.blink_value = True

            if hasattr(logic, 'blink_countdown'):
                logic.blink_countdown -= 1
            else:
                logic.blink_countdown = blink_cycles

            # any blinks left?
            if logic.blink_countdown > 0 or blink_cycles == -1:
                if blink_cycles == -1:
                    logger.info('LOGIC blinker.py BLINK (endless)')
                else:
                    logger.info(f'LOGIC blinker.py BLINK ({logic.blink_countdown} cycles remaining)')

                # set all cyclic items
                for item_name in blink_items_cyclic:
                    item = sh.return_item(item_name)
                    logger.info(f'LOGIC blinker.py SET {item_name} to {logic.blink_value}')
                    if not dry_run:
                        item(logic.blink_value)
                        print(f'    - {item.id()}:{item()}')

                # set all anti-cyclic items
                for item_name in blink_items_anticyclic:
                    item = sh.return_item(item_name)
                    logger.info(f'LOGIC blinker.py SET {item_name} to {not logic.blink_value}')
                    if not dry_run:
                        item(not logic.blink_value)
                        print(f'    - {item.id()}:{item()}')

                sh.trigger(f'logics.{logic.name}', by=trigger['by'], source=trigger['source'], value=trigger['value'], dt=sh.now() + datetime.timedelta(seconds=blink_interval))

            else:
                logger.info('LOGIC blinker.py countdown finished, set control item to False')
                control_item(False)  # this triggers logic again!

        else:
            logger.info('LOGIC blinker.py control item set to false: stop blink logic, restore saved item values')

            # RESTORE item states
            if hasattr(logic, 'saved_items'):
                for item_name in logic.saved_items:
                    item = sh.return_item(item_name)
                    value = logic.saved_items[item_name]
                    logger.info(f'LOGIC blinker.py: restore {item_name} = {item()}')
                    if not dry_run:
                        item(value)

            # reset persistent values
            if hasattr(logic, 'saved_items'):
                delattr(logic, 'saved_items')
            if hasattr(logic, 'blink_countdown'):
                delattr(logic, 'blink_countdown')
            if hasattr(logic, 'blink_value'):
                delattr(logic, 'blink_value')
            if hasattr(logic, 'blink_init'):
                delattr(logic, 'blink_init')

else:
    logger.info('LOGIC blinker.py triggered without source... ignoring...')

ich wurde vor längerer Zeit gefragt, ob ich den Weg meiner Implementierung mit Apache hier niederschreiben könnte, was ich hiermit erledigen möchte.

Warum man das macht und wie das ganze mit NGINX funktioniert hat psilo sehr gut auf dieser Seite erklärt!

Deswegen möchte ich auch hier nur auf die Änderungen zu Apache eingehen und setzte also Voraus, dass man weiß was man erreichen will und auch über die genannte Seite von psilo geschaut hat!

Als kleine Änderung will ich hier gleich anmerken, dass ich keine extra Maschine als Reverse Proxy einsetzte, da ich bei mir soweit alles abgesichert habe und darin einige Erfahrung habe

Damit gehe ich also auch davon aus, dass ihr Apache auch für eure smartVISU einsetzt, wie ich es mache. Falls nicht müsst ihr natürlich apache nachinstallieren.

Unter Debian/Ubuntu/Raspbian funktioniert das mit:

sudo apt-get update
sudo apt-get install apache2

Unter Ubuntu 18.04 habe ich auch keine weiteren Module (wie libapache2-mod-XXX) für Apache benötigt. Ob dies bei allen Debian-basierenden Distributionen der Fall ist müsste man im Einzelfall prüfen. Man wird es auf jeden Fall merken, wenn sich die kommenden Befehle zum aktivieren der Module nicht durchführen lassen.

Nun müssen wir die folgenden Module aktivieren:

sudo a2enmod proxy_wstunnel
sudo a2enmod rewrite
sudo a2enmod setenvif

Bei Apache arbeite ich gerne nach dem modularen Prinzip, weswegen ich mir für die Einstellungen die ich brauche, einer eigene Konfigurationsdatei mit dem Namen /etc/apache2/smartvisu.conf angelegt habe, die ich hier entsprechend erläutern möchte.

<IfModule mod_rewrite.c>
   RewriteEngine on

   # Eine Umleitung vom Ordner zur index.php (es gab da mal einen Bug,
   # in der alten VISU, keine Ahnung ob das noch aktuell ist, schaden
   # tut es aber nicht, man kann es aber gerne auch weglassen)
   RewriteCond %{REQUEST_URI} ^/smartVISU$ [NC,OR]
   RewriteCond %{REQUEST_URI} ^/smartVISU/$ [NC]
   RewriteRule .* /smartVISU/index.php [R=302,L]

   # Mit dieser Definition wird der Reverse Proxy für Websocket aktiviert
   # Da wie oben schon erwähnt, die VISU und SH bei mir auf dem lokalen Host
   # läuft, verwende ich hier als Ziel auch localhost. Das kann man aber
   # natürlich Anpassen und soll auch nur als Beispiel dienen.
   <IfModule mod_proxy.c>

      ProxyPreserveHost On
      ProxyVia On

      # socket.io 1.0+ starts all connections with an HTTP polling request
      RewriteCond %{QUERY_STRING} transport=polling [NC]
      RewriteRule /(.*) http://localhost:2424/$1 [P]

      # When socket.io wants to initiate a WebSocket connection, it sends an
      # "upgrade: websocket" request that should be transferred to ws://
      RewriteCond %{HTTP:Upgrade} websocket [NC]
      RewriteRule /(.*) ws://localhost:2424/$1 [P]
   </IfModule>

   # Hier ist Platz für spezielle Ausnahmen (die wie unten mit SetEnvIf
   # gezeigt nicht abgebildet werden können), z.B. für eine Manifest-Datei die
   # ich mir in die VISU rein Programmiert habe. Hier wird beim Auffinden
   # des entsprechenden Query-Strings die Umgebungsvariable
   # no_auth_required auf 1 gesetzt, was dann weiter unten ausgewertet wird
   # und dann dazu führt, dass keine Anmeldung erforderlich ist
   RewriteCond %{QUERY_STRING} page=manifest
   RewriteRule ^/smartVISU/index.php - [E=no_auth_required:1]
   # !! Das ist natürlich nur ein Beispiel und wäre bei euch nicht erforderlich !!

</IfModule>

# Hier definiere ich wann man sich anmelden muss und wann nicht und
# das gilt dabei für den kompletten Webserver Stamm also ab der Wurzel.
# Das ist !Wichtig!, da so auch automatisch die Websocket-Verbindung
# per Basic Auth geschützt wird!
<Location />
   # Hier kann ich dann wieder Dinge freigeben, die ohne Anmeldung funktionieren sollen
   # (wie auch weiter oben im Beispiel, nur das es mit SetEnvIf etwas einfacher geht)
   # z.B. kann sich jeder meine Temperatur Statistik im Unterordner /mytemplogger ohne
   # Anmeldung ansehen, dazu setzte ich wieder die Umgebungsvariable no_auth_required auf 1
   SetEnvIf Request_URI ^/mytemplogger no_auth_required=1

   # Dann definiere ich die Basic Auth Parameter
   AuthName "Private"
   AuthType Basic
   AuthUserFile /etc/apache2/htpasswd
   Require valid-user

   # Hier gebe ich an, dass man sich über die lokalen Netze nicht anmelden muss,
   # dass muss also jeder für sich Anpassen. Wer kein IPv6 hat kann die /64 Adressen
   # natürlich auch weg lassen
   Require ip 192.168.XX.0/24 2a02:810c:XXX:XXX::/64 fd00:XXXX:XXXX:XXXX::/64 fe80::/64
   # Und hier wird die Ausnahme mit der Umgebungsvariable definiert, so kann man einfacher
   # Seiten oder Aufrufe als Ausnahme definieren
   Require env no_auth_required

</Location>

Dann müssen wir uns natürlich die zuvor verwendete /etc/apache2/htpasswd anlegen:

htpasswd -cB /etc/apache2/htpasswd BENUTZER
New password: MEINSUPERPASSWORD
Re-type new password: MEINSUPERPASSWORD
Adding password for user visu

# Und dann die Rechte anpassen:
chmod 660 /etc/apache2/htpasswd

Wobei BENUTZER der Benutzername ist den man anlegen möchte. Es können natürlich mehrere Benutzer angelegt werden. Man sollte aber hier wirklich ein sicheres Passwort verwenden, da dies nicht vor Brute-Force Angriffen geschützt ist. Wobei man ganz klar die Webseite nochmal in mehreren wegen etwas weiter Schützen kann. Aber dazu später mehr.

Nun kann man auf jeden fall schon seine Konfiguration für den virtuellen Host anpassen. Im Standardfall wäre dass die /etc/apache2/sites-enabled/000-default.conf oder eben die von euch genutzte Datei. Da ich bei mir mehrere virtuelle Hosts habe, die jewels ein eigenes Zertifikat (Stichwort SSL) haben (für internen Host – ohne SSL, für externen Host – mit SSL, für den vom Internet und Intern aus erreichbaren IPv6 Host – mit SSL), kann ich jetzt die smartvisu.conf überall einbinden und hab eine zentrale Stelle für die Anpassungen.

Die nötige Anpassung zum Einbinden der Konfiguration sieht wie folgt aus:

Innerhalb des <VirtualHost></VirtualHost> Blocks muss nur noch folgende Zeile eingefügt werden:

Include /etc/apache2/smartvisu.conf

Jetzt könnte man den Apache2 neustarten und testen.

service apache2 restart

Nützliche Tipps zur Absicherung

Zum Absichern gibt es mehrere Faktoren – vieles hier setzt zwar auf Verschleierung/Tarnung (was eine gute Methode ist, Angriffe gar nicht erst aufkommen zu lassen), aber natürlich nicht ausschließlich:

• ) Die Webseite auf jeden Fall mit SSL absichern!! Auch ich verwende für die externen Zugriffe den kostenfreien Service von Let’s Encrypt. Möglich wäre aber auch ein self-signed Zertifikat (Anleitungen gibt es dazu wie Sand am Meer) aber eben nicht so schön und nicht ganz so sicher, oder wer von euch prüft schon den Fingerabdruck den Zertifikats?!
• ) die Brute-Force Angriffe auf die Basic-Anmeldung kann man ganz einfach mit fail2ban Abfangen/-mildern (Abmildern deswegen, da es möglich wäre auch ein Angriff von mehreren IPs zu koordinieren, was fail2ban nicht abfangen könnte), was ich trotzdem nur jeden empfehlen kann, weswegen ich es auch kurz erklären möchte:
  Zuerst installiert man das Paket mit sudo apt-get install fail2ban
  dann erstellen wir uns eine local.conf, in dem wir das definieren was nicht in der Standardkonfiguration erfasst ist. Man könnte zwar auch die Standardkonfiguration unter /etc/fail2ban/jail.conf bearbeiten, aber übersichtlicher wird es mit meiner vorgeschlagenen Variante. Dazu öffnen wir mit dem Editor unserer Wahl die Datei /etc/fail2ban/jail.d/local.conf und aktivieren die Jail für die Definition von apache-auth wie folgt:

  [apache-auth]
  enabled = true
  

  und danach können wir fail2ban neu laden mit sudo fail2ban-client reload und den Status prüfen mit sudo fail2ban-client status.
  
  Wichtig: Hat man den Protokollpfad seines Apache Vhosts modifiziert, muss man den Pfad für die Jail nochmals prüfen und ggf. in unserer local.conf überschreiben. Prüfen kann man das nochmal in der Datei /etc/fail2ban/jail.conf bzw. /etc/fail2ban/paths-arch.conf (dort steht bei meinem Ubuntu die Variable apache_error_log).

• ) Keine Standard-Ports für den Zugriff auf den Webserver von Extern verwenden. Das hält die ganzen Scanner davon ab die Seite zufällig zu finden. Natürlich wird ein gezielter Angriff (mit Port-Scan) die Seite trotzdem aufdecken, egal welcher Port verwendet wird. Dies wiederum könnte man mit Port Knocking (fwknop/knockd) ausschalten, finde ich aber überflüssig, da es das ganze wieder unnötig verkompliziert.
• ) zusätzlichen Schutz würde auch noch eine zwei-Faktor Anmeldung bringen, z.B. über den Google Authenticator, der den offener Standard OATH (Initiative for Open Authentication) umsetzt und leicht verwendet werden kann. Dazu verweise ich aber z.B. auf diese Anleitung.
• ) Client Zertifikate wären natürlich auch möglich, halte ich aber auch für Übertrieben/zu kompliziert und diese können genau so gut über einen Trojaner geklaut werden – dann lieber 2-Faktor
• ) den Webserver vor Zugriffen aus dem Ausland schützen wäre natürlich auch unter Apache möglich, alternativ mit iptables. Aber mal ehrlich, wenn ich im Urlaub bin will ich auch darauf zugreifen und nicht extra dran denken müssen es frei zu schalten.
• ) die Seite nicht öffentlich im Web verlinken, da b) sonnst auch keinen Sinn macht. Nicht dass wir was zu verbergen haben – aber wie heist es so schön: Schlafende Hunde soll man nicht wecken
• ) dafür sorgen dass das System aktuell gehalten wird – Stichpunkt UnattendedUpgrades, was es sowohl unter Debian und Ubuntu gibt. Auch sollte nur eine Distribution eingesetzt werden, welche auch noch vom Anbieter unterstützt wird.
• ) Keine öffentliche (also ohne Anmeldung zugängliche) Index Seite auf dem internen Webserver anlegen, wo mögliche öffentliche Inhalte „sichtbar“ verlinkt sind. Auch sollten die öffentlichen Inhalte (wenn überhaupt unbedingt benötigt – man kann diese ja auch nur Intern erreichbar machen) nicht über Standard-Ordner laufen, wie z.B. wp (WordPress), Joomla, phpmyadmin, Webmail usw…
  Die Gefahr dabei besteht, dass in den gehosteten Inhalten, eine Sicherheitslücke dafür sorgt, dass jemand sich Zugriffsrechte auf den Webserver erschleichen kann, was dann wieder durch Intensivierung des Angriffs über eine Rechteausweitung zu ROOT-Rechte führen kann!!

TODO: Konfiguration LetsEncrypt

Im develop Branch (also für SmartHomeNG v1.6) ist eine allgemein gültige Lösung implementiert. (Danke an ohinckel für die Idee).

Ab der Version muss der Fehler nicht mehr im einzelnen Plugin abgefangen werden, es sei denn, man möchte nicht das Laden des Plugins unterbinden, sondern vielleicht nur einzelne Funktionen des Plugins deaktivieren.

Wenn ein Plugin ein spezielles Python Package benötigt (Requirement) und dieses auf dem System des Anwenders nicht installiert ist, wird im Log beim ersten Zugriff auf Funktionen dieses Packages eine Exception in das Logfile geschrieben.

Für viele Anwender ist es schwierig, aus der Fehlermeldung auf die eigentliche Ursache zu schließen.

Durch einen kleinen Kniff im Plugin, kann im Logfile eine klare Fehlermeldung geschrieben werden. Außerdem kann das Laden des Plugins unterbunden werden, um Folgefehler zu vermeiden.

Vorgehen

Die zwei notwendigen Änderungen sind hier Beispiel des homematic Plugins und des benötigten Packages pyhomematic beschrieben.

Normalerweise wird das Package folgendermaßen importiert:

from pyhomematic import HMConnection

Um den Fehler zu behandeln, werden folgende zwei Änderungen vorgenommen:

1. Um den Fehler zu erkennen, wird die import Anweisung in ein try/except Konstrukt eingebettet und abhängig vom Ergebnis eine Variable gesetzt. (Zeilen 8 bis 12 im folgenden Beispiel)
2. Um den erkannten Fehler auszuwerten, wird eine If-Anweisung zur__init__ Methode hinzugefügt (Zeilen 37 bis 41), die Im Fehlerfall einen sinnvollen Log-Eintrag schreibt und durch das setzen der Variable self._init_complete signaliseiert, dass das Plugin sich nicht fehlerfrei initialisieren konnte. Das anschließende return sorgt dann noch für den Abbruch der Initialisierung.

#  You should have received a copy of the GNU General Public License
#  along with SmartHomeNG. If not, see <http://www.gnu.org/licenses/>.
#
#########################################################################

import logging

try:
    from pyhomematic import HMConnection
    REQUIRED_PACKAGE_IMPORTED = True
except:
    REQUIRED_PACKAGE_IMPORTED = False

from lib.module import Modules
from lib.model.smartplugin import *

from time import sleep


class Homematic(SmartPlugin):
    """
    Main class of the Plugin. Does all plugin specific stuff and provides
    the update functions for the items
    """
    
    PLUGIN_VERSION = '1.5.0'
    
    connected = False
    

    def __init__(self, sh, *args, **kwargs):
        """
        Initalizes the plugin. The parameters descriptions for this method are pulled from the entry in plugin.yaml.
        """
        self.logger = logging.getLogger(__name__)

        # Exit if the required package(s) could not be imported
        if not REQUIRED_PACKAGE_IMPORTED:
            self.logger.error("{}: Unable to import Python package 'pyhomematic'".format(self.get_fullname()))
            self._init_complete = False
            return

        # get the parameters for the plugin (as defined in metadata plugin.yaml):
        #   self.param1 = self.get_parameter_value('param1')

Im Logfile wird der Fehler dann durch zwei Zeilen, wie im folgenden Beispiel angezeigt:

2018-08-12  09:59:03 ERROR    plugins.homematic   homematic_hm1: Unable to import Python package 'pyhomematic'
2018-08-12  09:59:03 ERROR    lib.plugin          Plugins: Plugin 'homematic' initialization failed, plugin not loaded

Als Vorarbeiten wird im Wesentlichen der Artikel „Entfernungsmessung auf Basis eines ESP32 und SmartHomeNG“ vorausgesetzt.

Mittlerweile bin ich bei der Messung des Ultraschallsignales des HR-SR04 allerdings auf die Arduino Bibliothek NewPing umgestiegen, die die Messung übernimmt:Als Display kommt ein kleines OLED Display mit SSD 1306 Controller zum Einsatz (https://www.az-delivery.de/products/0-96zolldisplay, ca. 7 Euro).

Das Display wird wie folgt zusätzlich zum HC-SR04 angeschlossen:

Als Bibliothek kommt die „ESP8266 and ESP32 Oled Driver for SSD1306 display“ von Daniel Eichhorn und Fabrice Weinberg in Version 4.0.0 zum Einsatz:

Der angepasst Sourcecode sieht nun wie folgt aus. Es ist dabei zu beachten, dass das Webservices- Plugin inzwischen über die REST Schnittstelle angesteuert wird. Weiterhin sind alle Log-Outputs für den Seriellen Monitor entfernt worden. Sämtliche relevanten Outputs werden jetzt auf dem Display ausgegeben.

#include <HTTPClient.h>
#include <NewPing.h>
#include <WiFi.h>
#include <WiFiClient.h>
#include <WiFiServer.h>
#include <WiFiUdp.h>
#include <Wire.h>
#include "SSD1306.h"

const int triggerPin = 15;   // HC-SR04: Trigger Pin
const int echoPin = 4;       // HC-SR04: Echo Pin
const int sdaPin = 21;       // Display: SDA Pin
const int sclPin = 22;       // Display: SCL Pin
const int sensorRange = 280; // Reichweite (< maximale Reichweite)

// HC-SR04
NewPing sonar(triggerPin, echoPin, sensorRange); // create NewPing instance

// Wifi
char ssid[] = "<wlan_ssid>";     // your network SSID (name)
char pass[] = "<wlan_password>"; // your network password
char host[] = "192.168.178.100"; // ip of service interface in SmartHomeNG
int port = 4321;                 // port of service interface in SmartHomeNG
char cm_item[] = "test.numeric";
int status = WL_IDLE_STATUS;
WiFiClient client;

// Display
SSD1306Wire display(0x3c, sdaPin, sclPin);

void setup() {
  Serial.begin(19200);
  // Init Display
  display.init();
  display.flipScreenVertically();
  // Init Wifi
  initialise_wifi();
}

void loop() {
  delay(50);
  unsigned int result = sonar.ping();
  float cm = sonar.convert_cm(result); //(result/2)/29.1; //

  while (client.available()) {
    char c = client.read();
    Serial.write(c);
  }

  if (cm > 0) {
    if (client.connect(host, port)) {
      HTTPClient http;
      char portStr[12];
      sprintf(portStr, "%d", port);
      char url[128];
      sprintf(url, "http://%s:%s/rest/items/%s", host, portStr, cm_item);
      http.begin(url);
      http.addHeader("Content-Type", "application/json");
      char cmStr[12];
      char cmStrFull[24];
      sprintf(cmStr, "%f", cm);
      sprintf(cmStrFull, "%i cm", (int)cm);
      int httpCode = http.PUT(cmStr);
      String payload = http.getString();
      http.end();

      display.clear();
      display.setFont(ArialMT_Plain_16);
      display.drawString(0, 0, "Wasserstand:");
      display.setFont(ArialMT_Plain_24);
      display.drawString(0, 17, cmStrFull);
      display.display();
    }
  }
  // Wait 5 seconds and do next measurement
  delay(5000);
}

static void initialise_wifi(void) {
  display.setFont(ArialMT_Plain_10);
  display.drawString(0, 0, "Setting up wifi...");
  display.display();

  while (status != WL_CONNECTED) {
    display.drawString(0, 11, "Attempting to connect...");
    display.display();
    status = WiFi.begin(ssid, pass);
    delay(10000);
  }
  display.drawString(0, 22, "Connected to wifi!");
  display.display();
  printWifiStatus();
}

void printWifiStatus() {
  IPAddress ip = WiFi.localIP();
  String ipStr = String(ip[0]) + '.' + String(ip[1]) + '.' + String(ip[2]) + '.' + String(ip[3]);
  display.drawString(0, 33, "IP: "+ipStr);
  display.display();
  long rssi = WiFi.RSSI();
  char rssiStr[255];
  sprintf(rssiStr, "RSSI: %d dBm", rssi);
  display.drawString(0, 44, rssiStr);
  display.display();
}

Nach der Initialisierung des Displays in der Methode setup, kann mittels display.drawString(...) Text auf das Display gesendet werden. Der erste Parameter ist dabei die X-, der zweite die Y-Koordinate. Im dritten Parameter wird der String gesetzt. Mit display.display(); werden alle zuvor eingesteuerten Operationen dann wirklich auf dem Display ausgegeben. Ein display.clear(); leert die auf dem Display ausgegebenen Werte, damit neuer Text dargestellt werden kann. Wird kein display.display(); aufgerufen, so wird immer mehr auf das Display geschrieben. Dies kann soweit führen, dass Text über bestehenden Text geschrieben wird.

Dies kann am Beispiel der WLAN-Initialisierung gut gesehen werden. Das Gehäuse ist dabei wieder von Thingiverse bezogen und via 3D Drucker gedruckt worden (https://www.thingiverse.com/thing:2176764):

Nach der Initialisierung wird nun auf dem Display der Abstand angezeigt:

In Teil 3 folgt nun in Kürze noch ein Update zu meiner tatsächlichen Installation in der Zisterne und der Garage. Die Arbeiten sind bereits vollendet und die Werte werden via Kabel in die Garage auf den ESP32 übertragen. Mehr dazu aber in der nächsten Zeit…

(Die in diesem Artikel verwendeten Screenshots und Fotos wurden selber erstellt. Für den Schaltplan wurde das Tool Fritzing verwendet.)

Mit dem Traffic Plugin bietet SmartHomeNG die Möglichkeit, Fahrzeiten über die Google Directions API zu berechnen.

So lässt sich auf einfache Art und Weise ein Alarmsystem bauen, dass einem im Büro Bescheid gibt, wenn es Zeit wird zu fahren (oder man länger bleiben sollte, damit sich der Stau wieder auflösen kann).

Die Erkennung, wo man sich gerade befindet, wird dabei, wie in https://www.smarthomeng.de/geozonen-basierte-services-mit-der-egigeozone-app-und-dem-network-plugin beschrieben, über EgiGeoZone und das Network Plugin umgesetzt.

Das Traffic Plugin

Die automatisch generierte Doku zum Traffic Plugin findet sich unter https://www.smarthomeng.de/user/plugins_doc/config/traffic.html.

Die Readme liegt unter https://www.smarthomeng.de/user/plugins/traffic/README.html, der Quellcode auf Github unter https://github.com/smarthomeNG/plugins/tree/master/traffic.

Der Support-Thread im Forum findet sich unter https://knx-user-forum.de/forum/supportforen/smarthome-py/1048446-traffic-plugin-support-thread.

Das Plugin ist schnell in der etc/plugin.yaml konfiguriert:

traffic:
    class_name: Traffic
    class_path: plugins.traffic
    apikey: your own api key
    language: de (optional)

Der persönliche API Key für die Directions API von Google kann unter https://developers.google.com/maps/documentation/directions/intro?hl=de beantragt werden.

Die Items

Wichtig sind dabei folgende drei Items zur Erfassung des aktuellen Orts, an dem man sich aufhält. Die Items wurden bereits in dem oben genanntem Artikel zu EgiGeoZone eingeführt, und werden, wie im Artikel beschrieben, von EgiGeoZone bedatet:

location:

        lat:
            type: str
            visu_acl: ro
            cache: 'yes'

        lon:
            type: str
            visu_acl: ro
            cache: 'yes'

        zone:
            type: str
            visu_acl: ro
            cache: 'yes'

Wichtig dabei ist, dass der Zonenname in EgiGeoZone für die Arbeitsstätte (oder mehrere Arbeitsstätten) den String „Arbeit“ enthält und der Zonenname für daheim „Home“. Alternative Namen gehen auch, müssen dann aber in der Logik weiter unten angepasst werden.

Zusätzlich müssen noch die Home Koordinaten jeweils als Item definiert werden.
Tipp: Alternativ können auch die Attribute _lat und _lon direkt auf dem SmartHome Objekt (bin/smarthome.py) genutzt werden.

location:

    home:
        lat:
            type: str
            visu_acl: ro
            value: 48.xxxxxxx
            cache: 'yes'

        lon:
            type: str
            visu_acl: ro
            value: 11.xxxxxxx
            cache: 'yes'

Für die Speicherung der Reisedaten, die vom Traffic Plugin zurückgegeben werden, werden folgende Items benötigt:

travel_info:

    calculate_way_home:
       type: bool
       cache: 'yes'
    
    calculate_way_work:
        type: bool
        cache: 'yes'

    travel_time:
        type: num
        
        in_traffic:
            type: num

    travel_distance:
        type: num
        
    travel_summary:
        type: str

Die Logik traffic_info.py

Als nächstes muss die aktuelle Fahrzeit zyklisch jede Minute über eine Logik vom Plugin abgefragt werden.

TrafficInfo:
    filename: traffic_info.py
    crontab: '* * * *'

Der Code der Logik sieht wie folgt aus:

# Codeblock 1 - Fahrt von der Arbeit nach Hause
if sh.now().hour < 20 and sh.now().hour > 14 and sh.now().weekday() in [0, 1, 2, 3, 4] and ('Arbeit' in sh.location.zone()):
    sh.location.calculate_way_home(1)
    destination = sh.location.home.lat() + "," + sh.location.home.lon()
    origin = sh.location.lat() + "," + sh.location.lon()
else:
    sh.location.calculate_way_home(0)

# Codeblock 2 - Fahrt von zu Hause in die Arbeit
if sh.now().hour < 10 and sh.now().hour > 4 and sh.now().weekday() in [0, 1, 2, 3, 4] and sh.location.zone() == 'Home':
    sh.location.calculate_way_work(1)
    destination = "Musterstraße 5, München"
    origin = sh.location.home.lat() + "," + sh.location.home.lon()
else:
    sh.location.calculate_way_work(0)

# Codeblock 3 - Default: Fahrt nach Hause von "irgendwo".
if not sh.location.calculate_way_work() and sh.location.zone() != 'Home':
    destination = sh.location.home.lat() + "," + sh.location.home.lon()
    origin = sh.location.lat() + "," + sh.location.lon()
    sh.location.calculate_way_home(1)

# Codeblock 4 - Wege- und Zeitbestimmung, ggf. Alarmmeldung oder Reset der Items
if sh.location.calculate_way_work() or sh.location.calculate_way_home():
    route = sh.traffic.get_route_info(origin, destination, False)
    if route is not None:
        summary = route['summary'] + ": %.1f km in %.0f min" % (round(route['distance'] / 1000, 2), round(route['duration_in_traffic'] / 60, 2))
        sh.location.travel_time(route['duration'])
        if 'duration_in_traffic' in route:
            sh.location.travel_time.in_traffic(route['duration_in_traffic'])
        sh.location.travel_distance(route['distance'])
        sh.location.travel_summary(summary)
        if 'Arbeit' in sh.location.zone() and sh.location.travel_time.in_traffic() >= 2500 > sh.location.travel_time.in_traffic.prev_value() and sh.now().hour < 20 and sh.now().hour > 14:
            sh.pushbullet.note("Alarm: Verkehr", "%s Min. Fahrzeit nach Hause!" % round((sh.location.travel_time.in_traffic() / 60), 2))
else:
    sh.location.travel_time('')
    sh.location.travel_time.in_traffic('')
    sh.location.travel_distance('')
    sh.location.travel_summary('-')

Im ersten Block wird geprüft, ob die aktuelle Uhrzeit zwischen 14:00 und 20:00 liegt (Zeitraum für die Prüfung bzgl. „Weg von der Arbeit nach Hause“) und, ob der aktuelle Tag Montag – Freitag ist. Zusätzlich wird geprüft, ob man sich in einer Zone befindet, deren Name  die Zeichenkette „Arbeit“ enthält. Ist dies der Fall, so werden das boolsche Item calculate_way_home auf True und als destination die Home-Koordinate gesetzt.

Der zweite Codeblock macht das Gleiche, aber für die (bevorstehende) Anfahrt in die Arbeit von zu Hause aus (4:00-10:00 als Zeitintervall). Die aktuelle Zone enthält den String „Home“, als Destination wird die Adresse der Arbeitsstätte gesetzt. calculate_way_work wird auf True gesetzt.

Im dritten Codeblock wird nun geprüft, ob man auf dem Weg zur Arbeit und nicht zu Hause ist. Ist man dies nicht, so wird auf Basis der aktuellen Position (die nicht zwingend die Arbeitsstätte ist) immer die Fahrzeit nach Hause berechnet. Diese kann bspw. in der Visu angezeigt werden. calculate_way_home wird für die nachfolgende Berechnung ebenfalls auf True gesetzt.

Im vierten Codeblock wird nun das Traffic Plugin aufgerufen. Über get_route_info(origin, destination, False) werden die Daten zur Route von der aktuellen Position zum Ziel abgefragt. Das Item location.travel_time wird mit der reinen Fahrzeit ohne Berücksichtigung der aktuellen Verkehrlage, das Unteritem location.travel_time.in_traffic mit Berücksichtigung der aktuellen Verkehrslage befüllt.
In das Item location.travel_distance wird die aktuellen Distanz geschrieben.
In location.travel_summary landet ein kurzes Summary als String.
Zuletzt wird eine Alarmmeldung über das Pushbullet Plugin versendet: sh.pushbullet.note("Alarm: Verkehr", "%s Min. Fahrzeit nach Hause!" % round((sh.location.travel_time.in_traffic() / 60), 2))

Das Ergebnis ist hier zu sehen:

Neben der in diesem Artikel gezeigten Grundfunktionalität, lassen sich mit dem Plugin bzw. der Directions API auch noch deutlich mehr Informationen, wie bspw. die vollständigen Routing-Informationen zum Zielort, bestimmen.

Ich persönlich kombiniere einige dieser Daten mit der Anzeige meiner Position und der Wegstrecke nach Hause in Google Maps. Hierfür habe ich ein smartVISU Widget geschrieben. Dies ist Thema eines zukünftigen Artikels.

(Die in diesem Artikel verwendeten Screenshots wurden selber erstellt. Das Titelbild ist unter der Creative Commons Zero (CC0) Lizenz veröffentlicht und wurde von www.pexels.com bezogen.)