Läuft: Heizung mit eBus-Schnittstelle

[mirror]

Hallo John,
anbei die Daten der ecoCompact und des VCR700 Reglers (hatte ich schon mal auf Deinem github gepostet). Die bai.csv ist eine modifizierte 08.bai.HW7401.csv:

Code Auswählen Erweitern


pi@raspberrypi ~ $ ebusctl scan full
done

pi@raspberrypi ~ $ ebusctl scan result
08;Vaillant;BAI00;0116;9602
15;Vaillant;70000;0206;4103;21;15;43;0020171314;0082;036705;N4
ec;Vaillant;70000;0206;4103;21;15;43;0020171314;0082;036705;N4

pi@raspberrypi ~ $ ebusctl info
version: ebusd 2.0.5ccdb76
signal: acquired
symbol rate: 37
masters: 3
messages: 461
address 03: master #3
address 08: slave #3, scanned "MF=Vaillant;ID=BAI00;SW=0116;HW=9602", loaded "vaillant/08.bai.HW9602.csv"
address 10: master #6
address 15: slave #6, scanned "MF=Vaillant;ID=70000;SW=0206;HW=4103", loaded "vaillant/15.700.csv"
address ec: slave, scanned "MF=Vaillant;ID=70000;SW=0206;HW=4103"


[galileo]

Nachdem letzte Woche alle Bauteile eingetroffen sind habe ich jetzt den Probeaufbau gestartet. Gegenüber der ersten Idee hat sich aber nun doch noch einiges verändert.

1. Die LED für RxD war so angeschlossen, dass sie nicht bei den Pulsen sondern in den Pausen dazwischen geleuchtet hat. Dadurch war sie praktisch immer hell was relativ sinnlos war.
Also habe ich das Signal am CNY17 invertiert (Ausgang vom Emitter zum Kollektor verschoben), was aber einen weiteren Inverter notwendig machte um wieder die richtigen Polarität herzustellen. Ich habe dazu die zweite unbenutzte Hälfte des Komparators genommen, die war ja sozusagen "gratis". Ich hätte stattdessen auch den invertierenden Komparator auf einen nicht-invertierenden umbauen können, aber bei dieser Schaltung würden sich der Eingangs-Spannungsteiler und die Mitkopplung vermischen, was die ganze Sache nur komplizierter macht. Deshalb die einfache Schaltung "invertierender Komparator" und noch ein Inverter hintennach.

2. Was niemand bedacht hat und was bei meiner Schaltung dann zur Fehlfunktion geführt hat: VDD mag ja 5V sein, aber der CP2102 Chip, der auf dem USB/Serial Wandler verbaut ist, liefert nur einen High-Pegel von 3,3V. Das mag bei einem 4011 mit 5V Versorgung noch durchgehen, wenn man den aber wegrationalisiert und den Optokoppler direkt am Ausgang des CP2102 betreibt, dann muss man dort auch mit 3,3V arbeiten. Deshalb keine Verwendung mehr von den 5V auf der USB Seite.

Nachdem die Schaltung lief habe ich auch noch verschiedene Sachen nachgemessen, um die Theorie zu verifizieren.
Da ist einmal der TxD Pfad. Aus dem USB/Seriell Wandler kommt ein 0V/3,3V Signal, welches auch genug Strom liefern kann. Durch die LED im CNY17 fließen dann (3,3-1,25)/1k =  2mA. Damit der Ausgangstransistor beim Durchschalten die (5-1,6-0,7)/1k = 2,7mA Strom liefern kann, ist ein Übersetzungsverhältnis IC/IF > 100 notwendig. Das ist der Grund, warum ich hier einen CNY17-3 gewählt habe. Ist aber nicht ganz so kritisch, weil ja dieser Transistor mit dem BC337 noch einen "Darlington" bildet und dessen Stromverstärkung mit eingeht. Wichtig ist nur dass dieser letzte Transistor die von der eBus Spezifikation geforderten maximalen 100mA treiben kann. 100mA/2,7mA ergibt also ein hFE Minimum von 37.
Ich habe den BC337-40 mit einem garantierten hFE von 250 gewählt und somit sind wir insgesamt auf der gaaanz sicheren Seite. Und das kostet auch nicht mehr - die Preise für alle Strich-Versionen sind sowohl beim CNY17 als auch beim BC337 gleich. Man braucht aber jetzt für den Transistor keinen Darlington mehr, und es fällt an ihm auch keine nennenswerte Leistung ab. Im Anhang kann man ein Oszillogramm sehen, gemessen am Kollektor vom BC337, wo zuerst der Bus von einem anderen Busteilnehmer getrieben wird (5V/13V) und dann die Schaltung ,,sendet" und der BC337 sauber von 13V auf 0V zieht.

