EBUS: Unterschied zwischen den Versionen
| Zeile 321: | Zeile 321: | ||
interval = 5 | interval = 5 | ||
besetzt. Ferner wird die Datei /etc/watchdog.d/ebusd angelegt mit dem Inhalt | besetzt. Ferner wird die Datei /etc/watchdog.d/ebusd angelegt mit dem Inhalt | ||
<source lang="bash"> | |||
#!/bin/sh | #!/bin/sh | ||
# description: watchdog helper file for ebusd | # description: watchdog helper file for ebusd | ||
| Zeile 351: | Zeile 352: | ||
;; | ;; | ||
esac | esac | ||
</source> | |||
=Visualisierung und Steuerung= | =Visualisierung und Steuerung= | ||
Version vom 23. Januar 2016, 09:38 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 downgeloadet 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 genaue 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.
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:
[ ok ] Starting ebusd: ebusd.
die einen erfolgreichen Start des Dienstes signalisiert.
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 Raspberry Pi nach der beiliegenden Anleitung übersetzt und installiert. Wichtigste Bestandteile der Installation sind
ebusd - das eigentliche Programm zur Kommunikation mit dem EBUS ebusctl - ein Programm zur lokalen Ansteuerung des ebusd Das Verzeichnis /etc/ebusd => Alle hier liegenden Dateien im CSV(Comma Separated Value)-Format werden beim Start des ebusd eingelesen und als Kommandos für das Heizungsystem verwendet. Die Datei /etc/default/ebusd mit Startoptionen für den ebusd.
Als Software kommt auf dem Raspberry Pi der ebusd = eBus-Dämon zum Einsatz (aktuell im Januar 2016 die Version 2.0).
Wichtigste Bestandteile 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 drei 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 Installation
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("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 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);\
}\
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
TBD
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. cyc broad OutTemp.
- In einer CSV-Datei in /etc/ebusd muss festgelegt werden, in welche bzw. aus welcher binären Folge dieses Kommando übersetzt wird. Konkret handelt es sich z.B. bei cyc broad OutTemp 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 -l All (Alle Daten werden geloggt). Diese Optionen produzieren Unmengen an Daten, und zwar immer in Form von Telegrammen der Art
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 | OutTemp = 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
c;broad;OutTemp;Aussentemperatur;;FE;B516;3;01;1;temp;md;2,3;d2b;1.0;°C;-;-;;;;;;;;;;;;;;;;;;;;;;;;
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 Ausfagbe 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: