eBus Schaltung in Betrieb nehmen

[Tstolzmann]

Ich habe drei FTDI Module ausprobiert und alle drei haben zwischen GND und TXD und RXD 5V ist das richtig? Gemessen habe USB Kabel im Raspberry und FTDI ohne EBus Platine dahinter.
Wenn nicht welches FTDI Modul soll ich kaufen, habe auch schon eins gekauft was im ersten Thread verwendet wurde.

[pc1246]

Hallo
Da wir ja leider etwas raten muessen, habe ich mal eine Grafik angehaengt, wie ich vermute, dass es bei dir aussieht. Wenn Dein Regler in der Therme steckt, dann ist der intern irgendwo angeschlossen, evtl. am eBus, evtl. auch an einem 2. eBus. Wenn er an einem 2. haengt, dann kann es sein, dass die Telegramme nur dort rumschwirren.
Es waere also gut, wenn du uns einfach mal Deine Konfiguration beschreibst, oder Fotos machst! Ich hatte Dir schon vor laengerem geschrieben, dass ich vermute, dass der Regler das entscheidende Bindeglied ist.
Schaue auch wirklich mal in die CSV, die Dein eBusd geladen hat, wie cs-online schon geschrieben hat, dann siehst du was du maximal bekommen kannst!
Gruss Christoph

[pc1246]

Ich habe drei FTDI Module ausprobiert und alle drei haben zwischen GND und TXD und RXD 5V ist das richtig? Gemessen habe USB Kabel im Raspberry und FTDI ohne EBus Platine dahinter.
Wenn nicht welches FTDI Modul soll ich kaufen, habe auch schon eins gekauft was im ersten Thread verwendet wurde.

Moin
Schaust Du Wikipedia! https://de.wikipedia.org/wiki/RS-232
Gruss Christoph

[cs-online]

...soll heissen (wenn ich mich recht entsinne), dass die s.g. TTL-Pegel bei 0V und 5V liegen. Von daher kann das durchaus richtig sein, wenn im Leerlauf an beiden 5V anliegen, weil die mit hoher Wahrscheinlichkeit mittels Pullup auf High (5V) gezogen werden, um im Leerlauf ein definiertes Signal zu erzeugen.

[Tstolzmann]

Danke für eure Hinweise, funktioniert jetzt.

[Reinhart]

@realkeule

wie gesagt, wir brauchen ein Rawlog von den ersten 30 Sekunden nach dem Start des Dämons dann brauchen wir nicht länger rätseln.

Entscheidend ist was passiert wenn der Konverter seine Adresse an den Bus sendet. Es muss dann innerhalb von etwa 10-15 msec die Adresse zurück gesendet werden, wenn dies nicht der Fall ist, dann kann die Platine nicht senden! Ist die Zeit größer, wird die Arbitrierung nicht funktionieren und ein Timeout kommen.

entscheidend ist der Eintrag ab "starting initial broadcast scan"

Code Auswählen Erweitern

2017-11-08 11:04:10.134 [bus notice] <aa
2017-11-08 11:04:10.178 [bus notice] <aa
2017-11-08 11:04:10.221 [main notice] starting initial broadcast scan
2017-11-08 11:04:10.225 [bus notice] <aa     Syn vom eBus, Client dürfen den eBus belegen
2017-11-08 11:04:10.228 [bus notice] >31     eigene Adresse wird an den eBus gesendet um eine Anfrage zu initiieren
2017-11-08 11:04:10.233 [bus notice] <31     Bestätigung vom eBus, der Client darf nun senden
2017-11-08 11:04:10.237 [bus notice] >fe      nun setzt der Konverter seine Abfragen auf und baut sie Byteweise zusammen
2017-11-08 11:04:10.242 [bus notice] <fe      jedes Byte wird vom eBus bestätigt
2017-11-08 11:04:10.246 [bus notice] >07     usw.
2017-11-08 11:04:10.251 [bus notice] <07
2017-11-08 11:04:10.252 [bus notice] >04
2017-11-08 11:04:10.258 [bus notice] <04
2017-11-08 11:04:10.259 [bus notice] >00
2017-11-08 11:04:10.264 [bus notice] <00
2017-11-08 11:04:10.266 [bus notice] >14
2017-11-08 11:04:10.272 [bus notice] <14    die Anfrage ist durch, nun muss etwas gewartet werden, das ist aber jetzt für die Fehlerdiagnose nicht so wichtig
2017-11-08 11:04:10.275 [bus notice] >aa    es folgen wieder SYN und andere Client dürfen wieder den Bus belegen
2017-11-08 11:04:10.280 [bus notice] <aa
2017-11-08 11:04:10.327 [bus notice] <aa
2017-11-08 11:04:10.372 [bus notice] <aa
2017-11-08 11:04:10.418 [bus notice] <aa
2017-11-08 11:04:10.462 [bus notice] <aa
2017-11-08 11:04:10.506 [bus notice] <aa
2017-11-08 11:04:10.552 [bus notice] <aa
dieses Beispiel ist von einem funktionierendem Konverter V1.6


Beachtet dabei die Latenz, die ist hier sehr klein und beträgt nur 5 msec (233-228), das ist ein guter Wert.

Code Auswählen Erweitern

2017-11-08 11:04:10.228 [bus notice] >31     eigene Adresse wird an den eBus gesendet um eine Anfrage zu initiieren
2017-11-08 11:04:10.233 [bus notice] <31     Bestätigung vom eBus, der Client darf nun senden
kommt hier keine Antwort, weiß der eBus nicht das ein Client senden will, vermutlich ist dann das Sendesignal der Platine defekt oder fehlt!
Wenn jeder senden würde wie es ihm passt, dann käme es ansonsten ständig zu Kollisionen, deshalb gibt es hier im Protokoll Regeln damit dies funktioniert!

> bedeutet der Konverter sendet an den eBus
< bedeutet es kommen Bytes vom eBus

LG
Reinhart

[realkeule]

hallo,

erstmal vielen dank für die hilfe. ich bekomme raw nichts ausgelesen (es ging mal) und ich weiß nicht warum. aber ich habe folgendes im log gefunden was deine aussage bestätigt (denke ich)

Code Auswählen Erweitern

2017-11-08 14:19:55.260 [bus notice] <1008b5090329e201b30003e20100cd00
2017-11-08 14:19:57.103 [main notice] starting initial broadcast scan
2017-11-08 14:19:57.120 [bus error] send to fe: ERR: read timeout, retry
2017-11-08 14:19:57.152 [bus notice] >31
2017-11-08 14:19:57.164 [bus error] send to fe: ERR: read timeout, retry
2017-11-08 14:19:57.196 [bus notice] >31
2017-11-08 14:19:57.208 [bus error] send to fe: ERR: read timeout, retry
2017-11-08 14:19:57.241 [bus notice] >31
2017-11-08 14:19:57.252 [bus error] send to fe: ERR: read timeout
2017-11-08 14:19:57.253 [main error] initial scan failed: ERR: read timeout
2017-11-08 14:19:57.284 [bus notice] >31
2017-11-08 14:19:57.946 [update notice] unknown BC cmd: 10feb5050427001800
2017-11-08 14:19:57.950 [bus notice] <10feb5050427001800b8
2017-11-08 14:19:58.476 [update notice] unknown BC cmd: 10feb505034a0100
2017-11-08 14:19:58.480 [bus notice] <10feb505034a0100f4


de read timeout bedeutet wohl das er eine antwort erwartet die nicht kommt. ergo nicht sendet. oder?

[realkeule]

Hallo
Da wir ja leider etwas raten muessen, habe ich mal eine Grafik angehaengt, wie ich vermute, dass es bei dir aussieht. Wenn Dein Regler in der Therme steckt, dann ist der intern irgendwo angeschlossen, evtl. am eBus, evtl. auch an einem 2. eBus. Wenn er an einem 2. haengt, dann kann es sein, dass die Telegramme nur dort rumschwirren.
Es waere also gut, wenn du uns einfach mal Deine Konfiguration beschreibst, oder Fotos machst! Ich hatte Dir schon vor laengerem geschrieben, dass ich vermute, dass der Regler das entscheidende Bindeglied ist.
Schaue auch wirklich mal in die CSV, die Dein eBusd geladen hat, wie cs-online schon geschrieben hat, dann siehst du was du maximal bekommen kannst!
Gruss Christoph

so wie auf dem bild sieht es aus ich schaue heute abend mal wie die kabel intern stecken und schicke ein bild

[Reinhart]

hallo,

erstmal vielen dank für die hilfe. ich bekomme raw nichts ausgelesen (es ging mal) und ich weiß nicht warum. aber ich habe folgendes im log gefunden was deine aussage bestätigt (denke ich)

de read timeout bedeutet wohl das er eine antwort erwartet die nicht kommt. ergo nicht sendet. oder?

