Version vom 7. November 2016, 20:10 Uhr

Die Verwendung des EBUS zur Ansteuerung eines Heizungssystems kann dieses bei unsachgemäßer Anwendung beschädigen. Für unmittelbare oder mittelbare Folgen, die sich aus dem Nachbau des Interfaces oder der Verwendung der hier zur Verfügung gestellten Information ergeben, übernimmt der Autor keine Haftung.

Dieser Artikel beschreibt die Ankopplung von Heizungssysteme mit eBus-Interface an FHEM.

Der eBus ist eine bei vielen Heizungssystemen vorhandene serielle Schnittstelle mit zwei Leitungen. Verwendet werden dabei 2400 Baud als Geschwindigkeit und die beiden Signalpegel

logisch 1: 15–24 V
logisch 0: 9–12 V

Fertig aufgebaute eBus Platine, bereit für den Einsatz mit eBusd!

Interface

Schaltung

Eine direkte Ankopplung des eBus an FHEM via Pegelwandlung und serielle Schnittstelle ist nicht empfehlenswert, stattdessen wurde der Weg beschritten, einen separaten Raspberry Pi (Modell B) an den eBus zu koppeln und darauf die Software eBusd laufen zu lassen. Diese wird dann in einer beliebigen FHEM-Instanz als ECMD-Device definiert und somit per Telnet abgefragt.

Hierbei wird ein kommerziell für ca. 6,00 € erhältliches USB-Modul mit ein paar Zusatzbauteilen im Wert von ca. 5,00 € versehen. Das Interface hat die folgenden Eigenschaften:

Verpolungssicherer eBus-Anschluss
Galvanische Trennung zwischen eBus und USB

Die Bauteile sind unkritisch und können durch äquivalente Teile ersetzt werden. Allerdings sollte bei der Zenerdiode auf eine Belastbarkeit mit 1,3 W geachtet werden, und beim USB-Modul darauf, dass dieses einen FTDI-Chip enthält.

Achtung: Der Autor übernimmt keine Haftung für die Anwendung dieser Schaltung. Zur Vermeidung von Schäden durch unsachgemäße Bedienung des Heizungssystems wird ausdrücklich empfohlen, nur die lesende Hälfte des Interfaces nachzubauen und sich auf ein passives Lauschen auf dem EBUS zu beschränken. Dazu einfach den Zweig mit Darlington-Transistor aus der Schaltung nicht einbauen.

Die Schaltung des eBus von Prof. Dr. Peter A. Henning ist eine bewährte Schaltung die von zahlreichen Anwendern bereits nachgebaut wurde.

Eigenbau (Lochrasterplatine)

Hier ein Beispiel eines Aufbaues auf einer Lochrasterplatine.

Platine

Auf Basis der oben genannten Schaltung, wurde im FHEM Forum ein Platinenlayout erstellt und produziert. Die dazu benötigten Gerberfiles können hier heruntergeladen werden. Der Autor des Layouts hat dies mit der Freeware Version von EAGLE erstellt, d.h. die Files können bei allen Platinenherstellern eingereicht werden (keine Lizenz eines bestimmten Herstellers notwendig).

Diese Beschreibung sollte hauptsächlich für Personen dienen, bei denen es nicht das tägliche Brot ist elektronische Schaltungen in Betrieb zu nehmen. Ich setze hier voraus, dass der Umgang mit einem Lötkolben klar ist. Wer noch nie gelötet hat, sollte besser einen Bekannten ersuchen der das schon gemacht hat. Nachfolgend wird beschrieben, wie eine Platine mit den Bauteilen bestückt wird. Am einfachsten ist es einen fertigen Adapter zu kaufen. Siehe dazu auch den Link aus dem Forum:

Platine bestücken

Bei der Bestückung sollte darauf geachtet werden mit den niedrigsten Bauteilen zuerst zu beginnen, sonst fallen sie beim verlöten ständig heraus. Wer die Farbcodes der Widerstände nicht auswendig kennt sollte diese vorher mit einem Meßgerät (Ohmmeter) messen. Nach den Dioden und Widerständen können die IC Sockel eingelötet werden, hier sollte lediglich auf die Einkerbung laut Bestückungsaufdruck geachtet werden. Zum Schluß noch die restlichen Bauteile. Nach einer genauen Sichtkontrolle (verbogene Beinchen des IC, Kurzschlüsse beim Löten, richtige Polung) können noch die ICS eingesetzt werden. Diese können auf einer flachen Unterlage etwas vorgebogen werden, damit sie leichter in den Sockel passen.

Achtung: der IC 4011 ist ein Cmos Schaltkreis und ist empfindlich gegen statische Aufladungen, daher die Beinchen nicht mit dem Finger berühren, bzw. ein Antistatikband am Arm verwenden.

Bestückung der Widerstände bei Platine V1.6
R1 = 3k3
R2 = 1k0
R4 = 10k (nicht beschriftet, links neben R2)
R5 = 470
R6 = 22k
R7 = 100k (nicht beschriftet, links unten liegt quer)

Warenkorb der benötigten Bauteile von Reichelt

Platine Messpunkte

Hier abgebildet der Schaltplan mit einigen wichtigen Spannungen für den Testbetrieb am Netzgerät. Bitte beachtet den Widerstand am Eingang des eBus und die Anschaltung der behelfsmäßigen Led zur Abstimmung. Spätestens dann, wenn die Schaltung Fehler zeigt, wird man über so einen Versuchsaufbau nicht herum kommen. Damit kann in Ruhe die Schaltung getestet und gemessen werden. Defekte Bauteile oder fehlerhafte Lötstellen sollten dann schnell gefunden werden.

Der Schaltplan zeigt einige wichtigen Spannungen für den Testbetrieb am Netzgerät. Bei dem Versuchsaufbau ist insbesondere auf den Einsatz eines korrekten Vorwiderstands, am Eingang des eBus und die Anschaltung der behelfsmäßigen LED (zur Abstimmung), zu beachten (nur zur Abstimmhilfe).

Poti abgleichen

Zur ersten Justierung des Potis, wird der eBusd Dienst genutzt. Das Vorgehen sieht wie folgt aus:

1) eBus Dienst stoppen - Das kann mit der folgenden Kommandozeile bewerkstelligt werden:

service ebusd stop

2) eBus Dienst, jedoch mit minimalen Parametern und ohne eBusd Konfigurationsdateien (CSV-Files), mit der folgenden Kommandozeile erneut starten:

Hinweis: <DEVICE> Muss zuvor durch den entsprechenden USB-Port (siehe USB Device und Port unter Linux ermitteln) z.B. /dev/ttyUSB0 ersetzt werden.

ebusd -f -c /tmp --logareas bus --loglevel info -d <DEVICE>

3) Der eBusd Dienst läuft nun im Vordergrund.

4) Einem zweiten Terminal öffnen und den folgenden Befehl ausführen:

ebusctl raw

Mit dem Befehl erhält man im Terminalfenster die empfangenen Bytes als Hex, die wie folgt aussehen:

2015-12-24 12:07:16.955 [bus notice] <aa
2015-12-24 12:07:17.001 [bus notice] <aa
2015-12-24 12:07:17.047 [bus notice] <aa
2015-12-24 12:07:17.093 [bus notice] <aa
2015-12-24 12:07:17.097 [bus notice] <10
2015-12-24 12:07:17.102 [bus notice] <50
2015-12-24 12:07:17.107 [bus notice] <b5
2015-12-24 12:07:17.111 [bus notice] <04

