Die überwiegende Mehrheit der Nutzer nutzt SmartHomeNG auf einem Raspberry Pi. Dabei führt der Pi3 mit etwa 43% aller Nutzer direkt vor dem Pi 2 mit 23 % aller Nutzer. Der Pi 1 ist nur noch mit 10% der Nutzer vertreten.
Immerhin haben fast 15% eine virtuelle Maschine installiert unter der SmartHomeNG seinen Dienst verrichtet und 10% nutzen einen NUC von Intel.
Die restlichen Nutzer verwenden dann ODroid, BeagleBone, Docker Container, Banana Pi und sonstige Plattformen.
Stand dieser Nutzungsstatistik ist Mai 2018 mit über 160 Teilnehmern.

Startphase von SmartHomeNG

Für das tiefere Verständnis und Fehlersuche ist es unter Umständen wichtig zu wissen, wie der Start von SmartHomeNG abläuft. Prinzipiell gibt es 8 Bereiche die man betrachten kann:

• Der Kern mit Basisfunktionalitäten
• Zeitplanung von Ereignissen (Scheduler)
• Verbindungen über Netzwerke
• Module
• Plugins
• Items
• Logiken
• Szenen

Folgende Schritte werden beim Start von SmartHomeNG durchlaufen:

Zunächst Initialisierungen und Vorbereitungen für den Kern:

• Logging initialisieren aus etc/logging.yaml
• Startzeit überprüfen: Ist Echtzeit für Raspi vorhanden?
• Laden von etc/smarthome.yaml (bzw. smarthome.conf)
• Aktuelle Zeitzone prüfen
• Versionsinformationen ausgeben
• Zeichensatz UTF-8 im System voreingestellt?
• Objekte für Sonne und Mond erstellen (dazu wird Länge, Breitengrad und Höhe benötigt)

Dann der Hauptthread der nacheinander folgende Aufgaben ausführt und dann in einer Schleife weiterarbeitet

1. Init Scheduler
2. Start Scheduler
3. Init Connections
4. Laden von etc/module.yaml

• Init Modules z.B. http, dummy –> cherrypy wird gestartet (wird für das Backend benötigt)
• Start Modules

5. Laden von etc/plugin.yaml

• Init Plugins z.B. backend, database, knx, …
• Laden von plugins/pluginname/plugin.yaml
• Laden von plugins fertig: sh.plugin_load_complete == True

6. Start initialization of items

