eBus Schaltung in Betrieb nehmen

[Prof. Dr. Peter Henning]

Das Problem ist, dass beim "naiven" Öffnen der CSV-Datei dezimale Zahlen als Zahlen und hexadezimale Zahlen als String gelesen werden. Besser ist es also, mit einem Spreadsheet zu arbeiten, dessen Spalten ordentlich formatiert sind - und dann nur den Export in eine CSV-Datei zu machen.

LG

pah

[FunkOdyssey]

Ich bräuchte mal einen Tipp, denn ich komme mit meinem selbst zusammengelötetem eBus-Adapter nicht weiter.

Ich habe das Interface (mit und ohne angeschlossenem eBus) folgendenmaßen getestet:

Code Auswählen Erweitern

service ebusd stop
ebusd -f -c /tmp --logareas bus --loglevel info -d /dev/ttyUSB0
ebusctl raw

Es erscheint in beiden Terminalfenster absolut gar nichts. Keine weiteren Zeilen. Kein <AA oder sonstiges.

Erst als ich versehentlich den U1 am Pin 6 berührt habe (kein Kurzschluss - nur berühren), erschienen mehrere der folgenden Zeilen:

Code Auswählen Erweitern

2017-06-24 19:55:48.097 [bus notice] <00

Ich habe es mit einem neu installiertem Raspbian Jessie ausprobiert. Insgesamt habe ich zwei FTDI-Adapter (der "rote" mit dem Mini-USB-Anschluss FT232RL und der "eingeschweißte" anderer China-Bauart als USB-Stecker PL2303HX) ausprobiert.

Die Bestückung habe ich geprüft. Die Bauteile sind alle korrekt angeschlossen. Die Verlötung habe ich mittlerweile zweimal überprüft.

Ich habe nicht wirklich einen Plan, wie ich was durchmessen soll.

Wie könnte ich den Fehler nun eingrenzen? Habt ihr einen Tipp?

Die <AA in ebusd sollten doch auch erscheinen, wenn ich den Adapter nicht am Bus angeschlossen habe, oder? Das macht mir das Testen einfacher.

[john30]

Ich bräuchte mal einen Tipp, denn ich komme mit meinem selbst zusammengelötetem eBus-Adapter nicht weiter.

Ich habe das Interface (mit und ohne angeschlossenem eBus) folgendenmaßen getestet:

Code Auswählen Erweitern

service ebusd stop
ebusd -f -c /tmp --logareas bus --loglevel info -d /dev/ttyUSB0
ebusctl raw

Es erscheint in beiden Terminalfenster absolut gar nichts. Keine weiteren Zeilen. Kein <AA oder sonstiges.

Dann würde ich darauf tippen, dass Du Rx und Tx von Interface zu USB Adapter vertauscht hast.

Die <AA in ebusd sollten doch auch erscheinen, wenn ich den Adapter nicht am Bus angeschlossen habe, oder? Das macht mir das Testen einfacher.

Nein, die erscheinen nur, wenn der eBus auch angeschlossen ist.

[FunkOdyssey]

Hmm, ich habe es gerade vorsichtshalber mal geprüft und auch testweise getauscht. Daran lag es leider nicht.

Ich habe einen RasPi B+ mit Raspbian Jessie, eBus 2.4 im Einsatz.
Den eBus-Adapter habe ich an exakt folgenden USB-To-TTL-Adapter angeschlossen.

Die Anschlussklemme habe ich an den eBus einer Renovent Excellent 400 Lüftungsanlage angeschlossen. An den gleichen PINs ist auch die Digitale Fernbedienung angeschlossen. Im Lüftungsgerät ist die Steckverbindung auf eBus eingestellt (es geht auch OpenTherm).

Leider erscheinen weder "<AA" noch sonst irgendetwas im Terminalfenster (RAW-Logging).

USB-Kabel habe ich getauscht. RasPi-Netzteile auch.
Die eBus-Leitungslänge kann ich auch ausschließen, da ich mich heute direkt zur Lüftungsanlage bewegt habe.

Nun bin ich ein wenig ratlos.

Wie bereits erwähnt habe ich vom Schaltplan prüfen bzw. Platine nachmessen absolut keine Ahnung. Ich habe zwar ein Multimeter griffbereit - kann damit aber nicht wirklich gut umgehen.

Ich habe vorsorglich mal Fotos von meinem eBus-Adapter erstellt. Vielleicht seht ihr ja etwas und könnt mir weiterhelfen.

Ich würde mich sehr freuen. Vielen Dank.

[john30]

Wie bereits erwähnt habe ich vom Schaltplan prüfen bzw. Platine nachmessen absolut keine Ahnung. Ich habe zwar ein Multimeter griffbereit - kann damit aber nicht wirklich gut umgehen.

Hast Du denn das Poti justiert?

[FunkOdyssey]

Ehrlich gesagt: noch nicht wirklich.
Ich habe ganz vorsichtig nach rechts gedreht und wieder zurück.
Ich bin davon ausgegangen, dass ich auch ohne Justierung wenigstens irgendetwas sehen sollte und ich das Finetuning dann danach mache. Ist doch so, oder?

Nachtrag:
Wenn ich hier und/oder in deinem Wiki schaue, dann sollte wenigstens irgendein Output angezeigt werden. Darum habe ich erst einmal die Finger vom Poti gelassen.

[cs-online]

Wenn das Poti grob falsch steht, dann kommt gar nichts an Daten bei raus...

Grüße

Christian

[Paul.baumann]

Hallo eBus-Profis,

seit zwei Tagen ist meine neue Heizung installiert und ich habe nun auch einen eBus.

Ich habe das Interface aus dem WIKI nachgebaut und in Betrieb genommen. Nach dem Abgleich des Potis bekomme ich sauber die <aa Sequenzen und nach dem Start von ebusd empfange ich auch Protokolle. Allerdings werden die initialen Scans mit read timeout beendet, so dass die Teilnehmer am eBus nicht identifiziert werden und auch keine Konfigurationsdateien zugeordnet werden.

Code Auswählen Erweitern

pi@raspberrypi:/etc/ebusd/vaillant $ ebusctl info
version: ebusd 2.4.79708d2
signal: acquired
symbol rate: 23
reconnects: 0
masters: 3
messages: 1
conditional: 0
poll: 0
update: 0
address 03: master #11
address 08: slave #11, scanned
address 10: master #2
address 31: master #8, ebusd
address 36: slave #8, ebusd

Code Auswählen Erweitern

2017-07-01 14:06:49.153 [main notice] ebusd 2.4.79708d2 started
2017-07-01 14:06:49.222 [bus notice] signal acquired
2017-07-01 14:06:49.245 [main notice] found messages: 11 (0 conditional on 0 conditions, 0 poll, 4 update)
2017-07-01 14:06:55.533 [bus notice] new master 10, master count 2
2017-07-01 14:06:55.584 [bus notice] new master 03, master count 3
2017-07-01 14:06:55.585 [update notice] unknown MS cmd: 1008b5110101 / 09756f4015ff6e0000ff
2017-07-01 14:06:55.856 [update notice] unknown MS cmd: 1008b51009000000ffffff010000 / 0101
2017-07-01 14:06:59.221 [main notice] starting initial scan for fe
2017-07-01 14:06:59.254 [bus error] send to fe: ERR: read timeout, retry
2017-07-01 14:06:59.317 [bus error] send to fe: ERR: read timeout, retry
2017-07-01 14:06:59.381 [bus error] send to fe: ERR: read timeout, retry
2017-07-01 14:06:59.445 [bus error] send to fe: ERR: read timeout, retry
2017-07-01 14:06:59.509 [bus error] send to fe: ERR: read timeout, retry
2017-07-01 14:06:59.572 [bus error] send to fe: ERR: read timeout, retry
2017-07-01 14:06:59.636 [bus error] send to fe: ERR: read timeout, retry
2017-07-01 14:06:59.701 [bus error] send to fe: ERR: read timeout, retry
2017-07-01 14:06:59.765 [bus error] send to fe: ERR: read timeout, retry
2017-07-01 14:06:59.828 [bus error] send to fe: ERR: read timeout, retry
2017-07-01 14:06:59.892 [bus error] send to fe: ERR: read timeout, retry
2017-07-01 14:06:59.956 [bus error] send to fe: ERR: read timeout
2017-07-01 14:06:59.957 [main error] initial scan failed: ERR: read timeout
2017-07-01 14:07:00.021 [bus error] send to 08: ERR: read timeout, retry
2017-07-01 14:07:00.084 [bus error] send to 08: ERR: read timeout, retry
2017-07-01 14:07:00.148 [bus error] send to 08: ERR: read timeout, retry
2017-07-01 14:07:00.212 [bus error] send to 08: ERR: read timeout, retry
2017-07-01 14:07:00.276 [bus error] send to 08: ERR: read timeout, retry
2017-07-01 14:07:00.340 [bus error] send to 08: ERR: read timeout, retry
2017-07-01 14:07:00.404 [bus error] send to 08: ERR: read timeout, retry
2017-07-01 14:07:00.468 [bus error] send to 08: ERR: read timeout, retry
2017-07-01 14:07:00.532 [bus error] send to 08: ERR: read timeout, retry
2017-07-01 14:07:00.595 [bus error] send to 08: ERR: read timeout, retry
2017-07-01 14:07:00.659 [bus error] send to 08: ERR: read timeout, retry
2017-07-01 14:07:00.724 [bus error] send to 08: ERR: read timeout
2017-07-01 14:07:00.724 [main error] scan config 08 message: ERR: read timeout
2017-07-01 14:07:02.738 [bus error] send to 15: ERR: read timeout, retry
2017-07-01 14:07:02.802 [bus error] send to 15: ERR: read timeout, retry
2017-07-01 14:07:02.865 [bus error] send to 15: ERR: read timeout, retry
2017-07-01 14:07:02.930 [bus error] send to 15: ERR: read timeout, retry
2017-07-01 14:07:02.994 [bus error] send to 15: ERR: read timeout, retry
2017-07-01 14:07:03.058 [bus error] send to 15: ERR: read timeout, retry
2017-07-01 14:07:03.121 [bus error] send to 15: ERR: read timeout, retry
2017-07-01 14:07:03.185 [bus error] send to 15: ERR: read timeout, retry
2017-07-01 14:07:03.251 [bus error] send to 15: ERR: read timeout, retry
2017-07-01 14:07:03.314 [bus error] send to 15: ERR: read timeout, retry
2017-07-01 14:07:03.377 [bus error] send to 15: ERR: read timeout, retry
2017-07-01 14:07:03.441 [bus error] send to 15: ERR: read timeout
2017-07-01 14:07:03.441 [main error] scan config 15 message: ERR: read timeout
2017-07-01 14:07:05.656 [update notice] unknown MS cmd: 1008b5110101 / 09756e4015ff6e0000ff
2017-07-01 14:07:05.927 [update notice] unknown MS cmd: 1008b51009000000ffffff010000 / 0101
2017-07-01 14:07:06.198 [update notice] unknown MS cmd: 1008b5040100 / 0a03070714010706174015
2017-07-01 14:07:06.454 [update notice] unknown MS cmd: 1008b5110102 / 06033c9646826e
2017-07-01 14:07:06.693 [update notice] unknown BC cmd: 10feb516080006071401070617
2017-07-01 14:07:06.964 [update notice] unknown MS cmd: 1008b5110100 / 08ab030e001f000080
2017-07-01 14:07:07.173 [update notice] unknown BC cmd: 10feb51603014015
2017-07-01 14:07:15.722 [update notice] unknown MS cmd: 1008b5110101 / 09756e4015ff6e0000ff
2017-07-01 14:07:15.981 [update notice] unknown MS cmd: 1008b51009000000ffffff010000 / 0101
2017-07-01 14:07:25.792 [update notice] unknown MS cmd: 1008b5110101 / 09756e4015ff6e0000ff
2017-07-01 14:07:26.051 [update notice] unknown MS cmd: 1008b51009000000ffffff010000 / 0101
2017-07-01 14:07:35.850 [update notice] unknown MS cmd: 1008b5110101 / 09756e4015ff6e0000ff
2017-07-01 14:07:36.119 [update notice] unknown MS cmd: 1008b51009000000ffffff010000 / 0101
2017-07-01 14:07:36.375 [update notice] unknown MS cmd: 1008b5110102 / 06033c9646826e
2017-07-01 14:07:45.869 [update notice] unknown MS cmd: 1008b5110101 / 09746e4015ff6e0000ff
2017-07-01 14:07:46.140 [update notice] unknown MS cmd: 1008b51009000000ffffff010000 / 0101
2017-07-01 14:07:55.939 [update notice] unknown MS cmd: 1008b5110101 / 09746e4015ff6e0000ff
2017-07-01 14:07:56.209 [update notice] unknown MS cmd: 1008b51009000000ffffff010000 / 0101
2017-07-01 14:08:06.007 [update notice] unknown MS cmd: 1008b5110101 / 09746e7015ff6e0000ff
2017-07-01 14:08:06.279 [update notice] unknown MS cmd: 1008b51009000000ffffff010000 / 0101
2017-07-01 14:08:06.538 [update notice] unknown MS cmd: 1008b5040100 / 0a03070814010706177015
2017-07-01 14:08:06.793 [update notice] unknown MS cmd: 1008b5110102 / 06033c9646826e
2017-07-01 14:08:07.032 [update notice] unknown BC cmd: 10feb516080007081401070617

Wenn ich nun die Heizung neu starte, erkennt der Dämon die Teilnehmer am eBus und kann auch erste Konfigurationen laden. Auch habe ich nun dekodierte Telegrammeinträge im Protokoll.

Code Auswählen Erweitern

pi@raspberrypi:/etc/ebusd/vaillant $ ebusctl info
version: ebusd 2.4.79708d2
signal: acquired
symbol rate: 108
reconnects: 0
masters: 3
messages: 198
conditional: 3
poll: 0
update: 4
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0202;HW=9602", loaded "vaillant/08.bai.HW9602.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0419;HW=4603"
address 31: master #8, ebusd
address 36: slave #8, ebusd


Code Auswählen Erweitern

2017-07-01 14:28:33.704 [update notice] update bai Status02 QQ=10: auto;60;75.0;70;65.0
2017-07-01 14:28:43.233 [update notice] update bai Status01 QQ=10: 56.0;53.5;21.625;-;54.5;off
2017-07-01 14:28:53.304 [update notice] update bai Status01 QQ=10: 55.5;54.0;21.625;-;54.5;off
2017-07-01 14:28:53.571 [update notice] update bai Mode QQ=10: standby


Alles in Allem sieht das denke ich schon mal gut aus.

Allerdings bleibt die Frage, warum ich die Timeouts bei manuellen Anfragen (z.B. ebusctl scan) bekomme?


Paul

[john30]

Allerdings bleibt die Frage, warum ich die Timeouts bei manuellen Anfragen (z.B. ebusctl scan) bekomme?

entweder kann dein Interface generell nichts auf den Bus schreiben, oder du hast das latency Problem.
Rausfinden kannst du das, indem du das raw logging aktivierst (--lograwdata=bytes auf dem aktuellen ebusd 3.0pre, bei 2.4 war es glaub ich einfach nur  --lograwdata).
in der Ausgabe prüfen, ob ein von ebusd geschriebenes byte (>...) auch wieder vom Bus gelesen wird (<...) und wie hoch die zeitliche Verzögerung ist.

[Paul.baumann]

entweder kann dein Interface generell nichts auf den Bus schreiben, oder du hast das latency Problem.
Rausfinden kannst du das, indem du das raw logging aktivierst (--lograwdata=bytes auf dem aktuellen ebusd 3.0pre, bei 2.4 war es glaub ich einfach nur  --lograwdata).
in der Ausgabe prüfen, ob ein von ebusd geschriebenes byte (>...) auch wieder vom Bus gelesen wird (<...) und wie hoch die zeitliche Verzögerung ist.

Danke, so sieht es mit --lograwdata aus:

Code Auswählen Erweitern

2017-07-02 10:01:16.341 [bus notice] <31
2017-07-02 10:01:16.388 [bus notice] <aa
2017-07-02 10:01:16.390 [bus notice] >31
2017-07-02 10:01:16.400 [bus notice] scan 61 timed out (145 slaves left)
2017-07-02 10:01:16.404 [bus notice] <31
2017-07-02 10:01:16.451 [bus notice] <aa
2017-07-02 10:01:16.453 [bus notice] >31
2017-07-02 10:01:16.463 [bus notice] scan 62 timed out (144 slaves left)
2017-07-02 10:01:16.468 [bus notice] <31

Ist hier etwas auffällig? Ich habe mal mit --latency=15000 gestartet, augenscheinlich sieht es besser aus.



Paul

[john30]

Ich habe mal mit --latency=15000 gestartet, augenscheinlich sieht es besser aus.

Ist der serial Adapter via USB oder Netzwerk angebunden?
Via USB könntest (und solltest) Du mit setserial low_latency aktivieren, sonst klappt die Kommunikation nicht wirklich gut. Oder ebusd 3.0pre nutzen, der macht das gleich selbst.

[Paul.baumann]

Ist der serial Adapter via USB oder Netzwerk angebunden?

Via USB.

Oder ebusd 3.0pre nutzen, der macht das gleich selbst.

Dass die neueren Versionen low_latency aktivieren, hatte ich auch schon gelesen. Allerdings nutze ich seit gestern die 3.0pre:

Code Auswählen Erweitern

version: ebusd 3.0pre.p20170701
signal: acquired
symbol rate: 23
reconnects: 1
masters: 3
messages: 209
conditional: 3
poll: 0
update: 8
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0202;HW=9602", loaded "vaillant/08.bai.HW9602.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0419;HW=4603"
address 31: master #8, ebusd
address 36: slave #8, ebusd


Paul

[_Cyber_]

niemand hier mit einem übrigen PCB? 

[Axel21]

Hallo zusammen,

ich bin neu hier und möchte gerne die ebus-Konverter-Schaltung aufbauen. Es wurde VIEL Arbeit hier in Hardware und Foren hineingesteckt und ich habe durch das Wiki und durch 3 andere Foren viele Tipps gesehen, vielen Dank – ich bin gespannt wie es läuft.

Mein Stand:
1.
Es gibt ein Platine (V. 1.6) mit einem Abgleichpotentiometer. Diese ist bewährt und funktioniert. Im Moment (16-07-2017) gibt es keine Sammelbestellung mehr und keiner hat eine übrige Platine abzugeben.

2.
Eine Platine könnte ich selber herstellen lassen, dazu benötige ich das Gerberfile.
Der gefundene Link dazu http://forum.fhem.de/index.php/topic,45127.msg370647.html#msg370647 führt mich aber nicht weiter.

3.
Ich beabsichtige daher, zunächst einmal die Schaltung auf meinem Breadboard aufzubauen.

4.
Die Stückliste bei Reichelt enthält kein Trimpotentiometer. Dieses muss ich selber hinzufügen und werde dazu ein breadboard-taugliches nehmen.

5.
Beim Suchen, warum das Poti auf der Stückliste fehlt, bin ich auf Informationen gestoßen, dass es eine neue Platine gibt, die gar kein Poti mehr benötigt und sich selbst abgleicht. Ich konnte dazu aber keine weiteren Informationen finden, also werde ich die bekannte Schaltung wählen.

Nun meine Fragen:

A)
Sind die obigen Infos korrekt oder habe ich etwas übersehen?

B)
Statt eines FTDI- USB Konverters möchte ich die RXD und TXD direkt an einen Raspberry *2*, also einen RASP mit richtigem UART anschließen. Dazu muss ich softwareseitig die Konsole abstellen. Hardwareseitig muss ich den Empfangspegel der Schaltung V1.6 mit einem Spannungsteiler auf 3,3 V Niveau bringen und sendeseitig mal schauen, ob ich die 3,3 V ausreichen das NAND-Gatter zu steuern, ggf. zwei Transistoren dazwischenzuschalten.
Liegen hier Erfahrungen vor?
(Hintergrund dieser Idee: Ich hatte einen kommerziellen EBUS->USB Wandler und hatte zu viele read-Error und möchte diese durch den direkten Anschluss an eine echte USB Schnittstelle vermeiden. Dann kann ich dies als Ursache ausschließen. Dann bliebe als Alternative noch die lange Leitung vom Keller bis ins OG ist, die dafür verantwortlich sein könnte.)

Vielen Dank für Eure Antworten!

Axel

[john30]

A)
Sind die obigen Infos korrekt oder habe ich etwas übersehen?

nach kurzem Überfliegen würde ich sagen, dass ja.

B)
Statt eines FTDI- USB Konverters möchte ich die RXD und TXD direkt an einen Raspberry *2*, also einen RASP mit richtigem UART anschließen. Dazu muss ich softwareseitig die Konsole abstellen. Hardwareseitig muss ich den Empfangspegel der Schaltung V1.6 mit einem Spannungsteiler auf 3,3 V Niveau bringen und sendeseitig mal schauen, ob ich die 3,3 V ausreichen das NAND-Gatter zu steuern, ggf. zwei Transistoren dazwischenzuschalten.
Liegen hier Erfahrungen vor?
(Hintergrund dieser Idee: Ich hatte einen kommerziellen EBUS->USB Wandler und hatte zu viele read-Error und möchte diese durch den direkten Anschluss an eine echte USB Schnittstelle vermeiden. Dann kann ich dies als Ursache ausschließen. Dann bliebe als Alternative noch die lange Leitung vom Keller bis ins OG ist, die dafür verantwortlich sein könnte.)

ich würde dir von der Verwendung der RPi UART abraten, da wegen der hohen Latenz der Buszugriff dauerhaft nicht richtig funktionieren kann. Aber wenn Du mit arbitration loss und derlei Fehlern, die durch eine 5 EUR Investition auszumerzen wären, kein Problem hast, dann go for it