Wenn gerade kein Gerät den Bus nutzt, dann sollten ca. 20 Zeilen pro Sekunde ausgegeben werden und zwar mit "<aa" (im Beispiel die oberen 4 Zeilen).

Sobald ein Gerät den eBus nutzt, tauchen neben "<aa" auch andere HEX Werte auf (im Beispiel die unteren 4 Zeilen). Diese Werte können ignoriert werden.

Wichtig bei der Poti Einstellung ist, dass vor allem die regulären "aa"s zu sehen sind. Tauchen die "aa"s auf, dann kann davon ausgegangen werden, dass der Poti korrekt eigestellt ist. Ist dies der Fall, dann kann der eBusd Dienst regulär gestartet werden. Dabei muss der im Vordergrund laufende eBusd Prozess (siehe Punkt 2) mit der Tastenkombination STRG+C abgebrochen und der folgende Befehl in der Kommandozeile ausgeführt werden:

service ebusd start

Anschließend erscheint eine Meldung, die einen erfolgreichen Start des Dienstes signalisiert.

[ ok ] Starting ebusd: ebusd.

Bekannte Fehler

Das Logfile ist zur Inbetriebnahme unerlässlich und kann (z.B. mit PSPad) ausgelesen werden.

2015-12-22 16:27:34.195 [bus notice] signal acquired
2015-12-22 16:28:12.029 [bus error] signal lost
2015-12-22 16:28:12.339 [bus notice] signal acquired
2015-12-22 16:28:14.006 [bus error] signal lost
2015-12-22 16:28:16.372 [bus notice] signal acquired
2015-12-22 16:28:18.023 [bus error] signal lost
2015-12-22 16:28:18.729 [bus notice] signal acquired
2015-12-22 16:28:20.458 [update notice] update myCustom Status01: 43.0;41.0;8.000;41.0;38.0;ok
2015-12-22 16:28:26.460 [update notice] update bc Mode QQ=10: standby
2015-12-22 16:28:30.436 [update notice] update myCustom Status01: 41.0;40.0;8.000;41.0;38.0;ok
2015-12-22 16:28:32.458 [update notice] update broadcast vdatetime QQ=10: 16:24:52;22.12.2015
2015-12-22 16:28:32.696 [update notice] update myCustom2 Pumpenstatus: ok
2015-12-22 16:28:36.452 [update notice] update bc Mode QQ=10: standby
2015-12-22 16:28:40.478 [update notice] update myCustom Status01: 40.0;39.0;7.750;41.0;38.0;ok
2015-12-22 16:28:42.482 [update notice] update myCustom1 Status11: nosignal;41;5;18;-;-;-;-;8.000
2015-12-22 16:28:42.753 [update notice] update myCustom Status02: auto;60;70.0;70;54.0

Hier ein typisches Log wenn das Poti noch nicht oder falsch kalibriert wurde. Ab dem Eintrag 16:28:20.458 war dann die richtige Stellung gefunden. Das Poti soll daher zunächst ganz nach links (Transistor der Platine ist dann rechts unten) gedreht werden und dann vorsichtig auf etwa 2:00 Uhr. Bei knapp 2:00 Uhr ist bei der Testplatine dann die ideale Stellung. Der Stellbereich ist sehr klein (etwa 1-2 mm), daher einen Schraubendreher verwenden der sehr exakt passt und gleichzeitig mit dem Laptop abfragen starten. Zur Kontrolle dann das Log (var/log/ebusd.log) abfragen.

2015-11-29 06:26:55.271 [update notice] update myCustom1 Status11: nosignal;40;0;15;-;-;-;-;-0.188
2015-11-29 06:26:55.541 [update notice] update myCustom Status02: auto;60;70.0;70;54.0
2015-11-29 06:26:59.293 [update notice] update bc Mode QQ=10: standby
2015-11-29 06:27:03.323 [update notice] update myCustom Status01: 53.0;45.0;-0.438;47.0;46.0;error
2015-11-29 06:27:05.268 [update notice] update broadcast outsidetemp QQ=10: -3.188
2015-11-29 06:27:09.344 [update notice] update bc Mode QQ=10: standby
2015-11-29 06:27:11.934 [bus error] send to 08: ERR: read timeout, retry
2015-11-29 06:27:11.981 [bus error] send to 08: ERR: read timeout, retry
2015-11-29 06:27:12.025 [bus error] send to 08: ERR: read timeout, retry
2015-11-29 06:27:12.069 [bus error] send to 08: ERR: read timeout

In diesem Fall liegt ein Fehler bei jedem Sendeversuch vor. Ein "bus error" mit timeout sollte nicht (zu oft) zu finden sein. Gut zu sehen sind schon die Broadcast Meldungen, die selbständig über den Bus laufen und vom Konverter schon richtig interpretiert werden. Sollten wie in diesem Fall, die Meldungen nicht mit Texten zu lesen sein fehlen noch die Konfigurationfiles (csv) im Verzeichnis /etc/ebusd. Welche Files hier verwendet werden sollen ist natürlich von der Therme und dem Zubehör abhängig.

Achtung: Der Autor übernimmt keine Haftung für die Anwendung dieser Schaltung. Zur Vermeidung von Schäden durch unsachgemäße Bedienung des Heizungssystems wird ausdrücklich empfohlen, nur lesend auf die Schnittstelle zugreifen.

Kommerzielles Interface

Ein kommerzielles Interface für die Umsetzung eBus->USB ist hier erhältlich: eBus Koppler USB

Software

Als Software kommt auf dem Raspberry Pi der ebusd = eBus-Dämon zum Einsatz (aktuell im Januar 2016 die Version 2.0).

Der ebusd wird auf dem System (z.B Raspberry Pi) nach der beiliegenden Anleitung übersetzt und installiert.

Wichtigsten Bestandteile (Komponenten) der Installation sind:

ebusd - das eigentliche Programm zur Kommunikation mit dem EBUS
ebusd-configuration - Dateien im CSV(Comma Separated Value)-Format, die beim Start des eBusd eingelesen und als Kommandos (Befehle) für das Heizungsystem verwendet werden.

Nachfolgend wird die Installation der zwei Komponenten beschrieben.

eBusd Installation per Debian Package

Voraussetzungen

wget (ist in der Regel auf vielen Distributionen bereits installiert). Die Installation kann mit der folgenden Kommandozeile nachträglich durchgeführt werden:

sudo apt-get install wget

eBusd installieren

Das entsprechende eBusd Debian Package kann vom GitHub ebusd bezogen werden.

Die Installation (Stand Januar 2016 - Version 2.0) wird wie folgt durchgeführt:

EBUSDPACKAGE=ebusd-2.0_armhf.deb # <--- Version kann bei Bedarf hier angepasst werden.
wget https://github.com/john30/ebusd/releases/download/v2.0/$EBUSDPACKAGE
sudo dpkg -i --force-overwrite $EBUSDPACKAGE

Hinweis: Die eBusd wird dauernd aktualisiert. Aus diesem Grund sollte vor der Installation geprüft werden (siehe den o.g. Link), ob bereits eine neuere Version zur Verfügung steht. Der Name des Debian Packages muss, vor der Ausführung der o.g. Kommandozeilen, an der entsprechenden Stelle angepasst werden.

eBusd Konfigurationsdateien (CSV-Files)