ja, dürfte so sein weil die Zeit abgelaufen ist, aber die ist sehr knapp eingestellt. Der eBus reagiert nicht auf die Anfrage.
Das Rawlog kannst du in der /etc/default/ebusd aktivieren, wenn du diese beiden Einträge in der EBUSD_OPTS anhängst und ebusd neu startest "--lograwdata=bytes --latency=100000"
Latency erlaubt dann auch längere Antwortzeiten bis 100 msec. Das Rawlog wäre insofern wichtig, das du auch siehst ob die SYN (aa) dazwischen auch schön kommen und sich da nicht andere Zeichen dazwischen moggeln, dann wäre der Empfänger etwas daneben. Glaube ich aber nicht, da die anderen Logs ja bei Rxd passen und den Broadcast soweit detektieren können.
Wenn du dich in der Elektronik etwas auskennst, kannst ja versuchen den Fehler im Sendezweig zu suchen, meist ist es die Zenerdiode es kann aber auch eine Diode im Brückengleichrichter sein oder gar der Transistor. Mit einem Multimeter kannst die Halbleiter ja schnell überprüfen (ohne Spannung an der Platine, nur Diodenmessung am Messgerät einstellen).
Wenn du es nicht schaffst, es startet in Kürze wieder eine Sammelbestellung der neuen Platine V2 ohne Poti.

Wichtig ist es, dass du es verstanden hast wie das intern etwa abläuft, das erleichtert dir in Zukunft die Diagnose und wie ich sehe hast du es schon richtig gedeutet.

Wenn du ein Multimeter hast und nicht weißt wie du das messen sollst dann melde dich, ich helfe dir da gerne weiter.

LG
Reinhart

[realkeule]

Code Auswählen Erweitern

2017-11-08 17:59:03.280 [main notice] starting initial broadcast scan
2017-11-08 17:59:03.409 [bus notice] <aa
2017-11-08 17:59:03.411 [bus notice] >31
2017-11-08 17:59:03.453 [bus notice] <aa
2017-11-08 17:59:03.455 [bus notice] >31
2017-11-08 17:59:03.458 [bus notice] <10
2017-11-08 17:59:03.466 [bus notice] <0a
2017-11-08 17:59:03.469 [bus notice] <b5
2017-11-08 17:59:03.473 [bus notice] <13
2017-11-08 17:59:03.478 [bus notice] <03
2017-11-08 17:59:03.482 [bus notice] <04
2017-11-08 17:59:03.486 [bus notice] <00
2017-11-08 17:59:03.490 [bus notice] <00
2017-11-08 17:59:03.494 [bus notice] <9f
2017-11-08 17:59:03.538 [bus notice] <aa
2017-11-08 17:59:03.582 [bus notice] <aa
2017-11-08 17:59:03.626 [bus notice] <aa
2017-11-08 17:59:03.628 [bus notice] >31
2017-11-08 17:59:03.670 [bus notice] <aa
2017-11-08 17:59:03.671 [bus notice] >31
2017-11-08 17:59:03.714 [bus notice] <aa
2017-11-08 17:59:03.716 [bus notice] >31
2017-11-08 17:59:03.758 [bus notice] <aa
2017-11-08 17:59:03.760 [bus notice] >31
2017-11-08 17:59:03.803 [bus notice] <aa
2017-11-08 17:59:03.804 [bus notice] >31


die dioden habe ich schon überprüft....
ich checke mal den bus in der heizung, wer weiß wo ich da drauf hänge...

//edit

@pc1246: also die bedieneinheit hängt parallel zum bus. das habe ich durchgemessen. d.h. die platine hängt parallel zur bedieneinheit.
da ich noch teile für eine 2te platine habe, werde ich die am wochenende zusammenbasteln und testen.
davon unabhängig spiele ich die software mal neu auf.

zumindest hab ich jetzt gecheckt was im raw log ankommen muss. da er jetzt denkt er sendet und keine passende antwort kommt wirds wohl aqm senden liegen. kann man die latenz noch höher stellen oder macht das keinen sinn?

grüße

...

[Reinhart]

jetzt sieht man es ganz genau, der Konverter sendet seine Adresse (31) und bekommt keine einzige Anfrage zurück. Die "aa" sind normale SYN Zeichen, das der Bus frei ist. Du hast zufällig schon bei der 2. Anfrage eine Antwort im Log, das ist aber ein Broadcast der regelmäßig kommt und nicht vom Adapter ausgelöst wurde, es müsste eine <31 kommen weil das deine Adresse ist.

Die Latenz höher stellen hat keinen Sinn, war jetzt nur für den Test wichtig damit das Timeout nicht jedesmal kommt. Alles was höher als 15-20 msec ist, wird schon nicht mehr richtig funktionieren. Die 100 msec waren jetzt nur damit uns nicht der eBusd abriegelt und wir wirklich die Antwort sehen falls sie kommt. Alles was später kommt, ist ohnehin außerhalb der Toleranz.