Die Schaltschwelle des Komparators lag gemessen (am eBus) bei 13,1V (High to Low) und 13,8V (Low to High).

Das zweite Oszillogramm zeigt den Eingang VI vom 78L05 Spannungsregler. Man kann erkennen wie (in der Mitte vom Bild) die Spannung während einer Sendung zwar abfällt, aber eben nicht unmittelbar auf 8-9V sondern nur langsam wegen des 10uF Kondensators.

So, das war's vorerst von meiner Seite. Diese Schaltung läuft stabil und ohne Einstellung (natürlich ,,nur" solange sich alle an die Spezifikation halten). Wollte man etwas einstellbar machen, dann könnte man R3/R4 durch 2 Widerstände und ein Potentiometer ersetzen. Auch an der Mitkopplungs-Schraube könnte man drehen und R9 vergrößern. Dadurch würde die Hysterese kleiner werden und damit der Toleranzbereich zwischen High und Low vergrößert. Hilft vielleicht gegen die von pah geschilderten Installateur-Sünden 

Da ich persönlich mit meinem umgebauten eService Koppler zufrieden bin, habe ich nicht vor, einen Print zu machen. Mich hat nur die Schaltung als solche gereizt. Auch für den Testaufbau habe ich keine weitere Verwendung. Ich kann ihn gerne jemandem überlassen der damit spielen möchte.

LG
Eduard

[NemoN]

Vielen Dank für die "plug-and-play" Schaltung
Hast du auch ein Foto von der Rückseite der Lochrasterplatine?

[galileo]

Na das gewinnt sicher keinen Schönheitswettbewerb, aber ich hab's kreuzungsfrei geschafft, für den Preis einer sicherlich zu großen Fläche.

[john30]

2. Was niemand bedacht hat und was bei meiner Schaltung dann zur Fehlfunktion geführt hat: VDD mag ja 5V sein, aber der CP2102 Chip, der auf dem USB/Serial Wandler verbaut ist, liefert nur einen High-Pegel von 3,3V.

Wie kommt der CP2102 mit dem Timing auf dem Bus klar?
Wir hatten in der Vergangenheit häufig Probleme mit zu großen bzw. nicht einstellbaren Buffern an nicht-FT232 Bausteinen, was letztlich eine zuverlässige Kommunikation verhindert hat...

[john30]

anbei die Daten der ecoCompact und des VCR700 Reglers (hatte ich schon mal auf Deinem github gepostet). Die bai.csv ist eine modifizierte 08.bai.HW7401.csv:

Dein Produktcode ist wesentlich neuer, als das, was im github an solchen verfügbar ist. Insofern kann es seht gut sein, dass der gesuchte Wert nicht mehr in dem bis jetzt bekannten Register zu finden ist.
Du könntest jetzt das Script readall.sh nutzen, um nach einem 2-byte Wert zu suchen, der Deiner aktuellen Anzeige entspricht.
D.h. Wert aus der Anzeige nehmen und in Hex wandeln, die beiden Bytes vertauschen, "02" vorne dran stellen, und dann im Ergebnis von readall.sh nach dieser Folge suchen.
Also z.B. bei Anzeige des Werts 1590:
1590=0x0636.
In eBUS Format dann 023606.

[EDIT]: readall.sh ist natürlich das falsche Skript, ich meinte das Skript allregisters.sh im Anhang der Message von damals.

[galileo]

Hallo John!

Wir hatten in der Vergangenheit häufig Probleme mit zu großen bzw. nicht einstellbaren Buffern an nicht-FT232 Bausteinen, was letztlich eine zuverlässige Kommunikation verhindert hat...