Das entsprechende eBusd Konfigurations Debian Package kann vom GitHub ebusd-configuration bezogen werden.

Die Installation (Stand Januar 2016 - Version 2.0.5aa482c) wird wie folgt durchgeführt:

EBUSDCFGPACKAGE=ebusd-configuration-2.0.5aa482c-de_all.deb # <--- Version kann bei Bedarf hier angepasst werden.
wget https://github.com/john30/ebusd-configuration/releases/download/v2.0.1/$EBUSDCFGPACKAGE
sudo dpkg -i --force-overwrite $EBUSDCFGPACKAGE

eBusd starten

Nach der erfolgreichen Installation des eBusd und der eBusd Konfigurationsdateien kann nun der Dienst gestartet werden. Zuvor muss jedoch der USB-Port des eBus Adapters überprüft werden (siehe auch USB Device und Port unter Linux ermitteln). Sollte der USB-Port von dem Standardwert "/dev/ttyUSB0" abweichen, dann muss die Konfiguration "/etc/default/ebusd" angepasst werden. Andernfalls kann nun der Dienst mit der folgenden Kommandozeile gestartet werden:

service ebusd start

Anschließend erscheint eine Meldung:

[ ok ] Starting ebusd: ebusd.

die einen erfolgreichen Start des Dienstes signalisiert.

eBusd und Konfigurationsdateien deinstallieren

Nachfolgend wird die Deinstallation des eBusd und der eBusd Konfigurationsdateien beschrieben.

Zunächst muss der eBusd Dienst beendet werden, dies erfolgt mit der folgenden Kommandozeile:

service ebusd stop

Anschließend erscheint eine Meldung:

[ ok ] Stopping ebusd: ebusd.

die einen erfolgreichen Stop des Dienstes signalisiert.

Anschließend wird zunächst das Debian Konfigurations Package deinstalliert.

Achtung: Bei der Deinstallation werden alle Konfigurationsdateien (CSV-Files) unwiderruflich gelöscht!

Die Deinstallation erfolgt mit der folgenden Kommandozeile:

sudo dpkg -r --force-overwrite ebusd-configuration

Das eBusd Debian Package wird mit der folgenden Kommandozeile deinstalliert:

sudo dpkg -r --force-overwrite ebusd

Tipp: Mit der folgenden Kommandozeile:

dpkg -l | grep 'ebusd'

können die installierten eBusd Debian Packages überprüft werden.

Liefert der Befehl kein Ergebnis, dann kann davon ausgegangen werden, dass kein eBusd Debian Package mehr installiert ist.

eBusd Installation Build Prozess

Möchte man eine aktuelle Entwicklungsversion von eBusd nutzen, weil ein Fehler behoben wurde und für diese Version noch kein Debian Package vorhanden ist, dann kann der eBusd manuell kompiliert werden. Nachfolgend werden die dafür notwendigen Schritte beschrieben.

Voraussetzungen

Zunächst müssen die notwendigen Werkzeuge auf dem System installiert werden. Dies erfolgt mit der nachfolgenden Kommandozeile:

apt-get -y install git && apt-get -y install autoconf && apt-get -y install automake && apt-get -y install g++ && apt-get -y install make

Weiterführende Informationen findet man auch direkt im eBusd Wiki!

eBusd kompilieren

Nachdem alle Voraussetzungen erfüllt sind, kann der eBusd auf dem lokalen System kompiliert und installiert werden. Dafür sind folgende Schritte notwendig:

eBusd auschecken

git clone https://github.com/john30/ebusd.git

Den Kompilierungsvorgang starten

 cd ebusd
 sudo ./autogen.sh --prefix=/usr
 sudo make
 sudo make install
 sudo cp contrib/debian/default/ebusd /etc/default/ebusd # Konfigurationsdatei für eBusd Startoptionen.

Dieser Vorgang kann je nach Geschwindigkeit des Systems ca. 20 Minuten dauern.

Wurde der Vorgang erfolgreich durchgeführt, dann kann mit der folgenden Kommandozeile die Version abgefragt werden:

ebusd -V

Autostart von eBusd konfigurieren

Damit die Austostartroutine auch nach einem Neustart des Systems funktioniert, muss das Dämonstartfile in das entsprechende Verzeichnis kopiert werden. Die Konfiguration wird mit der folgenden Kommandozeile durchgeführt:

sudo cp contrib/debian/init.d/ebusd /etc/init.d/ebusd   # (Dämonstartfile kopieren)

Der eBusd Dienst kann, wie hier beschrieben, gestartet werden.

eBusd Logrotate

Logrotate ist ein logischer Ablauf was mit dem Logfile geschehen soll. Man kann damit das File täglich komprimieren und das 7 Tage lang, dann erst wieder beginnen es zu überschreiben. Dies ist besonders wichtig, denn sonst würde irgendwann das Logilfe bis zu einer extremen Größe anwachsen.

/var/log/ebusd.log {
     rotate 7
     copytruncate
     compress
     missingok
     notifempty
     daily
}

Das Logfile kann in /etc/logrotate.d/ebusd konfiguriert werden. In diesem Beispiel wird alle 7 Tage rotiert und die Datei komprimiert, das aktuelle Tagesfile ist unkomprimiert und mit einem Editor lesbar. Das Ergebnis aus der oben dargestellten Definition sieht wie folgt aus:

Systemüberwachung

Aufgrund unterschiedlicher Ursachen kann es vorkommen, dass der eBus Dämon seinen Dienst einstellt. Die hätte zufolge, dass der Lese- und Schreibzugriff nicht mehr möglich wäre. Nachfolgend werden zwei Möglichkeiten beschreiben wie eine Überwachung des Systems realisiert und im Störungsfall die Funktionalität wiederhergestellt, werden kann.

Mithilfe von FHEM

In FHEM kann man ein Notify einrichten, um bei einem Verbindungsabbruch mehrere Versuche zum Reconnect durchzuführen

# fhem.cfg
define EBUS.N notify (EBUS.*DISCONNECTED.*)|(HK.Hz:A.Temp.*err) { EBUSrecover("notify EBUS.N",0)}
attr EBUS.N group deviceDetector
attr EBUS.N room Alarm

Das dabei aufgerufene Perl-Programm besteht nur aus wenigen Zeilen und muss in die 99_myUtils.pm kopiert/erweitert werden:

# 99_myUtils.pm
sub EBUSrecover($$)
{   
  my ($evt,$num) = @_;
  Log 1,"[EBUS] Recover triggered from $evt, attempt No. $num";
  if(Value("EBUS") ne "opened"){
    if( $num < 7){
      $num++;
      fhem("set EBUS reopen");
      fhem("delete EBUSrecoverdly") if($defs{"EBUSrecoverdly"});
      fhem("define EBUSrecoverdly at +00:00:05 {EBUSrecover('EBUSrecover',$num)}");
    }else{
      fhem("set Device.warn EBUS") 
    }
  }
}

Mithilfe von Watchdog

Es empfiehlt sich auch, den ebusd kontinuierlich zu überwachen und ggf. neu zu starten. Mit der nachfolgenden Beschreibung wird alle 5 Sekunden die Existenz des Programms abgefragt und dieses bei einem versagenden Test neu gestartet.

Dazu wird auf dem System nach überall erhältlichen Anleitungen der Watchdog Timer installiert und die Datei /etc/watchdog.conf mit den beiden Parametern

test-timeout = 10
interval     = 5

besetzt. Ferner wird die Datei /etc/watchdog.d/ebusd angelegt mit dem Inhalt

#!/bin/sh
# description: watchdog helper file for ebusd  
case "$1" in
'test')
       #--- Test for ebusd
       if [ -s /var/run/ebusd.pid ] ; then
           RUN=`ps -ef | grep ebusd.*USB0 | grep -v grep`
           if [ "$RUN" != "" ] ; then            
              #echo "ebusd is already running"
              exit 0
           else
              echo "ebusd defunct at "`date`
              exit 1    
           fi
       else
           echo "ebusd not running, return 1 at "`date`
           exit 1    
       fi
       ;;
'repair')
       #-- Restarting ebusd
       echo "ebusd restarting at "`date`
       /etc/init.d/ebusd start
       RETVAL=$?
       exit 0
       ;;
*)
       exit 0
       ;;
esac

Visualisierung und Steuerung

Mit ECMD in FHEM

Eine einfache aber sichere Anbindung des eBusd an Fhem kann mit ECMD durchgeführt werden. Es ist egal ob eBusd auf dem selben Raspberry wie Fhem läuft oder ein eigener Raspberry dafür verwendet wird. Die gezeigten Beispiele sind nur eine der Möglichkeiten die zum Ziel führen, sollen aber sicher und schnell zu den ersten Erfolgen führen.

ECMD in FHEM aktivieren

# fhem.cfg
define EBUS ECMD telnet '''ip-raspi-ebusd''':8888   # IP Adresse ebusd einsetzen!!!
attr EBUS classdefs bai00.class=/opt/fhem/FHEM/bai00.cfg
attr EBUS icon usb
attr EBUS requestSeparator 000
attr EBUS room Vaillant

# Die Definition von ECMD, "ip-raspi-ebusd" muss durch die IP-Adresse ersetzt werden. Beispiel:
define EBUS ECMD telnet 192.168.0.10:8888

Die Kommunikation erfolgt über Telnet und 8888 ist das Port über welches kommuniziert werden soll.

ECMD Devices definieren

# fhem.cfg
define Vorlauf ECMDDevice bai00.class
attr Vorlauf IODev EBUS
attr Vorlauf group Vaillant
attr Vorlauf icon sani_supply_temp
attr Vorlauf room Vaillant

define Ruecklauf ECMDDevice bai00.class
attr Ruecklauf IODev EBUS
attr Ruecklauf group Vaillant
attr Ruecklauf icon sani_return_temp
attr Ruecklauf room Vaillant

define PumpeWatt ECMDDevice bai00.class
attr PumpeWatt IODev EBUS
attr PumpeWatt group Vaillant
attr PumpeWatt icon measure_power
attr PumpeWatt room Vaillant

define Fanspeed ECMDDevice bai00.class
attr Fanspeed IODev EBUS
attr Fanspeed group Vaillant
attr Fanspeed icon vent_ventilation_level_automatic
attr Fanspeed room Vaillant

define HKurve ECMDDevice bai00.class
attr HKurve IODev EBUS
attr HKurve group Vaillant
attr HKurve icon temp_control
attr HKurve room Vaillant

Jeder Messwert der von eBusd abgefragt werden soll, muss dazu ein ECMDDevice erstellt werden. Hier ein paar Beispiele mit Vorlauf, Rücklauf, Leistung der Pumpe, Ventilatorgeschwindigkeit und der Heizkurve.

Zu jedem ECMDDevice muss es eine Classdefinition in der bai00.cfg geben. Der Name "bai00.cfg" ist frei gewählt und wird in diesen Beispielen verwendet.

ECMD Classdefinition

Um eine Klasse zu definieren muss der dazu benötigte Code in eine eigene Datei (hier bai00.cfg) geschrieben werden.

################## bai00.cfg ###############
# 
#!/usr/bin/perl
# Aussentemperatur
get Aussentemp cmd {"r -f outsidetemp temp\n"}
get Aussentemp expect ".*\n*"
get Aussentemp postproc { $_ }
#
# vorlauftemperatur
get Vorlauf cmd {"r -m 10 status01 temp1.0\n"}
get Vorlauf expect "\d+\.\d+\n\n"
get Vorlauf postproc { sprintf("%5.1f",$_) }
#
# Ruecklauftemperatur
get Ruecklauf cmd {"r -m 10 status01 temp1.1\n"}
get Ruecklauf expect "\d+\.\d+\n\n"
get Ruecklauf postproc { sprintf("%5.1f",$_) }
#
# Pumpenleistung
get PumpeWatt cmd {"r -f PumpPower\n"}
get PumpeWatt expect "\d+\n\n"
get PumpeWatt postproc { sprintf("%5.0f",$_) }
#
# Fanspeed
get Fanspeed cmd {"r -f SDFanSpeed\n"}
get Fanspeed expect "\d+\n\n"
get Fanspeed postproc { sprintf("%5.0f",$_) }  
#
# Heizkurve lesen
get HKurve cmd {"r -f Hc1HeatCurve\n"}
get HKurve expect "\d+\.\d+\n"
get HKurve postproc { sprintf("%3.1f",$_) }
#
# HeizkurveSchreiben
get HeizkurveSchreiben cmd {"write 430 Hc1HeatCurve ".Value("HeizkurveEinstellen")."\n"}
get HeizkurveSchreiben expect ".*\n\n"
get HeizkurveSchreiben postproc  { $_ }

Für jeden Device wird hier festgelegt wie die Befehls Syntax der Abfrage auszusehen hat (cmd) und wie die Ergebnisse zu filtern sind (expect), wie soll das Ausgabeformat sein (postproc). Diese Definitionen bitte in einer neuen Datei "bai00.cfg" speichern.

ECMD Zyklische Abfrage

# Abfrage Timersteuerung, fhem.cfg
define EBUS.Timer at +*00:15:00 get Aussentemp Aussentemp;;get Vorlauf Vorlauf;;get Ruecklauf Ruecklauf;;get PumpeWatt PumpeWatt;get Fanspeed Fanspeed;;get PumpeWatt PumpeWatt;;get HKurve HKurve
attr EBUS.Timer group VaillantControl
attr EBUS.Timer icon time_timer
attr EBUS.Timer room Vaillant
attr EBUS.Timer verbose 0

Um die Daten auch zyklisch vom eBus abholen zu können, wird ein Timer gesetzt. Hier wird alle 15 Minuten abgefragt. Tipp: unwichtige Daten wie Druck oder irgendwelche Zähler definiert man in einem zweiten Timer, welcher dann zB. auf 1 Stunde getriggert wird. So wird die Häufigkeit des Zugriffs auf den eBus entlastet.

ECMD Solar, Warmwasser und Heizkreis

ECMD Beispiel Solar

Im nachfolgenden Beispiel wird der EBUS über das Modul ECMD angebunden und mit drei Klassen von Kommandos versehen. IP Adresse ist jene des Device wo der eBusd läuft.

