Checkliste für die Fehlersuche

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)