Sehr gut, du hast jetzt alles gecheckt worauf es ankommt. Wenn du noch Teile und eine Platine hast ist das gut, aber so eine Reparatur ist für einen Elektroniker/Bastler nicht schwer, falls du einen in der Bekanntschaft hast. An der Verkabelung wirst du nicht viel suchen müssen, es kommt keine korrekte Busanfrage aus dem Konverter raus (zumindest wird sie nicht beantwortet)  und der Empfang scheint ok zu sein. Die Syn sind sauber zu sehen.

Wir hatten bei unseren Tests für die 2.0 gelegentlich solche Phänome, das zwar elektronisch gesehen der Sendeweg ok war, aber das Signal kein schönes Rechteck, sondern beim Anstieg eine gekrümmte Kurve war, das hat ebenfalls zu  Sende Fehlern geführt, bzw. wurde vom eBus nicht mehr akzeptiert weil die Zeitfenster (50 ysec) hier sehr knapp sind. Mit einem Multimeter gemessen wäre aber alles in Ordnung gewesen, erst am Oszilloskop war es nachweisbar. Wenn du etwas tiefer in die Materie eintauchen willst, hier ist alles dokumentiert. Zumindest siehst du wie komplex das Thema eigentlich ist.

LG
Reinhart

[TiPpFeHlEr]

Hi realkeule

Du hast Platine 1.6 aufgebaut und die Teile bei reichelt bestellt?

Wenn deine Platine nicht sendet, verringere den Widerstand R6 von 22k auf 11-12k

Ansonsten Platine zu mir schicken, ich habe noch Teile da.

Dieses Problem war bei TobiasR auch,

Mfg Maik

[realkeule]

Hi realkeule

Du hast Platine 1.6 aufgebaut und die Teile bei reichelt bestellt?

Wenn deine Platine nicht sendet, verringere den Widerstand R6 von 22k auf 11-12k

Ansonsten Platine zu mir schicken, ich habe noch Teile da.

Dieses Problem war bei TobiasR auch,

Mfg Maik

ja genau. da ich die teile doppelt bestellt habe kann ich zum testen einen 22k zum r6 parallel löten.
ich habe gestern etwas in dem dokument von reinhard von flankensteilheit gelesen und, wie er auch geschrieben hatte, gedacht, das vllt irgendein pull widerstand zu knapp bemessen ist.
ansonten komme ich auf das angebot gerne zurück die platine zu dir zu senden
leider habe ich zuhause nur ein multimeter. elektronische kenntnisse sind aber etwas vorhanden.

[TiPpFeHlEr]

So wie ich es messen konnte, sind die beiden Stabiwiderstände im Darlington kleiner als angegeben.
laut Datenblatt ca. 10k gemessen ca. 3k

Mfg Maik

[frz]

Ich versuche auch gerade einen Adapter in Betrieb zu nehmen.
Leider habe ich (scheinbar?) beim Einstellen des Potis ein Problem. Ich kriege es im moment (mit min. 2-3h probieren) nur hin das ich entweder NUR "00" und vereinzelte "ff" im "raw logging" kriege:

Code Auswählen Erweitern


...
2017-11-09 22:30:47.187 [bus notice] <00
2017-11-09 22:30:47.218 [bus notice] <ff
2017-11-09 22:30:47.236 [bus notice] <00
2017-11-09 22:30:47.285 [bus notice] <00
2017-11-09 22:30:47.300 [bus notice] <00
...

oder alternativ ein instabiles signlar und mehr andere symbole:

Code Auswählen Erweitern


2017-11-09 22:33:26.714 [bus notice] signal acquired
2017-11-09 22:33:27.416 [bus notice] <e0
2017-11-09 22:33:27.432 [bus notice] <f8
2017-11-09 22:33:29.036 [bus error] signal lost
2017-11-09 22:33:32.423 [bus notice] <c0
2017-11-09 22:33:32.425 [bus notice] signal acquired
2017-11-09 22:33:32.439 [bus notice] <00
2017-11-09 22:33:32.471 [bus notice] <fe
2017-11-09 22:33:33.399 [bus notice] <fc
2017-11-09 22:33:35.002 [bus error] signal lost
2017-11-09 22:33:42.406 [bus notice] <f0
2017-11-09 22:33:42.407 [bus notice] signal acquired
2017-11-09 22:33:42.422 [bus notice] <f8

Auch nach langem probiere kriege ich keinen Datenstrom in dem mal "<aa" vorkommt.
In beiden settings scheint ebusd auch keine Geräte auf dem Bus zu finden (vermutlich erwartet)

Woran kann es liegen oder muss ich solange weiter versuchen es einzujustieren bis es klappt?