define EBUS ECMD telnet 192.168.0.192:8888
attr EBUS classdefs HK.SOL.class=/opt/fhem/FHEM/ebus_solar.cfg:HK.WW.class=/opt/fhem/FHEM/ebus_ww.cfg:HK.Hz.class=/opt/fhem/FHEM/ebus_hz.cfg
attr EBUS room System
#--
define HK.Hz ECMDDevice HK.Hz.class
attr HK.Hz IODev EBUS
attr HK.Hz group heating
attr HK.Hz room Verbrauch
#--
define HK.WW ECMDDevice HK.WW.class
attr HK.WW IODev EBUS
attr HK.WW group heating
attr HK.WW room Verbrauch
#--
define HK.SOL ECMDDevice HK.SOL.class
attr HK.SOL IODev EBUS
attr HK.SOL group solarGenerator
attr HK.SOL room Solaranlage
#--
# Diese drei Klassen werden als separate Files mit den in der EBUS-Definition stehenden Dateinamen ''ebus_hz.cfg'', ''ebus_ww.cfg'' sowie ''ebus_solar.cfg'' angelegt. Alle drei ECMD-Devices werden nun zyklisch (z.B. jede Minute) abgefragt mit
define EBUS.Timer at +*00:01:00 get HK.Hz A.Temp;;get HK.Hz state;;get HK.WW state;;get HK.SOL state
attr EBUS.Timer group heatingControl
attr EBUS.Timer room Verbrauch
attr EBUS.Timer verbose 0

ECMD Classdefinition Heizkreis

Die erste Datei definiert die FHEM-Readings für die Abfrage von Außentemperatur und Heizkreis:

# Außentemperatur
get A.Temp cmd {"cyc broad temp\n"}
get A.Temp expect ".*"
get A.Temp postproc { my $rval;\
 if(($_ eq "")||($_ eq "no data stored") ){\
   $rval = "err";\
 }else{\
   $rval=sprintf("%5.2f °C",$_);\
 }\
$rval; }
# Heizkeis HK1
get state cmd {"cyc mv HK1_temp\n"}
get state expect ".*"
get state postproc { my ($bval,$rval,$tval,$pval,$qval,$sval,$xval,$zval);\
my $hash  = $defs{"%NAME"};\
 if( ($_ eq "")||($_ eq "no data stored") ){\
    $bval = "err";\
    $rval = "err";\
    $tval = "err";\
    $pval = "err";\
    $qval = "err";\
    $sval = "err";\
    $xval = "err";\
    $zval = "err";\
 }else{\
    my @values=split(' ',$_);\
    if( $values[0] < 15 ){\
       $bval = "err";\
       $rval = "err";\
       $tval = "err";\
       $pval = "err";\
       $qval = "err";\
       $sval = "err";\
       $xval = "err";\
       $zval = "err";\
    } else { \
       $bval = HzBedarf();\
       $rval = sprintf("%5.2f °C",$values[0]);\
       $tval = sprintf("%5.2f °C",$values[1]);\
       if( $values[2] == 0 ){\
          $pval = "OFF";\
          $qval = "0 0";\
       }elsif( $values[2] == 1 ){\
          $pval = "ON (HK)";\
          $qval = "80 0";\
       }elsif( $values[2] == 2 ){\
          $pval = "ON (WW)";\
          $qval = "0 80";\
       }else{\
          $pval = "unknown";\
          $qval = "err";\
       }\
       $sval = sprintf("%d",$values[2]);\
       $xval = sprintf("%5.2f %5.2f %s %5.2f",\
         $values[0],$values[1],$qval,$bval);\
       $zval = sprintf("VL.T %5.2f °C, RL.T %5.2f °C, %s",\
         $values[0],$values[1],$pval);\
    }\
  }\
readingsSingleUpdate($hash, "VL.T", $rval, 1);\
readingsSingleUpdate($hash, "RL.T", $tval, 1);\
readingsSingleUpdate($hash, "Pumpe", $pval, 1); \
readingsSingleUpdate($hash, "Pumpe.P", $qval, 1); \
readingsSingleUpdate($hash, "Bedarf", $bval, 1); \
readingsSingleUpdate($hash, "Status", $sval, 1);\
readingsSingleUpdate($hash, "reading", $xval, 1);\
$zval; }

ECMD Classdefinition Warmwasserkreis

Die zweite Datei definiert die FHEM-Readings für den Warmwasserkreis:

# Warmwasserkreis
get state cmd {"cyc broad getstatus_WW\n"}
get state expect ".*"
get state postproc { my ($rval,$tval,$bval,$pval,$xval,$zval);\
my $hash  = $defs{"%NAME"};\
 if( ($_ eq "")||($_ eq "no data stored") ){\
    $rval = "err";\
    $tval = "err";\
    $bval = "err";\
    $pval = "err";\
    $xval = "err";\
    $zval = "err";\
 }else{\
    my @values=split(' ',$_);\
    if( $values[1] < 15 ){\
       $rval = "err";\
       $tval = "err";\
       $bval = "err";\
       $pval = "err";\
       $xval = "err";\
       $zval = "err";\
    }else {\
       $rval = sprintf("%5.2f °C",$values[0]);\
       $tval = sprintf("%5.2f °C",$values[1]);\
       $bval = ($values[2] == 80) ? "ON (WW)" : "OFF";\
       $pval = ($values[3] == 1) ? "ON" : "OFF";\
       $xval = sprintf("%5.2f %5.2f %5.2f %d %d",\
        $values[0],0.0,$values[1],$values[2],$values[3]);\
       $zval = sprintf("SF1.T %5.2f °C, %s",\
        $values[0],$pval);\
    }\
  }\
$zval; }

ECMD Classdefinition Solarkreis

Die dritte Datei definiert die FHEM-Readings für den Solarkreis:

# Solarkreis
get state cmd {"cyc broad getstatus_SOL\n"}
get state expect ".*"
get state postproc { my ($rval,$pval,$qval,$lval,$yval,$xval,$zval);\
my $hash  = $defs{"%NAME"};\
 if( ($_ eq "")||($_ eq "no data stored") ){\
    $rval = "err";\
    $pval = "err";\
    $qval = "err";\
    $lval = "err";\
    $yval = "err";\
    $xval = "err";\
    $zval = "err";\
 }else{\
    my @values=split(' ',$_);\
    $rval = sprintf("%5.2f °C",$values[0]);\
    $pval = ($values[1] == 1)?"ON":"OFF";\
    $qval = ($values[1] == 1)?65:0;\
    $lval = sprintf("%5.2f %%",$values[2]);\
    $yval = sprintf("%d",$values[3]);\
    $xval = sprintf("%5.2f %d %5.2f %d",\
      $values[0],$qval,$values[2],$values[3]);\
    $zval = sprintf("Coll.T %5.2f °C, %s",\
      $values[0],$pval);\
 }\
readingsSingleUpdate($hash, "Coll.T", $rval, 1);\
readingsSingleUpdate($hash, "Pumpe", $pval, 1);\
readingsSingleUpdate($hash, "Pumpe.P", $qval." W", 1);\
readingsSingleUpdate($hash, "Load",  $lval, 1);\
readingsSingleUpdate($hash, "Yield", $yval, 1);\
readingsSingleUpdate($hash, "reading", $xval, 1);\
$zval; }

ECMD Classdefinition Heizkurve

Diese Klassendefinition muss in der bai00.cfg gespeichert (angehängt) werden. in diesem Beispiel wurde sie für die Vaillant Calormatic 430 definiert, bei einer Calormatic 470 muss der Text entsprechend geändert werden.

# HeizkurveSchreiben Calormatic 430, bai00.cfg
get HeizkurveSchreiben cmd {"write -c 430 Hc1HeatCurve ".Value("HeizkurveEinstellen")."\n"}
get HeizkurveSchreiben expect ".*\n\n"
get HeizkurveSchreiben postproc  { $_ }