• Laden von items/*.yaml bzw. *.conf
• Laden von Items fertig sh.item_load_complete == True Achtung: Änderung zu erwarten, wenn Items dynamisch erstellt/verändert/gelöscht werden

7. Init logics

• Laden von Logiken aus etc/logics.yaml bzw. etc/logics.conf
• Laden von Logiken fertig wird nicht signalisiert, da es ab Version 1.4 während der Laufzeit neue Logiken geben kann

8. Init Scenes
9. Scheduler für Connections hinzufügen
10. Plugins starten

• plugin_start_complete == True Achtung: Änderung zu erwarten, wenn Plugins zur Laufzeit eingebunden/aktiviert/deaktiviert/entfernt werden

11. Scheduler für Garbage Collection hinzufügen
12. Hauptschleife

• Verbindungen auf anliegende Daten prüfen
• läuft bis ein Signal zum Beenden empfangen wird

Ein Attribut eval enthält eine Zeile Python die genau einen Wert zurückliefert. Es ist quasi eine Einzeilenfunktion. Der Syntax entspricht einer Python conditional expression.

Wenn in dieser Funktion Werte von Items genutzt werden sollen, dann müssen die Aufrufe die Form sh….<Item-Name>() haben. Sollte man sh. am Anfang vergessen funktioniert es genauso wenig, wie wenn man die Klammern am Ende wegläßt.

Ein Attribut eval_trigger ist nur eine Auflistung von Itemnamen, diese werden jedoch ohne sh. am Anfang aufgeführt.

eval Syntax

Ein Beispiel für einen eval Ausdruck:

eval=value if value>0 else 0

Achtung: Ein if-Statement in einem eval-Ausdruck muss auch einen else-Zweig haben.

Beispiele

Richtig:

myitem:
    eval: sh.my.value()
    eval_trigger: my.value|my.other.value

 
Falsch:

myitem:
    eval: sh.my.value
    eval_trigger: sh.my.value|sh.my.other.value)

08.04.2018: Ergänzt um Informationen aus einem Wiki Beitrag von henfri.

Der knxd implementiert Zugriffe auf verschiedenste Schnittstellen zum KNX Bus (z.B. IP-Router, IP-Schnittstelle, USB-Schnittstelle, etc.) und bietet dafür eine dokumentierte Softwareschnittstelle für Programme an. SmartHomeNG nutzt den knxd über seine TCP/IP Schnittstelle um Daten auf den KNX Bus zu schreiben oder zu lesen.

Der Einsatz von knxd (oder der Vorgänger Software eibd) ist Voraussetzung um das KNX Plugin von SmartHomeNG nutzen zu können.

Wer keinen KNX-Bus einsetzt, kann die Installation von knxd auslassen. Für den Fall, das die knxd Installation ausgelassen wird, kann es sein, das für weitere Module wie SmartHomeNG einige Pakete fehlen. Diese müßten dann per sudo apt-get install paketname nachinstalliert werden.

Grundsätzlich findet sich auf der knxd-Seite die Anleitung für die Installation. Auf der Github Seite kann unter Code immer der Branch ausgewählt werden. Jeder Branch hat sein eigenes Read.me. Support für knxd gibt es im knxd-Forum https://knx-user-forum.de/forum/projektforen/knxd

Wichtig: Der knxd wird derzeit aktiv weiterentwickelt. Ab Version 0.12.x ist pthsem nicht mehr notwendig und es wird libev eingesetzt. Wer genügend Wissen zum Testen hat ist herzlich eingeladen hier mitzuhelfen oder zu spenden. Auch bitte vor der Installation hier noch einen Blick auf knxd-Seite werfen um aktuelles nicht zu verpassen.

Diese Anleitung wird zwar in regelmäßigen Abständen aktualisiert aber eben nicht unbedingt wöchentlich oder gar täglich.

Die folgenden Installationsschritte beziehen sich auf Version 0.12.

zusätzliche Pakete installieren

Zunächst müssen für den Bau einige grundlegende Tools installiert werden:

sudo apt-get install git-core build-essential

debhelper-Erweiterung zur Behandlung von systemd-Dateien

sudo apt-get install dh-systemd

Erstellt automatisch configure-Skripte

sudo apt-get install autoconf

Generisches Skript zur Unterstützung von Bibliotheken

sudo apt-get install libtool

Bibliothek zum Programmieren von USB-Anwendungen ohne Kenntnis der Linux-Kernel-Interna

sudo apt-get install libusb-1.0-0-dev

Pkg-config ist ein System zur Verwaltung von Schaltern für die Übersetzung und Verknüpfung von Bibliotheken, das mit automake und autoconf arbeitet.

sudo apt-get install pkg-config

Die Bibliothek sd-daemon stellt eine Referenzimplementierung mehrerer APIs für neuartige Daemons bereit, wie sie vom Initialisierungssystem systemd implementiert werden

sudo apt-get install libsystemd-daemon-dev

Nun noch libev-dev installieren

sudo apt-get install libev-dev

Quellcode laden, compilieren und ein Paket schnüren

Zunächst den Quellcode für den knxd vom github laden und sicherstellen, das der 0.12 branch gewählt wird:

git clone https://github.com/knxd/knxd.git
cd knxd
git checkout v0.12

Dann übersetzen und das Paket schnüren:

dpkg-buildpackage -b -uc

Wichtig ist, das am Ende der Paketerstellung keine Fehler gemeldet wurden.

Sollte die Paketerstellung fehlerfrei ablaufen, dann kann das Paket nun noch installiert werden mit:

cd ..
sudo dpkg -i knxd_*.deb knxd-tools_*.deb

knxd konfigurieren

Als nächstes muß die Konfiguration des knxd für die zu verwendende Schnittstelle angepasst werden. Dazu muß bei Systemen mit systemd die Datei /etc/knxd.conf bearbeitet werden:

sudo nano /etc/knxd.conf

Die Originalzeile KNXD_OPTS=“-e 0.0.1 -E 0.0.2:8 -u /tmp/eib -b ip:“ am besten auskommentieren und in der Zeile darunter dann die gewählten Parameter eintragen.

Details zu Schnittstellen finden sich auf der Github-Seite vom knxd. Das -c ist für den knxd eigenen Cache. Danach folgen die Optionen für die Verwendung der Schnittstelle:

• IP Schnittstelle: KNXD_OPTS=“-e 0.0.1 -E 0.0.2:8 -c -b ipt:IP der knx Schnittstelle„
• IP Router: KNXD_OPTS=“-e 0.0.1 -E 0.0.2:8 -c -b ip:IP des knx Routers„
• USB-Interface: Bitte Wiki zum knxd konsultieren.

Es kann sein, das bei KNXD_OPTS hinter dem -c bei einigen Interfaces noch ein –send-delay=30 eingefügt werden muß um Telegrammverlust bei hohen Lasten zu minimieren. Die 30 bedeutet dabei eine zusätzliche Wartezeit von 30msec. Es wird damit zwischen den Paketen eine kleine Pause eingelegt um ein überfahren der Schnittstelle zu vermeiden. Der Parameter –no-tunnel-client-queuing ist obsolet und sollte nicht mehr eingesetzt werden.

knxd und systemd

Um die Änderungen wirksam werden zu lassen, muß der knxd die neue Konfiguration noch berücksichtigen dazu muß er ggf. beendet und neu gestartet werden. Der knxd hat dazu zwei Einträge, zum einen knxd.socket der die normalerweise die Kommunikation über der Port 6720 übernimmt und der knxd.service der die restlichen Aufgaben übernimmt.

Zunächst beenden des knxd:

sudo systemctl stop knxd.socket
sudo systemctl stop knxd.service

Die Reihenfolge ist wichtig: beenden wir erst den knxd, kann ein Prozess genau dann einen Socket öffnen und der systemd startet ihn sofort wieder.

Um sicher zu gehen, das der knxd mit dem Systemstart auch gestartet wird muß dem systemd mitgeteilt werden das diese beiden Einträge auch eingeschaltet also enabled sind.

sudo systemctl enable knxd.service
sudo systemctl enable knxd.socket

Jetzt können wir den knxd starten mit

sudo systemctl start knxd.socket
sudo systemctl start knxd.service

Auch hier ist die Reihenfolge wichtig: Starten wir erst den Service, werden dem knxd die Sockets nicht vom systemd übergeben.

Mit den folgenden Kommandos kann geprüft werden, ob die beiden Einträge ordnungsgemäßt funktionieren:

sudo systemctl status knxd.socket
sudo systemctl status knxd.service

Wenn alles ok ist, dann sieht das etwa so aus:

$ sudo systemctl status knxd.service
● knxd.service - KNX Daemon
   Loaded: loaded (/lib/systemd/system/knxd.service; enabled)
   Active: active (running) since Sa 2016-08-13 10:03:27 CEST; 5 days ago
 Main PID: 30769 (knxd)
   CGroup: /system.slice/knxd.service
           └─30769 /usr/bin/knxd -c -b ipt:192.168.10.38

$ sudo systemctl status knxd.socket
● knxd.socket - KNX Daemon (socket)
   Loaded: loaded (/lib/systemd/system/knxd.socket; enabled)
   Active: active (running) since Sa 2016-08-13 10:03:23 CEST; 5 days ago
   Listen: /var/run/knx (Stream)
           [::]:6720 (Stream)

Die Funktion des knxd läßt sich z.B. testen mit einer Gruppenadresse (hier: 1/0/170) für einen Schaltaktor mit 1 oder 0.

knxtool groupswrite ip:localhost 1/0/170 1

Sollte sich jetzt nichts tun, dann gibt es irgendwo einen Fehler und alles muß noch einmal geprüft werden. Vielleicht ist der Neustart des knxd vergessen oder ein Build-Fehler übersehen worden.

Wenn etwas nach erfolgter Installation nicht funktioniert, kann anhand folgender Punkte geprüft werden, was nicht klappt. Hilfe gibt es auch im KNX-User-Forum unter SmartHomeNG. Aber bitte erstmal alles durchdenken und prüfen. Wenn andere weiterhelfen sollen, dann müssen einige Informationen beigesteuert werden:

• Debug Ausgabe anhängen, mindestens bis das Problem ersichtlich geloggt wird. (Dazu SmartHome.py mit ‚-d‘ starten)
• Error und Warnings soweit möglich bereits vorher beseitigen
• evtl. die etc/plugin.conf und die items mit denen das Problem vermutlich zusammenhängt
• Wichtig ist auch u.U. die verwendete Hardware (VM oder Raspi 1, 2, 3) das Betriebssystem (Raspbian, Ubuntu x.y, Debian x.y) und ob eibd oder knxd genutzt werden.

Davor bitte einmal durch diese Liste durcharbeiten.

Läuft SmartHomeNG?

Auf dem Rechner auf dem SmartHomeNG laufen soll eine Shell öffnen und ps ax | grep smarthome eingeben.

In der Ausgabe darauf sollte in etwa folgendes zu finden sein:

smarthome@«yourcomputer»:~$ ps ax | grep smarthome
 1341 ?         Ss     0:00 sshd: smarthome [priv]
 1390 ?         S      0:52 sshd: smarthome@pts/0
 <Prozess-ID> pts/0    Sl+    8:24 python3 smarthome.py -d
11015 pts/1     S+     0:00 grep --color=auto smarthome
smarthome@«yourcomputer»:~$

Die beiden Zeilen oben mit sshd zeigen, das der User smarthome angemeldet ist.
Interessant ist die Zeile mit smarthome.py. Im Beispiel läuft der Prozess smarthome.py bereits und zwar im Debug Modus, erkennbar am -d. Sollte diese oder eine ähnliche Zeile nicht auftauchen, dann ist SmartHomeNG auch noch nicht gestartet.

Es darf von SmartHomeNG nur eine Instanz zur Zeit ausgeführt werden. Ein Versuch SmartHomeNG mehrfach zu starten wird immer mit Problemen bei der Bindung an diverse konfiguerierte IP und Ports quittiert. Das läßt sich im Debuglog ersehen:

ERROR    Connections  WebSocket: problem binding 192.168.x.y:2424 (TCP): [Errno 98] Address already in use
ERROR    Connections  CLI: problem binding 0.0.0.0:2323 (TCP): [Errno 98] Address already in use

Wenn Fehler dieser Art gezeigt werden dann ist dies ein klares Indiz dafür, das SmartHomeNG bereits läuft.
Um SmartHomeNG also im Debugmodus zu starten, muß die laufende Instanz erst beendet werden. Das geht mit smarthome.py -s oder aber man startet auf der Shell

kill «prozess-id»

. Die Prozess ID wird beim Aufruf von ps ax | grep smarthome angezeigt, siehe weiter siehe oben.

SmartHomeNG im Debugmodus starten

cd /usr/local/smarthome/bin
python3 smarthome.py -d

Jetzt sollte eine Menge an Loggingdaten aufgelistet werden. Der Debugmodus ist die Grundlage für weitere Fehlersuche. In den Loggingdaten werden Meldungen des Programmes angezeigt. Im Debugmodus werden sehr viele Logginginformationen dargestellt. Wichtig für die Fehlersuche sind vor allem Einträge die WARNING oder ERRROR enthalten.

Zugriff auf den KNX via eibd

ps ax | grep eibd

Nun sollte so etwas ähnliches gezeigt werden:

smarthome@sh13:~$ ps ax | grep eibd
  908 ?        Ss     1:13 /usr/bin/eibd --daemon --Server --Tunnelling --no-tunnel-client-queuing --Discovery --GroupCache --listen-tcp -d/tmp/eibd.log --pid-file=/var/run/eibd.pid --eibaddr=1.1.208 ipt:«ip der knx schnittstelle»
11045 pts/1    S+     0:00 grep --color=auto eibd
smarthome@sh13:~$

Im obigen Fall handelt es sich beim laufenden eibd um eine Installation, die auf eine KNX Schnittstelle zugreift. Wichtig ist hier, das die Zeile /usr/bin/eibd auftaucht. Wenn das der Fall ist, dann läuft der eibd.

Ob der eibd auch schalten kann stellt man fest mit

groupswrite ip:localhost 1/0/170 1

wobei hier 1/0/170 die Gruppenadresse eines Schaltaktors ist, der mit 1 eingeschaltet werden soll

Zugriff auf den KNX via knxd

Hier hängt die weitere Vorgehensweise davon ab auf welchem System der knxd installiert ist. Bei Ubuntu > 15.x oder Debian 8.x ist die Wahrscheinlichkeit recht hoch, das der Start vom systemd übernommen wurde. Sollte es ein älteres System sein, dann kann es auch sein, das ein herkömmliches Startskript verwendet wurde. In diesem Fall ist die Vorgehensweise wie oben unter eibd, nur das nun synonym dazu knxd benutzt wird.

Um festzustellen ob der knxd läuft auf der Shell systemctl status eingeben. Die Ausgabe sieht dann ähnlich aus wie hier:

«username»@«hostname»:~$ systemctl status
● sh11
    State: running
     Jobs: 0 queued
   Failed: 0 units
    Since: Fr 2016-03-11 10:49:08 CET; 2 weeks 1 days ago
   CGroup: /
           ├─1 /sbin/init
           ├─system.slice
           │ ├─avahi-daemon.service
           │ │ ├─463 avahi-daemon: running [sh11.local
           │ │ └─489 avahi-daemon: chroot helpe
           ...
           │ ├─knxd.service
           │ │ └─1204 /usr/bin/knxd -u /tmp/eib -b ipt:«ip der knx schnittstelle»
           ...
           └─user.slice
             └─user-1000.slice
               ├─session-7.scope
               │ └─2757 python3 ./smarthome.py -d
               ├─user@1000.service
               │ ├─1152 /lib/systemd/systemd --user
               │ └─1153 (sd-pam)
               └─session-1119.scope
                 ├─27926 sshd: smarthome [priv
                 ├─27928 sshd: smarthome@pts/
                 ├─27929 -bash
                 ├─28229 systemctl status
                 └─28230 pager
lines ... -.../«n» (END)

Sollte der knxd.service nicht laufen, so muß er zunächst lauffähig gemacht werden. Wenn knxd jedoch läuft, kann die Funktion des knxd getestet werden z. B. mit
Gruppenadresse = 1/0/170 für einen Schaltaktor mit 1 oder 0.
knxtool groupswrite ip:localhost 1/0/170 1
Sollte sich jetzt nichts tun, dann gibt es irgendwo einen Fehler und alles muß noch einmal geprüft werden. Vielleicht wurde der Neustart des knxd vergessen oder beim Erstellen des knxd packages ein Build-Fehler übersehen worden.

Kann SmartHomeNG schalten?

Nun kann geprüft werden, ob sich von SmartHomeNG ein Schaltvorgang auslösen läßt. Dazu muß entweder CLI– oder das Backend-Plugin installiert und konfiguriert sein (ist es bei den existierenden Anleitungen seit SmartHomeNG 1.3 eigentlich immer, das läßt sich durch einen Blick in die Datei etc/plugin.yaml feststellen)

Test mit CLI-Plugin

Zunächst muß über ein Telnetprogramm eine Verbindung zum CLI-Plugin hergestellt werden. Das Plugin lauscht standardmäßig auf Port 2323. Dazu wird eine zusätzliche Shell auf dem SmartHomeNG Rechner eröffnet und darin telnet localhost 2323 eingegeben.

«username»@«yourcomputer»:~$ telnet localhost 2323
Trying 127.0.1.1...
Connected to «hostname SmartHomeNG Rechner»
Escape character is '^]'.
SmartHome.py v1.1.26
Enter 'help' for a list of available commands.

Da unter Windows das mitgelieferte Telnet Programm nicht mit dem CLI-Plugin funktioniert, kann man auch Putty oder besser noch Kitty nutzen.
In Putty/Kitty bitte folgende Einstellungen setzen:

• Session:
  • Connection type → RAW wählen (nicht Telnet!)
  • Host Namen des Servers eintragen, Port 2323 (oder wie er in der plugin.yaml konfiguriert ist)
• Terminal:
  • Implicit CR in every LF → Haken setzen
• Connection – Telnet:
  • Keyboard sends Telnet special commands → Haken setzen
  • Return key sends Telnet New Line instead of ^M -→ Haken entfernen

Nach erfolgreichem Aufbau der Verbindung help eingeben.

> help
cl: clean (memory) log
ls: list the first level items
ls item: list item and every child item (with values)
la: list all items (with values)
lo: list all logics and next execution time
lt: list current thread names
update item = value: update the specified item with the specified value
up: alias for update
tr logic: trigger logic
rl logic: reload logic
rr logic: reload and run logic
rt: return runtime
quit: quit the session
q: alias for quit
>

Am einfachsten, die Befehle werden mal ausprobiert, z.B. ls um die First Level Items aufzulisten, dann ls item um ein bestimmten item abzufragen und schließlich update item = 1 für z.B. einen Schaltaktor einer Lampe um das Licht anzuschalten.

Wenn es bis hierher geklappt hat, dann ist das Grundsystem funktional.

Kontakt mit SmartVISU

Um mit der SmartVISU in Kontakt zu kommen sollten alle Punkte oberhalb schon funktional sein, also SmartHomeNG muß erfolgreich gestartet sein, keine Fehler oder Warnungen mehr im Log auftauchen und das grundsätzliche Schalten von Items über CLI- oder Backend-Plugin sollte funktionieren.

Für die Fehlersuche macht es Sinn SmartHomeNG im Debugmodus zu starten und parallel in einem Browserfenster die SmartVISU aufzurufen.
Bei der SmartVISU sollte sichergestellt sein, das der Seitencache ausgeschaltet ist, sonst werden Änderungen an einer html-Datei der SmartVISU nicht vom Browser angezeigt werden.

Im Debugmodus kann jetzt verfolgt werden, was passiert, wenn z.B. auf der Visu ein Button geklickt wird. Beispielsweise enthält das Log dann eine solche Zeile:

2018-04-01 12:39:17 DEBUG    item         Main         lib.item         Item ArbeitszimmerOG.Deckenlicht = False via Visu 192.168.20.70:54284 None -- item.py:__update:901

Passiert auf einen Tastendruck nichts, so kann es sein, das die SmartVISU nicht mit SmartHomeNG kommunizieren kann. Im Normalfall gibt es dann eine Fehlermeldung oben rechts.
Das erste, was dann kontrolliert werden muß ist die Konfiguration in der SmartVISU: Dort muß als Treiber SmartHomeNG eingetragen sein (Oder für SmartVISU 2.8 noch Smarthome.py), der Hostname des Rechners, auf dem SmartHomeNG läuft und als Port 2424.

Die häufigsten Fehler sind:

Mehr Informationen unter: CLI-Plugin
 

Fehlersuche mit Backend

Ab Version SmartHomeNG 1.2 gibt es das Plugin Backend. Das Backend Plugin muß in der
plugin.conf konfiguriert werden und wird über http://«ip-adresse von smarthomeng»:8383 im Browser aufgerufen. Es ist eigentlich selbsterklärend und bildet über den Browser ein wenig mehr Informationen ab als das CLI Plugin.

Prinzipiell ist es eine gute Idee im Backend zunächst zu schauen, ob selbst definierte Items auftauchen. Wenn das nicht der Fall ist, dann hat es beim Start von SmartHomeNG bereits Probleme gegeben. Fehlerquellen sind hier gerne mal

• falsche Codierung der betreffenden Datei Items/«meine items».yaml, also äöü enthalten aber nicht als UTF8 ohne BOM abgespeichert.
• Strukturfehler in der Datei die ein Item definiert, also falsche Einrückung oder inkonsistente Verwendung von TAB und Leerzeichen
• Ein reserviertes Python Wort (z.B. set oder get wurde verwendet
• Ein Itemname beginnt mit einer Zahl (z.B. 1Wire)

Installieren von Grafana

Es steht gerade eine neue Version 3.0 von Grafana für die Installation kurz vor der Release und damit ändert sich auch einges mit systemd. Bitte solange dem Link folgen und danach vorgehen. Wenn die Beta abgeschlossen ist und eine stable vorliegt, wird dieser Artikel im Wiki überarbeitet.

Datenverbindung zur Influx Datenbank

Wie oben müßt ihr mit Eurem Browser nun auf Port 3000 auf den Grafana Server zugreifen. Dort könnt ihr Euch dann mit Benutzer admin und Passwort admin anmelden. Der nächste Schritt ist die Einrichtung der Datenverbindung. Dazu wählt ihr Data Sources aus und dann oben in der Leiste Add New. Danach gebt Ihr als Name influxdb ein und als Type influxDB 0.9.x; den Haken bei default setzt man zweckmäßigerweise auch. Bei den http-Settings gebt Ihr diehttp://<IP>:8086, Access auf direct. Bei den InfluxDB Details als Datenbank smarthomemit User = root und Passwort root. Jetzt sollte Test Connection erfolgreich sein. Mit Klick auf Save seid Ihr jetzt einsatzfähig.

Erstes Dashboard anlegen

Ihr klickt jetzt auf Dashboards und anschließend auf Home. Weiter unten könnt Ihr nun +Newauswählen um ein neues Dashboard zu erzeugen. Wenn das geschehen ist, gibt es ein kleines grünes Rechteck. Darauf klickt ihr und dann weiter auf Add Panel und im Submenü Graph. Jetzt erscheint ein leeres Feld mit einem roten Ausrufezeichen in der oberen linken Ecke und einer Überschrift no title (click here). Darauf klickt ihr nun und wählt aus dem Popup Dialog Edit aus.

Unter Metrics ist jetzt eine Abfrage. Dort könnt Ihr – wenn bis dato alles richtig verlaufen ist und schon Werte in der Influx Datenbank zu finden sind – unter FROM select measurement eure erste Datenreihe eintragen. Ein Klick ganz oben auf das Diskettensymbol speichert nun das dashboard. Der Rest geht am besten über ausprobieren. Ein Klick auf den Farbstrich der Datenreihenlegende erlaubt es zu wählen ob die linke oder rechte Achse zur Anzeige genommen und welche Farbe zur Anzeige verwendet wird.

Viel Spaß!

Installation der InfluxDB Datenbank

Damit SmarthomeNG Meßwerte loggen kann existiert eine Schnittstelle zur SQLite Datenbank. Als Alternative für umfangreichere Auswertungen und mehr Performance gibt es ein neues Plugin um Meßdaten in eine Influx Datenbank zu schreiben. Die Influx Datenbank wurde speziell entwickelt für Meßwerte mit Zeitstempeln. Sie verfügt über Schnittstellen zu gängigen Programmiersprachen und es gibt eine interaktives Command Line Interface.

Vorbedingung

Die folgende Anleitung geht davon aus, das ein Debian Jessie System als 64-bit Variante vorliegt und damit der systemd benutzt wird um Dienste zu starten und zu beenden. Ihr könnt testen, welches System bei Euch installiert ist mit:

getconf -a | grep LONG_BIT

Das ergibt für ein 64 Bit System LONG_BIT 64.

(Alternativ kann man auch die Sourcen für InfluxDB holen und eine 32 Bit Version bauen. Allerdings sprengt das den Rahmen dieses How-to.

Zunächst der Download der InfluxDB Datenbank mit

wget https://dl.influxdata.com/influxdb/releases/influxdb_0.12.2-1_amd64.deb
sudo dpkg -i influxdb_0.12.2-1_amd64.deb 

Jetzt muß Influx noch einmalig gestartet werden:

sudo systemctl start influxdb.service

Ob die Datenbank nun im Hintergrund läuft, läßt sich prüfen mit

sudo systemctl status influxdb.service

Damit das Plugin später auch Daten in eine Datenbank schreiben kann, legen wir eine Datenbank an. Dazu starten wir das influx command line interface:

influx

Um die existierenden Datenbanken aufzulisten, geben wir das Kommando SHOW DATABASES ein. Da wir frisch installiert haben, sollten lediglich name und _internal gelistet werden. Nun erstellen wir eine neue Datenbank mit

CREATE DATABASE smarthome

Zur Prüfung geben wir erneut das Kommando SHOW DATABASES ein. Das Ergebnis sollte nun sein:

name: databases
---------------
name
_internal
smarthome

>

Mit quit kann das Command Line Interface wieder verlassen werden.

Installieren des InfluxDB Python Clients

Um die InfluxDB mit Python und damit mit SmarthomeNG nutzen zu können, bmuß noch ein passendes Zugriffsmodul installiert werden:

sudo pip3 install influxdb

Installieren des Plugins

In den nächsten Versionen von SmarthomeNG (> V1.1) wird das Plugin sicher Bestandteil des Masters werden. Bis es soweit ist, muss es nachinstalliert werden:

cd /usr/local/smarthome/plugins
mkdir influx
cd influx
wget https://github.com/SgtSeppel/smarthome-influxdb/archive/master.zip
unzip -j master.zip
rm master.zip

Konfiguration des Plugins

plugin.yaml

influxdb:
    class_name: InfluxDB
    class_path: plugins.influx
#   influx_host: localhost
#   influx_port: 8083
#   influx_user: root
#   influx_pass: root
#   influx_db: smarthome
    influx_keyword: influx

Der Eintrag influx_keyword legt fest, welche Daten in die Datenbank geschrieben werden. Ihr könnt entweder z.B. influx wählen und dann würde dieses item in die Datenbank geschrieben werden:

Vorlauftemperatur:
    name: Vorlaufemperatur
    type: num
    knx_dpt: 9
    influx: true
    visu_acl: rw
    knx_init: 8/1/1
    cache: on

Eine Superidee des Entwicklers ist es jedoch als influx_keyword nun sqlite auszuwählen, dann werden alle Daten die in die SQLite Datenbank geschrieben werden zugleich auch in die Influx Datenbank geschrieben.

Nun müßt ihr noch smarthome.py neu starten, damit das Plugin auch genutzt wird.

Wenn nun das Frontend Grafana genutzt werden soll um unabhängig von einer Visu auf dir nun frisch geloggten Daten zuzugreifen, dann bitte bei der Anleitung für Grafana fortfahren.

sql:
    plugin_name: database

Anschliessend wird im Item die Aufzeichnung aktiviert mit ‚database: yes‘ bzw. ‚database: init‘. Nun können weitere Items angelegt werden, die mit Hilfe einer Funktion, die das database-Plugin bereitstellt, die benötigten Werte erhalten.

Das ganze sieht dann in etwa wie folgt aus:

sensor:
    carport:
        temp:
            type: num   
            knx_dpt: 9  
            knx_send: 3/4/11  
            knx_reply: 3/4/11
            ow_addr: '28.52F1AA030000'
            ow_sensor: T 
            database: init  # Aufzeichnung der Daten aktivieren
            min:
                type: num
                knx_dpt: 9
                knx_send: 3/4/14
                knx_reply: 3/4/14
                eval: "sh.sensor.carport.temp.db('min', '28h')"  # Mimium über die letzten 28h berechnen
                eval_trigger: sensor.carport.temp  # Änderungen der Temperatur triggern die Neuberechnung
            max:
                type: num
                knx_dpt: 9
                knx_send: 3/4/15
                knx_reply: 3/4/15
                eval: "sh.sensor.carport.temp.db('max', '28h')"  # Maximum über die letzten 28h berechnen
                eval_trigger: sensor.carport.temp   # Änderungen der Temperatur triggern die Neuberechnung