Allgemein

Einige Grundprinzipien des EIB-Busses

In einem Eib-System gibt es Sensoren ("Schalter") und Aktoren ("Relais") die jeweils eine physikalische Adresse besitzen. Sie werden durch Gruppenadressen zu Gruppen verbunden. Jeder Sensor kann mehrere Gruppen ansprechen und jeder Aktor kann auf mehrere Gruppen hören.
rleibd benutzt zur Zeit nur Gruppenadressierung.
Sie haben z.B. einen Schalter für das Licht im Wohnzimmer und ein Relais, das dann tatsächlich Netzspannung an die Lampe legt. Sie programmieren nun den Schalter mit der ETS-Software daß er Gruppe 1.0.1 sendet und den Aktor daß er auf Gruppe 1.0.1 hört. Wenn Sie nun den Schalter betätigen sendet er den Wert (0=aus, 1=ein) für diese Gruppe und das Relais tut daraufhin seinen Dienst.
Bei manchen Geräten beeinflusst mehr als eine Gruppe seinen Wert. Ein Dimmer beispielsweise kann auf eine bestimmte Helligkeit (in %) gesetzt werden, er kann ein oder ausgeschaltet werden oder er kann heller oder dunkler gestellt werden. Es ist schwierig, den Helligkeitswert durch Verfolgung der Telegramme zu ermitteln. Einfacher ist es, den Dimmer einfach danach zu fragen.
Wenn Sie Ihre KNX/EIB-Installation planen ist es nützlich, Ihre Gruppenadressen zu strukturieren. So sollten Sie z.B. eine Hauptgruppe (1.x.x) für Beleuchtung, eine für Fenster, eine für Heizung usw. verwenden. Benutzen Sie die mittlere Gruppe (x.1.x) für jedes Stockwerk (0=Keller, 1=Erdgeschoß etc.) und schließlich die niederste Gruppe für das einzelne Gerät. Damit erleichtern Sie sich später die Erklärung von Telegrammen und das eventuelle Filtern.

Installation und Konfiguration

Laden Sie das Paket herunter und entpacken Sie es in ein leeres Verzeichnis. Zusätzlich benötigen Sie die folgenden Pakete auf Ihrem System:

Gnu-C compiler um rleibd zu bauen
den eib driver von der Tu-Wien
den Apache Webserver um die Ergebnisse anzuzeigen
mod_php
Perl und perlcgi
die mxml-Bibliothek (gibt es hier)

Installieren Sie den Eib-Treiber gemäß den Anweisungen der TU Wien. Testen Sie ihn mit dem "eibdump"-Tool (auch von TU Wien). Im Moment ist eibdump nur in einem der älteren Pakete enthalten (für Kernel 2.2 oder so). Wenn Sie es nicht finden, suchen Sie dort. /dev/eib[0123] müssen existieren und funktionieren bevor Sie weitermachen. Verlinken sie /dev/eib auf das in Ihrem System benutzte eib-device.
Kopieren Sie das Beispiel-CGI-Script in Ihr cgi-bin-Verzeichnis und passen Sie die Eib-Adressen Ihrer Installation an.
Passen Sie die eibdef.xml-Datei Ihrer Installation an. Tippen Sie "make". rleibd sollte sich ohne Fehler kompilieren lassen (Schande auf mich falls nicht ;-)). Alles was jetzt noch schiefläuft liegt an Ihnen. Beheben Sie die Fehler und Ihr System wird funktionieren.

Betrieb

Werte abfragen

EIB-Werte werden über http-ähnliche requests auf port 1215 abgerufen. Z.B. lesen Sie die Gruppe 1.2.3 indem Sie eine Anforderung "GET /eib/grp/1.2.3" senden. Der Portserver antwortet mit dem Wert in Klartext, d.h. "on" oder "off" für einen Schalter, "open" oder "close" für ein Fenster, "25%" für einen Prozentwert u.s.w.. Zur Zeit gibt es keine Möglichkeit (und keine Notwendigkeit) den binären Wert abzufragen.