Heizkurve schreiben

#fhem.cfg
define HeizkurveEinstellen dummy
attr HeizkurveEinstellen group Heizkurve_Einstellen
attr HeizkurveEinstellen icon temp_control
attr HeizkurveEinstellen room Vaillant,Heizung
attr HeizkurveEinstellen setList state:0.20,0.40,0.50,0.60,0.70,0.80,0.90,1.00,1.10,1.20,1.30,1.40,1.50,1.60,1.70
attr HeizkurveEinstellen webCmd state

define HeizkurveSchreiben_Click notify HeizkurveEinstellen {\
 fhem("get HeizkurveSchreiben HeizkurveSchreiben");;\
}
attr HeizkurveSchreiben_Click group heatingControl
attr HeizkurveSchreiben_Click room Vaillant

define HeizkurveSchreiben ECMDDevice bai00.class
attr HeizkurveSchreiben IODev EBUS
attr HeizkurveSchreiben group Heizkurve_Einstellen
attr HeizkurveSchreiben room Vaillant

Ein kleines Demo wie man via ECMD und eBus die Daten zurück in die Register der Therme (Calormatic) schreiben kann. Hier wird die Heizkurve verstellt. Ein Dummy wird definiert und über eine setList werden die verschiedenen Kurven vorgegeben. Dank setList kann es zu keinen unerlaubten Eingaben kommen. Über den notify wird die Heizkurve dann schließlich gesetzt.

Vorsicht: überlegt euch bitte gut was ihr zurück schreiben wollt, es kann unter Umständen gefährlich für eure Hardware oder Gesundheit werden (zB: Warmwasser auf über 60 Grad). Alles was hier durchgeführt wird, führt ihr auf eigene Verantwortung durch.

Wochenprogramme

Ein gerne benutztes Feature ist die Änderung der Zeitprogramme des Heizgerätes in FHEM. Die Visualisierung ist etwas komplexer weil alles x 7 ist und hier Steuerzeichen beim Zusammensetzen des Sendestrings vorkommen die nicht direkt übergeben werden können. Einzelne Timer können damit nicht geschrieben werden, daher wird bei jeder Timereingabe der komplette String geschrieben. Der Einfachheit halber und wegen der Übersicht sind nur 2 Tagesprogramme (Timer) im Beispielcode vorgesehen (die Calormatic kann 3).

#####################
#  Timer-Programme  #
#####################
get Mo cmd {"r -f hc1Timer.Monday\n"}
get Mo expect ".*\n\n"
get Mo postproc { Vaillant_Timer($_); }
get Di cmd {"r -f hc1Timer.Tuesday\n"}
get Di expect ".*\n\n"
get Di postproc { Vaillant_Timer($_); }
get Mi cmd {"r -f hc1Timer.Wednesday\n"}
get Mi expect ".*\n\n"
get Mi postproc { Vaillant_Timer($_); }
get Do cmd {"r -f hc1Timer.Thursday\n"}
get Do expect ".*\n\n"
get Do postproc { Vaillant_Timer($_); }
get Fr cmd {"r -f hc1Timer.Friday\n"}
get Fr expect ".*\n\n"
get Fr postproc { Vaillant_Timer($_); }
get Sa cmd {"r -f hc1Timer.Saturday\n"}
get Sa expect ".*\n\n"
get Sa postproc { Vaillant_Timer($_); }
get So cmd {"r -f hc1Timer.Sunday\n"}
get So expect ".*\n\n"
get So postproc { Vaillant_Timer($_); }
get ZeitfensterSchreibenMo cmd {"write -c 430 hc1Timer.Monday ".ReadingsVal("TimeMo","HHMM1",0) . chr(59) . ReadingsVal("TimeMo","HHMM2",0) . chr(59) . ReadingsVal("TimeMo","HHMM3",0) . chr(59) . ReadingsVal("TimeMo","HHMM4",0) . chr(59) . "24:00" . chr(59) . "24:00" . chr(59) . "selected\n"}
get ZeitfensterSchreibenMo expect ".*\n\n"
get ZeitfensterSchreibenMo postproc  { $_ }
get ZeitfensterSchreibenDi cmd {"write -c 430 hc1Timer.Tuesday ".ReadingsVal("TimeDi","HHMM1",0) . chr(59) . ReadingsVal("TimeDi","HHMM2",0) . chr(59) . ReadingsVal("TimeDi","HHMM3",0) . chr(59) . ReadingsVal("TimeDi","HHMM4",0) . chr(59) . "24:00" . chr(59) . "24:00" . chr(59) . "selected\n"}
get ZeitfensterSchreibenDi expect ".*\n\n"
get ZeitfensterSchreibenDi postproc  { $_ }
get ZeitfensterSchreibenMi cmd {"write -c 430 hc1Timer.Wednesday ".ReadingsVal("TimeMi","HHMM1",0) . chr(59) . ReadingsVal("TimeMi","HHMM2",0) . chr(59) . ReadingsVal("TimeMi","HHMM3",0) . chr(59) . ReadingsVal("TimeMi","HHMM4",0) . chr(59) . "24:00" . chr(59) . "24:00" . chr(59) . "selected\n"}
get ZeitfensterSchreibenMi expect ".*\n\n"
get ZeitfensterSchreibenMi postproc  { $_ }
get ZeitfensterSchreibenDo cmd {"write -c 430 hc1Timer.Thursday ".ReadingsVal("TimeDo","HHMM1",0) . chr(59) . ReadingsVal("TimeDo","HHMM2",0) . chr(59) . ReadingsVal("TimeDo","HHMM3",0) . chr(59) . ReadingsVal("TimeDo","HHMM4",0) . chr(59) . "24:00" . chr(59) . "24:00" . chr(59) . "selected\n"}
get ZeitfensterSchreibenDo expect ".*\n\n"
get ZeitfensterSchreibenDo postproc  { $_ }
get ZeitfensterSchreibenFr cmd {"write -c 430 hc1Timer.Friday ".ReadingsVal("TimeFr","HHMM1",0) . chr(59) . ReadingsVal("TimeFr","HHMM2",0) . chr(59) . ReadingsVal("TimeFr","HHMM3",0) . chr(59) . ReadingsVal("TimeFr","HHMM4",0) . chr(59) . "24:00" . chr(59) . "24:00" . chr(59) . "selected\n"}
get ZeitfensterSchreibenFr expect ".*\n\n"
get ZeitfensterSchreibenFr postproc  { $_ }
get ZeitfensterSchreibenSa cmd {"write -c 430 hc1Timer.Saturday ".ReadingsVal("TimeSa","HHMM1",0) . chr(59) . ReadingsVal("TimeSa","HHMM2",0) . chr(59) . ReadingsVal("TimeSa","HHMM3",0) . chr(59) . ReadingsVal("TimeSa","HHMM4",0) . chr(59) . "24:00" . chr(59) . "24:00" . chr(59) . "selected\n"}
get ZeitfensterSchreibenSa expect ".*\n\n"
get ZeitfensterSchreibenSa postproc  { $_ }
get ZeitfensterSchreibenSo cmd {"write -c 430 hc1Timer.Sunday ".ReadingsVal("TimeSo","HHMM1",0) . chr(59) . ReadingsVal("TimeSo","HHMM2",0) . chr(59) . ReadingsVal("TimeSo","HHMM3",0) . chr(59) . ReadingsVal("TimeSo","HHMM4",0) . chr(59) . "24:00" . chr(59) . "24:00" . chr(59) . "selected\n"}
get ZeitfensterSchreibenSo expect ".*\n\n"
get ZeitfensterSchreibenSo postproc  { $_ }