Wenn ich es richtig verstanden habe (bitte korrigiere mich) dann geht es dabei um die Bus Arbitrierung. Nachdem der Empfänger erkannt hat dass er jetzt senden darf, hat er nur eine gewisse Zeit zur Verfügung in der er mit dem Senden beginnen muss. Ich glaube mich erinnern zu können dass pah das Problem in diesem Thread einmal auf das Transmit-FIFO zurückgeführt hat. Dadurch dauert es einfach zu lange bis tatsächlich gesendet wird.

Ich habe mich einmal wegen eines ähnlichen Problems mit all den UARTs auseinandersetzen müssen und bin denke ich auf die eigentliche Ursache gestossen. Es gibt verschiedene UART-Familien und nicht alle sind für Anwendungen dieser Art geeignet. Ein Typ 32590 beispielsweise hat die Möglichkeit, sofort nach dem Empfang eines Zeichens im Receiver einen Interrupt am Prozessor auszulösen. Das wäre O.K.

Ein Typ aus der Familie 16650 hat als minimal mögliche Einstellung nur 1/8 Receiver FIFO full. Diese Familie gibt's mit 16 Byte FIFO, bis zu 128 Byte FIFO. Das heisst es müssen am Receiver wenigstens 2 oder 4 oder sonst wieviele Bytes eintreffen bevor der Interrupt ausgelöst wird. Treffen die nicht ein, hat der Chip noch ein "Timeout" sodass er dann trotzdem einen Interrupt auslöst. Das Timeout liegt aber auch in der Größenordnung einiger Character. Damit muss die Arbitrierung schiefgehen, weil das Timeout verstreicht falls die empfangenen Character nicht genau mit dem 1/8 FIFO Trigger Level zusammenfallen.

Jetzt ist natürlich richtig, dass der Linux-Treiber mit VMIN=1 und VTIME=0 korrekt eingestellt ist um bei genau einem empfangenen Byte zu reagieren, aber was kann denn die Software schon ausrichten, wenn die Hardware dahinter nicht mitspielt. Nicht mitspielen kann.

Der Rasperry Pi 3 hat den Broadcom BCM2837 eingebaut und dieser verwendet lt. Datenblatt einen 16C650-ähnlchen UART. Ich nehme an bei den älteren RASPIs wird das genauso sein. Das würde erklären warum die Schaltung direkt an der Seriellen des RASPI nicht funktioniert.
Welchen UART der CP2102 verwendet konnte ich bis jetzt nicht herausfinden. Würde mich sehr interessieren falls das jemand schafft. Prinzipiell denke ich aber dass es ein "guter" sein muss, denn wenn man das Oszillogramm betrachtet (Senden.jpg - mein vorheriger Post) dann kann man die Turnaround-Zeit sehen, also die Zeit die verstreicht vom Hören des letzten Bytes bis zum Senden des ersten Bytes (kleine Pegel - grosse Pegel) und diese Zeit ist sicher nicht um 1 oder 2 FIFO Füllungen verzögert.

[john30]

Jetzt ist natürlich richtig, dass der Linux-Treiber mit VMIN=1 und VTIME=0 korrekt eingestellt ist um bei genau einem empfangenen Byte zu reagieren, aber was kann denn die Software schon ausrichten, wenn die Hardware dahinter nicht mitspielt. Nicht mitspielen kann.

das hängt immer gravierend von der Modul Implementierung und den Möglichkeiten der Hardware ab. Der CP210x kann zumindest einen Timeout beim Lesen, der allerdings nicht verwendet wird.
Naja, solange das Interface mitspielt, ist ja alles gut

[primi]

Edit: Habe es gelöst. War ein Problem der Timeouts auf einem wesentlich schnelleren Rechner. Danke für die Anteilnahme

hallo pah, ich habe im Moment auch das Problem, dass mein Befehl zerlegt wird. welche Timeouts musstest du ändern?
lg Primi

Edit: Habe es gelöst. War mein Fehler... hatte aus welchen Gründen das Attribut RequestSeperator = 1 eingestellt. Daher hat er alle cmd's beim Auftreten des Zeichens "1" getrennt...

[hermann65]

Hallo,
ich habe mich im Forum angemeldet weil ich nicht weiterkomme. Ich vermute das meine Anlage zu neu ist und es noch keine csv-Dateien gibt.
Die Anlage besteht aus:
0010015603;ecoCOMPACT;VSC 206/4-5 150;21163800100156033100005407N2
;;VRC 700/4;
002184843;;VR70;21163400201848430082013423N2