Werte senden

Um einen Wert zu senden fügen Sie einfach ein "?val=..." am Ende Ihres Requests hinzu. Es erfolgt keine weitere Prüfung. Der Portserver sucht nur nach dem "val=" und benutzt alles danach als Wert. Im Moment können Sie nur numerische Werte senden (d.h. "0" und "1" statt "off" und "on") und Prozentwerte. Ein eventuelles "%" wird ignoriert. Der Wert wird einfach an atoi() übergeben und das Ergebnis gesendet.

Für einen binären Wert: alles was von "0" verschieden ist setzt den Wert (natürlich sollten Sie nur "0" und "1" verwenden)
Für einen Prozentwert: nur Werte zwischen 0 und 100 bewirken eine Änderung. Bruchteile werden ignoriert. Nur der ganzzahlige Anteil wird verwendet.
Der Portserver antwortet immer mit "Ok".
Der Zustand der Gruppe wird auf "unbekannt" gesetzt, der Server wird also danach fragen, wenn der Wert das nächste mal benötigt wird.

Wenn Sie das mit Ihrem Browser testen müssen Sie möglicherweise den "strg-Refresh"-Button (strg-F5 bei IE und Firefox) betätigen oder ihren Browsercache löschen damit die Anfrage wirklich gesendet wird.

Der Askerthread

Der Askerthread fragt alle Werte in regelmäßigen Intervallen (15s) ab. Damit können fehlende "invalidate"-Argumente und Inkonsistenzen zwischen dem tatsächlichen Zustand des Systems und seinem Abbild im Speicher gefunden und behoben werden. Der Thread geht alle Gruppen im XML-File durch, die gesamte Zeit für einen Asker-Lauf beträgt demnach 15s mal die Anzahl der Gruppen. Nur bei Gruppen mit dem "ask"-Tag wird auch wirklich gefragt. Achten Sie darauf, nicht auf Zentralfunktionen zu fragen sonst werden alle Ihre Lichter in diesem Moment erlöschen.
Wenn Sie keine "ask"-Tags eingetragen haben wird auch nichts passieren, ich empfehle aber, mindestens für jede Gruppe, die nur einen Aktor betrifft, einen ask-Tag einzutragen.
Wenn sich der empfangene Wert von dem im Speicher unterscheidet werden Sie einen Syslog-Eintrag bekommen sofern sie nicht das "nomismatch"-Tag verwenden. Dies kann sehr selten passieren aufgrund einer Race-Bedingung (wenn sich der Zustand des Aktors gerade in dem Moment ändert in dem der Askerthread danach fragt) aber es _wird_ z.B. bei Temperaturwerten passieren wenn sie nicht das "nomismatch"-Tag verwenden.
Wenn Sie z.B. 100 Gruppen definiert haben (was für ein Einfamilienhaus typisch sein dürfte) wird der Askerthread also etwa 25 Minuten für einen vollständigen Lauf benötigen.
Die allererste Asker-Runde wird in 1s-Intervallen durchgeführt um den Aufbau der internen Datenbasis zu beschleunigen.

Interne Funktion

rleibd startet drei Threads, einer hört auf dem Eib-Bus und einer auf dem Netzwerk (Port 1215) zur Kommunikation mit dem Benutzer. Wenn Ihr Browser das CGI-Script aufruft holt dieses die Daten von Port 1215, formatiert sie und sendet sie an den Browser.
Der dritte ist der oben erwähnte Askerthread, der den Zustand Ihrer Installation und deren Abbild im Speicher synchronisiert.

Beschreibung einiger Funktionen

rcvThread

läuft in einer Endlosschleife und empfängt Telegramme vom Eib-Bus. Interessante Daten werden im grpClass-Vektor gespeichert von wo sie der Klient abholt. Die BAU muß im Linklayer sein um Telegramme zu empfangen.

portserv

