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.

Es gibt jeweils einen eigenen Namensraum für Scheduler, die durch

• Items
• Logiken
• Scheduler

erzeugt wurden. Die Scheduler sind im Backend auf unterschiedlichen Reitern auf der Seite Scheduler zu sehen. Auf einem vierten Reiter sind die Scheduler zu sehen, die nicht in diese drei Namensräume fallen.

Das erweiterte API um diese Scheduler sauber anzusprechen ist noch auf der To Do Liste.

Zur Zeit können diese Scheduler über die bisherigen Scheduler Methoden angesprochen werden. Den Namen muss dabei jeweils ein Präfix vorangestellt werden.

Für:

• items   ->   items.<scheduler name>
• Logiken   ->   logics.<scheduler name>
• Plugins   ->   plugins.<scheduler name>

Es gibt zurzeit drei verschiedene Datenbank Plugins:

• database
• sqlite
• sqlite_visu2_8

Wenn Du neu mit SmartHomeNG beginnst, solltest Du das Plugin database verwenden. Das database Plugin unterstützt sowohl MySQL Datenbanken, als auch SQLite Datenbanken. Welcher Datenbank-Typ verwendet wird, wird in ../etc/plugin.yaml konfiguriert.

sqlite und sqlite_visu2_8

Die beiden SQLite Plugins dienen nur der Rückwärts-Kompatibilität für bestehende SmartHomeNG bzw. smarthome.py Umgebungen und werden nicht mehr weiterentwickelt.

Das Plugin sqlite unterstützt smartVISU bis zur Version v2.7.

Zur Unterstützung von smartVISU v2.8 und v2.9 muss das Plugin sqlite_visu2_8 verwendet werden. Das Plugin führt beim ersten Start eine Konvertierung der Datenbank von sqlite auf das sqlite_visu2_8 Format durch. Einen Weg zurück gibt es dann nicht. Es sollte also vorher eine Sicherung der Datenbank Datei ../var/db/smarthome.db durchgeführt werden.

Wichtig: Vor Beginn der Sicherung SmartHomeNG beenden.

Eine Routine zur Konvertierung der Datenbanken der sqlite Plugins zu einer Datenbank für das database Plugin gibt es (noch) nicht.

Der erste Blick sollte in die FAQs führen. Wenn Du da nicht fündig wirst, gibt es weitergehende Unterstützung.

Unterstützung

Im Forum https://knx-user-forum.de/forum/supportforen/smarthome-py gibt es Unterstützung von uns und anderen Nutzern.

Zusätzlich haben wir auf https://gitter.im/smarthomeNG/smarthome einen Chat für SmartHomeNG eingerichtet. Dort schauen viele User und Entwickler in (un-)regelmäßgen Abständen rein.

Fehlerbehebung

Bevor ihr postet oder um Hilfe fragt, bitte

• im Backend einen Überblick verschaffen ob z.B. config files richtig im SmartHomeNG ankommen
• Im Logfile nach Fehlern oder Warnungen suchen und wenn möglich deren Ursachen beseitigen.
• SmartHomeNG im Debugmodus starten

Wenn Ihr Hilfe braucht und nicht weiterkommt werden Euch andere hier im Forum gerne weiterhelfen.

Wenn ihr dann postet, geizt bitte nicht mit Informationen über eure Installation. Wir können alle nicht Hellsehen. Für uns hilfreich oder sogar notwendig sind unter anderem:

• Beschreibung was ihr erreichen wollt
• Erläuterung was ihr bisher gemacht habt
• Genaue Bescheibung des wahrgenommenen Problems („Läuft nicht“ ist da nicht ausreichend)
• Erläuterung welches Verhalten ihr erwartet
• SmartHomeNG Version
• Python Version
• Betriebssystem mit Version
• eingesetzte Hardware
• Art der Installation (z.B. Nach Komplettanleitung oder Raspberry Pi Image oder Update von Vorversion oder …)
• Konfigurierte Plugins (gerne die etc/plugin.yaml mit posten)
• gegebenfalls die entsprechenden Item Konfigurationen (aus items/*.yaml)

1. EIBD oder KNXD: (welchen Deamon genutzt ist dabei nicht erheblich). Die Funktionsfähigkeit des Deamons kann mit dem Kommando GROUPSWRITE getestet werden. Solange das nicht funktioniert, kann auch die Ansteuerung aus SmartHomeNG und smartVISU nicht funktionieren.
2. SmartHomeNG: Damit SmartHomeNG mit dem KNX Bus reden kann, muss das KNX-Plugin richtig konfiguriert sein. Dieses erfolgt in der Datei /etc/plugin.conf.

   Um zu testen, ob SmartHomeNG mit dem KNX Bus redet, kann man Quick-and-Dirty in der Conf Datei bei dem Item das geschaltet werden soll, einen Eintrag value = 1 oder value = 0 ergänzen und SmartHomeNG neu starten. Dann sollte der KNX Aktor ein- bzw. ausschalten.

   Erst wenn diese Kommunikation funktioniert, macht es Sinn sich der Visu zuzuwenden.

3. smartVISU: Die smartVISU muss richtig konfiguriert sein, damit sie mit SmartHomeNG spricht. Sonst sieht es zwar aus, als würde sie schalten, tut sie aber nicht.

   Auf der Konfigurationsseite muss unter I/O-Connection folgendes eingetragen sein:

   • Driver: Smarthome.py
   • Address:
   • Port: 2424
   • Realtime: on

   Wichtig: Der Eintrag localhost als Adresse funktioniert nicht!

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.

Bei der Wahl von Itemnamen ist folgendes zu beachten: Plugin-Instanzen und Items der obersten Ebene (Top-Level) teilen sich den Namensraum.

Es sollte vermieden werden, Top-Level Items einen Namen zu geben, der in ../etc/plugin.yaml (bzw. ../etc/plugin.conf) bereits für eine Plugin-Instanz gewählt wurde. Dieses kann zu unvorhergesehenen Problemen führen. (z.B.: Wenn ein Plugin Funktionen implementiert hat, wird dies beim Aufruf dieser Funktionen zu Problemen führen, da SmartHomeNG dann versucht auf eine (nicht existierende) Methode des Items zuzugreifen, statt auf das Plugin.)

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)