Hallo Leute,
kennt sich jemand mit der Belegung der
Datenschnittstelle/Steckkartenschnittstelle bei der Logamatic 2107 aus
(sieht aus wie ein kleiner ISA Steckplatz) ? Ich wollte an den Bus um
ein paar Parameter (Temp. ...) auszuwerten. Hat sich schon jemand damit
beschäftigt ???
Grüße & Danke!
Hi!
du meinst diese M292 Busplatine mit den 12poligen Stecksockeln drauf?
Ich stehe vor gleichem Problem.
Mir wurde, als wir die Heizungsanlage modernisiert haben, vorgeblaht,
dass eine Anbindung der Buderus Steuerung an einen PC möglich sei.
Später habe ich dann erst bemerkt, dass es dazu ein passendes Modul mit
rs232 Schnittstelle (unbezahlbar für den Einsatzzweck wie ich finde)
braucht.
Dann hat man aber immer noch keine Software und Protokollbeschreibung.
Per google habe ich auch schon einige Zeit mit suchen verbracht. Das
einzig sinnvolle ergebnis war eine Person in anderem Forum, der einen
Datenlogger python daemon geschrieben hat. Setzt aber eben wieder das
RS232 Modul voraus.
Bei diesem M292 handelt es sich um einen internen Kommuniationsbus
zwischen Hauptsteuerung und den (optionalen) Modulen. Wenn man den
direkt sinnvoll abgreifen könnte wäre das schon ne geile sache.
Ich habe es mittlerweile aufgegeben, mich mit dem Thema zu beschäftigen,
da Buderus auch nur ne Firma ist, die Kohle mit Zusatzartikeln machen
will.
Anfragen über den Heizungsmeister meines Vertrauens gingen ebenso ins
leere.
Wenn man wenigstens einen Ansatzpunkt hätte, um was für eine Art Bus es
sich dabei handelt. Da ich aber weder einen 12Kanal Logic Analyzer habe,
noch den richtigen Ansporn, da irgendwas dran zu fummeln lasse ich es
lieber bleiben.
Falls du (oder jemand anders) dennoch weitere Infos dazu hättet wäre mir
das auch sehr recht!
Gruss, Malte
Hallo,
ich hänge an der RC30 und hoffe das die Logamatic 2107 das gleiche
Protokoll fährt. Ich werde das die nächsten Wochen mal bei einer
Logamatic 2107 durchmessen ...
Das Protokoll der RC30 (am ServiceKey) ist etwas schwer zu lesen, aber
die meissten Werte, die ich haben will, werden schon geloggt (siehe
Bild).
Grüße.
Hi Rudi,
na das ist doch schonmal was. Nen ServiceKey scheint die 2107 nicht zu
haben. Nur eben diesen internen Bus (sofern man keine Module eingesteckt
hat, so wie wir ;)
Dein Lila "Was?" Im Graph sieht mir ganz verdächtig nach dem
Schaltzustand der Brennerfreigabe aus. Immer wenn deine Kesseltemperatur
hochgeht, gibt es auch dort eine entsprechend lange Flanke.
Ist das ein Analogwert? Komisch finde ich die verschiedenen Werte der
Flanken - hast du einen modulierten Brenner? Das würde die
unterschiedlichen Flankenhöhen erklären.
Wenn du dich diesem Bus mal annehmen könntest wäre das super, ich habe
hier die schematische Darstellung für die Inbetriebnahme (ein
spartanischer Schaltplan ohne wichtige Details.
Was ich aber sagen kann ist, dass nur die Pins 1-12 des 20poligen Busses
verwendet werden (dieser ISA aehnliche stecker hat auch entsprechend nur
2x6 pins.
Mehr geht aus dem Schaltbild auch nicht hervor.
Gruss, Malte
Hallo,
ich gehe direkt von der Service-Key-Schnittstelle (über Klinkenstecker)
an meine (Frickel)Schaltung, die das Signal auf einen MCU verträglichen
Wert wandelt (3V3). Die MCU kann dann direkt über die UART 9600Baud die
Daten empfangen.
Das "Was?" sagt eigentlich nur das der Brenner eingeschaltet ist und
welcher Kreis geheizt wird (Warmwasser/Heizung). Über einen weiteren
Sensor zeichne ich den Gasverbrauch am Zähler auf und kann so direkt
bestimmen wieviel Gas für Heizung und Warmwasser verbraucht wurde.
Ich habe leider noch nicht die Stellen für den Vor-/Rücklauf der Heizung
gefunden. Aber die sollten spätestens in der Heizperiode gefunden werden
...
Grüße.
Hi Rudi,
ich habe an meiner RC30 keine Service-Key Schnittstelle gefunden.
(vielleicht eine ältere Version) Aber an der BC10; ich habe eine
Logamatic EMS statt einer Logamatic 2107. Dort habe ich mit meinem Oszi
folgendes gemessen:
L= GND
R= Tx (aus Service-Key Sicht), mit Low Pegel=~11V und High Pegel=~16V
GND= ~16V
Ist dies bei Dir genauso?
Ist dort wo normalerweise GND beim Klinkenstecker ist, vielleicht der Rx
Eingang mit einem Pullup an 16V?
Magst Du uns oder mir deine Schaltung und das bislang erforschte
Protokoll mitteilen?
Gruß Malte
Hallo Malte,
die Schnittstelle befindet sich hinter einer Platikabdeckung neben den
Tasten (siehe Bild). Ist übrigens auch EMS.
Belegung:
Beitrag "Buderus Bedieneinheit RC30"
Ich koppel den DC-Anteil über einen Kondensator aus:
-+2.5V und dann per Spannungsteiler auf +-1.5 und dann per Opamp auf
0-3V Pegel. Ist nicht ideal denke ich, aber funktioniert erstmal. Hat
jemand eine bessere Lösung ????
An einem Erfahrungsaustausch bin ich sehr interessiert !
Grüße.
> Ist dort wo normalerweise GND beim Klinkenstecker ist, vielleicht der Rx> Eingang mit einem Pullup an 16V?
Ich "glaube nicht". Die Teilnehmer senden alle auf dem Bus (TX==RX). Du
kannst den Offset auf der Signalleitung für die Stromversorgung benutzen
oder die 12V. Wieviel Strom die Leitungen können kann ich dir aber nicht
sagen.
Grüße.
Ok, das sieht bei mir sehr ähnlich aus.
Ich hatte es so verstanden, dass das Teil mit dem größeren Display RC30
heißt und das Teil links daneben mit den beiden Drehschaltern und der
Servicekey Schnittstelle BC10 heißt.
Eigentlich auch egal wie sie heißen. :-)
Danke, das werde ich dann mal ausprobieren.
Gruß Malte
Leider habe ich nirgends nen ServiceKey oder ähnliches an meinem Teil
(Zubehör zu kaufen ist mir es dann aber doch nicht wert).
@Malte: Hallo Namensvetter ;)
@Malte: Moin Namensvetter :-)
und Du bist auch nur 11 Tage älter als ich. ;-)
Ich glaube hier oben im Norden kommt unser Name häufiger als im Süden
vor.
Gruß Malte
@Walter: Irgend so ne Buderus Gxx Gastherme mit Logamatic 2107
Steuerung. Allerdings diese Steuerung ohne jegliche Zusatzmodule, da das
ganze eine Zentralheizung für mehrere Wohnungen (vermietet) darstellt
und somit die pumpenansteuerung ueber buderus-kram zu teuer gewesen
waere.
Deshalb verwende ich den einen Heizkreis der 2107 nur als Freigabe für
die bestehenden Raumtemperaturschalter der alten Anlage (in den
Wohnungen).
@Malte: ja, denke ich auch - aber ich wohne im Sueden - weiss auch nicht
was meine Eltern sich dabei gedacht haben, einen "nordischen" Namen zu
nehmen :)
Naja, also von meiner Seite aus nicht, da ich keine Hardware habe um die
12 Pins zu analysieren.
Ich vermute (!) mal dass der interne Bus in etwa so aussehen könnte:
12 Pins:
V+
GND
CLK
unknown
8 Datenbits
Das kann natürlich auch völlig anders aussehen.
Zum beispiel könnte es auch ein serieller Bus sein und die anderen Pins
dienen dazu, das jeweils gesteckte Modul zu identifizieren.
Keine Ahnung. Solange ich keinen LogicAnalyzer in den händen halte
heisst es für mich erstmal warten und hoffen dass jemand anders eine
Erleuchtung bekommt :-(
Wie gesagt, mit entsprechender Hardware die einen ServiceKey oder direkt
das RS232 Modul bereitstellt gibt es ja schon lösungen.
Leider sind diese Module beim Hersteller/Heizungsfachbetrieb nicht
gerade günstig.
Und mal ehrlich, 150-200€ will ich nicht ausgeben, nur um die Daten
loggen zu können. Das muss weitaus günstiger machbar sein.
Gruss, Malte
Moin,
ich habe mir nun eine kleine Platine gebastelt und zwei Textdateien mit
dem Hyperterminal aufgenommen. Ich habe aber nen LM211 verwendet, der
war noch vorhanden.
@Rudi: Sieht das so erstmal richtig aus? Oder habe ich noch ein Hardware
Fehler?
Gruß Malte
Kann du mal im Bus-Monitor schauen welche Module vorhanden sind ?
Ansonsten sieht es schon mehr oder weniger nach den Daten aus. Bist du
sicher das der LM211 ordentliche Flanken am Ausgang hat ? Ich messe die
Zeit zwischen den einzelnen Zeichen um Anfang und Ende einer Nachricht
zu ermitteln (ein paar 10ms). Bei mir sieht es z.B. so aus:
Ich konnte heute an der Logamatic 2107 messen. Es liegen am
Flachbandkabel zur Displayeinheit zwei Signale mit 5V Pegel an, die nach
Daten aussehen. Das Signal wird mit etwa 50Khz geschickt. Demnächst wird
das Flachbandkabel "richtig" angezapft und dann gibt es mehr.
An den 3 freien 12poligen Steckverbindern sieht es eher schlecht aus.
Dort liegt nur eins der Signale an. Die Steckverbinder scheinen auch
nicht identisch verdrahtet zu sein.
Grüße.
Rudi:
ich bin mir nicht sicher, ich vermute mal, dass das jeweilige modul
welches man in die expansion slots stopfen kann, sich beim logamatic
controller erst anmeldet, bevor da was an kommunikation passiert.
Das macht das ganze Vorhaben meinerseits schon recht unmöglich.
Am Display Daten abgreifen?
Hm. ich bezweifle dass da was brauchbares rübergeht - im Zweifelsfall
das was gerade angezeigt wird.
Ich sollte mich wohl auch nochmal ein paar Stunden in den Heizraum
begeben...
Grüssle
Hallo,
über die Displayeinheit regelst du die Anlage und kannst alle Daten
abgreifen. Es müssen alle Daten an diese Einheit geschickt werden
(Temperatur etc.). Wenn du die Displayeinheite auf den Kopf drehst sind
es die zweiten Pins (oben/unten) von rechts auf denen die Daten
geschickt werden (am Flachbandkabel das von der Steuereinheit kommt).
Kannst du evtl. mal ein Bild von der Platine machen ? Ich habe leider
nur unscharfe mit meinem Handy machen können. Eins von der
Displayeinheit und dann noch eins links von den freien Steckverbindern
mit dem Steckverbinder für die Temperatursensoren. Dann kann ich das mal
einzeichnen.
Grüße.
Hi Rudi,
aber sicher doch.
die bilder findest du hier:
http://titan.neo-soft.org/temp/logamatic_2107/
Wollte die nicht hier anhängen (weil viel zu gross), kannst dir das
passende selbst rausschnippeln :)
Gruss, Malte
Super.
Jetzt habe ich mir beim foto machen auch mal die displayeinheit
angeguckt, da scheint ja die komplette Logik drauf zu sein.
Von daher ist das flachbandkabel vielleicht doch der punkt den wir alle
zusammen angreifen und vernichten sollten ;-)
Dachte die Logik sitzt woanders und das waere nur ne dumme platine mit
display und tasten.
Schade dass ich im signal reverse-engineeren so wenig erfahrung habe.
Wenn du da aber eine art interface dranbasteln koenntest, waere schon
sehr viel geholfen!
Gruss, Malte
Es wird wohl darauf hinauslaufen das auf das Kabel ein weiterer
Steckverbinder gepresst wird (wie bei den IDE Kabeln) um weitere
Messungen durchzuführen. Was mir etwas Kopfschmerzen bereitet sind die
50KHz Signal. Das passt irgendwie nicht.
Ja, weiterer Steckverbinder ist die einfachste Lösung.
Was ist an 50 KHz verkehrt? Klar, die passen nicht zu 9600 baud, aber
ich gehe mal nicht davon aus dass das signal unbedingt dem des
ServiceKeys entsprechen muss. Oder meinst du, dass die nur einen
internen Datenkanal im gesamten System haben und diesen als Abgriff auf
den ServiceKey geben?
Mich nervt das irgendwie gerade dass ich nur theoretisch mitdiskutieren
kann - will auch endlich was produktives dazu beitragen.
Hi,
ich habe im Bus Monitor nachgeschaut.
Ich habe anscheinend nur drei Module:
UBA3 / MC10 8
BC10 9
RC30 16
Mit der Flankensteilheit bin ich mir nicht sicher, die muss ich noch mal
überprüfen.
Die Texte "TEMP AUSSEN: 18.5" werden aber nicht so direkt übertragen?
Die hast Du interpretiert und eingefügt, oder? Was steht dann da, an der
Stelle?
Danke und Gruss,
Malte
Hallo,
die 3 Module sind ok. Die Texte habe ich interpretiert, klar. 18.5°C
wären im Hex-Dump dann "00 B9".
Ich bin mir nicht 100%ig sicher, aber ich glaube am Ende kommt noch eine
CRC. Die habe ich mir bisher aber noch nicht genau angesehen.
Ich werde wohl nächste Woche die Platine malen und abschicken, falls du
interesse hast, dann kann ich dir eine mitmachen. Ich benutze einen
Komperator der im Bereich 3V-5V arbeitet, aber an den Eingängen bis zu
22V verträgt. Der Ausgang ist dann direkt im VCC-Level.
Grüße.
Hi,
ich habe mit einem anderen Notebook Daten aufgezeichnet.
Die Daten sehen nun schonmal ähnlicher aus.
Was ist der Newline Character? FF?
Was kostet denn so eine Platine?
Hier sonst meine Email: hoelkynkoelkyn (aet) gmx (punkt) net
Gruß Malte
Hallo,
dieses 0xff sehe ich bei mir nicht. Auf dem Oszi ist nach den Daten auch
kein Start/Stop-Bit für ein 0xFF. Sieht eher wieder nach zu langsamen
Flanken aus !?
Hast du einen Warmwasserboiler mit dran ? Deine Anlage zeigt beim Druck
nur 0xff an. (0x08 0x00 0x18 ... die Stelle 21).
Die Platine wird nicht mehr als 10€ kosten, eher weniger. Ich melde mich
per E-Mail wenn sie fertig ist.
Grüße.
Hallo,
ich interessiere mich auch für den BUS. Habe gerade auch herausgefunden
dass die Daten nur seriell übertragen werden. Bis Mein OSZI geknallt und
geraucht hat.
Würde mich für die Schaltung oder Platine auch interessieren. Natürlich
möchte ich auch mithelfen die Daten zu dekodieren und die Software zu
entwickeln...
meine Mail: if38(at)arcor(punkt)de
Ich hatte eigentlich vor mir irgendwas zu basteln um die RC30 zu
ersetzen um z.B. am PC die Heizprogramme schnell zu ändern ohne die
rumdreherrei an der RC30. Sehe jedenfalls nicht ein 240€uro für
Service-Key und Kabel und nochmal 480Euro für die Software auszugeben.
Gruß
Ingo
Hallo,
ich habe mir auch gerade die Kommunikation auf dem EMS-Bus an der
Service-Buchse mitgeschnitten
Habe mal die decodierten Daten Telegramme bei mir gesucht und vermutlich
gefunden. habe meine Telegramme sind die unteren. Nach dem Trennstrich
stehen meine ermittelten ergebnisse. Die Außentemperatur scheint nicht
ganz zu stimmen. Das Telegramm mit der "Temperatur Warmwasser" ist bei
mir ein Zeichen kürzer.
Das erste Byte scheint wohl jeweils die BUS-Adresse zu sein die man in
der BC30 sehen kann. Wenn man an der RC30 z.B. die Temperatur verstellt
tauchen Telegramme mit 0x10 auf (RC30 Adresse =16)
Hier also meine Kabel:
Habe die Infos zur Service-Buchse hierher:
Beitrag "Buderus Bedieneinheit RC30"
LINKS : GND
RECHTS: SIGNALOFFSET +12V, +-2.5V Signalpegel (etwa)
GND : +12V
Da die Serielle Schnittstelle mit +-12V arbeitet und auch mit weniger
auskommt habe ich mal versucht die +-2,5V aus dem Service-Stecker zu
nehmen. Also GND (SubD9 Pin5) auf die +12V gelegt und auf RX (SubD Pin2)
auf "rechts" gelegt. Das TerminalProgramm habe ich auf 9.600 7 Even 1
eingestellt.
Kann es vielleicht sein dass der Dignosestecker bei GND auch wirklich
GND(0V) hat und auf Rechts das Signal(+-2,5V) und auf Links -12Volt?
Wenn nicht könnte es vielleicht Probleme geben wenn ein Rechner ans
Stromnetz angeschlossen ist. Ich habe mein Notebook mit serieller
Schnittstelle verwenden und über Batterie laufen lassen.
Der mittlere Kontakt und die Spitze scheinen die beiden Kabel zu sein
die zur RC30 gehen.
@Rudi:
Wie hast Du denn das Bild mit den Werten hinbekommen? Ist das ein
Programm dass Du selber geschrieben hast? Könnte man da schon mal eine
Testversion bekommen?
Gruß
Ingo
Hallo,
schön das es noch ein paar Leute gibt !
> Kann es vielleicht sein dass der Dignosestecker bei GND auch wirklich> GND(0V) hat und auf Rechts das Signal(+-2,5V) und auf Links -12Volt?
Nein, GND ist GND und von da gemessen sind die Signale so wie sie
offensichtlich sein sollen.
Wenn du die 12V als GND Potential genutzt sind es dann +-2,5V.
> Wie hast Du denn das Bild mit den Werten hinbekommen? Ist das ein> Programm dass Du selber geschrieben hast? Könnte man da schon mal eine> Testversion bekommen?
Mit gnuplot, wie gesagt schreibe ich die Daten in eine Datenbank und
werte sie dann aus.
Anbei noch ein Teilweises Skript ür meine Werte die ich bisher Ermittelt
habe (halt der Index!):
if ord(data[0]) == 0x08 and ord(data[2]) == 0x18:
t1 =
((ord(data[5])<<8)|ord(data[6]))/10.0
data_container.D_DB_TEMP_KESSEL
= change_value( D_DB_TEMP_KESSEL , data_container.D_DB_TEMP_KESSEL, t1 )
t2 = ord(data[11])
data_container.D_DB_CIRC =
change_value( D_DB_CIRC , data_container.D_DB_CIRC, t2 )
t3 = ord(data[21])/10.0
data_container.D_DB_BAR =
change_value( D_DB_BAR , data_container.D_DB_BAR, t3 )
print "TEMP KESSEL:",t1,t3
if (ord(data[11]) & 0x04) ==
0x04:
print "BRENNER",
if (ord(data[11]) & 0x80) ==
0x80:
print "ZIRK",
if (ord(data[11]) & 0x40) ==
0x40:
print "HK/WW",
if (ord(data[11]) & 0x20) ==
0x20:
print "HK Pumpe",
print "%02X" % (ord(data[11]) &
~0xe0)
if ord(data[0]) == 0x00 and ord(data[1]) ==
0x3D:
if ord(data[2]) == 0x02:
t1 = ord(data[3])/2.0
data_container.D_DB_TEMP_RAUM_GEST
= change_value( D_DB_TEMP_RAUM_GEST ,
data_container.D_DB_TEMP_RAUM_GEST, t1 )
print "TEMP RAUM GEST.:",t1
if ord(data[2]) == 0x07:
if ord(data[3]) == 0x00: print
"Einst. Nacht"
if ord(data[3]) == 0x01: print
"Einst. Tag"
if ord(data[3]) == 0x02: print
"Einst. Auto"
if ord(data[0]) == 0x08 and ord(data[1]) ==
0x33:
if ord(data[2]) == 0x02:
t1 = ord(data[3])/1.0
data_container.D_DB_TEMP_WASSER_GEST
= change_value( D_DB_TEMP_WASSER_GEST ,
data_container.D_DB_TEMP_WASSER_GEST, t1 )
print "TEMP WASSER GEST.:",t1
if ord(data[0]) == 0x08 and ord(data[2]) ==
0x19:
t1 =
((ord(data[4])<<8)|ord(data[5]))/10.0
data_container.D_DB_TEMP_AUSSEN =
change_value( D_DB_TEMP_AUSSEN , data_container.D_DB_TEMP_AUSSEN, t1 )
print "TEMP AUSSEN:",t1
if ord(data[0]) == 0x08 and ord(data[2]) ==
0x34:
t1 =
((ord(data[5])<<8)|ord(data[6]))/10.0
data_container.D_DB_TEMP_WASSER_WARM_1 =
change_value( D_DB_TEMP_WASSER_WARM_1 ,
data_container.D_DB_TEMP_WASSER_WARM_1, t1 )
t2 =
((ord(data[7])<<8)|ord(data[8]))/10.0
data_container.D_DB_TEMP_WASSER_WARM_2 =
change_value( D_DB_TEMP_WASSER_WARM_2 ,
data_container.D_DB_TEMP_WASSER_WARM_2, t2 )
print "TEMP WARMWASSER:",t1,
print "",t2
if ord(data[1]) == 0x3e and ord(data[2]) ==
0x00:
t1 = ord(data[7])/10.0
data_container.D_DB_TEMP_RAUM =
change_value( D_DB_TEMP_RAUM , data_container.D_DB_TEMP_RAUM, t1 )
print "TEMP RAUM:",t1
if ord(data[0]) == 0x00 and ord(data[1]) ==
0x06:
print
2000+ord(data[3]),ord(data[4]),ord(data[6]),ord(data[5]),":",ord(data[7]
),":",ord(data[8])
dump(data,len(data))
Have Fun!
> Ich hatte eigentlich vor mir irgendwas zu basteln um die RC30 zu> ersetzen um z.B. am PC die Heizprogramme schnell zu ändern ohne die> rumdreherrei an der RC30. Sehe jedenfalls nicht ein 240€uro für>Service-Key und Kabel und nochmal 480Euro für die Software auszugeben.
Ich sniffe nur um den optimalen Punkt für den Einsatz der Holzheizung zu
ermitteln. Steuerbefehle senden ist mir zu heiss ...
> Würde mich für die Schaltung oder Platine auch interessieren. Natürlich> möchte ich auch mithelfen die Daten zu dekodieren und die Software zu> entwickeln...
Ich habe grad 2 (mini) Platinen im der Queue. Es ist aber keine
Potentialtrennung vorgesehen. Der Kern der Schaltung ist ein ADCMP370.
Anbei noch der Schaltplan.
Also hat eine weile gedauert den Text zu formatieren und zu verstehen.
Das ist ja schon ein paar wichtige Daten.
Beim selber senden geht es mir auch mehr um die Heizungsprogramme mal
eben und schnell am PC zu erstellen. Mehr will ciha cuh garnicht in die
Regelung eingreifen. Mal sehen ob es irgendwann klappt.
Im Moment denke ich an einen Datenlogger mit USB-Anschluss zum Loggen
der Daten den man parallel zur RC30 anklemmen kann. Vermutlich würde ich
es dann als CSV-Datei abspeichern. Dafür nehme ich wohl einen PIC und
ein fertigen USB-PortAdapter für den USB-Stick.
Vielleicht kann man ja beide Schaltungen zusammenschmeissen..
Habe vor auch einen Datenlogger für die Heizung in JAVA zu schreiben.
Mit modelledit.rc-sim.de habe ich ja schon mal ein paar Erfahrungen
sammeln können. Vielleicht hat ja jemand Lust am Programm mitzuarbeiten.
Gru0ß
Ingo
> Vielleicht kann man ja beide Schaltungen zusammenschmeissen..
Da habe ich kein Interesse dran. Ich werde einen Netzwerkkontroller
benutzen (z.Z. sendet noch ein PC die Daten an den Server) und die
Platine einfach an das Board anschliessen.
> Vermutlich würde ich> es dann als CSV-Datei abspeichern.
Das kann ich dir bei der Datenmenge nicht empfehlen. Es sei denn dir
reichen die letzten Tage und der Rest wird gelöscht. Ich speicher alles
in die MYsql Datenbank und visualisiere mit Gnuplot die letzten 3 Tage.
Für Berechnungen ist eine einfache SQL-Anweisung, die dann über die
letzten Monate/Jahre geht, das Optimum.
> Habe vor auch einen Datenlogger für die Heizung in JAVA zu schreiben.> Mit modelledit.rc-sim.de habe ich ja schon mal ein paar Erfahrungen> sammeln können. Vielleicht hat ja jemand Lust am Programm mitzuarbeiten.
Ich bin da eher für eine automatisierte Lösung, die mir dann per
Webinterface die Daten liefert die ich brauche ;-)
Grüße.
> Wie kann man hier eigentlich die letzte "zitieren"? Also alles das was> grün ist....
Einfach per Hand ein "> " vor die Zeilen schreiben oder im Forum
anmelden.
> Ich bin da eher für eine automatisierte Lösung, die mir dann per> Webinterface die Daten liefert die ich brauche ;-)
Das hört sich ja super an... Aber dann muss man ja immer einen PC laufen
lassen, oder gibt es da auch andere Möglichkeiten?
Gruß
Ingo
> Das hört sich ja super an... Aber dann muss man ja immer einen PC laufen> lassen, oder gibt es da auch andere Möglichkeiten?
Ein PC bzw. ein kleiner Rechner muss laufen.
> Also hat eine weile gedauert den Text zu formatieren und zu verstehen.> Das ist ja schon ein paar wichtige Daten.
Es ist Python, sollte aber keine Probleme beim Lesen geben. Ist halt
rapid prototyping und die Rechner-Performance ist dafür soweit okay.
Grüße.
Hallo,
dank der hier stehenden Informationen bin ich mit der Auswertung der
Daten ein Stück vorwärts gekommen. Vielen Dank dafür.
Problematisch sehe ich noch die Auswertung der Telegrammlänge. Das
Messen der Pause zwischen 2 Telegrammen funktioniert mit dem WindowsPC
nur unzuverlässig.
Gibt es eine andere Möglichkeit, den Beginn und das Ende eines
Telegramms festzustellen? Ich kann keine Start- oder Ende-Bytes
erkennen.
Wie machen die das? Irgendwelche Ideen?
bye,
Mario
Hallo,
das mit der Laengenangabe im Header muesste man doch aber sehen.
Hier mal ein mitgeschnittenes Telegramm mit den bisher ermittelten bzw
vermuteten Bedeutungen zur Diskussion:
08 00 18 00 2F 01 C3 64 00 01 01 20 60 80 00 02 14 01 C1 00 01 0D 30 59
00 CC 00 00 00 F7 00
Byte0: Absenderkennung
Byte1:
Byte2: Funktionstyp ?
Byte3:
Byte4: Kesseltemp.Sollwert
Byte5+6: Kesseltemp. Istwert
Byte7: vermutl.Betriebsart
Byte8+9: vermutl.Abgastemperatur
Byte10+11: Brennerstatus
Byte12+13+14: unbekannt
Byte15+16: Warmwassertemp.
Byte17+18: Rücklauftemp.
Byte19+20: unbekannt
Byte21: Wasserdruck
Byte22+23: unbekannt
Byte24+25: Anlagentemp.
Byte26: unbekannt, immer 00
Byte27: vermutl.Betriebsart
Byte28: unbekannt, immer 00
Byte29: Checksum
Byte30: unbekannt, immer 00
Für die Länge des Telegramms ist kein passender Wert vorhanden.
Irgendwelche Ideen?,
Mario
Sind Byte1 und Byte3 immer 00?
Was kommt denn für ein Datensalat vor und nach dem Telegramm, kann es
vielleicht sein dass das Protokoll ein stop und Startcode im
Telegrammstil verschickt?
Ich kann mir schwer vorstellen, dass Start/Stop eines Telegramms nur
über Zeitfenster gemacht wird wenn die telegramme unterschiedlich lang
sind.
Leider habe ich jetzt aber auch nicht wirklich ne weitere Idee,
vielleicht könnte mal jemand nen BUS dump über ein paar minuten hier
reinposten, so dass ich mich damit auch mal befassen kann (habe ja
bisher noch nicht die möglichkeit, die logamatic direkt anzuzapfen
hier...)
Gruss, Malte
Sodele. Ich werde aus dem geposteten Dump von Malte (ich werd
schizophren) noch nicht ganz schlau.
Ich habe mich aber gerade nochmal über das Kabel zur Bedieneinheit
(direkt an der Logamatic 2107) hergemacht. Bewaffnet mit Oszilloskop bin
ich jetzt mal soweit gekommen und stelle das mal zum Brainstorming:
Es geht um das 26polige Flachbandkabel, dort habe ich einen dritten
Stecker draufgecrimpt und mal fleissig gemessen. Pinangaben beziehen
sich auf den roten draht als Pin #1.
Gemessen habe ich immer gegen Pin2 als GND
1
01 +5V - Versorgungsspannung? An der stelle steht ein "+" auf der Platine
2
02 GND
3
03 5V gemessen, vielleicht ein binärer E/A?
4
04 5V gemessen, vielleicht ein binärer E/A?
5
05 0V gemessen, vielleicht ein binärer E/A?
6
06 0V gemessen, vielleicht ein binärer E/A?
7
07 NC / Nicht an der Platine angeschlossen, gemessen 50hz 0,4V AC (also nix)
8
08 0V gemessen, vielleicht ein binärer E/A?
9
09 0V gemessen, vielleicht ein binärer E/A?
10
10 0V gemessen, vielleicht ein binärer E/A?
11
11 0V gemessen, vielleicht ein binärer E/A?
12
12 0V gemessen, vielleicht ein binärer E/A?
13
13 0V gemessen, vielleicht ein binärer E/A?
14
14 0V gemessen, vielleicht ein binärer E/A?
15
15 TTL Signal Low-Aktiv, feste Pulsbreite, unregelmässiges Signal, könnte Frame start interrupt sein
16
16 TTL Signal variable Pulsbreite, sieht nach Datenübertragung aus
17
17 TTL Signal variable Pulsbreite, sieht nach einem Enable Signal aus
18
18 TTL Signal variable Pulsbreite, sieht nach einem Enable Signal aus
19
19 5V gemessen, vielleicht ein binärer E/A?
20
20 5V gemessen, vielleicht ein binärer E/A?
21
21 0V gemessen, vielleicht ein binärer E/A?
22
22 TTL Signal variable Pulsbreite, sieht nach Datenübertragung aus
23
23 Datenübertragung Differential zu pin 24
24
24 Datenübertragung Differential zu pin 23
25
25 50hz sinus der fast wie dreieck aussieht 0,16V AC gemessen, ab und zu störungen messbar
26
26 NC / Nicht an der Platine angeschlossen, identisches Signal wie bei Pin 25
Meiner Meinung nach sollte man mal Augenmerk auf die Pins 15-18 legen.
Mir ist beim Vergleichen verschiedener Signale zueinander (2. Kanal am
Oszilloskop) auffgefallen, dass Flanken unterschiedlicher Signale immer
gleichzeitig auftreten. Ich gehe deshalb davon aus, dass die
Datenübertragung asynchron funktioniert, ich habe nirgendwo ein clock
signal gefunden (feste frequenz).
Das einzige Signal mit fester Pulsbreite ist Pin15, kann aber kein Clock
sein, ich vermute aber dass mit diesem Signal ein Frame start auf
anderen Datenleitungen (würde zu Pin16 passen) darstellt.
Leider bin ich halt immer noch nicht im Besitz eines Logikanalyzers.
Mehr aussagen kann ich deshalb nicht machen :(
Gruss, Malte
Also so weit ich gesehen habe werden immer 2Byte verschickt. das erste
Byte ist die BUS-Adresse und das zweite meistens 0x00 oft kommen auch
telegramme mit Werten von 0x80 oder größer mit dem zweiten Wert 0x00
gesendet werden. Vermute mal dass es wohl Kollisionen von zwei
Busteilnehmern sind. Also wenn man was senden möchte werden vermutlich
erst mal die zwei Byte geschickt und gleichzeitig mitgelesen. Wenn Beide
Werte gleich sind wird weitergesendet.
Oft treten auch nur 2Byte Telegramme auf wie 0x09 0x00 und 0x10 0x00.
Sieht wohl ao aus als ob dass dann vielleicht ein "Hallo ich lebe noch"
ist.
Prüfsummen oder Telgrammlängen konnte ich nicht finden.
Das dritte Byte scheint (meistens) der Telegrammtyp zu sein. Also müsste
man sich eine kleine Tabelle anfertigen aus der man mit den zweiten bis
vierten Byte die Telegrammlänge ablesen kann.
@Malte:
würde fast vermuten dass Pin 23 und 24 auch so eine Art BUS ähnlich dem
Service-Stecker darstellen, oder?
Gruß
Ingo
Ja, das hatte Rudi schon "vermutet" - er meint aber es waeren 50KHz
signal.
Kann ich nichts zu sagen, da ich nur einen 2kanal echtzeit LA habe
(oszilloskop ;)
Aber mich hat es eben nicht in ruhe gelassen, habe mich gerade nochmal
im Heizraum vergnügt und versucht die logikpins zuzuordnen.
Es hat sich jetzt herausgestellt, dass
1
09 Ausgang Heizkreis1 Pumpe (an=5V, aus=0V)
Also kann man getrost davon ausgehen, dass es auch TTL Ausgänge (und
vielleicht auch Eingänge) gibt.
Speicherladepumpe konnte ich noch nicht ermitteln. Muss mal die
Temperatur hochregeln, damit der schaltet.
"Brenner An" ist kein digitaler Ausgang! Der Befehl scheint per BUS
übermittelt zu werden, also sucht nicht danach.
Ich versuche mal demnaechst, ob ich die TTL Datenleitung mittels MAX232
abhören kann.
Gute Nacht, Malte
Timing Log ?
Kein Problem ! (ist bzip2 komprimiert und reiner text)
Aufbau:
C2CTIME TIME CHAR
C2CTIME: char to char time (gemessene Zeit zwischen den Zeichen)
C2CTIME: 1318 90 # timeout neue msg (char 0)
C2CTIME: 104 00 # (char 1)
C2CTIME: 218 10 # (char 2)
C2CTIME: 218 00 # (char 3)
C2CTIME: 1941 89 # timeout, zeichen ist gehört zu neuer msg
90 00 10 00 # log output (4 zeichen)
usw.
Leider kann ich bisher nur über die Zeit ein Frame erkennen. Es ist
bestimmt etwas anders und die Module senden mit unterschiedlichen Zeiten
(siehe dieses Beispiel). Der Timeout liegt bei 350.
Grüße.
Mario wrote:
> Problematisch sehe ich noch die Auswertung der Telegrammlänge. Das> Messen der Pause zwischen 2 Telegrammen funktioniert mit dem WindowsPC> nur unzuverlässig.
Ich habe es direkt mit einem uC gemessen (50mhz cortex) und dann die
Daten mit der Zeit über die Serielle an einen PC geschickt. Die Zeiten
sind alle im sub-ms bereich, also nicht praxistauglich für einem PC.
Ich hoffe ja noch das es sich um eine CRC in den Daten handelt.
Ich gehe davon aus das die 2 bytes ein Modul ansprechen und dann dieses
Modul in einer gewissen Zeit antwortet oder auch nicht. Evtl. liege ich
da auch falsch.
Grüße.
Malte wrote:
> Ich versuche mal demnaechst, ob ich die TTL Datenleitung mittels MAX232> abhören kann.
Ich werde parallel per uC über den ADC die Daten sampeln. Leider nur 1
Kanal, sollte aber auch etwas zu sehen und zu diskutieren geben. Ich
habe evtl. am Fr. wieder einen "Termin" beim Kumpel der die Heizung sein
eigen nennt ...
Bei meinen vorherigen Tests mit dem Scope konnte ich leider keine Start
und Stopbits erkennen.
Grüße.
Hallo,
das Modul für die Logamatic 2107 ist ja das KM271 um eine serielle
Schnittstelle zu erhalten. Vielleicht hat ja jemand so ein Modul und
kann uns mal ein hochauflösendes Fotos schicken - vielleicht kann man
dann erkennen welche Leitungen auf dem Bus benutzt werden und evtl sogar
welche Hardware für die Pegelanpassung verwendet wird.
Martin
Also ich schaue mir mal Pin16 und 22 an. Da es sich dort um TTL Level
handelt gehe ich fast schon davon aus, dass es sich um eine serielle
kommunikation zwischen dem Bedienpanel und der Hauptplatine handelt.
Wenn dem so ist hätten wir ja schon fast den jackpot.
Pin23/24 sieht ja wirklich so aus wie du den ServiceKey beschrieben
hast.
Auch vom Bild auf dem skope her sieht es wie ein bus aus - ne weile ruhe
und dann kurze bursts mit variabler pulsbreite.
Aber mal zurück zum Protokoll: ich habe mir gerade mal die EBUS
Spezifikation angeschaut, aber laut euren beiden BUS Logs hat das nicht
viel damit zu tun:
>ACK = 00h>NACK = FFh>SYN = AAh>QQ ZZ PB SB LEN DB1 DB2 DBn CRC (ACK) SYN
@Malte Kippis:
Deine beiden geposteten Logs sind schrott oder?
Jedenfalls unterscheiden die sich gravierend von Rudi's Capture...
Gruss, Malte
Hallo,
hiermit müsste sich ja feststellen lassen welche Pinne auf dem
Flachbandkabel auch an den Steckplatz K4 gehen (siehe Malte Bayers
Messungen) - ich sehe da im Moment 1-10 und 1-20 als Kanditaten. Leider
hatte ich damals kein Scope zur Verfügung um genau zusehen wie das
"Schwingen" aussieht.
Evtl ist es ja ein einfacher RS485 auf RS232 Wandler.
@Malte - vielleicht kannst du mal nachmessen welche Pinne des
Flackbandkabels auf die Pinne 1-10 und 1-20 der Relay Platine gehen die
auf die Bus Platine geht.
Martin
Hallo,
>Aber mal zurück zum Protokoll: ich habe mir gerade mal die EBUS>Spezifikation angeschaut, aber laut euren beiden BUS Logs hat das nicht>viel damit zu tun:
Die Ausgabe des Service-Keys den man bei Buderus kaufen kann ist auch
komplett anders und ähnlich Deinem Geposteten LOG. Wenn man aber direkt
an den Stecker geht und auf den BUS-hört kommen die geposteten Logs
heraus.
Der Service-Key (und wohl auch der RS232Gateway für den EMS-Bus) setzen
dann die Befehle auf den BUS um.
Ist also kein reiner Schnittstellenwandler.
Vermutlich kommen auch deswegen die vielen 2Byte Telegramme > 0x80 am
Anfang. Scheinen dann wohl Kollisionen zu sein. Am Service-Key wird man
davon nichts mitbekommen.
Gruß
Ingo
Ich habe den ServiceKey-Bus mal analog gemessen und eine wav-Datei
erstellt. Die kann man sich sehr leicht mit audacity etc. anschauen.
Evtl. kann nochmal jemand rüber schauen ob es wirklich mit uart 8n1 9600
ausgelesen werden kann oder ob es dort noch versteckte bits (ack/nack)
gibt.
Ich habe nochmal die Spec. vom Prozessor, bezüglich UART, gelesen und
die Daten gesichtet. Der 8n1 9600 Mode ist okay.
Das Nullbyte am Ende jeder Nachricht ist die Ende-Kennung bzw. ein UART
Break Error. Es wird ein 0-Byte gesendet bei dem das Stopbit auf logisch
0 bleibt. Bei diesem Fehler wird vom Prozessor ein 0-Byte in den
Bytestream eingefügt. Wird nach dem ersten Byte ein 0-Byte mit Stopbit 1
geschickt, folgen die Daten bis zum 0-Byte mit Stopbit 0.
Die möglichen Transfermodis sehen also so aus:
<ADDR> <0x00 (STOPBIT 1)> <DATA (STOPBIT 1)> <0x00 (STOPBIT 0)>
<ADDR> <0x00 (STOPBIT 0)>
@Malte Bayer
Meinst du die mit deinen Pins 3 & 4 die Pinne die ich auf dem Bild
gekennzeichnet habe ???
Beitrag "Re: Logamatic 2107 Schnittstelle"
Dort kommen Daten, dauert aber eine kleine Ewigkeit. Das sind die 50KHz
die ich gemessen habe !
@Rudi, ja genau das Flachbandkabel meine ich. Du meinst aber Pins 23 und
24, der rote draht ist 1, nicht 26 ;)
Auf dem Kabel gibt es noch TTL pegel Datenübertragung auf Pin 15 bis 18,
die werde ich demnächst mal näher untersuchen, da ich momentan auch kein
Material habe um das Differenzialsignal auszukoppeln. Ich bin sowieso
ein TTL Mensch, bei 5V fühl ich mich wohl, kümmer du dich ruhig weiter
um die anderen Signale, du hast da bestimmt viel mehr Ahnung von! :-)
Im nachhinein bereue ich es glaube ich schon, dass ich so faul war und
da ne Logamatic eingebaut habe - haette den Kessel ohne Steuerung
bestellen sollen.
Aber jetzt hat mich auch der Ehrgeiz gegriffen - das muss doch zu
knacken sein. Auch wenn es total "unwirtschaftlich" ist, da Stunden an
Zeit reinzuhauen, den Spass ist es mir wert, ausserdem lernt man ja nie
aus, nich wahr? :-P
Gruss & schoenes Wochenende,
Malte
Hallo Malte,
vielleicht kannst du mal nachmessen welche Pinne des
Flackbandkabels auf die Pinne 1-10 und 1-20 der Relay Platine gehen die
auf die Bus Platine geht (siehe mein Bild oben).
Danke.
Martin
> Aber jetzt hat mich auch der Ehrgeiz gegriffen - das muss doch zu> knacken sein. Auch wenn es total "unwirtschaftlich" ist, da Stunden an> Zeit reinzuhauen, den Spass ist es mir wert, ausserdem lernt man ja nie> aus, nich wahr? :-P
Kommt drauf an was man mit den Daten anfängt. Mir geht es um die
Kostenverteilung von Wasser und Heizung und dann per Holz die Heizkosten
drücken. Da ich auch den Gaszähler angezapft habe, seh ich die Kosten
mehr oder weniger direkt (der Gaszähler ist halt nur Mechanik).
Ansonsten ist das schon etwas Arbeit die man dafür investieren muss.
Wenn ich mir aber die Preise von diesem Zubehör anschaue dann hat es
sich für mich bisher auf alle Fälle gelohnt. Geld und Lernfaktor.
@Malte Bayer
> die werde ich demnächst mal näher untersuchen, da ich momentan auch kein> Material habe um das Differenzialsignal auszukoppeln.
Kannst du mal ein paar Infos zu dem Signal posten ? Welche Pegel zu GND
? Bei mir hat das Signal auf dem EMS-Bus einen Offset von 12V +-2.5V
Signal. Hast du dort evtl. 12V und die Signalleitung mit dem 12V Offset
?
@ Rudi:
Pin 23 und 24 gegen GND im Ruhezustand +4,9V bei Datenübertragung fällt
Spannung an beiden Pins zu unterschiedlichen Zeiten ab.
Differenzspannung zwischen 23 und 24 bei Datenübertragung = +/- ca 3,8V
Pulsabstand so wie ich das sehe ca 8 Mikrosekunden (bekomme ich nur mit
der Hold on Trigger funktion halbwegs zu sehen).
Also es ist doch nicht ganz das was du am Service key hast, gegen GND
sind beide Leitungen entweder 4,9V oder irgendwas zwischen 0 und 1V.
Wenn ich Pin23 als GND verwende und dann Pin24 messe bekomme ich
Positive und negative Peaks, also bilden beide Leitungen zusammen eine
AC Datenübertragung mit Pegel bei ca +/- 3,8V.
@ Martin:
Dein 1-10 und 1-20 ist exakt identisch mit Pin23 und Pin24 auf dem
Flachbandkabel zwischen der Platine NM282 und dem Bedienpanel.
(habe es mit dem Oszi verglichen, nicht mit durchgangsprüfer, so
wahnsinnig bin ich dann doch nicht ;)
@all:
Die 2 TTL Signalübertragungen bringen mir bei allen Standardbaudraten
über einen Max232 mit allen Kombinationen aus Stoppbits und parity nur
müll an, scheinbar also keine asynchrone serielle Übertragung. (bin
immer von 8bits ausgegangen).
Update:
1
01 +5V - Versorgungsspannung? An der stelle steht ein "+" auf der Platine
2
02 GND
3
03 5V gemessen, vielleicht ein binärer E/A?
4
04 5V gemessen, vielleicht ein binärer E/A?
5
05 0V gemessen, vielleicht ein binärer E/A?
6
06 0V gemessen, vielleicht ein binärer E/A?
7
07 NC
8
08 0V gemessen, vielleicht ein binärer E/A?
9
09 Ausgang Heizkreis1 Pumpe (an=5V, aus=0V)
10
10 0V gemessen, vielleicht ein binärer E/A?
11
11 0V gemessen, vielleicht ein binärer E/A?
12
12 0V gemessen, vielleicht ein binärer E/A?
13
13 0V gemessen, vielleicht ein binärer E/A?
14
14 0V gemessen, vielleicht ein binärer E/A?
15
15 TTL Signal Low-Aktiv, feste Pulsbreite, unregelmässiges Signal, könnte Frame start interrupt sein
16
16 TTL Signal variable Pulsbreite, sieht nach Datenübertragung aus
17
17 TTL Signal variable Pulsbreite, sieht nach einem Enable Signal aus
18
18 TTL Signal variable Pulsbreite, sieht nach einem Enable Signal aus
19
19 5V gemessen, vielleicht ein binärer E/A?
20
20 5V gemessen, vielleicht ein binärer E/A?
21
21 0V gemessen, vielleicht ein binärer E/A?
22
22 TTL Signal variable Pulsbreite, sieht nach Datenübertragung aus
23
23 Datenübertragung Differential zu pin 24
24
24 Datenübertragung Differential zu pin 23
25
25 50hz sinus der fast wie dreieck aussieht 0,16V AC gemessen, ab und zu störungen messbar
Hallo Rudi,
>Ich habe den ServiceKey-Bus mal analog gemessen und eine wav-Datei>erstellt.
Bei welcher Anlage/Steuerung hast Du die aufgezeichnet.
>Anbei noch ein paar Frames die ich aus den analogen Daten extrahiert>habe.
Na da warst Du aber Fleissig....
Oder hast Du da irgend ein Programm über die WAV-Datei laufen lassen die
die Daten dekodiert hat?
Denke da ist aber ein Fehler drin. Das LSB wird seriell als erstes
übertragen. z.B. habe ich aus der Datei ein Telgrammanfang ermittelt der
mit 08 00 18 00 97 01 0b 64... anfängt. Die Telegramme kann ich auch in
meinem log auf dem COM-Port wiederfinden. Wenn ich dann LSB und MSB
tausche komme ich auf ein Telegramm 10 00 18 00 E8 80 D0 26.....
Habe dort auch dann beim letzten Byte eines Telegrammes das Stopbit 0
Seltsamerweise zeigt mein Programm auf der seriellen Schnittstelle
keinen Fehler an obwohl das ja eigentlich ein Frameerror sein sollte.
(HTerm 0.8.1) und würde auch gerne das über den Soundkarten Oszilloskop
nachmessen. Aber irgendwie klappt das nicht.
Hast Du noch irgend eine spezielle Schaltung gehabt um diese Datei
aufzunehmen? Oder einfach nur mit der Soundkarte?
Mein Laptop hat leider nur einen MIC-Eingang und kein Line-In Eingang.
Dort konnte ich mit der Soundkarte kein vernünftiges Signal bekommen.
nur kleine negative oder positive Hügelchen wenn das Signal von 0 auf 1
oder in die andere Richtung wechselt.
Sollte man vielleicht vielleicht ein eigenen Thread für die
4000-Steuerung mit Service-Key aufmachen? Das hat ja eigentlich nichts
mit der 2107 zu tun, oder?
Gruß
Ingo
@IngoF
> Bei welcher Anlage/Steuerung hast Du die aufgezeichnet.
Bei der aus dem Bild:
Beitrag "Re: Logamatic 2107 Schnittstelle"> Oder hast Du da irgend ein Programm über die WAV-Datei laufen lassen die> die Daten dekodiert hat?
Ich konvertiere das Signal vom Bus auf 3V3-Pegel (siehe Schaltung) und
bin dann mit einem ADC an das Signal gegangen. Ich habe mit 300K-Samples
aufgezeichnet. Leider sind die Daten nicht wirklich analog, es wird nur
auf 1V5 getriggert, ansonsten hätte ich die Daten nicht auf den PC
bekommen.
Die Rohdaten habe ich dann in eine wav gewandelt und mir mit audacity
angeschaut. Der Parser ist über die Rohdaten gegangen und nicht über die
wav-Datei.
> Denke da ist aber ein Fehler drin. Das LSB wird seriell als erstes> übertragen. z.B. habe ich aus der Datei ein Telgrammanfang ermittelt der
Das würde wohl auch meine glücklosen Versuche, die CRC zu berechnen,
erklären.
> Seltsamerweise zeigt mein Programm auf der seriellen Schnittstelle> keinen Fehler an obwohl das ja eigentlich ein Frameerror sein sollte.> (HTerm 0.8.1) und würde auch gerne das über den Soundkarten Oszilloskop> nachmessen. Aber irgendwie klappt das nicht.
Ich habe mal andere Sachen mit dem Soundkarten Oszi gemessen, ging ganz
gut wenn 48KHz ausreiched sind. Dieser Break-Fehler ist ja mehr oder
weniger Hardwareabhängig.
> Dort konnte ich mit der Soundkarte kein vernünftiges Signal bekommen.> nur kleine negative oder positive Hügelchen wenn das Signal von 0 auf 1> oder in die andere Richtung wechselt.
Das Signal kannst du so nicht messen, da es sich um ein DC-Signal
handelt. Hinter dem Eingang kommt direkt ein Kondensator der nur den
AC-Anteil an die Soundkarte weiterleitet.
Ich habe mit einem cortex gemessen und dann über Netzwerk die Daten
übertragen. Leider hat das Biest keine DMA und aus diesem Grund konnte
ich keine echten Analog-Werte sampeln, da es die CPU nicht mehr
geschafft hat die Daten zu übertragen.
> Sollte man vielleicht vielleicht ein eigenen Thread für die> 4000-Steuerung mit Service-Key aufmachen? Das hat ja eigentlich nichts> mit der 2107 zu tun, oder?
Warten wir erstmal ab was bei der 2107 am Bus anliegt.
@Malte Bayer
> Pin 23 und 24 gegen GND im Ruhezustand +4,9V bei Datenübertragung fällt> Spannung an beiden Pins zu unterschiedlichen Zeiten ab.> Differenzspannung zwischen 23 und 24 bei Datenübertragung = +/- ca 3,8V> Pulsabstand so wie ich das sehe ca 8 Mikrosekunden (bekomme ich nur mit> der Hold on Trigger funktion halbwegs zu sehen).
Ich hatte damals diese beiden ganz gut messen können (zu GND). Wie schon
gesagt habe ich dort die 50KHz Signal gemessen (20uS).
Ich hoffe nächste Woche ist das Kabel bei der Heizung und dann kann ich
das mal aufnehmen.
Hallo Rudi,
Also mit den Frameerror habe ich inzwischen nachvollziehen können. Dazu
habe ich HTerm genommen und 9600 8N1 eingestellt. Am PC musste ich dann
noch am FIFO-Interupt Trigger Level den Wert auf 1 stellen, damit nach
jedem Byte ein Interrupt erzeugt wird. Wenn der Wert nicht verstellt
wird gibt es nur Overflow-Errors.
Die Roten Werte sind also dann nur noch die Frameerror. Wenn mehrere
Werte hintereinander rot gekennzeichnet sind liegt dass daran dass die
Werte zusammen mit einem 00-Byte mit Frameerror empfangen wurden. Also
ist nicht alles Rote auch wirklich ein Frameerroe.
Soweit ich sehen kann werden die Frameerrors nur erzeugt wenn Nach der
Adresse keine Daten mehr kommen.
man kann zwei 08-Telegramme sehen die hintereinander folgen. Hier kann
man sehen (Statusleiste unten)dass dort ein Abstand von etwa 170ms
kommt.
>Leider sind die Daten nicht wirklich analog, es wird nur>auf 1V5 getriggert, ansonsten hätte ich die Daten nicht auf den PC>bekommen.
Na das erklärt die super sauberen Flanken und absolut keine Störungen...
Habe mich auch schon gewundert warum bei 100KHz-Samplingrate (laut
Dateiinfo 100kHz/16Bit) dann nur die Übertragungsrate zwischen bei etwa
3600 Bit/s lag. Habe dann zum Spass mal zurückgerechnet und bin
rechnerisch auf 278kHz gekommen.
Hab sowas schon vermutet dass ein Kondensator der Übeltäter ist. Hatte
dann vermutet dass der Line-In vielleicht nicht so einen Kondendator hat
und es dann damit geklappt hätte.
Gruß
Ingo
P.S.:
noch vergessen:
Die Zeit wird zwischen den beiden blau hervorgehobenen Bytes gemessen
Am Anfang kommt nach allen zwei Bytes ein Frameerror nach einiger Zeit
kommen nach auf einmal viel weniger Frameerrors. Vielleicht liegt das an
Windows (Programmpriorität?)
Wenn das also alles so stimmt wie es dort angezeigt wird kommen die 00
mit Frameerror direkt nach der Adresse wenn keine weiteren Daten
gesendet werden.
Alles was über >=0x80 ist könnte vielleicht eine Art Statusänderungen
sein oder vielleicht Kollisionen. Aber in Deiner WAV-Datei sieht es eher
so aus als ob das keine Kollisionen sind...
Oder liege ich da falsch?
Gruß
Ingp
@IngoF
> Soweit ich sehen kann werden die Frameerrors nur erzeugt wenn Nach der> Adresse keine Daten mehr kommen.
Ja genau, siehe hier:
Beitrag "Re: Logamatic 2107 Schnittstelle"
Es gibt auch Adressen mit keiner 0. Das habe ich erstmal Timeout
genannt, danach wird sehr lange (relativ) nichts auf dem Bus gesendet.
> Na das erklärt die super sauberen Flanken und absolut keine Störungen...> Habe mich auch schon gewundert warum bei 100KHz-Samplingrate (laut> Dateiinfo 100kHz/16Bit)
;-)
Beim Import habe ich zwar 300KHz angegeben, aber audacity hat es nach
dem Import auf 100KHz gestellt. Scheint ein Bug zu sein.
> Die Roten Werte sind also dann nur noch die Frameerror. Wenn mehrere> Werte hintereinander rot gekennzeichnet sind liegt dass daran dass die> Werte zusammen mit einem 00-Byte mit Frameerror empfangen wurden. Also> ist nicht alles Rote auch wirklich ein Frameerroe.
Das liegt nur am FIFO. Habe ich im Datenblatt zum cortex auch gelesen.
Es wird nur angeben das bei den Daten im FIFO ein Fehler aufgetreten
ist, aber nicht bei welchem Byte.
> Am Anfang kommt nach allen zwei Bytes ein Frameerror nach einiger Zeit> kommen nach auf einmal viel weniger Frameerrors. Vielleicht liegt das an> Windows (Programmpriorität?)
Das kann ich dir nun nicht erklären, aber die Frameerrors sind
definitiv auf dem Bus.
Hast du schon Daten gesehen bei denen an zweiter Stelle keine 0 steht,
wie bei meinen "falschen" Daten weiter oben (alle Bits gedreht) ?
Die Adressen auf dem Bus zeigt dir die Anlage im Service Menu. Ich muss
selbst nochmal schauen welche Adressen bei mir auf dem Bus liegen, es
waren glaube ich 4 Geräte.
Laut Servicemenü:
0x08 UBA3/MC10
0x09 BC10
0x10 RC30
Eigentlich habe ich bisher noch keine Daten gesehen bei der nach der
Adresse keine 00 kommt. Allerdings habe ich auch kein Programm was mir
die Arbeit abnimmt und die Daten oder telegramme decodiert.
Vielleicht sollte ich mich mal ein daran machen...
>Es gibt auch Adressen mit keiner 0. Das habe ich erstmal Timeout>genannt, danach wird sehr lange (relativ) nichts auf dem Bus gesendet.
ja, die waren aber immer >=80 (Bit7 gesetzt) vielleicht ist das ja
irgend ein Status von irgendwelchen Anlagenteilen.
> Eigentlich habe ich bisher noch keine Daten gesehen bei der nach der> Adresse keine 00 kommt. Allerdings habe ich auch kein Programm was mir> die Arbeit abnimmt und die Daten oder telegramme decodiert.
Wenn du auf deinem Rechner python installieren kannst, dann könnte ich
dir ein paar Programmteile für die Kommunikation zukommen lassen. Da wir
jetzt mehr oder weniger die Daten kennen, bräuchte man nicht unbedingt
auf den Frame-Error achten.
Wenn du dich für python entscheidest, dann brauchst du noch pyserial für
die Kommunikation.
Mit python ist es erstmal easy going ...
Habe es inzwischen hinbekommen wie man sieht werden alle Telegramme mit
einer 00 mit Stopbit 0 beendet. Der Bildschirmaufbau hat die Ergebnisse
verfälscht. Wenn mann das Fenster so stark verkleinert dass nur noch die
Schaltflächen [Clear received] und [Connect] werden die korrekten Werte
angezeigt.
nach jedem 08 00 kommt ein Zeilenumbruch. Jetzt kann man schon viel
besser die Telegramme finden...
Gruß
Ingo
Das sieht doch schon gut aus. Ich sehe da auch 10 00. Das würde die
Theorie mit dem Status etwas über den Haufen werden. Ich behaupte
einfach mal das der Bus ganz stumpf gepollt wird. Wenn ein Gerät etwas
zu sagen hat dann antwortet es, ansonsten nicht.
Also ich sehe hier Timeouts bei Adresse 0x11,0x18 und 0x19.
Ich habe mal die ADC-Daten und den Parser angehängt. Der Parser is in
python geschrieben. Dort werden die Bits ausgewertet und dann auf
UART-Protokoll auf 8n1 gewandelt. Du kannst die Timeouts sehen, und den
Rest der Daten. Daten mit nur einem Byte (<ADDR> <0x00>) werden nicht
angezeigt.
Die ADC-Daten sehen wie folgt aus. Ein Wert besteht aus 2 Bytes. Das
erste Byte ist die Anzahl und das zweite Byte ist der Pegel (0/1).
@Rudi:
Also bei mir kommt nachdem ich "12345" durch den Dateinamen ersetzt habe
und das "Import Serial" gelöscht habe nur folgende Ausgabe:
1
out
2
11 timeout 2252
3
11 timeout 2252
4
19 timeout 2201
Wenn ich den Import nicht lösche wird rumgemeckert dass kein Modul
Serial eristiert. Habe irgendwo pyserial gefunden und versucht zu
installieren. meckert dann aber dass er win32file nicht findet.....
Wusste nicht dass bei Windows XP schon automatisch Phyton mitgeliefert
wird... Habe vorher eigentlich noch nie was von Phyton gehört...
Evtl. hat ein Programm python installiert. Mit Windows wird es meines
Wissens nicht mitgeliefert.
Das Modul serial ist nur für die serielle Kommunikation gedacht. Ich
habe es hier mit python 2.5 und 2.6 getestet und es funktioniert. Die
Ausgabe sieht wie folgt aus:
Info zur Logomatic 2107
und Post Beitrag "Re: Logamatic 2107 Schnittstelle"
Sockel K4
PIN 3,4,5,6
Gehen zum KM 271 RS232 Interface.
Siehe hier:
Beitrag "Re: Buderus Ecomatic 4000"
Hier nochmal ein Aufruf:
------------------------
Falls jemand im Besitz der KM 271 Platine ist, würden wir uns sehr über
hochauflösende Bilder von beiden Seiten freuen (Aufkleber bitte vorher
entfernen) !
Danke!
@IngoF
Könnten die Daten evlt. als 9n1 geschickt werden ? Ich habe mir das
Timing jetzt nicht angeschaut (ob das Stopbit dann noch passt), aber
dann bräuchte man nicht über diesen Frame-Error Fehler gehen, sondern
könnte direkt in den 9 Bit das Ende erkennen ???
Nein,
Das war ja auch mein erster Gedanke. Aber es werden 10Bit übertragen.
(1 Startbit + 8Datenbit + 1 Stopbit). Und es gibt keine Möglichkeit wie
1 Startbit + 8 Datenbit + 1 Parity Mark + 0 Stopbit. Das Parity-Bit wird
außerdem genauso ausgewertet wie der Frameerror. Es gibt auch nur 5-8
Bit Datenübertagung, 9 Bit ist nicht möglich.
Werde mich mal an ein JAVA-Testprogramm machen...
Zur 2107
Die Leitungen:
23 Datenübertragung Differential zu pin 24
24 Datenübertragung Differential zu pin 23
sind gegen GND jeweils eine Datenleitung und eine Clockleitung. Ich
konnte heute Messungen aufnehmen und Oszi-Bilder machen. Diese beiden
Signale tauchen auch auf K4 (für das RS232-Interface) auf. Die CLK ist
etwa 44KHz und es werden (auf den ersten Blick) 9 oder 10 Bits
verschickt.
Hallo Rudi,
seeeeeehr gut! Sehe ich das richtig? Gültige Daten bei fallender Flanke?
Wie hast du das .wav File aufgenommen? Evtl. Spanungsteiler vor eine
Soundkarte und dann linke Kanal Takt und rechter Kanal Daten.
Oder einen Mikrocontroller der bei fallender Flanke guckt was an
DatenPin anliegt und dann eine 0 oder 1 seriell rausschreibt. Das ganze
dann eine Zeitlang aufzeichnen. Meistens "sieht" man dann die logischen
Blöcke schon in Hyperterminal oder einem anderen Terminalprogramm.
Kommen denn ständig Daten oder ist da auch eine "längere" Pause zwischen
Blöcken?
Martin
> Wie hast du das .wav File aufgenommen? Evtl. Spanungsteiler vor eine> Soundkarte und dann linke Kanal Takt und rechter Kanal Daten.
Die Soundkarte ist zu langsam und kann nur analoge Daten aufnehmen. Die
Schaltung siehe oben und dann per ADC augenommen, der ADC ist aber zu
langsam wie man bei einigen Daten sieht.
> Oder einen Mikrocontroller der bei fallender Flanke guckt was an> DatenPin anliegt und dann eine 0 oder 1 seriell rausschreibt. Das ganze> dann eine Zeitlang aufzeichnen. Meistens "sieht" man dann die logischen> Blöcke schon in Hyperterminal oder einem anderen Terminalprogramm.
So will ich es nochmal versuchen, bei einer Bitrate von 44KHz sollten
die Daten problemlos über eine 115KBaud serielle mit FIFO gehen. Dann
ist die CLK wenigstens direkt mit bei.
Zwischen den "Blöcken" ist eine längere Pause und wie man in der
wav-Datei sieht, kommen die Daten kontinuierlich.
Hallo Rudi,
ich befürchte nur, da es sich um eine synchrone Übertragung handelt,
sich der Dateineingang noch auf einem anderen Pin befindet als der
Ausgang.
Aber sicherlich auf einem der wieder nur auf K4 anliegt....
Martin
> ich befürchte nur, da es sich um eine synchrone Übertragung handelt,> sich der Dateineingang noch auf einem anderen Pin befindet als der> Ausgang.> Aber sicherlich auf einem der wieder nur auf K4 anliegt....
Wenn es sich um einen Bus handelt, dann ist IN==OUT. Evtl. gibt es noch
ein BUS-Select o.ä.. Wenn der Input nicht an alle Teilnehmer geleitet
wird, dann könnte man den auch gleich weglassen.
Hi!
Ja, sieht echt verdammt nach einer synchronen Übertragung aus.
Ich versuche in den nächsten Wochen mal, so ein RS232 Modul beim
Heizungstechniker meines Vertrauens für ein paar Tage auszuleihen.
Vielleicht reicht auch ein Blick auf ne andere Buderus Steuerung bei nem
Kumpel (der hat ein RS232 Modul drin, ist keine Logamatic, aber
vielleicht identisches Modul - man weiss ja nie).
Melde mich wieder, wenn ich erkenntnisse habe!
Gruss, Malte
Hallo,
Nein, habe bisher noch nichts herausfinden können.. Hatte leider nicht
allzuviel Zeit.
Habe ein Programm in Java geschrieben um die Daten mitzuloggen.
Allerdings scheint das Programm bisher zu lahm zu sein. Die Erfolgsrate
bei der Erkennung des Break-Interrupt liegt noch bei 30%
Aber habe noch eine Idee wie ich das vielleicht ändern könnte...
Gruß
Ingo
Hi,
ich habe nochmal geschaut, da die Heizung langsam wieder anspringt. Die
Vorlauftemperatur habe ich gefunden, auch den Betriebsstundenzähler und
einige andere Temperaturen.
Ich werde mal alle gefunden Nachrichten sammeln und dann mit dem
Serviceheft (Anzeige Servicemenue) verlgleichen und hier posten.
Ich bin grad am überlegen ob ich den Levelkonverter direkt mit einer
CPU, die wenigstens 2 UARTs hat, verheirate und dann an meinen
Netzwerkkontroller gehe. Ich wollte eigentlich nicht 100% CPU-Last für
die Break-Erkennung investieren. Ich hätte einen mega644p der 2 UARTs
hat und den Schweinkram erledigen kann ;-)
Was hast du dir gedacht ?
Grüße.
Also hab es noch mal ausprobiert. Die Break-Interupt Auswertung mit Java
ist unmöglich. Ist eben einfach viiiiieeeeeel zu langsam dafür. Selbst
wenn ich GUI weglasse und nur die Anzahl der Bytes vor dem letzten Break
ausgebe haut das nicht hin.
Hatte auch schon den Gedanken. Allerdings hatte ich da an einen PIC
gedacht. Aber das macht wohl hier keiner.
Ich würde evtl. noch niemals einen UART für die Auswertung nehmen, nur
zum senden zum PC (mit mehr Dampf als die 9600Bit/s.) Als Option würde
sich der STI101 anbieten (USB-Stick Interface mit RS232/I2C) wenn man
keinen Server hat oder haben möchte.
Ich würde aus den 12V +- 2,5V die Speisung notfalls mit einen 7805
herstellen. An dem BUS-Abgriff würde ich vorschlagen einen simplen
Spannungsteiler zu nehmen und dann mit einem CMOS-Schmitt-Trigger das
Signal auf den Controller zur Auswertung geben. OP würde auch gehen.
Vielleicht noch eine galvanische Trennung mit Optokoppler oder ähnlichem
an der RS232 zum PC.
Vielleicht könnte ich mich auch mit einem AVR anfreunden. Allerdings
dann mit Assembler weil ich kein C programmieren kann und es schneller
ist.
Allerdings bräuchte ich dann die komplette Entwicklungsumgebung inkl.
Controller.
Als Simulator müsste auch AVR-Studio gehen, oder gibt es was besseres
dafür?
Gruß
Ingo
>und dann an meinen Netzwerkkontroller gehe.
habe ich glatt überlesen? Wie hast Du Dir dass denn vorgestellt? Wäre
natürlich super eine Verbindung über Netzwerk z.B. auf eine Festplatte
zu loggen. Aber vermutlich hast Du Dir noch eine Software auf dem Server
vorgestellt die dass übernimmt, oder?
Dann wäre man wieder beim "Server-Problem" wollte eigentlich keinen
Rechner nur für die Heizung mitlaufen lassen.
Gruß
Ingo
Hi,
schau dir mal den ADCMP370 an. Als Empfänger ist der soweit okay (läuft
hier bereits). Zwecks Abgriff der 12V als Stromversorgung: ich habe
keinen Plan was man dort abzapfen kann, aus diesem Grund möchte ich in
diese Richtung auch nicht weiterdenken. Vor dem ADCMP370 ein Opto wäre
okay, wenn es überhaupt möglicht ist, wäre aber auch mein Wunsch.
Damit das nicht eine eierlgende Wollmichsau wird würde ich folgendes
vorschlagen:
HEIZUNG <-> MODUL OPTO <-> MODUL WANDLER <-> MODUL SKLAVE <-> MODUL
KNECHT <-> MODUL AUSWERTUNG
Module:
OPTO : galvanische Trennung
WANDLER : level shifter
SKLAVE : Erkennung der Nachrichten (anhand des Breaks und Aufbereitung
der Daten)
KNECHT : Empfang der Daten vom Sklaven und redundanz Check bzw. Empfang
von anderen (nicht CPU lastigen) Sensordaten
AUSWERTUNG: wie immer man das auch machen möchte
Ich habe das Modul: WANDLER (ADCMP370) , KNECHT cortex (geht noch über
die Zeit, siehe andere Postings) / Laptop (Empfang der Daten vom KNECHT
und Weiterleitung per WLAN an Modul AUSWERTUNG) und AUSWERTUNG (SERVER)
Web-Interface/Datenbank
OPTO und WANDLER sind wohl erstmal Notlösungen oder nicht vorhanden. Für
den SKLAVEN kann ich mir eine einfache CPU vorstellen (PIC,AVR nur
einfach mit einer UART-BREAK-Erkennung und einer Schnittstelle zur
Anbindung an den KNECHT (UART/SPI/usw. (I2C ist zu CPU-lastig)). Das
Modul SKLAVE hat nur die Aufgabe der Break-Erkennung und der
Weiterleitung. Der KNECHT wird bei mir ein M3 mit Netzwerk und SD-Karte
sein. Der sendet die Daten an meinen Server, der die Daten
auswertet/visualisiert. Wenn der Server nicht erreichbar ist werden die
Daten auf SD-Karte gespeichert und später verschickt.
So sieht mein Plan aus.
Meine für die Zukunft vorhandenen Module:
OPTO --- nicht vorhanden
WANDLER (ADCMP370) --- läuft
SKLAVE (evtl. avr644p) --- in Gebrauch, für Aufgabe diese ungetestet
KNECHT (cortex LM3S8938) --- Prototyp läuft, für diese Aufgabe
ungetestet
AUSWERTUNG (server) --- läuft
Hier die Brennerstarts (evtl. 3 bytes) und eine neue Temp.
Die unbekannten Temperaturen sind wohl alles Mittelwerte.
Z.Z. geht es langsam los mit der Heizung (siehe Bild).
Hallo Rudi,
Habe mich mal ein wenig über die Komponenten informiert. Hört sich ja
alles sehr gut an. Vielleicht sollte man noch einen kleineren "sklaven"
nehmen... Der avr644p hat, wenn ich da richtig liege, 40 Pins. da müsste
doch ein ATtiny2313 oder ähnliches reichen, oder?
Kann mann den Cortex M3 auch über den USBprog programmieren, oder wie
programmierst Du den. Hast Du bis jetzt eine selbstentwickelte Schaltung
oder eine eingekaufte?
Also wenn ich was helfen kann, dann bin ich dabei...
Gruß
Ingo
Würde den Sklaven inkl. Wandler am liebsten auf eine eigene Platine
packen oder zumindest einen Steckplatz dafür vorsehen. Dann kann man
evtl hinterher noch die Platine gegen eine Sende/Empfangsplatine
austauschen falls es irgendwann mal oweit sein könnte. Ein Steckplatz
für ein einfache 2 oder 4 zeiliges LCD-Display mit Controller könnte man
auch einplanen. Da würden doch bestimmt ein paar Pins für freibleiben.
Außerdem könnte man dann noch ein paar Platinen mehr machen und vür
andere Funktionen gebrauchen. Hätte bestimmt ein paar
Anschlussprojekte...
Womit hast Du denn die Platinen geroutet?
Die Auswertung würde ich dann aber vermutlich hinterher noch in dem
Cortex reinpacken. Man könnte Werte dann abspeichern oder senden wenn
sie sich geändert haben. würde vermutlich das Datenvolumen doch ein
wenig reduzieren. Aber darum kann man sich noch gedanken machen wenn
erst mal alles läuft.
Gruß
Ingo
Leider noch nichts neues wegen dem KM271.
War eben nochmal dran und habe mir mal die freien Anschlüsse angesehen.
Da gibts noch 2 Klemmen "BF" wo man das "BFU" anschliessen kann.
Benutzer Fernbedienung oder sowas.
An den Klemmen liegt nur eine Versorgungsspannung an, es wird nichts
gesendet.
Scheinbar ist dann die BFU an dem Anschluss "master". Also auch
uninteressant wenn man das Gerät nicht zur Hand hat.
Habe eben auch nochmal verzweifelt nach Bildern von der KM271 gesucht,
aber die Produktbilder die man findet sind so klein, dass man nichts
erkennen kann. Scheint wohl absicht zu sein.
Ich versuche doch mal, leihweise an so ein Modul zu kommen.
Gruss, Malte
Hallo Rudi,
ich habe Deine und meine Infos zum Aufbau der Datentelegramme mal als
Diskussionsgrundlage in einer Excel-Tabelle dargestellt.
Je Tabellenblatt ist ein Telegramm im Aufbau mit den bekannten,
vermuteten und unbekannten Werten aufgeschlüsselt.
Es sind jeweils die Werte mehrer Tage eingetragen. Deshalb ist die
Tabelle auch ziemlich groß geworden (7,7 MB als ZIP).
Ich freue mich auf rege Diskussion.
Mario
@IngoF
> Würde den Sklaven inkl. Wandler am liebsten auf eine eigene Platine> packen oder zumindest einen Steckplatz dafür vorsehen. Dann kann man> evtl hinterher noch die Platine gegen eine Sende/Empfangsplatine> austauschen falls es irgendwann mal oweit sein könnte.
Ja, das habe ich mir auch überlegt, bin aber durch die Datenübertragung
der 2107 erstmal von ab.
Der Opto-Kram bräuchte den ADCMP370, einen LDO (5V) und dann den
Optokoppler, dann hat man das sauber getrennt und hat hinter dem Opto.
direkt das richtige Level für die Auswertung. Optokoppler für analoge
Signale sind mir zu teuer, auch aus diesem Grund der LDO/LinearRegler.
Eine Schaltung mit OPs vor dem Opto. wäre auch möglich, aber da werden,
meiner Meinung nach, mehr Bauteile benötigt.
Für die 2107 bräuchte man nur den Opto., aber dann zwei mal, die Signale
haben schon 5V Level.
Auf dem EMS-Bus haben wir nur 9600Baud, die per Hardware empfangen
werden können, auf dem Bus der 2107 muß alles erstmal per Software
empfangen werden und das bei einer relativ hohen Frequenz. Schon wegen
der Software würde ich bei beiden Lösungen eine CPU benutzen wollen. Ich
könnte eine Tüte Mega8 bekommen, dann stauben die nicht ein und laufen
mal ;-). Ob die UART die Break-Erkennung hat kann ich jetzt nicht sagen,
müsste ich mal im Datenblatt schauen.
Für die Kommunikation wäre I2C nicht schlecht, dann könnte man weitere
externe Module direkt an den Bus klemmen und gut. Multi-Master ist nicht
weiter wild.
> Ein Steckplatz> für ein einfache 2 oder 4 zeiliges LCD-Display mit Controller könnte man> auch einplanen. Da würden doch bestimmt ein paar Pins für freibleiben.> Außerdem könnte man dann noch ein paar Platinen mehr machen und vür> andere Funktionen gebrauchen. Hätte bestimmt ein paar> Anschlussprojekte...
Ja, das leidige Steckverbinderproblem ... ;-)
> Womit hast Du denn die Platinen geroutet?
Eagle.
> Die Auswertung würde ich dann aber vermutlich hinterher noch in dem> Cortex reinpacken. Man könnte Werte dann abspeichern oder senden wenn> sie sich geändert haben. würde vermutlich das Datenvolumen doch ein> wenig reduzieren. Aber darum kann man sich noch gedanken machen wenn> erst mal alles läuft.
Auf alle Fälle, anders mache ich es auch nicht. 100x die gleiche
Temperatur mit einem anderen Zeitstempel wird nicht wirklich benötigt.
Wo und wie die Auswertung läuft ist erstmal nebensächlich.
@Mario
Nicht schlecht, obwohl es Excel ist ;-)
Hier ein paar Änderungen:
MSG 08 00 18
25 : Fehlercode
07 : maximal Leistung (in %) (muss aber nicht sein)
08 : aktuelle Leistung (in %)
20 : evtl. auch 19 ist der Flammenstrom in uA (den Wert durch 10 teilen)
@Rudi
Danke, habe Deine Änderungen gleich übernommen. War nachvollziehbar.
Zum Auswerten und Suchen nehme ich gern Excel.
Das Programm selbst ist dann in Delphi (immer noch das
Übersichtlichste).
Mir fehlen noch die Temperaturen der Heizkreise (habe 2) und der
Mischer.
Hast Du eine Idee, wo ich suchen könnte?
bye,
Mario
@Mario
Ich schau eigentlich auch nur ins Service-Menu auf die Werte und
versuche diese durch die Heizung zu verändern und dann im Datenstream zu
finden. Ich rechne den dezimalen Wert in Hex um (X*1 und X*10 also 2
Werte) und dann suche ich den Wert im Stream. Dann wieder ändern usw..
Wie sieht eigentlich dein Hardwareaufbau aus ?
@IngoF
hab es wohl übersehen ...
> Kann mann den Cortex M3 auch über den USBprog programmieren, oder wie> programmierst Du den. Hast Du bis jetzt eine selbstentwickelte Schaltung> oder eine eingekaufte?
Wenn UBSprog einen ARM programmieren kann (JTAG) dann sollte es
funktionieren. Ich benutze zum Programmieren einen Luminary clon (mit
ftdi2232d/usb) und Flachbandkabel (siehe
Beitrag "Re: Zeigt her Eure Kunstwerke !"). Die fetten
Steckverbinder für das JTAG gehen mir ganz schön auf ...
Ich habe das Board selbst erstellt. Die Preise bei Luminary sind zwar
okay, keine Frage, aber von den Bauteilkosten + Platine (nicht die
Arbeitsstunden) ist man selbst noch billiger und hat was man haben
möchte.
Das Board kann man auf eine Trägerplatte schrauben die sich z.B. in
einem Gehäuse befindet. Ansonsten ist an dem Board nichts besonderes.
Alle programmierbaren Pinne sind über die Steckverbinder zugänglich und
mehr oder weniger sortiert. Beim Verpolschutz ist noch ein Bock drin,
aber für diesen Zweck ist es erstmal nicht problematisch.
Die Frameerkennung per Mega8 funktioniert. Habe den mit seiner einen
UART zwischen den Levelshifter und dem Cortex angeschlossen. Leider gibt
es noch die Bustimeouts, die ich noch nicht auswerte.
@ Rudi
meine Hardware ist simpel. Entspricht dem Referenzlayout des eBus-Moduls
mit angepassten Widerständen. Daran hängt der Serielle meines Servers.
Die Erkennung der Timeouts zwischen den Telegrammen funktioniert ganz
gut.
Nur die kompletten Telegramme werden weiter verwendet.
Die Variante mit einem Atmega ist natürlich das Beste. Habe hier noch
ein WebCat-Board mit einem ATmega128 liegen, habe mich aber mangels
C-Kenntnissen nicht daran versucht.
Habe mich Heute den ganzen Tag mit SQL und gnuplot beschäftigt.
Die Daten werden jetzt schön in einer MySQL-Datenbank gespeichert und
über gnuplot angezeigt.
Wie hast Du die Kurven in gnuplot geglättet? Bei mir sind noch Stufen zu
sehen.
Ich bin ja richtig erschrocken, wie oft meine Heizung den Brenner
anschmeisst. Ich denke, die moduliert die Leistung, um die Brennerdauer
zu verlängern und die Starts zu minimieren. Jetzt habe ich 6 Starts/h
gezählt.
Ist das normal?
bye,
Mario
@Mario
> ein WebCat-Board mit einem ATmega128 liegen, habe mich aber mangels> C-Kenntnissen nicht daran versucht.
Der 128 sollte auch funktionieren. Wenn ich nächste Woche mal den
Timeout ausmessen kann poste ich mal den kompletten simplen Source. Mein
Oszi steht noch an der 2107 :-/
> Wie hast Du die Kurven in gnuplot geglättet? Bei mir sind noch Stufen zu> sehen.
Bei dir sieht das nicht schlecht aus. Mein Kurven sind nicht geglättet.
Kannst du mal dein Script posten ? Die Zusammenfassung am unteren
Bildrand finde ich gut.
Der Brenner geht nicht mit voller Leistung an, siehe die Werte weiter
oben, und aus diesem Grund kann der auch mal öffters angehen. Die
Solltemperatur, nach der internen Temperaturkurve, ist übrigens der
HK1_VL-Wert und in den Daten auch so kantig. Das ist kein gemessener
Wert sondern der ermittelte von der Heizung.
Anbei noch mein Script für gnuplot, es wird direkt in ein Bild gewandelt
und dann auf dem Server ins www-Verz. verschoben ...
Nun die Daten für die 2107 mit Clock. Ich habe immer auf Level von CLK
oder DATA getriggert.
log_20091004.bin - Binärdaten - pro byte: bit0 CLK und bit1 DATA
log_20091004.wav - die importierten Daten (alle Bytes verdoppelt) als
WAV
Viel Spass.
So sehen die Daten in etwa aus. 2 Byte anfrage und dann Anwort mit den
Daten. Das letzte Byte scheint wieder diese ominöse CRC zu sein. Die
Anfrage an 0xAC ist noch falsch geparst, evtl. stimmen die Daten absolut
nicht ...
@Rudi
mit dem Quellcode für dem Atmega128, das wäre prima.
Das Script für gnuplot habe ich beigefügt. Dieses ist aber noch nicht
perfekt.
Ich suche noch nach einer Möglichkeit, wie ich den Zeitraum, welcher
ausgewertet werden soll, ändern kann. Bis jetzt lasse ich jedesmal die
Scriptdatei mit Start- und Enddatum neu erzeugen.
bye,
Mario
Moin,
danke.
> Ich suche noch nach einer Möglichkeit, wie ich den Zeitraum, welcher> ausgewertet werden soll, ändern kann. Bis jetzt lasse ich jedesmal die> Scriptdatei mit Start- und Enddatum neu erzeugen.
Kommt drauf an wie. Dynamisch wird das etwas zäh und könnte dann evtl.
über ajax laufen. Statisch kann ich dir die rrdtools empfehlen, dort
gibt es aber nur eine eingeschränkte grafische Möglichkeit. Anbei mal
der Gaszähler über rrdtools. Die Datenbank für die rrdtools erstelle ich
übrigens jede Stunde neu, da ich noch keine Lust auf eine Timestamporgie
hatte und rrdtool kein mysql unterstützt. Kann man aber auch eleganter
lösen.
> Die Variante mit einem Atmega ist natürlich das Beste. Habe hier noch> ein WebCat-Board mit einem ATmega128 liegen, habe mich aber mangels> C-Kenntnissen nicht daran versucht.
Absolut keine ? Kompilieren und brennen geht aber ?
> mit dem Quellcode für dem Atmega128, das wäre prima.
siehe Anhang
Kompiliert für den 128 (habe selbst keinen), sollte also laufen.
@Mario
Hier eine kleine Optimierung für das Skript und deine Datenbank. Du
kannst die Werte aus der 08 00 18 (10/11) in einen 16 Bit-Wert
konvertieren und dann bei Gnuplot einfach die Bits abfragen:
decode_status(t,w) = ( (int(t)&int(w)) == 0) ? 0 : 1
plot "data_14.txt" using 1:(decode_status($2,64)) with boxes notitle
Kann Gnuplot eigentlich auch mit Hexwerten etwas anfangen ? Ich habe
bisher nicht dazu gefunden ?
@Mario
Ich habe deine Aufteilung in Gnuplot übernommen und denke das Bit 7
(0x40) vom Brennerstatus nicht richtig sein kann. Ich sehe da Aktivität
ab 0 Uhr beim Brenner und der Pumpe im Warmwasserkreislauf ohne
Gasverbrauch (die Heizung sollte um die Uhrzeit nicht an
sein/Temperaturabsenkung). Kannst du das bestätigen ? Meine Bit-Masken
sehen wie folgt aus (die 3 Diagramme unten):
Zeile1: 8+4+1
Zeile2: 64
Zeile3: 32
Ich habe direkt 2 extra Temperatursensoren an den Vor-/Rücklauf der
Holzheizung gehängt ;-) Der Testaufbau funktioniert soweit richtig gut.
@Rudi
erstmal vielen Dank für den Quellcode. Beim ersten Anschauen habe ich
aber nicht viel verstanden. Ich bin scheinbar C-inkompatibel ;-)
Ein erster Kompilierungsversuch mit GNU AVR-GCC (Bestandteil des
EtherNut-Paketes/ Nut/Os) ist gescheitert. Ich werde es mir nochmal
genauer anschauen müssen.
In dem Paket Nut/Os gibt es einen Beispiel-Code, welcher eine RS232 auf
Netzwerk ( per Telnet) umsetzt. Vielleicht könnte man darauf aufbauen?
Dann wären die Daten gleich im Netzwerk und man braucht keine weitere
serielle Schnittstelle. Ich habe den Quellcode mal angehangen.
Zu deiner Vermutung Brennerstatus:
das ist nach meiner Ansicht das Bit 2 (04H) aus dem Byte 11 des
08-00-18-Telegramms. Im Absenkbetrieb bleibt dieses bei mir auf "0".
Das Bit 6 (40H) muss die Warmwasserbereitung sein. Ist immer auf "1",
wenn Warmwasser bereitet wird. Nächtliche Aktivität habe ich auch alle
paar Tage, da gegen 01:00 Uhr die thermische Desinfektion läuft. Dann
geht die Warmwassertemperatur bis auf 75 Grad hoch.
bye,
Mario
@Mario
> Das Bit 6 (40H) muss die Warmwasserbereitung sein. Ist immer auf "1",> wenn Warmwasser bereitet wird. Nächtliche Aktivität habe ich auch alle> paar Tage, da gegen 01:00 Uhr die thermische Desinfektion läuft. Dann> geht die Warmwassertemperatur bis auf 75 Grad hoch.
Die Desinfektion habe ich abgeschaltet, das bringt evtl. etwas, wenn das
Wasser ein paar Wochen im Kessel steht.
Wie im Bild zu sehen, ist das Flag eingeschaltet, aber es passiert
nichts (kein Gas, keine Temperaturänderung). Muss ich mir die Tage
nochmal genauer anschauen.
> erstmal vielen Dank für den Quellcode. Beim ersten Anschauen habe ich> aber nicht viel verstanden. Ich bin scheinbar C-inkompatibel ;-)> Ein erster Kompilierungsversuch mit GNU AVR-GCC (Bestandteil des> EtherNut-Paketes/ Nut/Os) ist gescheitert. Ich werde es mir nochmal> genauer anschauen müssen.
Ja, wenn du mir deine eingestellte CPU Geschwindigkeit sagst, dann kann
ich das hier durchleiern. Ein Port mit LED wäre auch nicht schlecht.
> In dem Paket Nut/Os gibt es einen Beispiel-Code, welcher eine RS232 auf> Netzwerk ( per Telnet) umsetzt. Vielleicht könnte man darauf aufbauen?> Dann wären die Daten gleich im Netzwerk und man braucht keine weitere> serielle Schnittstelle. Ich habe den Quellcode mal angehangen.
Gleich ist gut ;-) Da braucht es mindestens einen Netzwerkkontroller.
Ehrlich gesagt bin ich von Nut/OS nicht so begeistert.
@Malte Bayer
Bist du schon weiter gekommen ? Ich hänge noch über den Daten der 2107
und komm nicht weiter.
Die Daten sehen etwa so aus (in chronologischer Reihenfolge):
1
A8E7:A901FFFF00FFFFA8
2
A8EE:A901210084212161
3
A8F5:A920844121408450
4
A8FC:A961216084
5
AA00:AB812162
6
AA03:AB808AA127A08DD0
7
AA0A:ABC12AC084C290CD
8
AA11:ABC290C290C2900B
9
AA18:ABC290C290C2900B
10
AA1F:ABC290C290C2900B
11
AA26:ABC290C290C2900B
12
AA2D:ABC290C290C2900B
13
AA34:ABC290C290C2900B
14
AA3B:ABC290C290C2900B
15
AA42:ABC290C290C2900B
16
AA49:ABC290C290C2900B
17
A81C:A9030105650005B6
18
A80E:A9650005052D019B
Nun könnte man ja meinen das es sich beim zweiten Byte um eine Adresse
handelt. Wenn ja, dann ändern sich die Daten nach einer gewissen Zeit
nicht mehr im Speicher. Es wird gesendet, aber so gut wie keine
Änderungen. Falls noch jemand eine Idee hat !?
...
Hallo,
würde gerne bei der Decodierung mithelfen. Mit Java kann ich am PC die
Daten nicht auseinanderhalten.
Brauchbare Hardware habe ich auch nicht mehr.
Die Brennersoftware bekomme ich nicht mehr zum laufen, und die Software
die mit meinem Brenner funktioniert unterstützt meine PICs nicht. Muss
also eigentlich wieder bei Null anfangen. Also Brenner kaufen und
versuchen ob ich mit C klarkomme. Mit Assembler habe ich eigentlich
weniger Probleme.
Würde gerne mit Eagle eine Platine entwickeln mit der man dann evtl
zusammen an der Software arbeiten könnte. Am liebsten würde ich den
"Sklaven" austauschbar machen damit man evtl. nachträglich andere
Bus-Systeme oder eben auch die Sendefunktion ünterstützen könnte.
Die Idee mit der SD-Karte und Netzwerkanbindung ist schon mal genial.
Dann kann die Platine fleissig Daten sammeln und man muss nicht immer
einen PC laufen haben um die Daten zu loggen.
Würde gerne auch einen Port für ein 4x20 LCD-Display einplanen damit die
Platine entweder Daten anzeigen könnte oder eben auch noch für andere
Projekte verwendbar ist. Vielleicht auch ein Tastaturport. Muss ja nicht
alles am Anfang genutzt oder unterstützt werden.
Dazu müssten wir uns für einen bestimmten "Sklaven", die andere Hardware
und die Verbindung zwischen Cortex und dem Sklaven entscheiden.
Würde die Platine mit Eagle entwerfen.
@Rudi, kannst du mir einen Plan von deinem Cortex und dem ATmega
zukommen lassen.
@all wer hätte Interesse an so einer Platine?
meine Mail:
if38(at)arcor(punkt)de
Gruß
Ingo
Hallo Ingo,
> Die Brennersoftware bekomme ich nicht mehr zum laufen, und die Software> die mit meinem Brenner funktioniert unterstützt meine PICs nicht. Muss> also eigentlich wieder bei Null anfangen. Also Brenner kaufen und> versuchen ob ich mit C klarkomme. Mit Assembler habe ich eigentlich> weniger Probleme.
Diese Probleme mit PIC, Brenner und Software hatte ich auch. Und weisst
Du, was ich gemacht habe?
Dieses Tutorial angeschaut:
http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial
Dann ein Experimentierboard mit einem Atmega gekauft, welches Plug&Play
am PC anschliessbar ist und es hat auf Anhieb funktioniert. Echt Klasse.
Und nie wieder Assembler: Heute und morgen weiss jeder, wie er was in
Assembler programmiert hat, aber übermorgen? Und dann noch Änderungen
machen? C ist wirklich nicht schwierig und wahrlich keine Hexerei, da es
Libraries und Demosourcen à gogo auf dem Internet gibt.
Gruss
Christian
@ Rudi:
>Bist du schon weiter gekommen ? Ich hänge noch über den Daten der 2107 und komm
nicht weiter.
Nein, ist zum verrückt werden. Kumpel hat irgendeine uralt-asbach
buderus steuerung an der öltherme. Der vermeintliche D-9 Stecker hat
sich als D-15 herausgestellt, also wohl keine echte RS232.
Und an ein "leihweise" Modul komme ich nicht ran. knappe Antwort "kaufen
ja, leihen nein" ;-(
Habe inzwischen auch nochmal die restlichen Pins, die auch nur annähernd
nach TTL Signal aussehen, versucht mittels max232 zu untersuchen.
Aber egal welche baudrate startstop paritykonfiguration - es kommt
immer nur müll und frame errors ohne ende an.
Kann ich dir nicht sagen ob sich das lohnt - interessant zu analysieren
wärs aber schon. Bin mir allerdings ziemlich sicher dass diese Pins die
Datenübertragung vom/zum display sind.
Wie gesagt, habe kein Speicheroszi - habe nur mit dem timing und dem
Trigger rumgespielt - ob da immer der gleiche Dreck übertragen wird
weiss ich nicht, schliesse ich aber aus (wäre ja unlogisch).
>Dann ein Experimentierboard mit einem Atmega gekauft, welches Plug&Play>am PC anschliessbar ist und es hat auf Anhieb funktioniert. Echt Klasse.
Wenn ich für mich selber eine Schaltung entwickele würde ich mir
vermutlich einen neuen Microchip ICD2-clon kaufen und hätte auch keine
Probleme mehr.
Warum sollte ich wenn ich mich schon mit der Programmierung und den PICs
vertraut gemacht habe aufeinmal einen neuen Controller nehmen, Neue
Entwicklungsumgebung und mich in eine andere Programmiersprache
einarbeiten?
Die alten selbstgeschriebenen "Bibliotheken" kann man dann nicht mehr
verwenden.
>Und nie wieder Assembler: Heute und morgen weiss jeder, wie er was in>Assembler programmiert hat, aber übermorgen?
Assembler hat auch Vorteile. Ist viel schneller als C-Code. Man weiß
genau was der Controller macht und kann Programmspeicher sparen.
Ob man jetzt in C, Assembler oder einer anderen Sprache screibt ist
egal. Man hat in jeder Sprache probleme wenn man nach einer Pause alte
Programme weiterentwickeln will und nichts im Quelltext dokumentiert
hat. Wenn vernünftig dokumentiert wird ist das kein Problem.
Ich hatte mir vorgestellt dass ich erstmal die Platine route und für
alle interessierten fertigen lasse. Dazu brauch ich allerdings
Informationen ob es beim Cortex und ATmega128 bleibt. Wichtig ist auch
zu wissen wie die bisherige Software des ATmega128 aussieht. Wäre ja
blöd wenn ich die bisher von der Software benutzten Anschlüsse für was
anderes verplane und man mit der Software wieder von vorne anfangen
kann.
Wenn wir uns über die Hardware einig werden könnte ich loslegen.
@Rudi welches Cortex-Board hast Du denn verwendet? Vielleicht kann ich
dann ja irgendwie an den Schaltplan kommen.
Gruß
Ingo
@IngoF
> welches Cortex-Board hast Du denn verwendet? Vielleicht kann ich> dann ja irgendwie an den Schaltplan kommen.
Ich benutze den LM3S8938. Für den 8962 gibt es ein Eval-Board und den
Schaltplan, kannst du bei Luminary runterladen. Hast du schon über ein
fertiges ARM9 Board nachgedacht ? Ich kenne jetzt nicht die Preise, aber
sollte im Vergleich zum Aufwand und den Kosten billiger werden. Auf dem
würde dann wohl auch die Grafikerstellung direkt laufen.
Ich würde erstmal überlegen was man wofür braucht. Wenn du nur einen
kleinen Netzwerkkontroller benutzt, kannst du nicht ohne zweiten Rechner
die Grafiken erstellen. Braucht man das oder nicht. Wie sollen die Daten
gespeichert und ausgewertet werden und wieviel Daten werden es ? usw.
usf.
Mir reicht ein Cortex, da ich die Daten nur weiterleite und ein paar
Sensoren mit dem auswerte. Was brauchst du ?
Beim Sklaven kann ich erstmal nichts sagen, ein MEGA8 mit rund 11MHz
funktioniert am ServiceKey, ob der für die 2107 ausreicht weiss hier
niemand.
Also ich hatte daran gedacht dass ich ein Board erstellen würde was für
alle Möglichkeiten funktionieren würde.
Also Der Cortex mit Netztwerk und SD-Karte ist doch ideal. Die Daten
sollten dann auf SD zwischen gespeichert werden und wenn ich meinen PC
hochfahre werden Die Daten dann zum PC übertragen.
Die Kommunikationsplatine mit dem Slave-Prozessor würde ich über einen
Stecker miteinander verbinden. Dann ist es möglich die Platine für
andere Bussysteme auszustauschen. Oder man kann hinterher doch eine
zweiweg-Kommunikationsmodul einstecken.
Da vermutlich noch genug Ein-/Ausgabepins frei sind würden die für ein
LCD-Display heralten und vielleicht ein paar Taster. Die würden erst mal
vernachlsääsigt und/oder nicht bestückt werden.
Das Board könnte man auch noch für andere Entwicklungen verwenden. Denke
ich hätte schon ein paar Ideen
Ideal wäre es dann wenn mehrere sich hinterher eine Platine aufbauen
wollen...
Die Software könnte man zusammen entwickeln. (Software für PC, Slave und
Master).
So wie es aussieht ist ein großteil der Software ja schon geschrieben.
(Visualisierung auf dem PC und Sammeln der Daten).
Wäre doch am besten wenn man gemeinsam an einem Strang zieht und nicht
mehrere Leute parallel das selbe Entwickeln/Programieren.
Denke doch dass man auf einen Nenner bei der Software und Hardware
kommen könnte, oder.
Gruß
Ingo
@Malte Bayer:
Wir bräuchten dann also noch Messungen an folgenden Pins mit Augenmerk
auf die TTL Signale !? Ich würde die TTL-Signale einzeln analog messen
und dann komplett als Set ohne Zeitinformationen.
Die anderen würde ich dann als zwei Sets messen (max 8bit), wenn denn da
was anliegt. Ein Pin hatte noch 12V oder mehr, muss ich dann nochmal
messen.
09 Ausgang Heizkreis1 Pumpe (an=5V, aus=0V)
03 5V gemessen, vielleicht ein binärer E/A?
04 5V gemessen, vielleicht ein binärer E/A?
05 0V gemessen, vielleicht ein binärer E/A?
06 0V gemessen, vielleicht ein binärer E/A?
08 0V gemessen, vielleicht ein binärer E/A?
10 0V gemessen, vielleicht ein binärer E/A?
11 0V gemessen, vielleicht ein binärer E/A?
12 0V gemessen, vielleicht ein binärer E/A?
13 0V gemessen, vielleicht ein binärer E/A?
14 0V gemessen, vielleicht ein binärer E/A?
19 5V gemessen, vielleicht ein binärer E/A?
20 5V gemessen, vielleicht ein binärer E/A?
21 0V gemessen, vielleicht ein binärer E/A?
15 TTL Signal Low-Aktiv, feste Pulsbreite, unregelmässiges Signal,
könnte Frame start interrupt sein
16 TTL Signal variable Pulsbreite, sieht nach Datenübertragung aus
17 TTL Signal variable Pulsbreite, sieht nach einem Enable Signal aus
18 TTL Signal variable Pulsbreite, sieht nach einem Enable Signal aus
22 TTL Signal variable Pulsbreite, sieht nach Datenübertragung aus
@IngoF
Ich habe das Board mit dem Cortex schon als Prototyp aufgebaut. Durch
die Messungen an der 2107 konnte ich es auch schon mehr oder weniger
testen. Mir ging es darum: so wenig wie möglich, so klein wie möglich
und leicht adaptierbar. Also nur die CPU, Netzwerkbuchse, LDO, SD-Card,
2 LED, 2 Taster (einer Reset), Quarz (3 Stück). Das JTAG+UART ist über
Flachbandkabel zugänglich und geht an einen JTAG-Luminary-Clone + UART.
Alle nicht belegten Pins + JTAG + UART gehen mehr oder weniger sortiert
an die Steckverbinder um die CPU. Damit kann ich (konnte ich bisher)
alles anschliessen, von zu vielen speziellen Steckverbindern halte ich
nicht viel, es sei denn das Board soll nur einem Zweck dienen. Bauteile
sind fast alle 0402, das hat mir das Routing der Versorgung etwas
erleichtert.
@IngoF
Nachtrag:
Schau dir mal bei watterott das LM3S8962 Board an. Mit JTAG kommst du
damit unter 100€, billiger wird ein Kleinserienselbstbau leider auch
nicht :-/. Die Luminary-Boards haben alle JTAG onbaord und dann noch
mehr (z.B. Display) und sind nicht unbedingt viel teurer.
Ich will dich aber nicht davon abhalten ein Board selbst zu bauen ;-)
16 TTL Signal variable Pulsbreite, sieht nach Datenübertragung aus
2
22 TTL Signal variable Pulsbreite, sieht nach Datenübertragung aus
3
23 Datenübertragung Differential zu pin 24
4
24 Datenübertragung Differential zu pin 23
Diese 4 Pins jeweils gegen GND scheinen interessant zu sein.
Die anderen "TTL" dingens sind eher uninteressant, jetzt weiss ich auch
was du meintest mit "ändert sich da was" ;)
Die anderen Pins scheinen wirklich nur "1bit-EA" zu sein, also zeigen
nur einen status an. Die ändern sich auch so gut wie gar nicht.
Interessant wären 16+22 gleichzeitig recorden und 23+24 gleichzeitig.
Zeitinformationen unwichtig, aber wichtig waere jeweils die beiden Pins
nebeneinander sehen zu koennen (stereo wav?).
Gruss, Malte
@Malte:
Die 23/24 habe ich nun schon lang und breit gemessen, da ist zwar ein
Datenstream, der ändert sich mit der Zeit aber so gut wie nicht. Siehe
meine diversen Posts weiter oben (auch mit wav usw.).
Mit dem ADC geht leider nur ein Pin, aber mit der anderen Methode ohne
Zeitinformation gleich 8 Signale.
@Malte Bayer:
Bei dir ist PIN 10 die Pumpe für WW. Hast du zufällig 2 HK ? Für den
zweiten HK müsste es auch noch einen Pin geben. Die Flamme ist
offensichtlich nicht auf dem Kabel.
Ich habe alle 7 TTL-Pins mit 900KHz Auflösung aufgezeichnet, also 7
Signale mit Zeitinformation ! Die Datenaufbereitung könnte etwas dauern,
es ist ein großer Datenhaufen angefallen ;-)
Okay, ging schneller als gedacht. Die wesentlichen Leitungen sind 23/24.
Die anderen Leitungen senden zyklisch die gleichen Sequenzen. Mein
vermutetes Format aus den Daten ohne Clock stimmt nicht. Mit Clock sieht
es schon ganz anders aus.
Ich habe kurz mal drüber geschaut und es der Anfang der Frames sieht
wohl so aus:
1. 9 Clocks und ein ACK oder NACK auf der Datenleitung ohne Clock
2. 9 Clocks und ein ACK oder NACK auf der Datenleitung ohne Clock
3. 8 Clocks mit "Daten" ... usw.
Malte Bayer schaust du mal über die Daten ? Samplerate ist 900000Hz. Die
Dateien sind jeweils 56MB groß und du kannst diese direkt in Audacity
importieren.
<Mit JTAG kommst du damit unter 100€, billiger wird
<ein Kleinserienselbstbau leider auch nicht :-/.
Naja, dabei bleibt es ja nicht...
Dann müsste ich ja noch eine Experimentierboard mit einem ATmega128
kaufen. Und dann muss man auch noch alles irgendwie verdrahten. Und
irgendwann müsste man sowieso eine vernünftige Platine mit allen
Komponenten darauf entwickeln. Also müsste man die Prozessoren noch mal
kaufen. Auslöten ist ja grober Unfug.
Einfach die drei Platinen zusammenklatschen und in ein Gehäuse stopfen
ist ja auch nicht das beste. Platzsparend wäre das nicht wirklich.
Also warum nicht gleich eine richtige Platine entwickeln und auf die
beiden Experimentierplatinen verzichten.
Einen Port für ein LCD-Diaplay ist ja kein Problem. notfalls einfach
einen 8-Bit Steckverbinder um einige Signale erweitern (Kontrast, und
zusätzliche Signale. wer den nicht haben will bestückt die Platine eben
mit der 8-Bit-Standartwanne. Die LCD-Displays hat ja vermutlich sowieso
jeder herumfleigen. Entweder aus alten Faxen, Telefonen, Druckern oder
sonstwo her.
Warum also nicht Deine Miniversion entwickeln mit einer leicht
abgeänderten Portwanne?
Den Schaltplan bei Luminary für dieses Board habe ich noch nicht
gefunden. Hast Du evtl einen Link?
Gruß
Ingo
@IngoF
> Dann müsste ich ja noch eine Experimentierboard mit einem ATmega128> kaufen. Und dann muss man auch noch alles irgendwie verdrahten. Und> irgendwann müsste man sowieso eine vernünftige Platine mit allen> Komponenten darauf entwickeln. Also müsste man die Prozessoren noch mal> kaufen. Auslöten ist ja grober Unfug.
Glaub mir, es ist kein Unfug. Ein Platine mit alles Komponenten ist zu
teuer und nie richtig für etwas anderes verwendbar. Das ist aber nur
wahr, wenn man die Arbeit (die Stunden die man dort rein gesteckt hat)
nicht auch für andere Projekte verwenden kann. Das ist bei einer Eier
legenden Wollmilchsau nur bedingt möglich, alles viel zu speziell.
> Einfach die drei Platinen zusammenklatschen und in ein Gehäuse stopfen> ist ja auch nicht das beste. Platzsparend wäre das nicht wirklich.
Für den Heizungskeller oder wo auch immer die Heizung steht ist das kein
Problem. Auf dem Tisch ist das "one in all" Board lästig. Ich will z.B.
mehrere Temperatursensoren (werden wohl etwas mehr als 8) über Mini-USB
(I2C) adaptieren, wenn ich die Steckverbinder alle auf dem Board
platziere freut sich nur der Leiterplattenhersteller ... das mit den
Modulen ist okay, es ist zwar noch nichts da, aber das ist meiner
Meinung nach die richtige Richtung.
> Also warum nicht gleich eine richtige Platine entwickeln und auf die> beiden Experimentierplatinen verzichten.
Sagen wir mal eher Module und dann ist das Konzept wieder okay.
> Einen Port für ein LCD-Diaplay ist ja kein Problem. notfalls einfach> einen 8-Bit Steckverbinder um einige Signale erweitern (Kontrast, und> zusätzliche Signale. wer den nicht haben will bestückt die Platine eben> mit der 8-Bit-Standartwanne. Die LCD-Displays hat ja vermutlich sowieso> jeder herumfleigen. Entweder aus alten Faxen, Telefonen, Druckern oder> sonstwo her.
Ja, die Adaption von externen Komponenten macht eh jeder wie er Lust und
Laune hat.
> Warum also nicht Deine Miniversion entwickeln mit einer leicht> abgeänderten Portwanne?
Ich mag die nicht. Die Kelchstifte sind so viel einfacher zu verdrahten
;-). Ich war aber auch mal deiner Meinung.
> Den Schaltplan bei Luminary für dieses Board habe ich noch nicht> gefunden. Hast Du evtl einen Link?
Kein Problem:
Kits -> Evaluation Kits -> LM3S8962 Ethernet+CAN Evaluation Kits ->
dann z.B.:
EKC-LM3S8962 Evaluation Kit for CodeSourcery's G++ ->
Stellaris LM3S8962 Evaluation Board User's Manual
Sollte auch ohne Anmeldung funktionieren.
@Rudi
heute habe ich Deinen C-Quellcode auf den Atmega128 angepasst und
übersetzt. Als C-Unwissender hatte ich mich ja schon geoutet ;-).
Mir fehlt noch das Verständnis, an welchem Port das TTL-Signal des
EMS-Bus angeschlossen wird.
In Deinem Code sehe ich immer nur, dass auf dem gleichen USART gelesen
und geschrieben wird. Das kann ja aber nicht sein.
Bitte hilf mir auf die Sprünge.
Danke,
Mario
@Mario
Das ist okay so. An RX der UART hängst du den EMS-Bus und beim TX kommen
die aufbereiteten Daten raus. Da ich es mit einem MEGA8 probiert habe,
der hat nur eine UART, habe ich das so gemacht ;-)
Baudrate bleibt, aber es werden mehr Daten durch den Header und die
Längenangabe. Wenn du noch genügend freien Speicher hast, kannst du den
Puffer etwas vergrößern.
@Mario
Kannst du mal deinen avr-gcc Befehlszeile posten ? Du kannst dort direkt
den Include-Pfad angeben und musst nicht die #include-Pfade in C
anpassen.
Anbei mal ein geparster Stream von der 2107 (Pin 23/24). Das zweite Byte
habe ich extra noch als binär angegeben. Die zweite Zahl ist die Zeit in
Sekunden.
Beispiel:
@Rudi
Nach einem langen Wochenende (regnerisch und kalt) läuft der Atmega128
mit Deinem Programm am EMS-Bus der Heizung (RC35). Nochmal Danke für die
Hilfe.
Jetzt lassen sich die Daten viel leichter auswerten. Dem werde ich mich
mal die nächste Zeit widmen.
Mario
@Mario
Da ich auch eine RC35 habe und irgendwie in diesem ganzen langen Thread
den Überblick verloren habe, wollte ich fragen, was denn Du mit Deinem
Atmega128 alles machen kannst oder ist das immer noch die Versuchsphase,
die Daten zu entziffern?
Gruss
Christian
@Hennessy
Der Atmega liest die Daten auf dem EMS-Bus, erkennt das Ende eines
Telegramms und sendet das Telegramm mit Start- und Endzeichen sowie
Längenangabe an den PC (Dank der super Hilfe durch Rudi). Die
Telegrammaufzeichnung nur mit dem PC hat sich als zu langsam
herausgestellt. Ein zwischengeschalteter Microprozessor ist absolut
notwendig, da sonst das Telegrammende (ein fehlerhaftes Null-Byte) nicht
ausgewertet werden kann.
Im Rechner werden die Daten ausgewertet, angezeigt und in eine
SQL-Datenbank geschrieben.
Damit ist dann eine Langzeitanzeige als Diagramm möglich.
Natürlich alles noch Testphase, aber ein Großteil geht schon.
Zur Zeit werden gelesen:
Kesseltemp Soll und Ist
Anlagentemp
Rücklauftemp
Wamwassertemp Soll und Ist
Außentemp
Raumtemp (nur wenn RC35 im Wohnraum hängt, sonst Null)
Anlagendatum/Zeit
Zahl Brennerstarts
Betriebstunden
Laufzeit in Tagen
Stunden WW-Bereitung
Anzahl WW-Bereitung
Fehler-/Statuscode
Betriebsart
Status von Brenner, Zündung, Flamme, Heizkreispumpe, Zirkulationspumpe,
Dreiwegeventil
Flammenstrom
Wasserdruck im Heizkreis
aktuelle Leistung
Maximalleistung
Leider fehlt mir momentan die Zeit, um richtig vorwärts zu kommen, aber
der Winter naht ;-)
bye,
Mario
@Mario
> Raumtemp (nur wenn RC35 im Wohnraum hängt, sonst Null)
Das kann ich nicht bestätigen. Hier: RC35 am Brenner mit Raumtemperatur.
Mal eine andere Frage. Sieht die Vorlaufkurve der Heizung bei dir z.Z.
auch so merkwürdig aus ?
>Das kann ich nicht bestätigen. Hier: RC35 am Brenner mit Raumtemperatur.
Muss aber eigentlich so sein. Habe zwar "nur" die RC30. Aber der
Temperatursensor ist in der RC30 eingebaut. Wenn also die RC30 oder RC35
angeklemmt ist dürfte keine Temperatur gesendet werden.
Also muss es dann irgendeine andere Temperatur sein die Du auswertest.
Vielleicht eine errechnete Temperatur die von der Gebäudeart abhängt?
Gruß
Ingo
@Mario / Rudi
welches Format haben denn die Daten die vom ATmega128 gesendet werden?
Dann könnte ich vielleicht noch mal ein Versuch mit meinen vorhanden PIC
machen und die Daten im selben Format senden.
Dann könnte ich vielleicht Euer Script laufen lassen und beim decodieren
mithelfen.
Ob ich mir dann auch irgendwelche Hardware baue oder sogar den
RS232-Gateway von Buderus nehme habe ich noch nicht entschieden.
Hi,
habe hier zu Hause auch eine Buderus Heizung mit RC30 und BC10. Habe mir
den Thread jetzt ein paar Mal durchgelesen, blicke aber nicht so richtig
durch :)
Also: Grundsätzlich geht es hier im Thread um 2 verschiedene
Protokolle/Systeme, einmal den EMS-Bus, der u.A. an der Klinkenbuchse
des BC10 anliegt und zum anderen geht es um das Protokoll der Logamatic
2107, soweit richtig? :)
Das Protokoll der 2107 ist also nicht identisch mit dem EMS-Bus (also
dem was an der Klinkenbuchse ankommt).
Gibt es nun irgendwie eine Protokollbeschreibung vom EMS-Bus? Mir ist
das noch nicht ganz klar :/
Auf der Klinkenbuchse ist also einmal +12V, GND und das Signal. Auf der
Signalleitung können alle angeschlossenen Teilnehmer senden und
empfangen (RX=TX , so stand es weiter oben) und man kann mit einem UART
auf 9600Baud begrenzt (mit Fehlern?) alles was auf dem EMS-Bus gesendet
wird mitlesen?
Bitte korrigiert mich wenn ich irgendwo falsch liege :)
> Muss aber eigentlich so sein. Habe zwar "nur" die RC30. Aber der> Temperatursensor ist in der RC30 eingebaut. Wenn also die RC30 oder RC35> angeklemmt ist dürfte keine Temperatur gesendet werden.
Angeklemmt ist die doch immer.
> Also muss es dann irgendeine andere Temperatur sein die Du auswertest.> Vielleicht eine errechnete Temperatur die von der Gebäudeart abhängt?
Die Temperatur wird mir als Raumtemperatur im Menü angezeigt, ich bin
mir also 100%ig sicher ;-)
> welches Format haben denn die Daten die vom ATmega128 gesendet werden?
0xAA 0x55 <DATA> <LEN> 0xAA 0x55
DATA die Daten vom EMS Bus
LEN das Längenbyte (Anzahl der DATA-Bytes)
Eine CRC-16 wäre auch nicht schlecht, auf der UART sind ja immer
zyklische Fehler vorhanden.
> Ob ich mir dann auch irgendwelche Hardware baue oder sogar den> RS232-Gateway von Buderus nehme habe ich noch nicht entschieden.
An das Gateway konnte man doch diese 1000km Kabel antütern oder ? Ich
glaube das Gateway bekommt man für etwa 250€. Ganz schöner Preis, für ne
Serielle ;-)
@Niclas
richtig beschrieben, hier geht es parallel um zwei verschiedene Sachen,
den EMS-Bus (bei mir und Rudi) und die 2107.
Ich bastel nur am EMS-Bus. Eine Protokollbeschreibung gibt es noch
nicht. Ich hatte mal eine Excelliste gepostet (weiter oben im Thread).
Diese enthält aber noch Fehler, da die Telegramme nur mit dem PC
aufgezeichnet waren.
Im Moment ergänze ich die Liste gerade, da jetzt alle Telegramme richtig
ankommen. Alles Erkannte basiert nur auf Diagnose und Raten.
Beschreibung gibt Buderus (jetzt Bosch) nicht raus.
Korrigierte Liste kommt die nächsten Tage.
@Rudi
Ich hab doch noch keine Vorlauffühler wie Du.
Aber gerade habe ich zwei interessante Daten im Telegramm 11 00 9C
Byte4+5 und 21 00 AB Byte 5+6 gefunden. Das dürften die VL-Temp. von
Heizkreis 1 und 2 sein. Muss ich erst in die SQL-Datenbank
implementieren.
bye,
Mario
>Angeklemmt ist die doch immer.
Vielleicht war es ja auch ein Misverständnis. Hatte den Satz "Raumtemp
(nur wenn RC35 im Wohnraum hängt, sonst Null)" so verstanden dass die
RC35 in der Zeit garnicht angeklemmt ist.
>0xAA 0x55 <DATA> <LEN> 0xAA 0x55
Hatte mir auch schon Gedanken gemacht wie ich die Telegramme übertragen
wollte. Ich hätte die dann Als Hex codiert übertragen und nach jedem
Telegramm ein Enter geschickt. Dann hätte ich mit 115,2 KBit übertragen
(Also 1 Byte senden wärend der Abtast-Pause zwischen zwei Bits die
Empfangen werden. So ist das natürlich auch eine gute Idee.
CRC16 ist ja nicht ganz so einfach zu berechnen. Um vieles Einfacher
wäre ein einfaches XOR der Bytes als Prüfsumme anzuhängen.
>...für etwa 250€. Ganz schöner Preis...
Genau deswegen überdenke ich das ja schon seit 2003. Damit wäre es ja
nicht getan Die Software kommt ja auch noch dazu. Für
Heizungsfachbetriebe könnte sich sowas ja lohnen. Aber für
Privatanwender ist das ja fast sinnlos.
Würde natürlich gerne die Heizprogramme am PC einstellen. Die Dreherei
an der RC30 ist ja viel zu Umständlich. Dazu müsste man aber
herausbekommen wie die Prüfsumme berechnet wird. Ein einfaches XOR oder
CRC8 scheint es nicht zu sein. Habe schon mal mit verschiedenen Anfangs
und Endwerten und Bitfolge herumgerechnet, habe aber nichts herausfinden
können. Vielleicht haben die ja auch eine eigenes Polynom dafür
genommen? Vielleicht werd ich da ja noch irgendwann mal was
herausbekommen.
Oder irgend eine Idee zur Prüfsumme? Oder ist das vielleicht doch keine?
Gruß
Ingo
@Mario
Vielen Dank für Deine Zusammenfassung, jetzt ist mir einiges klarer.
Genau das, was ich suche, deshalb werde ich mich auch mal dahinter
klemmen. Bin schonmal gespannt auf die korrigierte Liste.
Gruss
Christian
@Mario
> Ich hab doch noch keine Vorlauffühler wie Du.> Aber gerade habe ich zwei interessante Daten im Telegramm 11 00 9C> Byte4+5 und 21 00 AB Byte 5+6 gefunden. Das dürften die VL-Temp. von> Heizkreis 1 und 2 sein. Muss ich erst in die SQL-Datenbank> implementieren.
Die sehe ich hier nicht. Sind das evtl. Lesefehler ??? Adresse 11 und 21
???
Hallo Leute, ich habe den Thread jetzt mehrfach gelesen, und blicke
vielleicht deswegen nicht mehr durch.
Pin 23/24 an der Logamatic 2107 zwischen Controllerplatine und
Hauptplatine sind zu verwenden?
Welche Pegelanpassung? Welches Protokoll?
Hat schon jemand eine Liste mit Telegrammen? Würde da auch gerne
einsteigen.
mfg Chris
@Rudi
das sind keine Lesefehler. Sowas gibt es bei mir nicht mehr ;-)
11 ist der Absender WM10 (Pumpe Heizkreis 1)
Beispiel:
11 08 1E 00 00 D1 B3 00
Byte 4+5: Vorlauf HK1 IST
Byte 6 : scheint auch eine Temperatur zu sein, für Rücklauf aber zu
niedrig
21 ist der Absender MM10 (Pumpe und Mischer Heizkreis 2)
Beispiel:
21 00 AB 00 05 00 CD 00 9C 01 10 F9 00
Byte 4 : Vorlauf HK2 SOLL
Byte 5+6: Vorlauf HK2 IST
Byte 8 : Mischersteuerung
Hast Du die Anzeige Außentemperatur schon für Minusgrade korrigiert?
Das Highbyte wird dann FF. Ich kann das System noch nicht erkennen.
Rückwärtsrechnen von FFFF passt auch nicht. Hast Du eine Idee?
bye,
Mario
@Mario
> das sind keine Lesefehler. Sowas gibt es bei mir nicht mehr ;-)
Du hattest ja 2 Heizkreise ... Lesefehler gibt es noch, wenn der
Bustimeout aufschlägt wird am Anfang einer Nachricht ein falsches Byte
gelesen.
B3 ist die CRC:
11 08 1E 00 00 D1 B3 00
^^ Byte 0 mit Frameerror
^^----CRC
> Hast Du die Anzeige Außentemperatur schon für Minusgrade korrigiert?
Nein, ich muss noch warten ;-)
> Das Highbyte wird dann FF. Ich kann das System noch nicht erkennen.> Rückwärtsrechnen von FFFF passt auch nicht. Hast Du eine Idee?
Hast du ein Beispiel ? Wir haben hier noch keine Temperaturen unter 0°C.
@Rudi,
leider habe ich für die Minusgrade kein Beispiel mehr. Auch bei mir sind
es jetzt 10 Grad plus.
Nachvollziehen konnte ich, dass -0,1 °C als FFFFH dargestellt wird.
-0,2 °C könnte FFFEH sein, ich hatte allerdings den Eindruck, dass die
negative Temp. eine andere Auflösung hat (event. 0,05 °/Digit).
Werde ich lt.Wetterbericht Ende nächster Woche testen können. Ich wohne
in einer kalten Gegend ;-)
Hier mal eine Liste aller Telegramme, die es bei mir gibt:
Absender = UBA3 (Brenner)
08 00 07 keine Änderungen
08 00 18 Kesseltemp Soll/Ist, Leistung WWTemp,
Ruecklauftemp, Fehlercode, Betriebsart, Druck
08 00 19 Außentemp, Brennerstarts, Betriebststundenzaehler
08 00 34 WWTemp Soll/Ist, Zähler WW-Bereitung, Status 3-Wegeventil
08 00 1C keine Änderungen
08 10 10 Lebenszeichen?
08 10 11 Lebenszeichen?
08 10 14 irgendwelcher Zähler
Absender = BC10
09 10 keine Änderungen
Absender = RC35
10 00 06 Datum/Zeit, Betriebszeit
10 00 48 unklar
10 00 3E Raumtemp.
10 00 A2 keine Änderungen
10 00 A3 3 Temperaturen (unklar)
10 08 35 unklar
10 08 1A unklar
10 11 9D unklar
10 21 AC unklar
10 88 10 Lebenszeichen?
10 88 11 Lebenszeichen?
10 88 14 keine Änderungen
10 89 29 keine Änderungen
Absender = WM10 (Pumpe HK1)
11 00 9C Vorlauftemp HK1
11 08 1E Vorlauftemp HK1
Absender = MM10 (Pumpe/Mischer HK2)
21 00 AB Vorlauftemp Soll/Ist HK1, Mischersteuerung
Wie immer als Diskussionsgrundlage.
bye,
Mario
@Mario
> Nachvollziehen konnte ich, dass -0,1 °C als FFFFH dargestellt wird.> -0,2 °C könnte FFFEH sein, ich hatte allerdings den Eindruck, dass die> negative Temp. eine andere Auflösung hat (event. 0,05 °/Digit).
Die Änderung der Auflösung wäre eigentlich untypisch. Das Problem wird
sich in den nächsten Wochen aber von selbst erledigen ;-)
Jedes Modul hat noch eine Versionsnummer, ich vermute das die in den
Nachrichten ohne Änderung verschickt werden. Es könnte sich aber auch um
Werte von "fehlenden" Sensoren handeln.
Ich werde in den nächsten Tagen meine alten Logdateien parsen und eine
Liste der Nachrichten erstellen. In 3 Monaten sind etwa 10GB an Rohdaten
aufgelaufen die langsam mal wech können.
zur 2107:
Bei den Nachrichten handelt es sich offenbar um eine Art "ECO-CAN" Bus
von B.. Die Datenlänge spricht dafür, die Speicheradressen sind aber
noch etwas unklar.
Jeder Teilnehmer auf dem Bus hat eine Adresse und einen Speicherbereich
der ausgelesen oder beschrieben werden kann. Initial sollte der
komplette Speicher übertragen werden (ich habe leider noch keine
Einschaltsequenz der Anlage) und danach nur Speicherbereiche in denen
Änderungen stattgefunden haben. Da die Adressierung des Speichers noch
unklar ist, sehen die Nachrichten immer gleich aus, welches Bit MSB und
LSB ist, ist leider auch noch unklar ... die dezimale 65 in den Daten
ist wohl ein Lückenfüller für nicht vorhandene Werte bzw. Werte die
nicht beschrieben werden sollen/können.
Zur 2107:
Soooooo, ich konnte die Angaben in den Dokumenten von B., bezüglich dem
ersten kompletten Datenaustausch, heute verifizieren. Nach dem
Einschalten wird ein Datenwulst auf dem Bus verschickt und danach geht
es eher ruhig zu (siehe Anhang).
Nebenbei habe ich die Anlage "virtuell" verkabelt und habe jetzt den
unbekannten "realtime"-Log vom Bus jederzeit zur Verfügung. Falls jemand
Interesse an den Daten hat bitte melden, ich weiss das ein Busmitschnitt
und das Parsen der Daten "noch" etwas kompliziert ist ...
Nachtrag:
Auf dem Bild ist der rechte Bereich von LOG1 und LOG2 nicht identisch.
Beim zweiten Mitschnitt kam kurz nach dem Einschalten eine Anforderung
für die Warmwasserbereitung, ein möglicher Grund dafür ...
Ich habe den Speicher ausgelesen:
PAGE0 0xff
PAGE1 0xff
PAGE2 0xff
PAGE3 0xff
PAGE4 DATEN
PAGE5 DATEN
PAGE6 DATEN ein paar Byte, der Rest 0xFF
PAGE7 0xff
Andere Teilnehmer (die CPU) befindet sich wohl nicht auf dem Bus.
Hier nochmal die Pins. Ohne Pin15 (High) wird der Kessel/WW als fehlend
angezeigt. Jetzt sehe ich schonmal die alten Werte vom WW/Kessel usw.
(auf dem Tisch) ;-)
Nachtrag:
Die Temperaturen werden offensichtlich über über Pin 15 übertragen. Wenn
ich dort direkt SCL oder SDA anschliesse gibt es Temperaturänderungen im
Display die im EEProm hinterlegt werden.
Es geht jetzt eingentlich nur um die richtigen Adressen im EEProm und
dann wars das eigentlich ...
Announcement: there is an English version of this forum on 