läuft ebenfalls in einer Endlosschleife und lauscht auf Port 1215 nach Benutzeranforderungen.
Anforderungen können zum Testen auch mit einem Standard-HTTP-Browser gemacht werden unter der URL "eib/grp/x.y.z". Das vollständige HTTP-Protokoll stört dabei nicht, portserv sucht jedoch lediglich nach dem Schlüsselwort "GET" gefolgt von der URL. Die Antwort ist der formatierte Wert als Klartext. Werfen Sie einen Blick auf das Beispielscript um zu sehen wie es funktioniert. Wenn der angeforderte Wert "unknown" ist wird auf dem Bus danach gefragt. Da dies eine Pause (200ms) erfordert kann dies für die Seite eine lange Zeit bis zur Darstellung bedeuten. Das heißt auch, daß Sie keine Seiten erstellen sollten, die viele Werte enthalten, nach denen nicht gefragt werden kann.
Hinweis: Fragen und Antwort (vom Bus) bekommen ist ein asynchroner Prozess und es ist nicht garantiert, daß der Wert nach 200ms empfangen wurde. Meist funktioniert es, aber bei hoher Buslast kann eine zweite Anforderung nötig werden.
Falls sie keinen Wert für eine Gruppe bekommen, überprüfen Sie, ob das "lesen"-Flag für diese Gruppe (und nur für diese) in der ETS-Software gesetzt ist.

getBauBytes

liest Daten vom internen Speicher der BAU (ram oder eeprom). Hinweis: Das funktioniert nur zuverlässig wenn sich die BAU nicht im Linklayer befindet da sich sonst unerwartete Telegramme mit den empfangenen Daten vermischen können.

bauSetRcvTable

Diese Funktion setzt die Länge der Empfangstabelle auf "0". Die BAU wird daraufhin alle Telegramme im Linklayer empfangen. Um unnötige Eeprom-Schreibzugiffe zu vermeiden wird getBauBytes aufgerufen um festzustellen, ob ein Schreibzugriff tatsächlich nötig ist. Das ist normalerweise der Fall, wenn Sie zuvor die ETS-Software benutzt haben.

bauToLinkLayer

schaltet die BAU in den Linklayer. In dieser Betriebsart empfängt die BAU alle Telegramme, die an Adressen in ihrer Receive-Table gerichtet sind (oder schlicht alle Telegramme, wenn die Receive-Table leer ist). rcvThread erwartet diese Betriebsart.

bauReset

führt einen BAU-Reset durch. Die BAU empfängt danach keine Telegramme mehr. Das passiert wenn rleibd normal beendet wird.

Signale

rleibd fängt das SIGUSR1-Signal ab und schreibt dann das stats.xml. Sie können das in einem Cron-Script benutzen um den Verlust an Statistik-Daten zu begrenzen wenn ihre Maschine (oder rleibd) abstürzt.

Zukünftige Erweiterungen

Ich plane bereits folgende Erweiterungen für die Zukunft:

Bedingungen in Skripten. Sie können z.B. das Licht im Schlafzimmer flackern lassen wenn noch Fenster offen sind.
Insertable Triggers. Sie können Trigger im laufenden Betrieb einfügen und löschen wenn sie nicht mehr benötigt werden.

Support

Ich habe rleibd in meiner Freizeit entwickelt ohne dafür einen Cent zu bekommen. Bitte verstehen Sie daher, daß ich nicht viel Zeit investieren kann um an Ihrem System mitzuwirken. Wenn Sie es versucht haben und es funktioniert nicht, versuchen Sie es bitte nochmal. Ich habe Monate gebraucht nur um den Eib-Treiber zum laufen zu bringen. Wenn Sie es bereits nochmal versucht haben, senden Sie mir eine Mail, ich werde tun, was meine Zeit erlaubt um Ihnen zu helfen.
Ich werde auch eine FAQ erstellen sobald ich genug Fragen dafür habe :-). Bitte sehen Sie dort zuerst nach.