Dieses Beispiel ist für eine Vaillant Calormatic 430, bei einer Calormatic 470 müssen die entsprechenden Zeilen angepasst werden (write -c 430....) .

#########################################################
#
#                      Vaillant_Timer
# Datenstring = 03:30;19:30;20:00;20:00;20:00;20:00;Mo-Fr
#########################################################
# 99_myUtils.pm
sub Vaillant_Timer($)
{
 my @values=split(/[; ]/,$_);
 #-- suppress leading zero ?
 for(my $i=0;$i<7;$i++){ 
   $values[$i]=~s/^0//;
 }
 my $sval=sprintf("%s-%s",$values[0],$values[1]);
 $sval  .=sprintf(", %s-%s",$values[2],$values[3])
   if($values[2] ne $values[3]);
 $sval  .=sprintf(", %s-%s",$values[4],$values[5])
   if($values[4] ne $values[5]);
 return $sval;
}

Oben gezeigtes Beispiel benötigt den Vaillant_Timer (von Prof. Peter Henning). Dieser Code muss in die 99_myUtils.pm gespeichert werden. Unter diesem Link gibt es weiterreichende Informationen zu diesem Thema.

GAEBUS

GAEBUS ist ein Perl Modul welches es in FHEM ermöglicht sämtliche Daten des eBus bequem zu konfigurieren. Das Protokoll ist ebenso wie bei ECMD Telnet, aber die Einrichtung unterscheidet sich sehr stark und wird von den meisten Anwendern einfacher empfunden. Allerdings ist im derzeitigen Entwicklungsstand der GAEBUS noch nicht so flexibel wie ECMD. Das betrifft vor allem die Datenfilterung und Datenformatierung.

Eine genaue Installations- und Einrichtungsanleitung kann aus diesem Forums-Thread entnommen werden.

Den Diskussionsthread des Autors findet man hier.

FHEM Tablet UI (FTUI)

Die Tablet-UI ist ein ansprechendes HTML Frontend welches durch intensive Betreuung des Autors sehr gepflegt wird. Mit sogenannten Widgets kann hier auch für ungeübte schnell ein optisch ansprechendes Ergebnis erzielt werden. Die Tablet-UI stellt mit ihren Widgets direkt die Verbindung zu den Readings in Fhem her. Alle Messwerte die hier dargestellt werden sollen, müssen daher vorher in Fhem bereits definiert werden.

Der komplette Demo-Code der abgebildeten Seite kann hier downgeloadet werden: Tablet-UI

Tipps & Tricks

eBusd Bedeutung der Telegramme

Der ebusd wird entweder über ebusctl oder über telnet durch Klartextkommandos abgefragt, die lauten z.B. read -c broadcast outsidetemp.

In CSV-Dateien in /etc/ebusd wird festgelegt, in welche bzw. aus welcher binären Folge ein Kommando übersetzt wird. Konkret handelt es sich z.B. bei read -c broadcast outsidetemp um die Außentemperatur, die im Heizungssystem zyklisch als Broadcast gesendet wird und vom ebusd einfach mitgelesen wird.
Für unterschiedliche Heizungssysteme werden unterschiedliche CSV-Dateien benötigt.

Für die Übersetzung der binären Daten in den Klartext ist es notwendig die entsprechenden Konfigurationsdateien(CSV-Files) zu installieren. Den aktuellen Stand dieser Dateien findet ihr im GIT von John.

Desweiteren kann der eBusd gestartet werden, und zwar mit den Optionen -f (läuft im Vordergrund) und --loglevel debug (alles wird geloggt). Diese Optionen produzieren Unmengen an Daten und damit werden auch alle empfangenen Telegramme protokolliert, z.B.

10feb5160301f00d44

Hierin bedeutet

Byte	Bedeutung	hier
0x10	Adresse des Senders	Zentrale
0xfe	Adresse des Empfängers	Alle Geräte
0xb5	Herstellercode	Vaillant
0x16	Klasse des Kommandos	Broadcast
0x03	Anzahl Datenbytes	3
0x01	Bedeutung des Wertes	outsidetemp = Außentemperatur
0xf0	LSB des Wertes	240
0x0d	MSB des Wertes	12
0x44	CRC

Damit ergibt sich in diesem Falle eine Außentemperatur von (12*256 + 240)/256 = 12,9375 Grad Celsius. In der zugehörigen CSV-Datei wird dem ebusd diese Übersetzung mitgeteilt durch eine Zeile der Form

u,broadcast,outsidetemp,Außentemperatur,,FE,B516,01,temp2,m,D2B,,°C,Temperatur

Diese CSV-Dateien können z.B. mit OpenOffice aus einem Spreadsheet generiert werden, indem dieses als CSV-Datei mit Separator "," gespeichert wird.

Bei einem vollkommen unbekannten Heizungssystem sollte man den Hersteller fragen, welche Codes er verwendet
Für Vaillant- und Wolf- Heizungssysteme liegen in dem oben genannten Verzeichnis ein paar Beispiele vor, die man als Ausgangspunkt nehmen kann.

Serieller Konverter

Es hat sich als nicht praktikabel erwiesen, den eBus mit einem Pegelwandler direkt an den seriellen GPIO-Port des Raspberry Pi anzuschließen. Die ständig einlaufenden Synchronisationssignale auf dem eBus, sowie die interne Verarbeitung der GPIO-Signale im Raspberry führen zu einer intolerablen Latenz, d.h., die eBus-Signale kommen verspätet bei der Software eBusd an (bis zu 90 Minuten wurden beobachtet). Stattdessen sollte grundsätzlich ein Seriell-USB-Konverter verwendet werden und der Raspberry Pi über einen USB-Port mit dem eBus verbunden werden.

USB Device und Port unter Linux ermitteln

Die einfachste Art den USB Device zu ermitteln erfolgt direkt am Raspberry Pi mit dem Befehl "lsusb".

pi@raspberry2 ~ $ lsusb
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
Bus 001 Device 004: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC

in diesem Beispiel ist das der Device 004, dieser FT232 lauscht am eBus und ist mit dem eBus-Konverter verbunden.

Der USB Port kann mit der folgenden Kommandozeile ermittelt werden:

sudo dmesg | grep -i tty

Die Ausgabe sieht wie folgt aus:

[553999.530995] usb 1-1.3: FTDI USB Serial Device converter now attached to ttyUSB0

eBusd

Prüfen der eBusd Konfigurationsdateien

Mit dem Parameter "--checkconfig --scanconfig" kann die Installation der benutzten CSV Dateien am Raspberyy Pi überprüft werden. Vor allem wird hier angezeigt wieviele Messages übersetzt werden.

pi@raspberry2 ~ $ ebusd --checkconfig --scanconfig
2016-01-22 17:14:12.619 [main notice] Performing configuration check...
2016-01-22 17:14:19.336 [main notice] found messages: 4440 (416 conditional on 89 conditions, 2 poll, 64 update)