Die eBus-Schnittstelle und das Programm läuft. Ich habe folgendes mit einem scan ausgelesen:

pi@raspberrypiwlan ~ $ ebusctl scan result
08;Vaillant;BAI00;0116;9602;21;16;38;0010015603;3100;005407;N2
15;Vaillant;70000;0419;4603
52;Vaillant;VR_70;0109;2903;21;16;34;0020184843;0082;013423;N2

pi@raspberrypiwlan ~ $ ebusctl info
version: ebusd 2.3.5bcc475
signal: acquired
symbol rate: 23
masters: 3
messages: 212
conditional: 3
poll: 0
update: 8

address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0116;HW=9602", loaded "bai.308523.inc", "vaillant/08.bai.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
address 52: slave, scanned "MF=Vaillant;ID=VR_70;SW=0109;HW=2903"

und wie man sieht fehlen die csv-Dateien für den VRC 700/4 und für den VR70, dazu habe ich noch nichts gefunden.

[john30]

address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0116;HW=9602", loaded "bai.308523.inc", "vaillant/08.bai.csv"
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0419;HW=4603"
address 52: slave, scanned "MF=Vaillant;ID=VR_70;SW=0109;HW=2903"
und wie man sieht fehlen die csv-Dateien für den VRC 700/4 und für den VR70, dazu habe ich noch nichts gefunden.

Für die VRC700 gibt es bereits eine erste Fassung im aktuellen Stand vom git.
Allerdings ist dafür noch kein neues Release verfügbar.

[Sven77]

Wenn dich aktuelle Erkenntnisse zum VR70 interessieren, schicke mir bitte per PN deine Mailadresse.
Allerdings gibt es aktuell nur 4 Meldungen, die ich dazu interpretieren kann und deren Inhalt steht eigentlich auch im VRC700.

Ich bin allerdings immer an bereitwilligen Testern interessiert, gerade mit unterschiedlichen Systemkonfigurationen, um vielleicht auch noch fehlende Sachen im VRC zu finden!

[john30]

Kleine Ankündigung: ebusd Version 2.4 ist fertig und als Release verfügbar.
Das ist auch wahrscheinlich die letzte Version 2, jetzt geht es an Version 3 mit neuen Features.
Wünsche werden noch angenommen und können in den Github Issues für Milestone 3.0 hinterlegt werden. Die Issues mit den meisten +1 reactions werden zuerst bearbeitet
VG John

[galileo]

Hallo John,
Ich habe bisher mit ebusd V2.1 gearbeitet. Nun habe ich mit

Code Auswählen Erweitern

dpkg -i --force-overwrite ebusd-2.4_armhf.deb
ein Upgrade gemacht. Nach dem Reboot ging das ebusctl nicht mehr:

Code Auswählen Erweitern

pi@raspberrypi:~ $ ebusctl info
error connecting to localhost:8888
Nachdem ich mit

Code Auswählen Erweitern

dpkg -i --force-overwrite ebusd-2.1_armhf.deb
die alte Version wieder drüber installiert habe, ging's wieder.
Ich hab das mehrmals probiert, immer mit dem gleichen Effekt.
Mache ich etwas falsch ? Oder vergesse ich etwas ?
LG Eduard

[john30]

Ich habe bisher mit ebusd V2.1 gearbeitet. Nun habe ich mit

Code Auswählen Erweitern

dpkg -i --force-overwrite ebusd-2.4_armhf.deb
ein Upgrade gemacht. Nach dem Reboot ging das ebusctl nicht mehr:

Code Auswählen Erweitern

pi@raspberrypi:~ $ ebusctl info
error connecting to localhost:8888

Danke für den Hinweis!
Da war leider noch ein kleiner Fehler drin, der sich offensichtlich nur auf dem Raspi zeigt. Ich baue das Paket gerade neu.

UPDATE: Paket ist neu gebaut und im Release hochgeladen. Könntest Du das bitte nochmal probieren?

UPDATE die zweite: Also da ist noch ein zweiter Wurm drin, das kann ich Euch so nicht guten Gewissens in die Hand geben.
Darum: Release 2.4 nochmal um ein paar Tage verschoben.