pi@raspberry2 ~ $ ebusctl info
version: ebusd 2.0.0ea7efc
signal: acquired
symbol rate: 24
masters: 3
messages: 426
address 03: master #3
address 08: slave #3, scanned "MF=Vaillant;ID=BAI00;SW=0518;HW=7401", loaded  "vaillant/08.bai.HW7401.csv"
address 10: master #6
address 15: slave #6, scanned "MF=Vaillant;ID=43000;SW=0215;HW=2002", loaded "vaillant/15.430.csv"

Info hingegen zeigt genau welche CSV Dateien geladen worden sind und ihre Soft- und Hardewareversion.

Bedeutung von "unknown MS" in der eBusd Logdatei

Der Autor des eBus Dämons ist ständig bemüht die Geräte der unterschiedlichen Hersteller alle zu erfassen und so die Konfigurationsdateien zu ergänzen. Je nach Hard- und Softwarekonfiguration können Broadcast Meldungen vom eBus kommen die in der _broadcast.csv noch nicht übersetzt werden.

2015-12-30 21:48:57.662 [update notice] unknown MS cmd: 1008b5110101 / 09404210004a620000ff
2015-12-30 21:48:59.670 [update notice] unknown BC cmd: 10feb516080001492130120315
2015-12-30 21:48:59.923 [update notice] unknown MS cmd: 1008b512020064 / 00
2015-12-30 21:49:01.711 [update notice] unknown MS cmd: 1008b5100900003c7affff00ff00 / 0101

Diese Meldungen haben in der Regel für den weiteren Verlauf der Kommunikation über den eBus keinen Einfluß und ist keine Fehlfunktion der Schaltung oder Platine!

Bedeutung von "signal lost"

pi@raspberrypi /etc/init.d $ sudo ebusd -f -c /tmp --logareas bus --loglevel info -d /dev/ttyUSB0
2016-01-18 22:38:56.348 [bus notice] signal acquired
2016-01-18 22:38:56.477 [bus notice] new master 10, master count 2
2016-01-18 22:38:56.481 [bus notice] new master 3f, master count 3
2016-01-18 22:39:02.051 [bus error] signal lost

Bei dieser Meldung verliert der USB Konverter nach 20-Sekunden die Verbindung zum Raspberry Pi und produziert dann den Logeintrag. Lösungvorschlag

ERR: unable to load

2016-01-17 19:04:03.961 [main error] unable to load scan config 08: no file from /etc/ebusd/vaillant with prefix 08. matches ID "bai00", SW0604, HW5502

Ebusd wird gestartet, findet aber ein Konfigurations File (CSV) nicht.

Die eBusd Konfigurationsdateien könne nach diesem Vorgehen installiert werden. Die Konfigurationsdateien aus dem Git neu laden und installieren. Lösungvorschlag

ERR: duplicate Entry

ERR: End of input reached

Die CSV Dateien wurden fehlerhaft installiert oder sind defekt! Eine Neuinstallation dieser Dateien ist erforderlich!

Error reading "/etc/ebusd/vaillant/05.vd3.csv" line 1 field 1 value "05.vd4.csv": ERR: end of input reached
Erroneous item is here:
05.vd4.csv
 ^
Error reading "/etc/ebusd/vaillant/15.hep.csv" line 1 field 1 value "15.sdr_p.csv": ERR: end of input reached
Erroneous item is here:
15.sdr_p.csv
 ^

BUS ERR send to 15

2016-01-16 19:20:28.575 [bus notice] new master 03, master count 4
2016-01-16 19:20:28.575 [update notice] unknown MS cmd: 1008b513020508 / 00
2016-01-16 19:20:29.413 [update notice] unknown MS cmd: 100ab504010d / 054201008037
2016-01-16 19:20:32.398 [bus error] send to 08: ERR: read timeout, retry
2016-01-16 19:20:33.005 [bus error] send to 08: ERR: read timeout, retry
2016-01-16 19:20:33.613 [bus error] send to 08: ERR: read timeout, retry
2016-01-16 19:20:34.859 [bus error] send to 08: ERR: read timeout
2016-01-16 19:20:34.859 [main error] scan config 08 message: ERR: read timeout
2016-01-16 19:20:37.017 [main notice] read common config file /etc/ebusd/vaillant/scan.csv
2016-01-16 19:20:37.019 [main notice] read common config file /etc/ebusd/vaillant/broadcast.csv

Diese Fehlermeldung (read timeout) kann verschiedene Ursachen haben, meist liegt der Fehler in einer fehlerhaften Verkabelung. Lösungsvorschlag

Systemarchitektur / Systemdesign

Es muss sich jeder vorher überlegen, ob man für den eBus einen eigenen Rechner Raspberry Pi nimmt, oder auf der bestehenden FHEM Installation laufen lassen will. Eine Trennung bietet mehrere Vorteile die dann speziell im Testbetrieb den normalen Smart-Home Betrieb nicht beinflussen.

Hier eine Konfiguration von Fhem und das Zusammenspiel mit eBusd via ECMD. Das soll aber jeder so handhaben wie es am Besten in das eigene Konzept passt.

Werkzeuge / Tools

PSPad

Pspad ist ein besonders auf Programmierer zugeschnittener unicode-fähiger Editor für Microsoft Windows, welcher in der Lage ist auch per FTP die Dateien direkt zu editieren und zu schreiben ohne den Umweg sie vorher kopieren zu müssen! Besonders wichtig ist neben einem Syntaxhighlighter das er Linuxkonform ist und die Steuerzeichen am Zeilenende richtig interpretiert.

Hier zwei wichtige Infos zur Einrichtung des PSPad.

Im Tab "FTP" unten mit der rechten Maustaste auf die weiße Fläche klicken und in dem neu geöffneten Fenster "FTP verbinden" wählen.

Es öffnet sich ein Fenster mit den Verbindungsdaten des FTP Servers. Nicht vergessen, das unten markierte Häckchen "Verbindung halten ..." zu markieren. Es wird dann alle 60 Sekunden ein NOOP Signal gesendet und die Verbindung wird nach einem Timeout nicht jedes Mal beendet.

Filezilla

Ebenso wie PSPad wird es für viele Arbeiten am Raspberry und eBusd eine Erleichterung sein manche Dateien direkt zu kopieren oder am PC zu sichern. Filezilla beherrscht ebenfalls das FTP Protokoll und speichert die Verbindungsdaten in einem Profil.

Links oben öffnet man den Servermanager und wählt (links unten) "neuer Server". Man gibt die Verbindungsdaten des Raspberry ein und drückt "speichern". Das Verbindungs Profil steht nun im Servermanager als "Raspberry" zur Verfügung und die Verbindung kann nun mit einem Doppelklick geöffnet werden. Dateien können nun durch einfaches Drag & Drop zwischen linken (lokales Laufwerk am PC) und rechten Dateifenster (in diesem Fall Raspberry) bequem kopiert werden.

Putty

PuTTY ist ein SSH Client welcher neben Secure Shell auch Telnet, Remote login und eine serielle Schnittstelle enthält. Als Tipp sei hier erwähnt, dass hier einige sehr nützliche Features zur Verfügung stehen:

rechte Maustaste = Zwischenablage wird ins Terminalfenster kopiert
Text mit Maus markieren = in Zwischenablage kopieren
Pfeiltasten Auf/Ab = die letzten Befehle wiederholen, durch die Liste steppen

Ebenso können mit Putty mehrere Terminalfenster parallel geöffnet werden. Diese Methode ist bei der Kalibrierung des Potis im Raw-Modus sehr von Vorteil.

Weiterführende Links

Diskussionsthread aus dem Forum: