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 ...
So, zu den Temperaturen bei der 2107. Leider werden nur die
programmierbaren Temperaturen im EEProm gespeichert. Die eigentlichen
Temperaturen werden über einen extra Bus übertragen. Es gibt 8 mögliche
Temperaturen (ADC-Werte), wobei eine/r die Referenz ist. Ich konnte hier
schon die Temperaturen per Hardwaresimulation durchfahren, aber die
Referenz ist noch etwas undurchsichtig, geht aber in die Berechnung der
Temperaturen mit ein. In der Serviceanleitung sind die Kurven und
entpsrechenden Werte der Widerstände abgebildet. Hat jemand zufällig
Widerstandskurven zur Temperatur in digitaler Form die denen aus der
Serviceanleitung entsprechen ????
Hier das Update der Pins:
Identifizierung Temperatursensoren (2107) aus den Kurven im Serviceheft:
http://www.fuehlersysteme.de/resistance_characteristics_de.pdf
Außentemperatur: NTC 10Kohm
Kesselwasser : NTC 10Kohm
Raumtemp : NTC 10Kohm
Abgas : ???
Kollektor : ???
Falls jemand digitale Quellen für die Temperaturkurven des NTC 10Kohm
kennt, immer her damit ;-).
@Mario
Hast du schon negative Temperaturen gemessen ? Hier ist die Temperatur
in den letzten Tagen leider nicht unter 0°C gegangen :-/. Kältespray
habe ich auch nicht zur Hand ...
Die Beschaltung kenne ich nicht.
Ich bekomme nur einen Wert in Form von einem Zeitintervall, der dann in
Zusammenhang mit dem Referenzwert die Temperatur darstellt. Da die
Temperatur/Werte-Paare stark nicht linear sind, ich habe zum Testen eine
Kurve aufgenommen (ohne Referenzwert), bräuchte ich eine mehr oder
minder gute Kurve vom NTC, um den Zusammenhang von diesem Refernzwert zu
ermitteln. 16Bit für einen Test ist wohl mehr als genug.
Die Temperaturen habe ich jetzt per Messung bestimmt, wie der
Referenzwert in die Messung eingeht ist jetzt auch klar.
Ich bau einen Adapter für den Bus auf RS232/TTL mit Opto und einem
AVR644er als Sklaven. Die Platine kann an das Kabel angezapft oder per
zweitem Kabel direkt eingeschliffen werden. Folgende Daten werden
erkannt bzw. können dann geändert werden: EEProm per I2C (wie die
Steckkarte, Werte sind noch nicht bekannt), alle Temperaturen und der
Status der Relais und die bisher unbekannten Pins. Die Daten können dann
per RS232 gelesen oder geschrieben werden (wenn bekannt), die Software
dann als OS. Die Platine wird etwa 6x6cm groß. Evtl. auch einen Tick
größer.
Falls Interesse besteht, würde ich mehrere Platinen fertigen lassen.
Update zur Platine:
Die Platine wird jetzt erstmal nur eine Möglichkeit zur Adaption bieten.
Das Flachbandkabel muss von der Displayeinheit gelöst werden und die
Platine wird direkt auf den Stecker von der Displayeinheit gesteckt, das
Kabel dann direkt auf die Platine. Der 644er wird erstmal mit den
internen 8MHz laufen, ein externes Quarz wird vorgesehen (falls es
Probleme mit der UART geben sollte). Dann noch ein 32KHz Quarz für den
Timer. Reset-Taster, 3 LED, Programmieradapter (6 Pol) und eine
Klemmleiste für die UART über den OPTO (RX,TX,VCC,GND). Die gefundenen
Inputs können durch Widerstände vom Bustreiber getrennt und direkt als
Inputs genutzt werden (wenn nötig).
Der 644er ist dann auch am Ende der möglichen Verdrahtung.
@rudi
Außensensor an EMS:
zum Glück waren nur ganz kurz Minusgrade (ich warte nicht wirklich
darauf).
Hat aber gereicht, um zu sehen, dass die negativen Temperaturen von
0xFFFF
rückwärts gerechnet werden 0xFFFF entspricht -0,1 Grad, 0xFFFE -0,2 Grad
usw.
Ich schlage mich gerade mit der Bereitstellung der Daten im Webserver
herum, damit mein Internet Tablet (Nokia N770) die Daten aktuell
anzeigt.
Das Nokia soll mein Hausdisplay werden (gab es günstig bei Ebay). Es
macht aber noch Probleme bei AJAX bzw. Javascript.
Aber der Winter ist ja noch lang.
Tschau,
Mario
@Mario
> herum, damit mein Internet Tablet (Nokia N770) die Daten aktuell> anzeigt.
Auch eine Idee ;-)
Zur 2107:
Die ersten Daten sind heute eingeflogen ;-) Anbei eine Grafik von den
Temperaturen und den Relais direkt vom Bus ...
Ich suche schon lange nach einer Möglichkeit die Istdaten meiner GB162
in meiner Linux-Haussteuerung auszuwerten. Nach dem Lesen des Threads
bin ich total begeistert :-)
Ich plane, den EMS-Bus mit einem Net-Io (Ethernet-AVR von Pollin)
mitzulesen. Die aktuellen Daten würde ich dann per Modbus über Ethernet
der Linuxsteuerung zur Verfügung stellen. Falls Interesse besteht würde
ich den Sourcecode natürlich auch gern weitergeben.
Eine Frage hätte ich zum Interface (Pegelwandler), gibt es da zum
Schaltplan (oben im Thread) auch eine Bestückungsliste mit richtiger
Dimensionierung der Bauelemente bzw. einen aktualisierten Schaltplan?
Grüsse Matthias
Hallo Matthias,
so etwas in der Art wollte ich auch aufbauen. Hatte aber bisher noch
keine Zeit hierfür. Wenn Du bereit wärst den Quellcode weiterzugeben,
wäre es toll.
Viele Grüße
Gerhard
> Eine Frage hätte ich zum Interface (Pegelwandler), gibt es da zum> Schaltplan (oben im Thread) auch eine Bestückungsliste mit richtiger> Dimensionierung der Bauelemente bzw. einen aktualisierten Schaltplan?
Nein, der IC wird als reiner Komparator benutzt, der Rest ist Hysterese
und Überspannungsschutz.
@ Gerhard:
Das mit der Zeit ist auch immer mein Problem...
Prinzipiell habe ich schon früher mal die WebServer-Software von Ulrich
Radig genommen, Sachen, die ich nicht brauche entfernt und eine
ModBus-Schnittstelle (Code für uCLinux stammte auch aus dem Web)
eingebaut.
Fehlt also nur noch das EMS-Interface, aber da gibt's im Thread ja auch
schon ein Beispiel für den Atmel.
Da also der verwendete Code auf der Arbeit anderer basiert geb' ich das
fertige Projekt natürlich auch gern weiter.
@Rudi
>Nein, der IC wird als reiner Komparator benutzt, der Rest ist Hysterese>und Überspannungsschutz.
Hättest Du ein Problem damit mir die Stückliste deines Aufbaus zukommen
zu lassen? Ich kenne mich nämlich eher in Software fit und für die
Hardware müsste ich mich erst noch tiefer mit der Materie befassen, da
ich meine Heizung ja nicht schrotten will.....
Falls Du das nicht über das Forum machen willst. meine eMail ist
matthias punkt bartsch at gmx punkt net.
Viele Grüsse Matthias
Nachtrag:
Der Bus ist dann nach wie vor ungeschützt.
Ein Komparator mit Opto wäre ideal, ich habe zwar die Bauteile, bin aber
noch nicht zu einem Testaufbau gekommen ...
Hallo Rudi,
ganz vielen Dank für den Schaltplan. Da kann ich mich ja sobald als
möglich an's Basteln machen. Einen Optokoppler werde ich mir
wahrscheinlich aber noch gönnen...
Grüsse und nochmals vielen Dank
Matthias
@all
Oben im Thread ist ja das Protokoll auf dem EMS-Bus beschrieben, soweit
ich gesehen habe als Phyton Programm. Ich will den Phyton-Code in eine
C-Library portieren. Oder hat das schon jemand gemacht und ich hab es
nur überlesen?
@Matthias
EMS:
ich denke, eine Library gibt es noch nicht. Rudi hat seine Auswertung in
Phyton, ich in Delphi erstellt. Da ich jetzt alle interessanten Werte
aus der Heizung habe, tut es das für mich erstmal;-)
Zum Thema Optokoppler:
ganz so kritisch würde ich das nicht sehen. Der EMS-Bus ist ja zur
Vernetzung der Heizungskomponenten im ganzen Haus gebaut und dürfte
daher ziemlich resistent gegen äußere Einflüsse sein. Im Zweifelsfall
bricht halt die Kommunikation zusammen und geht nach Störungsbeseitigung
wieder. Der Bus muss schließlich heizungsbauerkompatibel sein ;-)
Die Entscheidung muss natürlich jeder selbst treffen. No Risk, No Fun.
bye,
Mario
Hallo an Alle
Habe mich inzwischen von meinem PIC verabschiedet und habe mir ein
ATmega8 Entwicklungskit mit USB-Prog enscheiden mit dem man auch andere
Microcontroller programmieren kann. Habe den C-Quelltext von Rudi
übernehmen können und fast ohne Änderungen übernehmen können. Auch wenn
ich nicht wirklich verstehe was der Quelletext eigentlich wirklich macht
;-)
Auf der Platine ist ein Max RS232-Chip den ich einfach über ein Kabel an
den Service-Key angeschlossen habe. Funktioniert erst mal fürs erste.
Nur gibt es noch Probleme mit dem Java-programm die ich nicht wirklich
in den Griff bekomme. Irgendwie bekomme ich sämtliche Daten nur nach dem
ich den COM-Port schließe. vorher scheine ich keine Daten zu bekommen.
Würde ja auch gerne mit Python mithelfen. Allerdings habe ich echt
keinen Bock mich jetzt Tage/Nächtelang erst mal in Phyton, MySQL oder
andere Datenbank und GNU-Plot zu beschäftigen.
@All
fände es auch gut wenn nicht jeder sein eigenes Süppchen kocht. Mein
Versuch das zu ändern ist ja wohl fehlgeschlagen...
Jetzt hätten wir Rudi mit Phyton, Mario mit Delphi, ich mit Java und
jetzt kommt noch C dazu... ;-)
@Rudi
würdest Du mir/uns vielleicht Dein Script zur Verfügung stellen? Dazu
müsste ich auch wissen welche Datenbank dazu installieren müsste. Das
GNUPlot-Script wäre vielleicht auch interessant.
@Matthias
Wäre auch an einer gemeinsamen Hardware interessiert und auch an dem
Quelltext. Leider habe ich kaum den Quelltext fur den ATMega verstanden
und wäre vermutlich keine große Hilfe bei der Software. Würde auch noch
mal für das AVR-Board von Pollin geld ausgeben. Auch wenn ich für dieses
Projekt am Ende mehr Geld ausgegeben habe als für die Original Hardware
von Buderus.
Allerdings wäre es schön wenn man nicht unbedingt auf Linux angewiesen
wäre und auch mit Windows auf dem PC lassen könnte. Wäre natürlich noch
besser wenn man eine SD-Karte hätte die die Daten solange
zwischenspeichert bis man den PC hochfährt und nicht unbedingt einen
Server mitlaufen lassen muss. Das hätte den Vorteil dass man die Daten
auch weiterhin aufzeichnen kann wenn man aus irgendwelchen Gründen der
Server mal neugestartet wird.
*Könnte gerne bei der Decodierung mithelfen, auch wenn es schon so
aussieht ob schon alle Telegramme komplett entschlüsselt sind.
*Könnte auch gerne Adapterplatinen entwickeln auf der dann der
"Telegrammumwandler" sitzt und eine SD-KKarte platz findet.
Mir wäre dann aber auch wichtig dass auf der Platine eine Sendefunktion
untergebracht werden kann. Nachdem das loggen funktioniert will ich auf
jeden fall auch vom PC, Server, Controllerplatine oder was auch immer
Die Heizungsprogramme ändern kann. Vielleicht sogar automatisiert für
Feiertage und Urlaubstage für das ganze Jahr im Vorraus. Aber bis dahin
ist es wohl noch ein längerer Weg....
Gruß
Ingo
@IngoF
> fände es auch gut wenn nicht jeder sein eigenes Süppchen kocht. Mein> Versuch das zu ändern ist ja wohl fehlgeschlagen...
Jein, bisher verwenden wir mysql und gnuplot (in ajax gibt es ja auch
schon etwas) für die Visualisierung. Wie die Daten in die Datenbank
gelangen ist bisher das "Süppchen".
Ich kann meinen suboptimalen Aufbau kurz beschreiben:
Heizung -(EMS)-> Mega8 -(RS232)-> CORTEX -(RS232/USB)-> Laptop -> Parser
(python) -> Binary-Log/Sqlite-DB -(Network upload)-> Server -> Mysql ->
Gnuplot -> Web
So sieht es bei mir aus ;-)
> würdest Du mir/uns vielleicht Dein Script zur Verfügung stellen? Dazu> müsste ich auch wissen welche Datenbank dazu installieren müsste. Das> GNUPlot-Script wäre vielleicht auch interessant.
Das Skript kann bisher nicht alle Daten parsen. Ich kann die beiden mal
posten. Die Konvertierung nach Sqlite will ich da nicht drin haben, da
das mit einem kleinen Netz-Controller nicht funktioniert. Ich bin leider
bei mir, wegen der 2107, nicht viel weiter gekommen.
> Allerdings wäre es schön wenn man nicht unbedingt auf Linux angewiesen> wäre und auch mit Windows auf dem PC lassen könnte. Wäre natürlich noch> besser wenn man eine SD-Karte hätte die die Daten solange
Ja, ich werde demnächst den Kram auch auf einem Windos PC installieren.
Ab dem Netzwerkkontroller soll das dann identisch zu meiner Installation
(etwas verbessert) laufen, aber eben auf Windos. Die Adaption zur
Heizung ist komplett anders (leider). Die Tools für die Visualisierung
sind für mehrere Platformen verfügbar. Wir bräuchten einen kleinen
Webserver der die Daten empfangen/quittieren kann und in die Datenbank
schreibt und/oder ein kleines Programm welches die Daten abholt. Ich
würde schon wegen der Platformunabhängigkeit und der Wartung kein C
benutzen wollen, ich komme übrigens aus der C/C++-Ecke.
> Mir wäre dann aber auch wichtig dass auf der Platine eine Sendefunktion> untergebracht werden kann. Nachdem das loggen funktioniert will ich auf> jeden fall auch vom PC, Server, Controllerplatine oder was auch immer
Mach das ! Du hast 12V/GND und das Signal. Das Signal liegt bei +- 2.5V
auf den 12V (9600 Baud). Eingang dann vom uC mit 3.3V oder 5V. Wenn du
daran arbeiten könntest wäre das super !
Das Hauptproblem bei Senden ist die CRC. Im schlimmsten Fall muss man
den String 256 mal senden ...
Hallo,
will mich nochmal zu Wort melden bzgl. meiner Vorstellung mit dem
Pollin-Board. Vorteil sind die geringen Hardwarekosten (ca. 20€ als
Bausatz bzw. knapp 30€ für das Fertiggerät). Die Busanschaltung muss man
dann natürlich noch selber basteln. Für das Board sind schon viele
fertige Projekte im Netz zu finden, mit denen man ohne grossen
Entwicklungsaufwand eine gute Software-System-Grundlage hat.
Implementiert man darauf das EMS-Protokoll hat man mit geringen Kosten
eine netzwerkfähige Schnittstelle zur Heizung (seriell könnte das Board
auch).
Implementiert man jetzt hier drauf das Modbus-Protokoll, kann man die
Kiste neben Linux und Windows z.B. auch mit einem
Wago-Ethernetcontroller (Wago System 750) auslesen.
Prinzipiell könnte ich mir als Interface natürlich auch andere Hardware
vorstellen, aber nach meiner Erfahrung ist es oft so, das wenn man noch
viel neu entwickeln muss ein Projekt oft einschläft.
Zweifelsohne wäre aber ein SD-Interface praktsch, wenn man keinen Server
ständig am Laufen hat.
Vielleicht sollte man im ersten Schritt aber mal alle Infos in einem
Wiki o.ä. sammeln. Dann könnte man sich besser orientieren was es schon
gibt. Ich habe zwar noch nie ein Wiki aufgesetzt aber ich könnte mir mal
ansehen wie das geht. Denn auf die Dauer wird der Thread schon ziemlich
unübersichtlich.
@Werner Brösel,
nöhh, hab keine Lust am hijacken. Macht ja im Endeffekt nur Arbeit. Für
meine privaten Zwecke komme ich mit den Infos hier gut klar. Ich könnte
also auch nur schnorren und mich an der Arbeit anderer bedienen, ohne
was beizutragen..
@Matthias
> Ich könnte also auch nur schnorren und mich an der Arbeit anderer> bedienen, ohne was beizutragen..
Was hast Du dir vorgestellt ? Für eine Wiki kann ich mich nicht
begeistern, man findet nichts wieder und es gibt irgendwie keine
gescheite Übersicht der Artikel.
Wenn wir einen zentralen Ort anlegen, dann für alle. Doku, Software und
ein Forum/Mailinglist für Hilfe und Austausch, von der möglichen
B.-Kontra abgesehen ;-)
Evtl. können sich die stillen Mitleser dazu äußern ...
@Rudi
>Was hast Du dir vorgestellt ? Für eine Wiki kann ich mich nicht>begeistern, man findet nichts wieder und es gibt irgendwie keine>gescheite Übersicht der Artikel.
Beim Suchen nach einer Schnittstellenbibliothek für Buderus bin ich auf
ein Projekt für Viessmann-Geräte gestossen (http://openv.wikispaces.com)
Etwas in der Art fände ich praktisch... Zumal ja jeder etwas andere
Bedürfnisse/Infrastruktur hat und da könnte man übersichtlich die
einzelnen Lösungen sortieren.
@Matthias
> Beim Suchen nach einer Schnittstellenbibliothek für Buderus bin ich auf> ein Projekt für Viessmann-Geräte gestossen (http://openv.wikispaces.com)> Etwas in der Art fände ich praktisch... Zumal ja jeder etwas andere> Bedürfnisse/Infrastruktur hat und da könnte man übersichtlich die> einzelnen Lösungen sortieren.
Also eher ein CMS als ein Wiki. Die Sourcen und Programme sind bei denen
nicht auf der gleichen Domain.
Ich würde ein Projekt auf Sourceforge anlegen, Webseite,
Sourceverwaltung, Mailingliste ... . Für die Webseite könnte ich mir
(bitte nicht schlagen;-)) joomla vorstellen und dann über die
Userverwaltung das Editieren erledigen. Am Ende sind es eh nur eine Hand
voll Leute die aktiv etwas tun. Siehe hier ;-)
>Ich würde ein Projekt auf Sourceforge anlegen, Webseite,>Sourceverwaltung, Mailingliste ... . Für die Webseite könnte ich mir>(bitte nicht schlagen;-)) joomla vorstellen und dann über die>Userverwaltung das Editieren erledigen.
@Rudi
Ok, wollen wir es mal angehen? Die Webseite ja keinen Schönheitspreis
gewinnen, Hauptsache man strukturiert die vielen Infos mal.
Vielleicht kannst Du initial die Seite anlegen, Du hast ja auch am
meisten zu dem Projekt beigetragen. Damit keinn Hijacker-Verdacht
aufkommt....
Habe mir gestern aus dem Thread mal die Protokoll-Infos zusammengesucht,
die ich für die Anbindung brauche. Ich schreib jetzt das sowieso mal für
mich zusammen. Post wenn ich fertig bin mal meine Zusammenfassung.
Hallo,
lese auch bei Euch mit, obwohl ich eine Ecomatic 4000 habe ... beim
Aufbau der Seite mit Joomla! kann ich Euch gerne ein wenig unterstützen.
Gruß,
Mike
Buderus HS2401 / Ecomatic 4000 (mit Schieberegler) / Baujahr 1994
ATMEL ATMEGA32, Pollin AVR Net I/O, EvalBoard 2.0.1 / AddOn Board
@Ingo:
Vielen Dank für die Tabelle. Habe Sie mal mit den anderen Infos
abgeglichen und ergänzt. Muss ich noch weiterbearbeiten, aber mal als
Zwischenstand für alle.
Gruss Matthias
@Rudi
sieht sehr gut aus. Wie sehen denn die Dokumentation aus wenn einzelne
Bits eine bestimmte Bedeutung haben?
Allerdings müsste man dafür TEX installieren um es zu bearbeiten. Oder
ist das ein Format dass man mit OpenOffice oder anderen Programmen
öffnen könnte?
Warum kein Dateiformat wofür man kein spezielles Programm für benötigt?
Kann man die Datei denn auf der Webseite (Joomla) bearbeiten und
automatisiert aus der Datenbank erstellen? Glaub mit Joomla kann man ja
auch automatisiert PDF Dateien erstellen, oder?
Gruß
Ingo
> sieht sehr gut aus. Wie sehen denn die Dokumentation aus wenn einzelne> Bits eine bestimmte Bedeutung haben?
Das könnte man da problemlos einbauen, z.B etwas eingerückt.
> Allerdings müsste man dafür TEX installieren um es zu bearbeiten. Oder> ist das ein Format dass man mit OpenOffice oder anderen Programmen> öffnen könnte?
Das Tex-Quell-Format ist reiner Text ;-). Okay, die Syntax ist etwas
anders. Du kannst den auch mit Edit öffnen, um aber ein formatiertes
Dokument zu erstellen brauchst du Tex. In meinem Fall habe ich es in
eine PDF-Datei gewandelt. Das gute daran, du kannst den "Quelltext" in
GIT oder was auch immer verwalten und Änderungen verfolgen.
> Warum kein Dateiformat wofür man kein spezielles Programm für benötigt?
Ich finde PDF schon als normales Format, es ist allerdings nur der
Output.
> Kann man die Datei denn auf der Webseite (Joomla) bearbeiten und> automatisiert aus der Datenbank erstellen? Glaub mit Joomla kann man ja> auch automatisiert PDF Dateien erstellen, oder?
Nein, das wäre mit viel Aufwand verbunden.
Das mit dem Bild war auch nur ein Vorschlag wie man es machen könnte.
Hallo!
bin leider erst jetzt auf diesen Thread gestoßen. Ich habe ein KM271
bei mir in Betrieb, an einer Logamatic 2105 (wie 2107, nur ohne
Solarmodul-Nachrüstmöglichkeit) mit Warmwasserbereitung.
Ich habe auch die Software und mittels Serial-Logger das Protokoll
zum Teil ermittelt. Eine Beschreibung findet Ihr im Anhang. Im Moment
kenne ich nur den Log-Modus, kann also nur die laufenden Meldungen
der Heizung interpretieren, aber keine Änderungen an der Konfiguration
vornehmen. Dazu müsste ich mal wieder die Windows-Software von Buderus
laufen lassen und mitprotokollieren.
Das KM271 könnte ich bei Gelegenheit ausbauen und fotografieren damit
man die Bauteile und Verbindungen bestimmen kann, aber das kann ich erst
am Wochenende.
Schreibt mal, ob das Protokoll der KM-271 hilft bei Eurem Ansatz.
Himtronics
@Joachim König
Das sind doch mal ein paar Daten. Sind die evtl. auch dort beschrieben:
Beitrag "Re: Logamatic 2107 Schnittstelle"
Das KM271-Modul setzt die RS232 auf I2C um und vice versa. Das
Display-Modul fragt eine I2C-Adresse ab, die evtl. ohne Solar oder KM271
nicht auf dem Bus vorhanden ist '(Beide benutzen wohl die gleiche
Adresse). Ich konnte die Displayeinheit aber nicht zur Kommunikation
überreden, bzw. habe dort auch nicht weiter geforscht, da die Daten auch
direkt abgegriffen werden können, mit direktem Zugriff auf das EEProm
(I2C).
Viele Daten können eigentlich nur im EEProm gespeichert werden, den
Aufbau der Daten zu finden ist mit einem KM271 mit Sicherheit viel
einfacher ...
Einige Bilder mit erkennbaren IC Bezeichnungen und Leiterbahnen wären
super !
Einige Fragen habe ich noch:
Was ist die Pumpenleistung ? Braucht man für die Steuerung ein extra
Modul ?
Was sind das für Werte:
Brennereinschalttemperatur/Brennerausschalttemperatur ??? Welche
Temperaturen werden dort gemessen ?
@Rudi schrieb:
> Was sind das für Werte:> Brennereinschalttemperatur/Brennerausschalttemperatur ??? Welche> Temperaturen werden dort gemessen ?
das sind keine Messwerte sondern die Temperatur, bei der der
Brenner ein- beziehungsweise ausschaltet. Die ist abhängig
von der Aussentemperatur, dem Gebäudetyp etc, also wenn's
draußen kalt ist, soll das Wasser im Kessel heißer
sein als wenn's lau ist, insbesondere wenn kein Mischer
vorhanden ist. So ähnlich jedenfalls.
Hallo,
habe es endlich geschafft Ein Java-Programm zum laufen zu bekommen. Es
werden nur Telegramme mit Daten mitgeloggt.
Man muss den PC mit dem Sklaven verbinden der das Break erkennt und
einen Rahmen um die Daten setzt. Dannach noch die richtige Schnittstelle
auswählen und 'Verbinden' drücken.
Wenn Java installiert ist muss man nur das ZIP entpacken und emslog.jar
oder emslog.bat mit doppelklick starten. Wenn man EMSlog schließt ohne
vorher auf 'Verbinden' zu klicken muss man EMSlog mit dem TaskManager
beenden.
Es gibt noch unter bestimmten Bedingungen Lesefehler auftreten.
Sonst kann das Programm noch garnichts. Jetzt kann ich endlich mit der
Programmierung anfangen ;-)
Für die Mitleser die keine Hardware zum Testen haben können sich ja das
Screenschot ansehen.
Gruß
Ingo
Sehr schön. Also gibt es doch noch 2 Leitungen für eine UART auf dem
Bus.
Empfängst du, auch ohne den Logmodus zu aktivieren, Daten auf der UART ?
Wird dort zufällig zyklisch etwas gesendet ?
Rudi schrieb:
> Sehr schön. Also gibt es doch noch 2 Leitungen für eine UART auf dem> Bus.> Empfängst du, auch ohne den Logmodus zu aktivieren, Daten auf der UART ?> Wird dort zufällig zyklisch etwas gesendet ?
Nein, da ist Ruhe. Werde mir bei Gelegenheit mal das Protokoll
ansehen für das Ändern der Konfiguration. Die Konfiguration
die am Anfang nach dem Aktivieren des Protokoll-Modus gesendet
wird, kann ich schon zum Teil interpretieren, z.B. die Zeiten für
die Heizphasen.
Hallo Rudi,
kannst Du mir ein wenig über die Struktur Deiner mySQL-Datenbank geben?
Wie hast Du die angelegt? Pro Telegramm eine Tabelle? Die
unterschiedlichen Telegramme kommen ja zu unterschiedlichen Zeit und
natürlich unterschiedlich oft.
Belegen eigentlich nicht benutzte Werte Speicherplatz? Denke schon.
Was für Datenformate hast Du verwendet. Hätte nie gedachte dass es
soooooooo viele Datenformate geben kann. Bei der Datenbank soll ja nicht
wirklich unütz Platz verschwendet werden.
Gruß
Ingo
@IngoF
Ich speicher keine Datensätze von der Anlage in der Datenbank. Die
Logdateien belaufen sich in etwa auf 10GB über gefühlte 3 Monate.
In der Datenbank werden nur relevante Daten gespeichert. Temperaturen,
Brenner, Gaszähler usw..
Ich habe bisher 2.5M Einträge vom Juli an. Der Durchschnitt ist im Laufe
der Zeit durch Optimierung aber weniger geworden.
Der Aufbau der Datenbank ist für eine Query nicht optimal, aber ich sehe
erstmal nichts einfacheres. Es gibt eine Tabelle mit IDs der Sensoren
und die Datentabelle.
SOURCE-TABLE:
Die ADDR ist bei mir der MAC angelehnt, z.B. 00:12:33:12:21:55:45:45
oder auch HE:IZ:00:00:00:00:00:01.
Da ich mehrere Sensoren habe, und es auch mehr werden sollen, ist das
erstmal für mich wichtig die Daten nach dem Absender zu unterscheiden.
Die Datentabelle ist dann nicht sooo optimal, hält sich aber in Grenzen:
Bei der Tabelle:
SOURCE : Source-ID aus der Tabelle SOURCE
TYPE: Typ der Daten, kann für jeden Sensor selbst festgelegt werden
DATA: die Daten
TIME: UTC Zeitstempel
>Ich speicher keine Datensätze von der Anlage in der Datenbank. Die>Logdateien belaufen sich in etwa auf 10GB über gefühlte 3 Monate.>>In der Datenbank werden nur relevante Daten gespeichert. Temperaturen,>Brenner, Gaszähler usw..
Da hast Du mich falsch verstanden. Natürlich wollte ich auch keine
unnützen Daten speichern.
------------------------------------------------------------------------
--
Mal angenommen jedes Telegramm hätte 22Byte.
Das Telegramm 0815 kommt alle 10 Sekunden und hat 10 Temperaturen
(0815=2 +10*2 pro Temperatur).
Das Telegramm 4711 kommt jede Sekunde und hat eine Temperatur.
(4711=2Byte +1*2Byte für Temperatur +18Byte noch unbekannt).
Ich hatte jetzt gedacht:
eine Tabelle für Telegramm 0815 mit 10 Spalte/Werten und 6 Einträgen pro
Minute.
Die zweite Tabelle für Telegramm 4711 mit einer Spalte/Wert und 60
Einträgen pro Minute.
------------------------------------------------------------------------
--
Also hätte man hinterher 2 Tabellen mit etwa 60Byte pro Minute.
> `DATA` char(200) NOT NULL,
Sorry, aber bin noch nicht soweit mit mySQL... Ich hoffe nicht dass für
jeden Sensor mit 200 Zeichen gespeichert wird.
Gruß
Ingo
> > `DATA` char(200) NOT NULL,> Sorry, aber bin noch nicht soweit mit mySQL... Ich hoffe nicht dass für> jeden Sensor mit 200 Zeichen gespeichert wird.
Doch, aber dafür gibt es dann:
PACK_KEYS=1 ROW_FORMAT=DYNAMIC
;-)
Ich wollte erst ein float, aber evtl. kommen doch noch andere Daten.
> Ich hatte jetzt gedacht:> eine Tabelle für Telegramm 0815 mit 10 Spalte/Werten und 6 Einträgen pro> Minute.> Die zweite Tabelle für Telegramm 4711 mit einer Spalte/Wert und 60> Einträgen pro Minute.
Wenn du keine Daten verlieren willst kannst du es so machen. Im
Zweifelsfall einfach eine Tabelle anlegen und mit Pseudodaten füllen und
schauen wie groß die Tabelle etwa wird.
Das füllen der Tabelle ist nicht das Problem. Die Abfragen für die
Grafik usw. sind bei vielen Daten sehr CPU lastig. Speicherplatz ist
eigentlich kein Problem.
@Joachim K.
> Nein, da ist Ruhe. Werde mir bei Gelegenheit mal das Protokoll> ansehen für das Ändern der Konfiguration. Die Konfiguration> die am Anfang nach dem Aktivieren des Protokoll-Modus gesendet> wird, kann ich schon zum Teil interpretieren, z.B. die Zeiten für> die Heizphasen.
Ich konnte es mehr oder weniger verifizieren. Ohne eingesteckte Platine
lässt sich der Modus nicht aktivieren. Bei erkanntem/eingeschaltetem
zweiten Heizkreis werden dort andere Daten gesendet und es wird nicht
auf 0x02 oder 0x10 geantwortet.
Moin allerseits,
ich hänge mich hier mal mit dran, da ich schon ne Weile mitlese ...
Wir haben eine GB142 mit ner RC35. Das Ganze Projekt klingt recht
spannend, aber einiges habe ich noch nicht verstanden.
Es sind 2 unterschiedliche Systeme, ja? Einmal die Logamatic2107 und
einmal die RC30/35 Serie, wobei aber beide Systeme das gleiche Protokoll
haben?
Technische Möglichkeiten wie Oszi stehen mir leider nicht zur Verfügung,
daher könnte ich höchstens versuchen bei der weiteren Entschlüsselung zu
helfen!?
Benötigt wird also der Klinkenstecker für die RC3x und dann eine kleine
Platine zur Umsetzung. Bei mir läuft eh ein Homeserver 24/7 , auf dem
die Daten dann verarbeitet werden könnten. SQL ist ebenfalls vorhanden.
Das Signal kann man dann einfach über die RS232 Schnittstelle im PC
verwerten oder wird noch weiteres benötigt wie z.B. ein µC zur Umsetzung
des Datenstroms auf der Platine und dann erst die Kommunikation zum PC?
Gruß
Jens
@Jens H.
> Es sind 2 unterschiedliche Systeme, ja?
Ja.
> Einmal die Logamatic2107 und einmal die RC30/35 Serie, wobei aber beide> Systeme das gleiche Protokoll haben?
Nein.
> Technische Möglichkeiten wie Oszi stehen mir leider nicht zur Verfügung,> daher könnte ich höchstens versuchen bei der weiteren Entschlüsselung zu> helfen!?
Ja, die CRC ist bei der RC30/35 noch nicht ganz klar.
> Benötigt wird also der Klinkenstecker für die RC3x und dann eine kleine> Platine zur Umsetzung.
Ja.
> Das Signal kann man dann einfach über die RS232 Schnittstelle im PC> verwerten oder wird noch weiteres benötigt wie z.B. ein µC zur Umsetzung> des Datenstroms auf der Platine und dann erst die Kommunikation zum PC?
Ein uC vor dem PC ist besser, siehe oben die Posts.
@Matthias:
> Unter Beitrag "eBus CRC Berechnung nachvollziehen" wird über den eBus> diskutiert. Der EMS-Bus scheint dem eBus ja sehr ähnlich.> Unter> http://www.mikrocontroller.net/attachment/54958/eB...> ist auf S.28 ein eBus Interface dargestellt. Würde das auch für den> EMS-Bus gehen? (vielleicht nicht unbedingt 24V Versorgung) Was meint ihr> dazu?
Könnte funktionieren. Musste man aber auf 12V auslegen. Evtl. sind die
9600 Baud zu schnell, muesste man mal aufbauen und messen.
Hallo Rudi,
danke für die Antworten! Ein µC davor ist besser, aber nicht zwingend
notwendig oder wird auf jeden Fall benötigt? Oder hängt das von der
verwendeten Software auf dem Rechner ab?
Ich war mir sicher das mit dem µC gelesen zu haben, habe es aber vorhin
nicht wiedergefunden und deswegen gefragt ;-)
Die main.c von Mario hab ich gefunden, aber leider noch kein Schaltbild
um eine Platine aufzusetzen. Wobei ihr ja scheinbar unterschiedliche
Versionen einsetzt, da Mario mit nem Mega128 arbeitet und du nen Mega8
einsetzt.
Magst du vielleicht das Layout preis geben?
@Matthias:
Falls die eBus Platine funktionieren sollte, wäre das natürlich auch
noch ne Möglichkeit ;-)
Sorry für die vielleicht blöde Frage, aber direkt von Buderus gibt es ja
noch ein RS232 Gateway für die aktuellen Thermen, das ist aber nicht die
Logamatic 2107 Schnittstelle oder doch?
Gruß
Jens
@ Jens H.
> danke für die Antworten! Ein µC davor ist besser, aber nicht zwingend> notwendig oder wird auf jeden Fall benötigt? Oder hängt das von der> verwendeten Software auf dem Rechner ab?
Ein PC ist zu langsam bzw. hat kein Realtime. Also uC und fertig.
> aber leider noch kein Schaltbild> um eine Platine aufzusetzen. Wobei ihr ja scheinbar unterschiedliche> Versionen einsetzt, da Mario mit nem Mega128 arbeitet und du nen Mega8> einsetzt.> Magst du vielleicht das Layout preis geben?
Ein Mega8 und dann VCC/GND RX/TX, also nichts kompliziertes was
unbedingt ein Layout erfordert. Fertige Eval. Boards gibts ja wie Sand
am Meer.
Also ich habe auch den ATmega8.
Habe mir ein Komplettkit mit USBprog fur etwa 69 Euro gekauft. Ist alles
drin was man zur Programmierung für den Atmega8 braucht.
Am Service-key gibt es zwei Kontakte die das Signal mit +-2,5Volt haben.
Diese habe ich einfach ohne weitere Technik auf den RX-Eingang des
Atmega8 gelegt.
Der Quellcode für den ATmega8 wurde hier schon von Rudi gepostet.
Den PC schließt man am TX-Ausgang des Atmega8 an.
Bisher läuft es nur am Service-Key direkt. Wenn man die Platine am Bus
anschließen will benötigt man auf jeden Falle ein Schaltung die ich mir
auch noch zulegen werde.
Ich habe es schon, mit Hilfe von Rudi geschafft ein Java-Programm zu
schreiben dass die Daten mittloggt und in der MySQL-Datenbank
abspeichert. Wenn die letzten Fehler weg sind werde ich hier gerne den
Download-Link posten. Die Visualisierung kommt natürlich auch noch rein.
Vermutlich mit GNUPlot oder direkt im Java-Programm.
Gruß
Ingo
Hallo ihr zwei, vielen Dank für die Hinweise
Da ich KEINEN Service-key habe, muss ich direkt an den Bus. Sehe ich das
richtig, das Ingo mit Service-Key arbeitet und Rudi ohne oder auch mit?
Denn Ingo schreibt ja ohne Service-Key benötigt man ne Schaltung dafür!?
Daher auch meine Frage nach einer passenden Platine ... Denn wenn dafür
noch ne Schaltung benötigt wird, dann könnte man die ganze Sache auch
auf eine Platine basteln.
Gruß
Jens
Also an der Service-Key-Buchse gibt es das Bus-Signal mit +-2,5 Volt. Ab
Bus (also dort wo die RC30 oder RC35 dran hängt) kommen 12 +-2,5 Volt an
und können nicht einfach ohne Schaltung an den ATmega8 angeschlossen
werden.
Habe nur zwei Brücken auf der Platine eingelegt, ein Adapterkabel ohne
Elektronik gebastelt und es hat funktioniert.
Habe die CRC-Berechnung noch mal mit dem Generator-Polynom berechnet.
Hat laeider nicht funktioniert. Werde mal wenn ich Zeit habe einfach
alle möglichen Berechnungen durchlaufen (Startwerte 0x00-0xff, XOR am
Ende 0x00-0xff und Generatorpolynome 0x00-0xff) und dann sollte sich das
Geheimnis irgendwie lüften lassen.
Es ist jedenfalls kein simples XOR oder addierung über alle Werte.
Standart CRC-8 funktioniert auch nicht.
Aber für das simple mitloggen braucht man erst mal keine CRC. Aber
irgendwann möchte ich ja auch mal die Schaltprogramme ändern. spätestens
dann geht es nicht ohne CRC-Berechnung.
Gruß
Ingo
Zur 2107:
Anbei die ersten Daten der Platine. Der Anfang (rot) ist noch vom
Versuchsaufbau mit einigen Störungen auf den langen Datenleitungen. Was
sich die Leitungen eingefangen hatten, wenn der Brenner startet, ist
schon nicht schlecht.
@IngoF
> Habe die CRC-Berechnung noch mal mit dem Generator-Polynom berechnet.
Ich habe es auch schon mit Bruteforce versucht. Filter dir einfach mal
eine kurze Nachricht, die sich zyklisch ändert. Am besten das Datum.
Dort sieht man sehr schön wie sich die CRC ändert. Für ein paar dieser
Nachrichten kann die CRC berechnet werden, und für andere wieder nicht.
Sehr komisch die Berechnung.
Ich habe mir diese Nachrichten genommen (etwa 10) und habe dann per
Bruteforce das gemeinsame Polynome/Startwert/XOR-Endwert gesucht. Leider
ohne Erfolg (Fehler nicht ausgeschlossen).
Bin auch gerade dabei. Habe zwei Nachrichten genommen und schreibe
gerade eine BatchDatei....
Welchen Teil hast Du denn zur Berechnung eingeschlossen?
vielleicht werden die ersten (adress)Bytes ja nicht mit einbezogen.
Versuche mich gerade an diesen beiden:
10 88 14 00 03 6e 00
10 89 29 00 01 90 00
Berechne die Checksumme über alles inkl. der Prüfsumme (6e und 90) und
ignoriere das break (00).
Dann sollte beim richtigen Polynom oder Berechnung 00 als Prüfsumme
herauskommen.
Gruß
Ingo
> Welchen Teil hast Du denn zur Berechnung eingeschlossen?> vielleicht werden die ersten (adress)Bytes ja nicht mit einbezogen.
Deswegen habe ich immer den gleichen Nachrichtentyp genommen. Da sollte
es bei CRC8 keine Probleme geben, da der Startwert immer gleich ist.
> Berechne die Checksumme über alles inkl. der Prüfsumme (6e und 90) und> ignoriere das break (00).
Ja.
> Dann sollte beim richtigen Polynom oder Berechnung 00 als Prüfsumme> herauskommen.
Genau.
@Jens H.:
> Daher auch meine Frage nach einer passenden Platine ... Denn wenn dafür> noch ne Schaltung benötigt wird, dann könnte man die ganze Sache auch> auf eine Platine basteln.
Ohne Service-Key benötigst du eine kleine Schaltung für den RX. Der
MEGA8 wäre dafür geeignet, da man die Kommunikation zur Heizung über
eine Software-UART realisieren muesste (Frame-Error). Der MEGA hat ja
nur eine UART. ...
Mario schrieb:
> @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
@Rudi
als Antwort schriebst du, der Mega8 hat nur einen Usart.
An Rx den EMS-Bus und an Tx kommen die Daten raus ????
Dann kannst du aber doch nicht ZUM Bus schreiben ??? Verwirrung ???
Noch `ne Frage:
Würdest du das Hex und die Configuration dafür rausrücken?
Gruß Helmut
@Helmut
Also zur Zeit gibt es nur ein "Interface" zum loggen. Wenn man schreiben
will benötigt man entweder einen zweiten UART oder einen zweiten
ATMega8.
Allerdings müsste man sich noch Gedanken über "Schaltung" machen die
auch auf dem selben Bus senden <b>und</b> empfangen kann.
Aber darüber kann man sich Gedanken machen wenn die CRC bekannt ist.
Ohne die CRC-Berechnung nützt das "senden können" leider ganrichts wenn
die Heizung die wegen Übertragungsfehler ignoriert. Und jedes Telegramm
evtl. 256 mal zu senden ist auch keine Lösung.
Habe gerade ein Batch Datei geschrieben die die CRC-Berechnung für fast
alle Parameter die man angeben kann durchführt.
Es sind 1048576 Berechnung für die mein PC vermutlich 26 Stunden
brauchen wird.
Dummerweise wird die LOG-Datei etwa 8MByte groß und muss dann noch nach
den richtigen Werten durchsucht werden.
Vielleicht hat ja jemand eine Idee oder kann ein auswertescript oder
Programm schreiben.
jede errechnete CRC steht als Dezimalzahl in einer Zeile mit einem
Doppelpunkt als erstes Zeichen. Jeder Block besteht aus 4 Zeilen
(4Telegramme).
Die Datei muss nach vier gleichen aufeinanderfolgenden CRC-Prüfsummen
durchsucht werden. Eventuell reicht schon ein durchsuchen nach vier
aufeinander folgenden 0-CRC.
Gruß
Ingo
Ups.. das war alles nicht für Helmut gedacht....
@Helmut.
Der C-Quelltext wurde von Rudi ja schon gepostet. Kann aber auch gerne
die HEX-Datei hier hochladen die ich daraus erzeugt habe, falls Rudi
nicht schneller ist. Allerdings ist mein PC mit der HEX-Datei gerade mit
CRC-Berechnungen beschäftigt und ich muss warten bis er damit fertig
ist. Die Datei ist auf der anderen Partition :(
@all
wer eine Idee hat hier mal eine Kostprobe der CRC-Datei die gerade
entsteht:
Danke für den hinweis... Aber meine CRC-Berechnung müsste bald fertig
sein und das Script wird vermutlich auch nicht schneller als die
JAVA-Version sein. Fragt sich nur wie ich das Ergebnis durchforsten
soll...
Gruß
Ingo
Habe für diese Telegramme die CRC berechnet:
108811241829
108811181B52
10881400036e
108929000190
Habe fast alle möglichen Kombinationen berechnen lassen:
Polynom: 0x00 bis 0xff
Startwert 0x00 bis 0xff
Eingabe gespiegelt: true,false
Ausgabe gespiegelt: true,false
Ein abschließendes XOR habe ich nicht eingegeben weil die Berecnung
sonst 280 tage gedauert hätte. Aber wenn man bei den Telegrammen nach
gleicher Prüfsumme sucht erübrigt sich ja die Berechnung, oder?
Nur das Durchsuchen der Ergebnisse ist nicht ganz sooo einfach.
Habe schon mal versucht die vorkommenden Nullen mit Zeilennummer
(findstring in DOS) in eine Textdatei zu exportieren. Die Ergebnisse
habe ich in Excel geladen und durch Berechnung die vierer Blöcke zu
finden (Wert Zeile)-(Wert-Zeile-3). Also sollte als ergebnis 3 für die
vierer Blöcke herauskommen.
Alle Zeilen mit falschen Ergebnis gelöscht. Dann den Abstand mit Exel
errechnet. Dabei kam immer ein Abstand zwischen den Polynomen von 128
oder 256. Also gabe es wenn meine Überlegungen richtig waren nur bei
0x00 und 0x80 zu einem vierer Block mit CRC=0
Demanch wurde keine richtige CRC erkannt oder die CRC würde anschliend
noch mal mit XOR verknüpft.
Also müsste man nicht nach einem vierer Block 0 suchen sondern nach
einem Block mit vier selben CRC. Keine Ahnung wie ich das anstellen
könnte. mit Excel kann ich die Ergebnisse natürlich nicht einlesen weil
max 64k Zeilen erlaubt sind.
Gruß
Ingo
Na dann bruach ich ja garnicht weitersuchen.... Dann kann es keine
"richtige" CRC-Berechnung sein sondern irgendwelchen Berechnungen.
Kann es vielleicht sein dass es doch keine Prüfsumme ist?
Bei deinen Beispielen gibt es ja nur 2 Prüfsummen für 20 verschiedene
Telegramme. Was macht denn dann eine Prüfsumme für einen Sinn wenn die
Prüfsumme keine Sicherheit bietet?
Bei anderen Telegrammen habe ich allerdings festgestellt dass sich die
"Prüfsumme" schon ändert wenn sich nur ein einziges Bit geändert hat.
08 00 18 00 07 01 11 00 00 00 00 00 60 80 00 02 0D 01 1D 00 00 0C 30 48
00 CB FF 00 00 4B 00
08 00 18 00 07 01 10 00 00 00 00 00 60 80 00 02 0D 01 1D 00 00 0C 30 48
00 CB FF 00 00 94 00
Gruß
Ingo
Aus den Fotos habe ich mal den angehängten Schaltplan extrahiert. Die
Werte für die Widerstände und Kondensatoren kann ich nicht erkennen. R2,
1003 (100k) konnte ich erkennen. Die Widerstände werden möglicherweise
für die Modulerkennung benötigt.
Ich habe versucht ohne die R/C-Beschaltung mit 2400,8N1 ein Byte 0x02
(STX) zu schicken, darauf erhalte ich keine Antwort (DEL, 0x10). Wird
ein eingestecktes KM271 irgendwo im Display-Menue angezeigt?
@IngoF
> Kann es vielleicht sein dass es doch keine Prüfsumme ist?> Bei deinen Beispielen gibt es ja nur 2 Prüfsummen für 20 verschiedene> Telegramme. Was macht denn dann eine Prüfsumme für einen Sinn wenn die> Prüfsumme keine Sicherheit bietet?
Nene, der letzte Wert ist die XOR über alle Daten+CRC ;-)
Die CRC8 ist eine schwache Prüfsumme, aus diesem Grund ändert sich die
auch relativ gleichmaessig mit den Daten.
Je nachdem welches Bit sich in welchem Byte ändert, geht es in die CRC
anders mit ein. Es ist auf alle Fälle ist die CRC kein einfaches XOR.
> Wird ein eingestecktes KM271 irgendwo im Display-Menue angezeigt?
Im Installationsmenue erscheint unter KESSEL der Menuepunkt
ABGASTEMPERATURSCHWELLE, wenn das KM271 erkannt wurde.
Rudi schrieb:
> Nene, der letzte Wert ist die XOR über alle Daten+CRC ;-)
Dann habe ich Dich falsch verstanden.. Ich dachte die A3 und A0 wäre die
Prüfsumme... deswegen auch meine Verwunderung. 20 verschiedene
Telegramme und jedesmal die Prüfsumme "A3". Was ist denn die A3?
> Je nachdem welches Bit sich in welchem Byte ändert, geht es in die CRC> anders mit ein. Es ist auf alle Fälle ist die CRC kein einfaches XOR.
Hatte es so verstanden dass eine CRC durch eine Polynomdivision
errechnet wird. Wenn die anders errechnet wird ist es keine CRC sondern
nur eine andere Art der Prüfsumme, oder habe ich das
falsch verstanden.
Hatte auch mal einige Prüfsummen für Telegramme mit XOR berechnet und
habe keine Übereinstimmung gefunden. Habe wohl was falsches
berechnet.... Werde das auch mal testen...
Gruß
Ingo
@Rudi:
Richtig, das R/C Netz R1/R2/C5 stimmte nicht. Gegenüber dem Foto ist im
Schaltplan der Edgeconnector um 180° gedreht, damit er mit der Aufsicht
auf die Steuerung von vorne übereinstimmt. Zur Orientierung noch ein
Lageplan des Modul-Steckverbinders auf der Busplatine mit den
Pinnummern.
chipshuffler schrieb:
> Wird ein eingestecktes KM271 irgendwo im Display-Menue angezeigt?
Wenn man am Drehknopf dreht erscheint nach der Kesseltemperatur dann
die Abgastemperatur. Man muss also nicht ins Installationsmenue.
Kennt jemand eine günstige Bezugsquelle für einen geeigneten PTC
für die Abgastemperaturbestimmung?
@Joachim K.
Es gibt bei B. eine Liste mit den Werten und Bezeichnungen für die
unterschiedlichen PTC, hatte ich mal gesucht, aber keinen Link mehr.
Die Module werden über die Temperatursensoren identifiziert und nicht
über Steuerleitungen ... ;-). Die Leitungen gehen an die Steuerplatine
und dann die ADC-Werte über das Flachbandkabel an die Displayeinheit,
die diese dann identifiziert. Alles sehr abenteuerlich ...
@chipshuffler
Schau dir die Sensorleitungen besser nochmal an. Das ist übrigens eine
Schutzbeschaltung für die Eingange mit Pullup oder Down. Mach dir deine
Heizung nicht kaputt ! Da hängt ein ADC dran.
@Ingo F.
> Was ist denn die A3?
XOR über die Daten und CRC
> Wenn die anders errechnet wird ist es keine CRC sondern> nur eine andere Art der Prüfsumme, oder habe ich das> falsch verstanden.
Ich denke das ist schon eine CRC. Evtl. etwas abgeändert. Ich habe mich
damit nicht wirklich tiefgründiger beschäftigt. Ich sehe aber in den
Betriebsstunden einen guten Ansatz um diese zu finden.
Rudi schrieb:
> @Joachim K.>> Es gibt bei B. eine Liste mit den Werten und Bezeichnungen für die> unterschiedlichen PTC, hatte ich mal gesucht, aber keinen Link mehr.>> Die Module werden über die Temperatursensoren identifiziert und nicht> über Steuerleitungen ... ;-). Die Leitungen gehen an die Steuerplatine> und dann die ADC-Werte über das Flachbandkabel an die Displayeinheit,> die diese dann identifiziert. Alles sehr abenteuerlich ...
An das KM271 kann man einen PTC zum Messen der Abgastemperatur
anschließen (FG 1 und 2 in meinem Photo der Platine). Ich suche
mal den Wert raus.
@Joachim K.:
Nach der Kennlinie müsste die 2107 mit ca. 10k als Ersatz für den
Abgfasfühler-PTC erkennen.
Ich habe ein Paar Widerstände aus deinem Foto erraten (siehe Schematic)
und Testweise an die 2107 angeschlossen (ohne den FG-Fühler). Damit
erkennt die 2107 das "Modul" noch nicht.
Kannst du nochmal schauen, welche Werte die Widerstände (bzw. womit sie
beschriftet sind)auf deiner Platine haben?
Ich vermute aber, dass die Kommunikation über das KM271 auch laufen
müsste, wenn kein Abgasfühler angeschlossen ist. Der zweite ADC Eingang
(festverdrahtet mit Widerstand) auf dem K4 Board-Stecker ist dann wohl
für den Solar-Fühler (FM244).
Hallo,
Zum EMS-Telegrammaufbau habe ich noch eine Kleinigkeit herausgefunden:
das Erst Byte ist die Absenderadresse, das zweite Byte die Zieladresse.
Wenn das Ziel auf dieses Telegramm antworten soll ist das Bit 7 gesetzt.
10 88 ...ist ein Telegramm von 10 (RC30/RC35) zu 08 (UBA3/MC10) mit der
Aufforderung zu antworten.
Die UBA3/MC10 antwortet dann mit dem Telegramm 08 10 ...
Alle ein Byte Telegramme mit Bit 7 gesetzt ist ein normales Polling.
90 soll dann 10 aufordern zu antworten. Wenn die RC30 oder RC35
angeschlossen ist antwortet diese. Wenn es nichts besonderes gab
antwortet dir RC30/35 nur mit der eigenen Adresse 10
Wenn Daten gesendet werden kommt als nächstes ein Byte für den
Telegrammtyp gefolgt von den Daten und zum Schluss die Prüfsumme.
Das Break ist immer der Abschluss vom Telegramm.
Habe inzwischen auch ein eigenes Interface mit einem OP damit ich nicht
immer zum Dachboden muss um was zu testen. Jetzt kann ich mich auch
parallel zur RC30 dranhängen und mitloggen.
Gruß
Ingo
Arrrggggghhhhhhhh... Und ich wundere mich wieso der Thread jetzt so
riesig geworden ist.
RE-ABO... aus irgend einem Grund habe ich keine Mails mehr bekommen.
Sorry Leute, aber ohne die Mailbenachrichtigungen habe ich den Thread
irgendwie vergessen.
Habe eben mal alles neue seit Oktober überflogen und muss sagen:
@Rudi:
Godlike! wirklich godlike. Mehr fällt mir dazu gerade nicht ein :)
Die Frage nach meinem zweiten Heizkreis (nein, habe nur einen an der
logamatic aktiv) hat sich ja wohl erübrigt.
Ich werde mir den Thread noch vor Weihnachten nochmal im detail
anschauen muessen... Freue mich jetzt schon darauf.
Ich überlege mir gerade ob ich die ganzen Informationen im Wiki
strukturieren soll (mittlerweile unwichtig gewordenen "schrott"
natürlich ausfiltern).
Besteht da interesse, dann würde ich das schön strukturiert aufbauen und
den Link posten?
Gruss, Malte
PS: hoffentlich bleibt die mailbenachrichtigung jetzt aktiv, hab
momentan wieder viel zuviel aktives im Kopf ;)
Hallo Malte,
ist eine gute Idee... Vermutlich wird das dann aber nur ein Wiki über
die 2107. Oder gibt es da auch einen Bereich für den EMS-Bus (RC30/35)?
Gruß
Ingo
Ne, schon beide getrennt - ich versuche halt die infos so weit es geht
auseinander zu halten :-)
Ich habe mich aben mal hingesetzt und versucht, alles bisher
verifizierte in das Wiki zu strukturieren.
Dabei ist mir aufgefallen, dass in den letzten Wochen der Wunsch nach
einer Doku/Projektplattform gekommen ist.
An sich kann man sowas schon per SourceForge lösen...
Für die Dokumentation würde ich schon ein Wiki vorschlagen. Es kommt nur
darauf an wie durchdacht man das ganze strukturiert.
Ich könnte so ein Setup machen, so dass wir dann alle darin editieren
können (momentan ist es halt in meinem Scratchpad wiki drin).
Für Sourcen würde ich vorschlagen das ganze per SVN zu machen.
http://wiki.neo-soft.org/index.php/Heizungsschnittstellehttp://wiki.neo-soft.org/index.php/Heizungsschnittstelle/Logamatic2107http://wiki.neo-soft.org/index.php/Heizungsschnittstelle/ServiceKey
Also ich biete mich gerne an, das einzurichten und zu hosten.
@rudi:
sehe ich das richtig dass diese aufsteckplatine sowas wie eine
eierlegende Wollmilchsau werden soll? :)
Auf jeden Fall vielen Dank für deinen Breakthrough bei der 2107!
@all:
Habe ich das jetzt richtig verstanden, dass der neue Erkenntnisstand
(Logamatic 2107) wie folgt aussieht:
1) KM271 ist ausser dem FG Anschluss NICHTS anderes als ein TTL->RS232
Umsetzer?
2) Auf dem Sockel K4 liegen Spannungsversorgung (24 und 5V) sowie eine
asynchrone serielle Schnittstelle (RX/TX) sowie der I2C Bus (SDA/SCL)
auf?
3) Temperaturen werden nicht über I2C übermittelt sondern nur über die
RS232 oder eben als gemultiplexter ADC Wert am Flachbandkabel?
Ich frage mich nämlich gerade ob Rudis Aufbau nötig ist oder ob es für
mich auch einfacher gehen könnte (in Form einer Steckkarte für K4).
Muss zu meinem Leid sagen dass ich die Bestückung von miniaturbauteilen
nicht hin bekomme ;-)
Temperaturen brauche ich schon, werde deshalb wahrscheinlich nicht drum
herum kommen, ebenfalls die Bedieneinheit anzuzapfen :-)
Gruss, Malte
@Malte Bayer
> Ich frage mich nämlich gerade ob Rudis Aufbau nötig ist oder ob es für> mich auch einfacher gehen könnte (in Form einer Steckkarte für K4).
Wenn der Schaltplan für das KM271 klar ist, dann reicht es aus. Die
Daten kommen dann, nach der beschriebenen Methode, über die RS232.
@chipshuffler
Bist du schon weiter gekommen ?
@Malte Bayer
> Für die Dokumentation würde ich schon ein Wiki vorschlagen. Es kommt nur> darauf an wie durchdacht man das ganze strukturiert.
Das sieht doch schon gut aus. Hauptsache das wird für einzelne
Nachrichten nicht unübersichtlich.
> sehe ich das richtig dass diese aufsteckplatine sowas wie eine> eierlegende Wollmilchsau werden soll? :)
Nein ;-) Die Platine ist halt aus der Not und dem bisherigen Stand der
Dinge entstanden. Die Wahl der Bauteile liegt an der Platinengröße
(Preis) und den vorhandenen Bauteilen.
Die Datenerfassung ist auch nur ein kleiner Teil. Dazu kommen noch
diverse extra Temperatursensoren an den Wasserleitungen etc.. Ich kann
nur jedem die Überprüfung der richtigen Einstellungen der Heizung
empfehlen, besonders bei der 2107 gibt es schon einige Überraschungen
und Optimierungsbedarf. Je nach Budget für den Einbau und Heizungsbauer
können da schöne Geldverbrennanlagen entstehen.
Ja das ist schon mein Ziel dass ich das ding optimiere.
Ich habe die Heizung im Februar selbst mit eingebaut (parametrisierung
nicht dem heizungsmensch ueberlassen).
Komisch finde ich auch dass es nur 3 Gebäudetypen gibt - völliger
Quatsch bei meiner Konfiguration, da passt keine der 3 Einstellungen.
Das dumme im moment ist, dass ich mir zur zeit auf dauer im Heizraum den
hintern abfriere... da hats nur noch 10°C wenns draussen am Gefrierpunkt
ist.
Das war letztes jahr mit 32° noch anders ;-)
Ich versuche mal ob ich mit den bisherigen Infos an K4 weiter komme. den
Abgasfühler brauche ich ja hoffentlich nicht.
Wegen dem Wiki: Sowie es weitere Infos gibt mache ich daran weiter.
Ein Datagram zu dokumentieren ist da auch kein riesen Act, da kann ich
ein Template für machen.
Gruss & gute nacht, Malte
Nach gut einer Stunde bei 10°C im Keller gibts einige neue Ergebnisse:
@Rudi: Ja, die Schaltung war nicht richtig. Die Verbindung R3,C6,C7
stimmte nicht. Inzwischen wird das "Modul" erkannt und ABGAS --- wird im
Display angezeigt. Ich habe dazu einen 1k Dummy-Widerstand an FG Pin 1+2
angeschlossen.
Ich habe dann zum Anschluss an den PC einen USB-TTL-RS232 Adapter von
FTDI
http://www.ftdichip.com/Documents/DataSheets/Modules/DS_TTL-232R_CABLES_V201.pdf
angeschlossen. Damit umgehe ich den Umweg über RS232 und COM-Port, da
das Netbook nur noch USB und keine RS232-COM-Ports hat.
Hier die Verdrahtung mit den Farben aus dem FTDI-Datenblatt und den
Signalen aus dem angehängten Schaltplan:
Orange an UARTTX
Gelb an UARTRX
Schwarz an 0V
Grün/Braun verbunden (RTS/CTS)
Beim Einschalten sendet die 2107 mit 2400Baud,8N1 ein STX (02) als
Sendeaufforderug aus.
Dann folgt ein Protokoll mit der Prozedur 3964R (ein betagtes S5/S7 SPS
Kommunikationsprotokoll).
Danke an Joachim K. für die Fotos und die Protokollbeschreibung.
Angehängt ist mein Trace (der Anfang fehlt, ist aus dem Kopf
rekonstruiert).
Folgende Erkenntnisse gibt es:
Ein Protokollfehler wird mit NAK beantwortet (das letzte Byte ist immer
die Prüfsumme als XOR vom ersten bis zum letzten Byte).
04 00 07 01 81 A5 00 E3 10 03 D6
Es gibt kein Längenbyte in der Nachricht. Der Parser sucht nach 10 03
(DLE, ETX), nach folgt die Prüfsumme.
Ein DLE (10) in den Daten wird beim Übertragen verdoppelt und geht in
die Prüfsummenberechnung ein (muss beim Empfangen wieder entfernt
werden).
Der LogMode wird mit EE 00 00 10 03 FD eingeleitet.
Danach kann mit 10 (DLE) jeweils der nächste Datensatz angefordert
werden.
Zuerst folgt der Inhalt des EEPROMs Page 0 und 1. Das EEPROM ist in
Records mit 6 Bytes+Prüfsumme eingeteilt. Die EEPROM Prüfsumme wird
nicht übertragen, dafür wird ja eine Nachrichtenprüfsumme über die
Nachricht neu berechnet angehängt. Die Page 0 enthält die
Modus-Parameter, die Page 1 die Absenk/Heizzeiten. Die mit Adresse 0xxx
beginnenden Datensätze (EEPROM-Konfiguration) haben eine Länge von 10
Bytes+Prüfsumme.
Die EEPROM-Records an Adresse 0000 und 0038, sowie Adresse 0007 und 003F
sind (wahrscheinlich zur Verifikation) identisch und enthalten die
Heizkreis 1 und Warmwasser-Betriebsart/Soll-Temperaturen.
Ein 65 ("e" für empty) in den EEPROM-Daten kennzeichnet beim Lesen und
Schreiben zu ignorierende Bytes.
Nach Einigen Sekunden ohne Aktivität sendet die 2107 ein STX (02) als
Sendeaufforderung.
Nach den EEPROM-Konfigurationsdaten folgen die Ereignisse die an einer
16-Bit Adresse mit gesetztem Bit 15 (8xxx) erkennbar sind. Diese
Datensätze haben eine Länge von 5 Bytes + Prüfsumme und folgen der
Beschreibung von Joachim K.
Die nächste Frage ist nun, ob die Schreibzugriffe im Direktmodus mit dem
Führenden Byte 0xB0 (Parameter Setzen) oder 0xDD (Direktmodus)
stattfinden und welche Adressen für die Schreibzugriffe verwendet werden
können.
Mit 0xDC kommst du wieder in den Normalmodus und mit 0xDD Direktmodus.
Nach 60sec. ,ohne Nachrichten, schaltet die Anlage automatisch in den
Normalmodus.
Der Wert z.B. 0x80 XX ist die Adresse (Heizkreis 1) und ein Offset. Es
wundert mich das bei Joachim K. der Offset bei anderen Adressen nicht
bei 0 anfängt. Evtl. ein Schreibfehler !?
Mit B0 sollten die Parameter verändert werden können. Es kann aber sein
das die Adressen anders sind.
Versuch mal den Befehl 0xA1 <ADRESSE> zum lesen der Schaltuhrparameter.
Oder mit 0xA2 um die Monitordaten von <ADRESSE> zu holen. Immer im
Direktmodus.
Sehen die Nachrichten im Normalmodus anders aus ?
Thx Chipshuffler.
Wiki geupdated.
Habe eben einen KM271 Nachbau als kleine Steckkarte geroutet.
Muss nochmal gegenchecken ob ich mich nicht mit den Anschlüssen vertan
habe, mache so selten doppelseitige Platinen ;)
Werde das ganze dann am Wochenende mal aufbauen und testen, mal sehen,
wenn alles klappt bin ich ab nächster woche dabei mit Protokolltests.
Gruss, Malte
Dann denk auch gleich an Serienwiderstände in den Datenleitungen. Die
Anlage rotzt ganz schon rum. Ein geschirmtes Kabel, z.B. altes USB-Kabel
ist auch von Vorteil.
@Rudi:
Hatte vor den XPORT den ich hier eh noch rumliegen habe direkt auf das
Steckmodul drauf zu pflastern.
Dann erspare ich mir auch gleich Frostbeulen durch zu langen Aufenthalt
@ 10°C und kann bequem vom Sofa aus kommunizieren ;)
Gleichzeitig habe ich noch alle Anschlüsse (ausser die 4 für FG) auf
einer Pinleiste ausgeführt, falls man alternativ dann doch noch nen
externen RS232 Wandler einbauen möchte.
Die Bestückungsseite zeigt nach hinten wenn man vor der Steuerung steht.
Das heisst man hat da noch massig platz, ein Sandwitch drauf zu packen
(auf der anderen Seite ist ja K3 und K1 im Weg :)
Was für ne Spannung hat die Zener überhaupt? Braucht es die überhaupt?
Soweit mein Verständnis da geht, begrenzt diese doch die Spannung die
ich extern an FG anlegen könnte. Da da aber entweder nichts oder ein
Widerstand dran hängt ist die doch an sich sinnlos oder?
Selbst ein 0 Ohm Widerstand sollte da nicht weh tun, oder habe ich mich
da verguckt?
@all: ich verifiziere das Layout noch, wenn alles passt schmeisse ich
die Boarddaten und natürlich jegliche neuen Erkenntnisse ins Wiki.
Ist Pin 3/4 eine Versorgungsleitung ?
Sollten es nicht auch 100k an 4/8 und 3/7 und dann 1k an 8/7 auch tun ?
Die Diode soll wohl eher den Eingang schützen. Wenn da ein paar Meter
Kabel dran kleben, fängst du dir alles ein was da so in der Luft liegt.
Die Kondensatoren sind wohl eher zum Glätten der Signale gedacht, evtl.
ein RC-Filter gegen Netzbrummen (R1/C7) (Versorgungsspannung???, kann da
mal jemand messen???) und bei R2/C5 das gleiche für den Eingang.
Die Anzeige --- als Wert, bedeutet ein Wert ausserhalb der Spec..
Beim XPORT würde ich das Gehäuseground vom Netzwerk "erstmal" nicht mit
dem Ground der Anlage verbinden (wenn es nicht schon intern mit Ground
verbunden ist).
Hallo,
ich habe in Verbindung mit einem Buderus Service Key versucht meine
Heizung (GB-125) abzufragen. Leider konnte ich an den Pins 2,3 der RS232
des Keys keine keinerlei Daten sehen können (via Oszi). Muss der Key via
Steuerzeichen aktiviert werden oder was könnte ich sonst noch falsch
machen ? Wer kann mir hierzu helfen ?
Die mitgelogten Telegramme hier haben nichts mit dem Service-Key
(Hardware) von Buderus zu tun. Im Servicekey ist irgendwelche Hardware
drin die die Kommunikation mit der Heizung übernimmt.
Hier geht es ja um die Schnittstelle an der der Service-Key
angeschlossen wird.
Soweit ich weiß sendet die Buderusoriginal-Software an den Servicekey
ein STX (0x2). oder ein aderes Steuerzeichen damit der Servicekey
antwortet.
Habe keine Ahnung wie die Kommunikation mit dem Service-Key genau läuft.
Gruß
Ingo
> Ist Pin 3/4 eine Versorgungsleitung ?
Vermutung: 3 = AGND, 7,4,8 sind ADC-Inputs für Vorlauf HK2, Abgas und
Solar.
Als ich einen der Eingänge mal mit 5V bauaufschlagt habe, zeigte die
2107 danach VORLAUF --- und einen Heizkreis 02 im Display und meinte
zeigte FEH FM241 (das Mischer-Modul) wäre nicht gefunden worden. Ich
habe den Heizkreis 02 dann per Menue entfernt und die Fehlermeldung
verschwand.
Die Kondensatoren sind als Tiefpass-Filter drin. Die grossen
Vorwiderstände 100k legen wohl nur die unbenutzten ADC-Eingänge
(Vorlauf, Solar) auf definierte Pegel, vermutlich wird dadurch aus das
KM271 vom FM244 Solarmodul im gleichen Steckplatz unterschieden.
> Sollten es nicht auch 100k an 4/8 und 3/7 und dann 1k an 8/7 auch tun ?
Für einen Nachbau als Dummy reicht das. Die Werte im Schaltplan sind aus
dem Foto "erraten".
@Joachim K. kannst du nochmal prüfen, wie die Beschriftung der 0805
Widerstände ist?
Die Kondensatoren sollten unkritisch sein (10nf-1uF). Weglassen wie bei
meinem Testaufbau geht auch). Ich habe ja keine Fühler angeschlossen.
@Rudi: Es sieht so aus als wäre bei den Status-Nachrichten wirklich 80
für HK1 und 81 für HK2, 84 für Warmwasser, 88 für Brenner/Kessel und 89
für sonstiges Verwendet und das nächste Byte zählt einfach von 00..xx
durch.
Der Versuch mit dem Direkt-Modus steht noch aus, die 3964R Prozedur
lernt gerade den Schreibzugriff...
> @Rudi: Es sieht so aus als wäre bei den Status-Nachrichten wirklich 80> für HK1 und 81 für HK2, 84 für Warmwasser, 88 für Brenner/Kessel und 89> für sonstiges Verwendet und das nächste Byte zählt einfach von 00..xx> durch.
Die 89 ist die Konfiguration.
Inzwischen konnte ich auch Schreibzugriffe auf die 2107 zu machen. D.h.
Ein- Ausschalten (Automatik, Tag, Nacht Manuell) sind getestet und
funktionieren über die KM271 Schnittstelle. Die Telegramme entsprechen
der Doku für die 4311/12, bis auf die ersten beiden Bytes (B0 und
ECO-CAN Adresse).
D.h. das Telegramm zum Verändern der Betriebsart/Solltemperaturen:
(02) 07 00 65 65 NN TT MM 65 (10) (03) (CC)
07 = TYP Heizkreis 1
00 = OFFSET 0 für Heizkreisparameter
65 = Dont Care
NN = Nach-Solltemperatur in 0.5C
TT = Tag Solltemperatur in 0.5C
MM = Betriebsart (00=Manuell Nacht, 01=Manuell Tag, 02=Automatik)
CC = XOR-Prüfsumme
In Klammern das 3964R Framing.
Eine Umschaltung DD/DC Direktmodus/Normalmodus scheint nicht
erforderlich zu sein.
Zum Senden wird vorher 0x02 geschickt, die 2107 Antwortet mit 0x10. Dann
folgt das Telegramm (s.o) mit DLE(0x10), ETX(0x03) und Prüfsumme am
Ende. Bei fehlerfreiem Empfang antwortet die 2107 wieder mit DLE(0x10).
Warmwasser Parameter ändern:
(02) 0C 07 65 65 65 WW 65 65 10 03 CC
0C = TYP Warmwasser
07 = OFFSET 7 für Warmwasserparameter
65 = Dont care
WW = Warmwasser Solltemperatur in 1.0C
CC = XOR Prüfsumme
Betriebsart Warmwasser ändern:
(02) 0C 0E MM 65 65 65 65 65 10 03 CC
MM = Betriebsart (00=Manuell Nacht, 01=Manuell Tag, 02=Automatik)
Danach sendet die 2107 alle durch den Schreibzugriff veränderten
Ereignisse. Ich sehe am Ende übrigens noch Ereignisse vom Typ 0x91 die
in keiner 4311/12 Doku beschrieben sind:
TYP 91 ADDR=0x9142 0
TYP 91 ADDR=0x9143 32
TYP 91 ADDR=0x9144 110
TYP 91 ADDR=0x9145 0
TYP 91 ADDR=0x9146 255
TYP 91 ADDR=0x9147 0
TYP 91 ADDR=0x9148 0
TYP 91 ADDR=0x9149 0
TYP 91 ADDR=0x914a 0
TYP 91 ADDR=0x914b 0
TYP 91 ADDR=0x914c 0
TYP 91 ADDR=0x914d 0
Hat eigentlich irgendjemand einen Service-Key oder RS232-Gateway von
Buderus den ich mir mal für ein paar Tage ausleihen könnte? Finanziell
würde man sich bestimmt auch einig. Wäre ganz interessant um die
Prüsumme herauszubekommen.
Gruß
Ingo
Hallo Rudi,
man könnte z.B. den Betriebsstundenzähler jede Minute Abfragen. Bei mir
wird häufig nur jede zweite Minute der Betriebstundenzähler angefragt.
Manchmal ist sogar eine Pause von 15 Minuten. Man hätte mehrere Werte
und könnte sich die Zählerstände so sortieren dass vielleicht nur ein
Bit geändert wird und kann sehen wie sich das auf die Prüfsumme
auswirkt.
Vielleicht könnte man sich ein Telegramm über das man mit der
PC-Software Daten sendet nehmen und beliebig verändern und sehen wie
sich das auf die gesendete Prüfsumme auswirkt. Wenn sich der Service-Key
ähnlich wie das RS232-Gateway oder Fernwirkmodem verhält brauch man beim
Senden über den Service-Key keine Prüfsumme. Oder es ist vielleicht nur
ein simples XOR wenn es doch eine Prüfsumme gibt.
Sieht auch fast so aus als ob vielleicht jemand mit einem Notebook mit
orignal-Software (oder vergleichbar) mal vorbeischaut. Der Service-Key,
RS232-Gateway, Fernwirkmodem, ... ist wohl das Problem.
Kann natürlich sein dass das alles auch nicht weiterhilft...
Und natürlich gaaanz viel Neugier auf den Service-Key.
Gruß
Ingo
Ah sorry, hatte ich uebersehen.
Auch mit 1k geht nix.
Also ich habe als Anzeige nur Kessel, WW, Aussen und Betriebsstunden.
Wenn ich im HK1 die (nicht vorhandene) Fernbedienung aktiviere habe ich
noch ne weitere Temperatur "Raum1" die mit --- angegeben ist (normal, is
ja kein Signal da).
Das wars dann auch schon.
Falls ich nicht irgend einen Leichtsinnsfehler im Layout habe (den ich
nicht finden kann) verstehe ich nicht wieso das Teil nicht als Modul
erkannt wird.
@Chipshuffler: Stimmt der Schaltplan mit deinem Selbstbau überein?
Welche Werte hast du für R1 R2 und C5 verwendet? Hast du D1 weg gelassen
oder wenn ja mit welchem Wert bestückt?
Gruss, Malte
Hallo,
die KM271-Nachbauplatinen sehen ja schon ganz gut aus. Vielleicht kannst
Du ja noch die beiden Abgriffe für RX/TX vom XPORT oder MAX232 neben die
richtigen UART-Pinne setzten. Dann könnte man die richtige Schnittstelle
jumpern und muss keine Kabel umstecken
Gruß
Ingo
@hellraiser:
Es sieht so aus, als wäre das Layout genau seitenverkehrt
(Bottom/Top-Layer Pins vertauscht), d.h. Pin 1 und 2 vertauscht, Pin 3
und 4 vertauscht etc. Dadurch sind auch 0V und 5V vertauscht und der
SP232 dürfte gelitten haben.
Ich habe alle Kondensatoren und D1 weggelassen. Die Werte für R1 und R2
sind wie im Schaltplan bestückt.
Ich habe dein PCB um 180° gedreht und mit dem Foto von himtronics
verglichen. Nach Vergleich mit dem Schaltplan bin ich der Meinung, dass
das Pinning im Schematic stimmt. Die Position der Pinnummern in dem
Kasten unten bezieht sich auf die Position der Buchse auf der
Busplatine.
@IngoF: Ja, ist jetzt drin. Ich bin mir nur noch nicht sicher ob ich
RX/TX vertauscht habe. Wird sich in der nächsten Woche zeigen :)
@chipshuffler:
Viel schlimmer. ich muss irgendwie beim layouten einen totalaussetzer
gehabt haben. Ich schiebe es mal auf die vielen Telefonate mit den
Kunden zwischendrin ;-)
Spannungsversorgung war richtig rum. Die Pins für das
Widerstandsgebrösel auch, nur habe ich mit der Verschaltung total
gepennt (böser fehler drin, aber die logamatic lebt noch :)
@all:
Habe jetzt die rev C für das Selbstbaumodul soweit fertig, dass es
korrekt erkannt wird.
Ich versuche noch die Widerstände auf einen PT1000 abzustimmen, so dass
die Abgastemperatur nachher auch halbwegs korrekt ist und nicht irgend
einen Mist anzeigt der eh nicht stimmt.
http://wiki.neo-soft.org/index.php/Heizungsschnittstelle/Logamatic2107/K4#KM271_Selbstbau-Modul
Alles was ich bisher habe ist im wiki aktualisiert. Aber bitte sparsam
mit Kommentaren zu den Bildern, ich habs echt schwer mit diesem scheiss
doppelseitigen Basismaterial mit weisser Schutzfolie. Ich hätte die
dinger einfach in die tonne kloppen und mir noch nen stapel Bungard
Material holen sollen :-P
Ansonsten werde ich jetzt die Arbeit mal ruhen lassen.
In diesem Sinn wünsche ich euch allen schöne Feiertage!
Gruss, Malte
Soweit ich das bisher beurteilen kann funktioniert das Einsteckmodul.
bekomme Antwort von der Steuerung (Logmode aktiv, dann die events
pollen).
Mir ist da allerdings etwas aufgefallen: Heizkreis 2 habe ich im Setup
auf "Kein" eingestellt, also abgeschaltet.
Abgastemperatur mit 1K Widerstand bei 208°C.
Soweit okay vorerst.
Das komische ist aber dass sobald das Modul drin steckt die
Kesseltemperatur manchmal springt. So passiert es, dass die temperatur
normal im 1° Schritt unter irgendwas um 55° sinkt und dann der Brenner
gestartet wird. kurz danach springt die temperaturanzeige für den kessel
aber auf 67°C (für ein paar sekunden, dann zurück auf 54°C. Dieses
Springen stoppt den brenner (halbwegs logisch).
Dumm nur dass das immer wieder passiert und der brenner dann für 2-3 sec
zündet, dann aber wieder abgeschaltet wird.
Ich habs noch nicht raus was das sein könnte, kann das jemand bestätigen
oder ist es nur bei mir so?
Mir ist aufgefallen dass ich das springen manchmal erzwingen kann indem
ich am modul "wackle". Schlachten Kontakt kann ich mir aber schlecht
vorstellen, habe extra vorher die Kupferkontakte die in den Sockel gehen
blank gereinigt.
(vergolden kann ich leider nicht ;)
Werde nächste woche nochmal weiter probieren. In dem Zustand lasse ich
das Modul erstmal nicht eingebaut.
Gruss, Malte
Bei mir springt die Kesseltemperatur nicht, wenn das Modul eingesteckt
ist. Ich vermute, dass ein Offset am AGND-Pin am Modulstecker die
Messung der Kesseltemperatur beeinflusst.
Okay, das muss ich nochmal genauer angucken. Mir ist eben aufgefallen
(ja ich kanns nicht lassen) dass es nicht nur die kesseltemperatur ist.
Alle Temperaturen stimmen mit aktivem Modul nicht, Alle Temperaturen
werden niedriger ausgegeben als tatsächlich gemessen kurz bevor das
modul eingesteckt wurde (Kessel, Speicher, Aussentemperatur). Habe jetzt
auch mal nen 500 Ohm Widerstand als Abgassensor verwendet -> 218°C, also
sollen 500 Ohm 10° Unterschied ausmachen? da stimmt echt was nicht bei
mir.
Ich versuche es erst nochmal mit nem steckbrett.
Vielleicht habe ich ja auch Leiterbahnen auf der Platine ungünstig
gelegt, rudi meinte ja "das ding rotzt rum"... Für Analogmessungen nicht
gerade von Vorteil.
Gruss, Malte
Hallo,
da Rudi nachfragt...
Ich habe schon mal eine erste Testversion von meinem Java-Programm.
Dazu muss Java 1.6 installiert sein.
Das ZIP-File entpacken.
MySQL muss installiert werden und der Ordner EMSlog aus dem ZIP in das
Daten-Verzeichnis von MySQL kopiert werden und gestartet werden.
Oder in der MySQL die SQL_Create.sql ausgeführt werden. Das SQL-Script
erzeugt die Datenbank EMSlog und die Tabellen für die Telegramme 080018,
080019, 080034 und 10003e an.
Das Java-Programm ausführen. Den COM-Port auswählen an dem der Wandler
hängt und auf [Verbinden] klicken. Die Daten für MySQL angeben
(IP-Adresse, User, Passwort) und auch auf [Verbinden] drückenDas
eingetragene Defaultpassword ist password.
Die Daten werden von dem Wandler der an der Schaltung hängt empfangen,
angezeigt und in der MySQL geloggt. Gleichzeitig werden die Daten aus
der MySQL-Datenbank ausgelesen und in der Grafik angezeigt.
Bevor man das Programm schließt natürlich auf [Trennen] drücken.
Im Moment müssen beide Verbindungen aufgebaut werden. Später sollen man
mit dem Programm auch nur loggen oder nur die Daten auswerten können. Je
nachdem was man will.
Natürlich benötigt man noch den "Wandler" mit ATMega8 und den Komparator
der programmiert sein muss. Leider kann ich mein HEX-File nicht
wiederfinden. Notfalls eben den von Rudi geposteten C-Quelttext
kompilieren und programmieren.
Gruß
Ingo
Hallo,
ich suche ein Interface für meine Heizung um die Daten in meiner
Hausautomation zu visualsieren und bin über den Thread hier gestolpert -
echt interessant ! Hat jemand eine Leerplatine oder einen Bausatz über ?
Gruß Andreas
Hallo Rudi
habe mal einen kleinen Versuch gestartet. Irgendwo war hier ein link zu
einem anderen Thread. Dort war eine Version mit einer ZenerDiode die mit
Transistor auf den Bus geschaltet wurde um die Spannung herunter zu
ziehen. Habe mal gemessen dass dort dann 160mA fliesen. An der Z-Diode
fallen also 1,5 Watt ab. Hatte anders als dort angegeben eine
8,2-Z-Diode genommen statt der 7,5Z-Diode. Allerdings ist dann die
Spannung noch höher als 10 Volt. Hatte nur gerechnet ohne mir die
Kennlinie der Z-Diode anzusehen.
Also war die Lösung mit 7,5-Volt Z-Diode und zwei normalen Dioden
(Brückengelichrichter damit die Polung des Busses egal ist) plus
Transisitor.
Nach dem Senden ist allerdings erst mal längere Stille auf dem Bus. Was
auch schon mal öfter bei langen Telegrammen der RC30 vorkommt.
Habe mal das mit Deiner Schaltung getestet und noch einen freien Treiber
vom MX232 genommen um den Transistor anzusteuern. Habe dazu die
Sendeleitung vom PC die ja noch nicht benutzt wurde einfach auf den
MAX232 geklemmt.
Allerdings müsste ich meiner Software erst noch angewöhnen auf das
Polling zu reagieren und das richtige Senden zu können.
Gruß
Ingo
> Nach dem Senden ist allerdings erst mal längere Stille auf dem Bus. Was> auch schon mal öfter bei langen Telegrammen der RC30 vorkommt.
Das könnte auch am fehlenden "Frameerror" liegen, da alle Teilnehmer auf
das Ende warten und dann wohl in den Timeout rennen.
Ach ja.......
Wenn man aber noch einen Master nimmt bräuchte man den ja nur mit
normalen Port-Pins verbinden. Der Slave könnte sich bemerkbar machen
wenn ein Polling mit einer bestimmten Adresse kommt und der Master
könnte dann einfach sein Telegramm abschicken. Dazu müsste man nicht
unbedingt einen zweiten UART nehmen. Ein einfacher Port-Pin mit
entsprechender Assembler-Programmierung könnte reichen. Oder gibt es
einee Art Software-Uart denn man mit C verwenden könnte?
Ideal wäre ja noch ein kleiner Buffer im Master der die Daten decodiert
und zwischenspeichert und dann direkt über Ethernet in die SQL-Datenbank
schreibt. Habe mir inzwischen ein gebrauchten Laptop gekauft. Der könnte
dann automatisch zu einer bestimmten zeit hochfahren, MySQL starten und
nach einer bestimmten Zeit wieder herunterfahren. Dann könnte mann den
Jahresverbrauch noch stärker drosseln. Sind zwar nur 20Watt, aber selbst
das sind schon immerhin 170kW/h. Mein normaler Mini-Tower braucht
immerhin 100W. Der Laptop hat natürlich noch den Vorteil der
Akkupufferung.
Gruß
Ingo
>Das könnte auch am fehlenden "Frameerror" liegen,
Wäre möglich.. allerdings habe ich ein Zeichen und ein Break gesendet.
Dieses Break vom Terminal-Programm ist um einiges länger als das
EMS-Bus-Break. Man müsste also noch sehen ob man am PC diese Break-Länge
ändern kann. Aber wenn man einen Master einbaut könnte der automatisch
die richtige Länge erzeugen.
Gruß
Ingo
Hallo,
Habe eine 2107 mit km271. Ich hatte vor laengerer Zeit schon mal mit dem
3964R etwas experimentiert und ein paar Mittschnitte gemacht von der
Windows Software (die leider durch crash abhanden gekommen ist). Leider
bin ich aus Zeitgruenden nie dazu gekommen es weiter zu analysieren bzw
zu implementieren. Hatte aber mit http://libnodave.sourceforge.net/ ein
wenig gespielt bis mir die Software zum Vergleich fehlte.
Hat hier schon jemand versucht das hier gelernte ueber die Libnodave
laufen zu lassen?
Ich hatte damals eine NSLU2 dafuer genommen, mit Debian und externer
Platte, und USB serial. Ich denke das ist eine Gute Loesung zusammen mit
der KM271 oder der ersatzplatine.
Mich interessiert jetzt brennend ob jemand etwas auf linux lauffaehiges
hat das z.b. auf einer NSLU2 laueft.
Gruesse und Hut ab.
Sean
Moin,
> Hat hier schon jemand versucht das hier gelernte ueber die Libnodave> laufen zu lassen?
Ich nicht. Das einzige was mir auf der Seite bekannt vor kam war der
"Basic data exchange". Evtl. kannst du ja mal kurz erklären wofür diese
Lib. gut sein soll.
> Mich interessiert jetzt brennend ob jemand etwas auf linux lauffaehiges> hat das z.b. auf einer NSLU2 laueft.
Ja, auf Linux schon, aber bei den Datenmengen ist das schon Tierquälerei
;-). Ist aber auch nur eine Vermutzung, keiner weiss was du vor hast.
Hi,
Ich will mindestens den Zustand an/aus nacht/tag/auto erkennen und
beinflussen koennen. Soweit moeglich wuerde ich dann gerne Aktuelle
Werte Anzeigen lassen koennen (Aussentemperatur, vor/ruecklauf
Differenz, etc). Danach ggf. Historische Daten und danach zb. die
Zeiteinstellung korrigieren (winter Sommer etc und ggf. mit ntp
angleichen). Danach wuerde das Modifizieren der programierten
Schaltzeiten selber in betracht kommen.
jedenfalls alles Schritt fuer Schritt und moeglichst einfach und
wartbar. Fuer mich bedeutet das eine definierte Schnittstelle wie Z.b.
das KM271 oder das Ersatzboard und dann Schnittstellen Treiber auf einem
System das moeglichst direkt auch als Web interface dienen kann um das
ganze autark laufen lassen zu koennen. Der NSLU2 ist da fuer mich
interessant da Linux drauf laueft und es ggf. sogar direkt als
Entwicklungsumgebung herhalten kann. Ein anderes Beispiel waehre zb. ein
Plug computer.
Gruesse
Sean
Hi,
Darf ich kurz eine Frage an die Besitzer einer 2107 Regelung einwerfen ?
Man kann ja die Versionsnummer abfragen, falls jemand hier eine
Version größer 3.14 hat, bitte mal kurz melden.
Vielen Dank !
Rudi schrieb:
> könntest du einen kleinen Schaltplan für den TX-Pfad posten ?
hier mal der erste Versuch des Schaltplans meiner laufenden Platine. Der
Gleichrichter sorgt dafür das man den Bus beliebig anklemmen kann.
Ist natürlich noch nicht die entgültige Version.
Gruß
Ingo
In den TX-Pfad sollte ich noch den zweiten Comperator einbauen damit der
Transistor nicht direkt über die serielle Schnittstelle angesteuert
wird, oder?
Die Spannungswandler des MAX232 wird noch für die Versorgung der
Comperatoren benutzt. Hatte leider keinen anderen Comperator/OP greifbar
der ohne +-10V auskam.
Kritik und Anregungen sind gerne willkommen.
Gruß
Ingo
> hier mal der erste Versuch des Schaltplans meiner laufenden Platine. Der> Gleichrichter sorgt dafür das man den Bus beliebig anklemmen kann.
Danke !
Auf welche Spannung ziehst du das Signal runter und welcher Strom fließt
dann ?
Hallo!
Ich würde gerne mein Logamatic 2107 an die Haussteuerung (fhem)
anschließen, aber leider bin ich kein Hardware- sondern ein Software-
Bastler. Ich habe mich auch damit abgefunden, den KM271 zu kaufen,
leider weiss ich nicht wo. Ich habe auch keine Angst von irgendwelchen
nachbauten, und ob es via RS232 oder Ethernet, ist mir auch egal, aber
soweit ich es sehe kann man keine fertigen Alternativen kaufen. Kann mir
hier jemand weiterhelfen?
Gruss,
Rudi (der Zweite :)
@Rudolf Koenig
> Ich habe mich auch damit abgefunden, den KM271 zu kaufen,> leider weiss ich nicht wo.
Frag einfach deinen Heizungsmenschen, wenn er mal wieder zur Wartung da
ist, der besorgt dir das Modul.
Die KM271-Alternative ist irgendwie eingeschlafen !?!?!?!?
Ziehe im Moment auf 10Volt herunter. Ist ja vergleichbar mit der RC30.
Ein Test mit normalen Wiederständen hat gezeigt dass dann 160 mA fließen
wenn man die Spannung so weit herunterzieht. Deswegen auch die 1,3 Watt
Z-Diode.
Habe allerdings im Moment eine 8,5 Volt Z-Diode drin und nur eine Diode.
Das dürfte dann ja der 7,5Volt Diode mit vorgeschalteten Gleichrichter
entsprechen.
Wäre vielleicht auch eine Idee den MAX232 wegzulassen und den X-Port
dafür zu nehmen. Dann müsste ich aber noch einen OP/Comperator nehmen
der mit 5 Volt auskommt.
Hätte den Vorteil dass man überall aus dem Netzwerk drauf zugreifen
könnte.. SOgar aus der Ferne wenn man will.
Gruß
Ingo
> Ziehe im Moment auf 10Volt herunter. Ist ja vergleichbar mit der RC30.> Ein Test mit normalen Wiederständen hat gezeigt dass dann 160 mA fließen> wenn man die Spannung so weit herunterzieht. Deswegen auch die 1,3 Watt> Z-Diode.
Bist du sicher das 160mA okay sind ? Hört sich für mich, aus dem Bauch
heraus, etwas viel an. Wenn man von Störungen ausgeht dann ist das
sicherlich berechtigt.
> Wäre vielleicht auch eine Idee den MAX232 wegzulassen und den X-Port> dafür zu nehmen. Dann müsste ich aber noch einen OP/Comperator nehmen> der mit 5 Volt auskommt.
3-5V wären ausreichend, dann kann man direkt einen uC seiner Wahl
anschalten. Ich frage wegen der Schaltung mal einen anderen Hardwerker (
ich bin keiner ;-) ).
> Hätte den Vorteil dass man überall aus dem Netzwerk drauf zugreifen> könnte.. SOgar aus der Ferne wenn man will.
Jup.
@Andreas
> ich suche eine KM271 Platine. Hat jemand eine über oder läßt jemand> demnächst welche machen ?
Es gibt hier keine Plagiate. Alles hausbacken ;-)
@ rudi:
>Die KM271-Alternative ist irgendwie eingeschlafen !?!?!?!?
Naja. eingeschlafen noch nicht.
ich bin noch etwas gefrustet wegen dem offensichtlich bescheuerten
layout. Ich muss das nochmal neu machen, scheinbar hätte ich nicht die
gesamte fläche als gnd nehmen sollen bzw so wie es aussieht gibts da
einen getrennten agnd.
Jedenfalls ist das layout so nicht brauchbar (verfaelscht alle
gemessenen temperaturen im system um mehr als 10°C
Werde mich nochmal dran setzten sobald ich wieder mehr zeit habe!
Gruss, Malte
@Rudi
Rudi schrieb:
>> ich suche eine KM271 Platine. Hat jemand eine über oder läßt jemand>>> demnächst welche machen ?>>>> Es gibt hier keine Plagiate. Alles hausbacken ;-)
okay, ich nehme auch eine hausgebackene ;-) Vielleicht erbarmt sich ein
Bäcker.
Ich habe eine erste Version eines fhem Moduls fuer KM271 implementiert,
vielen Dank nochmal an alle die das Protokoll dokumentiert haben.
Die in dieser Liste erwaehnten Buderus Dokumente haben auch etwas
geholfen, zusaetzlich gibt es noch den hier nicht erwaehnten
63011377.pdf
Ich habe die Daten eine Weile protokolliert, siehe die Plots in dem
Abschnitt
http://www.koeniglich.de/fhem/commandref.html#KM271
Kann jemand mir erklaeren, was der Logamatic mit "Kesselintegral" meint?
Laut Buderus Doku wird es in KK gemessen (was auch immer das wiederum
ist).
Weiterhin meldet mein KM271 nachdem ich es ins logmode setze nur noch
die Aenderungen, aber keine Konfigurationsdaten bzw. Zeitprogramm, wie
es in der Doku von himtronics steht.
Btw. der wiki scheint seit ein paar Tagen ein Problem zu haben.
Gruss,
Rudi
@Rudolf Koenig
Ich seh da grad deine Vorlauftemperatur & Warmwasser. Kann es sein das
die Pumpe deiner Heizung dein WW in den Vorlauf der Heizung drückt ? Ein
Freund von mir hat das gleiche Problem. Es ist schön zu sehen wie lange
die Temperatur hält wenn sich die Heizung in der Absenkung befindet.
> Weiterhin meldet mein KM271 nachdem ich es ins logmode setze nur noch> die Aenderungen, aber keine Konfigurationsdaten bzw. Zeitprogramm, wie> es in der Doku von himtronics steht.
Die RC3X sendet auch nur Datensätze die sich geändert haben.
@Ingo F.
> In den TX-Pfad sollte ich noch den zweiten Comperator einbauen damit der> Transistor nicht direkt über die serielle Schnittstelle angesteuert> wird, oder?
Eine Stromsenke mit OP & FET wäre wohl besser (ich habe da mal einen
anderen Hardwerker gefragt). Problem könnte evtl. der RX-Pfad sein, da
es keine getrennten RX/TX-Leitungen gibt.
Leider bin ich da nicht so bewandert...
Rudi schrieb:
> Eine Stromsenke mit OP & FET wäre wohl besser (ich habe da mal einen> anderen Hardwerker gefragt).
Ich habe ja keinen festen Strom. Also kann ich keine Konstantstromsenke
nehmen. Die Schaltungen die ich bis jetzt gefunden habe waren alles
Konstantstromsenken. Ich muss mal nach einer Stromsenke suchen die von
der Ausgangspannung abhängig ist....
Rudi schrieb:
> Problem könnte evtl. der RX-Pfad sein, da> es keine getrennten RX/TX-Leitungen gibt.
Die Sende- und Empfangsdaten sind doch nur auf einer Leitung. Man könnte
höchstens die Schaltung so modifizieren dass der Empfangsteil
abgeschaltet wird wenn die Daten gesendet werden. Aber denke das kann
man doch auch in der Software des ATMega8 machen..
Rudi schrieb:
> Leider bin ich da nicht so bewandert...
Macht nichts... ich auch nicht ;-)
Gruß
Ingo
@rudi (der erste :)
Habe es glaube ich jetzt rausbekommen, ich verwende ja noch einen 3.3v
spannungsregler für den xport. Wenn ich vcc vom regulator abtrenne
stimmen alle temperaturen wieder. Allerdings ist das modul im moment
dann sinnfrei, da keine kommunikation.
Ich denke ich werfe den kram mit dem xport weg und mache ein reines
rs232 modul, das kann sich dann jeder nachbauen der es braucht.
A propos: ich habe firmware version 4.00, eben nachgeschaut. falls das
irgendwann mal was zu bedeuten hat :)
@all:
wiki geht jetzt wieder und ist nebenbei auf den aktuellen Stand gebracht
worden.
Wer sich an der Doku beteiligen mag, der kann sich dort gerne
registrieren und selbst mit daran arbeiten.
Auf der Hauptseite
http://wiki.neo-soft.org/index.php/Heizungsschnittstelle
habe ich einen Hinweis "Aktualität der Inhalte: 2010 02 13".
Dieser bezieht sich auf den Letzten aus diesem Thread entnommenen
Informationsstand, diesen bitte nicht verändern, da ich sonst beim
nachtragen von Informationen durcheinander komme....
Mal sehen, ich habe wieder in absehbarer Zeit mehr Luft für Basteleien,
ich halte euch auf dem Laufenden, wenn ich Neuigkeiten habe.
Auf Grund der kranken Temperaturen habe ich seit wochen keine Lust mich
laenger in meiner Werkstatt aufzuhalten (nicht beheizt), weshalb ich zzt
etwas "eingeschlafen" wirke. Aber Frühling ist ja bald in Sicht ;)
> Ich seh da grad deine Vorlauftemperatur & Warmwasser. Kann es sein das> die Pumpe deiner Heizung dein WW in den Vorlauf der Heizung drückt ?
Ich glaube das passiert ohne Mitwirkung der Pumpe. Wir haben teilweise
sehr dicke Heizungsrohre und die Rueckstauklappe wurde wegen
Laermbelaestigung entfernt. Im Sommer trenne ich die Heizung manuell.
Finde ich faszinierend, dass Du sowas ablesen kannst :)
@ IngoF
> Die Sende- und Empfangsdaten sind doch nur auf einer Leitung. Man könnte> höchstens die Schaltung so modifizieren dass der Empfangsteil> abgeschaltet wird wenn die Daten gesendet werden. Aber denke das kann> man doch auch in der Software des ATMega8 machen..
Dann den Sender, da der Strom vom Pegel auf dem Bus abhängt. Bleibt noch
die Frage was passiert wenn der Sender eingeschaltet wird und eine
andere Einheit anfängt zu senden.
> Ich glaube das passiert ohne Mitwirkung der Pumpe. Wir haben teilweise> sehr dicke Heizungsrohre und die Rueckstauklappe wurde wegen> Laermbelaestigung entfernt. Im Sommer trenne ich die Heizung manuell.> Finde ich faszinierend, dass Du sowas ablesen kannst :)
Nein, ich habe da nicht drauf geachtet, mir kam es nur komisch vor das
das WW so oft geladen wird. Der erwähnte Freund hat dann nochmal drüber
gegrübelt. Was ist an einer Rückstauklappe so laut ??? Wäre mal
interessant ob die überhaupt etwas bringt. Besser wäre natürlich ein
Mischer und keine zwei Pumpen am gleichen Strang.
Hallo Rudi,
> Dann den Sender, da der Strom vom Pegel auf dem Bus abhängt. Bleibt noch> die Frage was passiert wenn der Sender eingeschaltet wird und eine> andere Einheit anfängt zu senden.
das kann ja nicht passieren weil die Busteilnehmer nur auf das Polling
antworten. Wenn jetzt natürlich der ATMega8 einfach drauf los sendet
ohne auf sein Polling zu warten wird es natürlich Probleme geben.
Schätze dass dann die fehlerhaften Telegramme ignoriert werden dank der
ominösen Prüfsumme.
Gruß
Ingo
IngoF schrieb:
>> Dann den Sender
habe das vermutlich falsch verstanden. Den Sender kann man ja schlecht
abschalten wenn er senden soll... Dachte höchstens den Empfänger, damit
die selbst gesendeten Daten nicht wieder empfangen werden.
Aber das könnte man ja im Atmega8 besser machen. Einfach nach dem Senden
die eigelesenen Daten irgnorieren. Kann man auch notfalls an der
eigenene Adresse erkennen...
Gruß
Ingo
@IngoF
> habe das vermutlich falsch verstanden. Den Sender kann man ja schlecht> abschalten wenn er senden soll... Dachte höchstens den Empfänger, damit> die selbst gesendeten Daten nicht wieder empfangen werden.
Den Empfänger kann man schon anlassen, dann sieht man direkt ob die
Daten sauber gesendet wurden und es keine Buskollision gab.
> welcher Händler bietet denn den verwendeten ADCMP370 an? Oder gibt es> Vergleichstypen? Ich kann da nichts finden!
Den kannst du bei Analog sampeln oder bei digikey gibt es den auch.
Andere Möglichkeit wäre ein Komparator der über seiner
Versorgungsspannung Signale am Eingang verträgt.
Eine andere ungetestet Methode wäre auch eine z-diode (etwa 11.5V) in
Reihe und dann an einen Opto., evtl. noch mit Transistor zwischen. Das
wäre dann die sichere low-cost Variante.
Hallo zusammen,
ich bin gerade über diese Diskussion gestolpert und fasziniert darüber
was Ihr erreicht habt :-)
Ich habe ein Buderus Heizung mit BC10 und RC35. Die Anlage ist nett hat
aber ein Problem. Alle paar Wochen läuft sie in einen Fehler, gefühlt so
ca. 10 Mal im Jahr. Das BC10 zeigt Fehlercode 6A (Handbuch: Brenner kann
nicht gezündet werden) und der Warmwasserspeicher kühlt langsam aus. Man
merkt das dann dadurch dass kein heisses Wasser mehr kommt...
Ich würde gerne das Verhalten der Anlage über längere Zeit mitschreiben
um zu schauen woran das wohl liegen könnte.
Gibt der BC10 über die Service-Key-Schnittstelle auch Fehler aus? Dazu
habe ich hier noch nix gesehen.
Nach einem A6-Fehler kommt man über einen Reset (Taster an der BC10)
wieder in den Normalzustand. Kann man den reset auch über die
Service-Key-Schnittstelle auslösen?
Viele Grüße,
Bernd
> Nach einem A6-Fehler kommt man über einen Reset (Taster an der BC10)> wieder in den Normalzustand. Kann man den reset auch über die> Service-Key-Schnittstelle auslösen?
Wie wäre es den Heizungsfritzen an das Gerät zu zitieren ?
Schon drei mal gemacht. Gibt immer eine Riesenbaustelle. Nutzt aber nix
weil der Fehler nie auftritt wenn die da sind. Und die stellen nicht
einen Monat einen Rechner hier hin um mitzuschreiben was die Kiste
macht. Und ich werde deswegen den Brenner nicht rausreißen lassen.
Deshalb: Nase voll und Selbsthilfe...
Viele Grüße,
Bernd
Bei einem defekten Brenner oder defekter Flammenerkennung helfen dir die
Daten auch nicht. Es gab bei B. eine Rückrufaktion für einige Brenner,
evtl. gilt das auch für dich !?
Die letzte Fehlermeldung ist in den Daten, wie auch im Monitormenü am
Display.
> Nach einem A6-Fehler kommt man über einen Reset (Taster an der BC10)> wieder in den Normalzustand. Kann man den reset auch über die> Service-Key-Schnittstelle auslösen?
Evtl. über SSR Heizung aus/an ?
Hat jetzt nicht mehr zu viel mit dem Thema zu tun...
Ich glaube nicht dass der Brenner defekt ist. Der zündet problemlos
einige 100 Mal (einige 1000 Mail?) im Jahr. Google sagt mir dass der 6A
Fehler verschiedenste Ursachen haben kann, von Abgas in der Zuluft bis
kein Gas.
Vielleicht finde ich ja ein Muster in den Daten. Jedenfalls passiert das
fast immer nachts, die morgentliche Dusche danach ist erfrischend.
Viele Grüße,
Bernd
Die Bedienungsanleitung sagt "Bei 6A Reset drücken". 6A kommt wenn die
Elektronik es mehrmals hintereinander nicht geschafft hat den Brenner zu
zünden. Die Kiste geht dann schlafen weil sie nicht weiss was sie machen
soll, eine Heizung die nicht heizen kann hat eine Identitätskrise.
Wenn ich dann einige Stunden später komme und Reset drücke dann springt
der Brenner (bisher immer) problemlos an.
Wie komme ich denn an den Fehlerspeicher? Über das RC35 Modul?
Logamatic 2107/KM271
Nur als Info: hab an dem KM271 fhem Modul weitergebastelt: Ich kann (wie
oben schon erwaehnt) bestaetigen: nach dem senden der "logmode"
Aufforderung sendet der 2107 erst ca 60 Stueck 6-er Bloecke aus dem
Adressbereich 0000 bis 01e0, dann die schon bekannten einnzelnen Bytes
aus dem Bereich 8000-8940 und dann die vom chipshuffler erwaehnten
"unbekannten" 914x und 03xx Daten.
Ich habe durch drehen aller Knoepfe meiner Logamatic ca 20 Bytes aus dem
ersten 60x6 Block entschluesselt. Weiterhin kann das fhem Modul die vom
vom Chipshuffler beschriebenen Werte auch aendern.
Siehe auch:
http://cvs.berlios.de/cgi-bin/viewvc.cgi/fhem/fhem/FHEM/00_KM271.pm?revision=1.3&view=markup
Gruss,
Rudi
BerndV schrieb:
> Wie komme ich denn an den Fehlerspeicher? Über das RC35 Modul?
Über das Service-Menü. Bei meiner RC30 muss man drei Tasten gleichzeitig
drücken. Soweit ich weiß die ganz linke und die beiden rechten. Evtl.
mal in der Bedienungsanleitung nachsehen. Allerdings kann man dort nur
die Fehler sehen. Vielleicht kann man die dort auch herauslöschen.
Wenn das helfen sollte kann man bestimmt auch eine Softwarelösung dafür
finden. Ist allerdings nur ein herumbasteln an den Symptomen wenn es
klappen sollte.
Vermute allerdings dass Du wirklich den Reset-Schalter an der Anlage
drücken musst. Dann kann eine Softwarelösung wohl kaum helfen.
Allerdings gibt es (noch) das Problem dass die Prüfsumme vom Protokoll
her nicht bekannt ist. Notfalls müsste man die Software-Reset-Prozedur
der RC35 mitschneiden und von einer Elektronik mit oder ohne PC
automatisch schicken.
Man könnte die Daten am Bus mitloggen und eventuell die Fehlermeldung
darin finden. Was Dir vermutlich auch nichts helfen wird
Mit der Schaltung von Rudi oder mir könntest Du Die Daten aufzeichen und
Dir ansehen. Habe inzwischen meine Schaltung wieder ein wenig geändert.
Ist vermutlich unwahrscheinlich den Fehler zu finden. Aber vielleicht
hilft es ja trotzdem.
Wie gesagt sind alles nur Vermutungen....
Falls Du das mal versuchen möchtest und nicht mit dem lötkolben umgehen
kannst oder möchtest, kann ich dir die Schaltung zum selbstkostenpreis
zusammenbauen und mit Software zuschicken. Allerdings muss dann immer
ein PC rund um die Uhr laufen.
Gruß
Ingo
Ich wollte mal meine Projekte zur Verfüging stellen.
ETH_M32 (URadig) ist für das Pollin-AVR-Net-IO Board. Läuft bei mir aber
mit einem Atmega644 statt Atmega32. Wenn man sich per Telnet drauf
verbindet werden die empfangenen Telegramme über die Telnet-Verbindung
weitergeben. 1-Byte-Telegramme werden aus Performancegründen nicht
versendet und die Daten gehen nicht binär sondern als Hex-Text über die
Leitung (Telegramm-Ende CR/LF). War für mich einfacher für das Debugging
und die Auswertung als das binäre Protokoll wie von Rudi. DAC1 wird als
Ausgang für die Empfangs-LED verwendet.
EmsBusReceiver ist der Code von Rudi für Atmega8 (binäres Protokoll).
Als Hardware verwende ich das Pollin-AVR-Evaluationsboard.
Am Pollin-Board gehe ich mit der Empfängerplatine direkt auf den RS232
Stecker, deshalb habe ich an der Platine +/- Eingang getauscht damit mir
der OP das Signal invertiert.
Ein Problem habe ich noch mit der Auswertung der daten vom UBA3. Die
Warmwassertemperatur geht manchmal für 1 Telegramm auf (immer) 25.7
Grad. Brennerstatus stimmt auch nicht. Die Daten für den Wasserdruck
liegen bei mir auch auf anderen Stellen im Telegramm. Kann mir hier
jemand nochmal seine komplette Auswertungsroutine posten? Mein Eindruck
ist das die Daten in der Excel-Liste teilweise nicht stimmen.
Gruss Matthias
Beitrag "Re: Logamatic 2107 Schnittstelle"
Der Druck ist an Stelle 21. Poste doch mal eins von deinen falschen
Telegrammen. Evtl. sind es einfach nur Übertragungsfehler.
Hallo Rudi
Das Telegramm sieht bei mir so aus (letztes Byte ist Anzahl der Zeichen
im Telegramm)
Das Telegramm ist also immer nur 18 Byte gross.
Der Druck ist an Stelle 13.
080018003C02640125800201010F48C8028E12
080018003C02640125800201010F48C802C712
080018003C02640125800201010F48C802EA12
080018003C02640125800201011048C8021412
080018003C02640125800201011048C8022112
080018003C02640125800201011048C8022D12
080018003C02640125800201011048C8022D12
080018003C02640125800201011048C8023712
080018003C02640125800201011048C8028212
080018003C02640125800201011048C8028F12
080018003C02640125800201011048C8029B12
080018003C02640125800201011048C802A412
080018003C02640125800201011048C802BD12
080018003C02640125800201011048C802BD12
080018003C02640125800201011048C802E512
080018003C02640125800202011048C8027712
080018003C0264012C800102000D4C1C027512
080018003C0264012D800102000E4C1C02F012
080018003C0264012D800102000F4C1C02E412
080018003C0264012D800200000D4C1C025F12
Bei der Aussentemp. konnte ich dagegen noch keine "Fehler" feststellen.
080019000002140000640802370002A006002313
08001900000B2C00001F0802120002BD06026413
08001900000C1F0000270802160002C106029013
08001900000C2300002E0802190002C406024113
08001900000C270000210802130002BE06024C13
08001900000C3700001E0802110002BC0602E213
0800190000895A00001E08022F00029C06012113
080019000089800000000802A20002C306001813
0800190000898000001E08022D00029A06012613
Die Daten vom WM10 und RC35 passen auch.
Gruss Matthias
Hallo Matthias,
habe vorgestern die Auswertung der Satusbytes 10 und 11 vom Telegramm
080018 bei mir eingebaut. Ich musste hinterher die Bytes 11 und 10
tauschen. Vielleicht mal ausprobieren die Bytes zu tauschen.
Habe nicht mehr nachgeschaut obe es jetzt von mir ein Programmierfehler
war oder wirklich die Exeltabelle die Bytes 10 und 11 vertauscht hat.
Ich meinte die Exel-Tabelle die die ganzen Telegramme auswertet werden
und 5 Megabyte hat oder noch größer ist.
Die Telegramme kann ich imm Moment nicht mit meinen vergleichen.
Gruß
Ingo
Hallo Ingo,
An einen Byte-Verdereher glaube ich nicht, da die Werte ja zur Anzeige
im RC35 passen. Komisch ist das ich nur ein 18-Byte-Telegramm habe (ganz
selten war's mal ein 17-Byte-Tele, das war dann wohl ein
Übertragungsfehler).
Vielleicht muss ich auch nochmal meine Empfängerplatine optimieren.
Verwende einen LM393, die Signale nehme ich mittels Spannungsteiler vom
Bus ab damit mein Eingang kleiner 5V ist (Vcc vom LM393). Allerdings
würde mich halt wundern, das das Telegramm immer so schön reproduzierbar
ist.
Gruss Matthias
Hallo Matthias, ich habe auch einen LM393 in meiner Schaltung. Klappt
eigentlich problemlos.
@Rudi,
meinte nur die Bytes 10 und 11 der Rest wird wohl stimmen.. Aber wie
gesagt, kann auch ein Programmierfehler von mir gewesen sein den ich
dann glatt gezogen habe.
Gruß
Ingo
@Rudi
Mit der Telegrammlänge wunder ich mich auch.
Was hast Du den für Komponenten-Versionen?
Bei mir ist:
RC35 1.08
UBA3 3.06
BCM Version 12
BCM Nummer 1072
BC10 2.03
WM10 2.0
Werde aber auch noch mal in meiner Netio-Software schauen ob ich da etwa
irgendwas versemmel...
@ Ingo
Dneke auch das der LM393 gut funktioniert, da die Kommunikation
reproduzierbar ist.
Gruss Matthias
@Matthias
Ein anderes Protokoll in Abhängigkeit von der Versionsnummer kann ich
mir nicht wirklich vorstellen.
Kommt die Länge vom Pollin-AVR-Evaluationsboard oder berechnest du die
neu ?
Kannst du mal ein Log mehrerer Nachrichten posten (mit Space zwischen
den Bytes bitte) ?
Ich habe hier eine RC30.
Hallo Rudi,
die Länge berechne ich beim Empfang wenn der Frameerror kommt auf dem
Atmega, das ist prinzipiell das Verfahren aus deinem Atmega-Code.
Die Logdaten zeichne ich heute Abend mal auf.
Das unterschiedliche Versionen ein unterschiedliches Protokoll fahren
sollten käme mir auch seltsam vor (zumindest bei Heiztechnik).
Allerdings finde ich schon komisch das bei mir auch der Heizungsdruck
reproduzierbar auf anderen Adressen liegt.
Gruss Matthias
Hallo Rudi,
anbei das Log (ca. 2h 18:15-20:30) mit Spaces.
Bzgl. der Datenerfassung hab ich nochmal geschaut. Sollte eigentlich so
stimmen. Der Netio erfasst direkt die Telegramme und sendet sie per
telnet. Am Anfang hatte ich etwas Probleme mit der Performance, deshalb
sende ich nicht mehr die 1-Byte Telegramme. Muss es aber nochmal mit dem
Eval-board versuchen (deine Version - Ausgabe über Uart) und schauen, ob
ich damit andere Daten bekomme.
Gruss Matthias
@Matthias
Die Daten werden offensichtlich wirklich in einem anderen Format
geschickt. Hast du die Hard-/Software kontrolliert ?
Hier meine Versionen:
UBA3/MC10 (Universeller Brennerautomat/Mastercontroller) - 8 - V3.02
BC10 (Basiscontroller) - 9 - V2.02
RC30 (Raumcontroller) - 16 - V2.08
Version 3
KIM (Kesselidentifikationsmodul) 1051
@Rudi
Hallo Rudi,
vielen Dank für dein Infos.
Habe bei mir in meiner jetzigen Konfiguration alles geprüft, scheint OK
zu sein. Ich werde jetzt nochmal die Telegramme direkt über die RS232
auslesen (deine Atmega8-Software). Allerdings fehlt mir gerade etwas die
Zeit, deshalb kann es noch ein paar Tage dauern.
Ich melde mich sobald ich es getestet habe.
Gruss Matthias
@IngoF
Bist du mit deiner Sendefunktionalität weiter gekommen ? Ich habe es
jetzt mit zwei Fets und einer Z-Diode aufgebaut. Senden funktioniert,
nur wird die Nachricht offensichtlich nicht ordentlich empfangen.
Entweder ich bekomme keine Antwort oder eine Falsche. Ich habe zum
Testen die 10 88 ... Nachricht verwendet.
Nein, noch nicht wirklich.. Habe mich an der Prüfsumme versucht und aber
nur ein wenig weiter gekommen.. Mit praktischen Versuchen habe ich noch
nichts versucht... Vielleicht sollte ich doch den Microcontroller zum
senden nehmen, Dann muss ich aber erst noch mal Dein Programm in
Assembler nachschrieben oder noch mal von vorne anfangen...
Gruß
Ingo
Also es scheint schon mal ein "normales" XOR zu sein. Und nach der
Berechnung wird die Prüfsumme ein Bit nach rechts rotiert. Aber bei
Bytes mit gesetztem MSB werden die beiden mittleren Bits getauscht. Aber
irgendwie Ist das noch nicht ganz OK so...
Vielleicht hat ja noch jemand eine Idee...
Gruß
Ingo
@IngoF
Senden funktioniert nur mit gleichzeitigem RX. Es kann auch nicht mit
einer vorhandenen Adresse gesendet werden. Sendet man z.B. einfach ein
0x10 Antwortet die vorhandene 0x10 mit 0x10. Kollisionen werden über das
RX erkannt, da der Bus bei einem "high" released wird ein ein anderer
Sender den Bus auf "low" halten würde.
Das mit der CRC hört sich doch schonmal gut an.
Bei mir sah es etwas anders aus. Die oberen 4 Bits gingen nur in die
oberen Bits der CRC ein. Die unteren 4 Bits in die unteren 4 Bits der
CRC. Ich habe aber nur einen Nachrichtentyp getestet. Mit einer
vorhandenen Sendefunktion sollte es evtl. einfacher werden.
Soweit ich herausgefunden habe müsste man auch erst auf sein Polling
warten. Und kann dann erst senden. Also 0x90 0x00 ist das Polling für
die RC30/35 die mit 0x10 0x00 antwortet, oder noch Daten
hinterhersendet.
Ich hatte bei drei verschiedenen Telegrammen die Bits getestet. Dann
wurde immer rechts rotiert. Also ging auf die Prüfsumme Bit0 das Bit0
vom letzen Byte, Das Bit1 vom vorletzten Byte , das Bit2 vom drittletzen
Byte ein.
Soweit ich mitbekommen habe schien die Adresse nicht mit in die
Berechnung gegangen zu sein. Immer nur die Daten nach den Quell und
Zieladresse.
Die Prüfsumme von den Betriebsstunden kann man relativ gut berechnen.
einfach 0x60 XOR mit dem erten Byte, dannach dann das Zwischenergebnis
rotieren und dann XOR dem aktuellen Byte.. Das klappt dann bei allen
Telegrammen. Außnahme sind die Telegramme die an dem vorletzten Byte das
MSB gesetzt haben.
Wäre ja mal ganz interessant zu wissen ob in der RC30/35 dann ein neuer
Bus-Teilnehmer auftaucht wenn man das Polling immer mit der Adresse
beantwortet. Vielleicht kann man schon mal herausfinden welche Adressen
für welche Module vorgesehen sind.
Gruß
Ingo
@IngoF
So ganz komme ich bei deiner Berechnung nicht mit.
Mal ein Bsp.:
CRC = 0xE9
08 10 14 00 1E 64 00 <E9>
crc = 0x60
crc = crc ^ 0x08
crc = crc >> 1
usw. bis 0x00
Da komme ich auf 0x1A
Genau so...
hier mal meine Beispiel-Berechnung mit Excel. Wer kein Excel kann sich
das Bildchen ansehen...
bei den Telegrammen mit größer 0x7f habe ich als Startwert 0x00
genommen. Die Prüfsummen sind in der Fett gedruckt.
Bei anderen Telegrammen hat es aber nicht geklappt.. Aber immerhin schon
mal ein weiterer Schritt in die Richtige Richtung.
Habe alle Telegramme mitgeloggt und dann die passenden Telegramme
ausgesucht und zum Berechnen genommen.
Ja, habe ich ja gesagt... bei den Telegrammen mit 0x80 oder größer muss
genau bei dem XOR wohl die beiden mittleren Bits getauscht werden.
Oder man nimmt den STartwert 0x00, dann stimmt es auch wieder...
ABer wie gesagt bei den anderen Telegrammtypen am Anfang der Excel-Datei
stimmt es auch nicht..
Also wie gesagt.. Ich habe für etwa einen Monat die Telegramme
mitgeloggt und dann immer zwei Telegrammpärchen ausgesucht wo nur ein
einziges Bit geändert wurde. Da habe ich dann bei allen Telegrammen
herausgefunden dass die Bytes immer bei jedem XOR verschoben sind. Auch
bei anderen Telegrammtypen.
Gruß
Ingo
Nein, das kann ich nicht bestätigen. Mal auf die letzten Bytes und den
Betriebsstundenzähler bezogen, es ändert sich bei der 0x80er Grenze
(durch das Polynome) und dann noch bei einem Wechsel vom vorletzten
Byte. Für mich bedeutet das eine normale CRC (Tabellenbezogen). Die
Tabelle wird wohl hausbacken sein, ansonsten wäre die CRC schon klar.
Bei einem Polynome von 0x09 (xort wenn das MSB in der CRC gesetzt ist)
bleibt die Differenz zwischen berechneter und vorhandener CRC immer
gleich, bis zu einem Wechsel des vorletzten Bytes, da es nun als Index
auf einen neuen Wert in der Tabelle verweist. Da sich die Bytes davor
nicht ändern ist dieser Index erstmal gleich. Teste es einfach mal ;-)
Anbei noch eine Ausgabe als Logdatei:
FOUND: 08 * ! 10 * ! 14 * ! 00 * ! 1E * ! 5E * ! 6D * ! F0 DE 21 2E
Die letzten 4 Byte:
F0 DE 21 2E
**----------CRC-1 aus dem Datenstream
**-------CRC-2 berechnet mit dem finalen XOR 0xff
**----CRC-3 ohne Polynome (einfaches XOR aller Bytes ohne finales
XOR)
**-berechneter Wert aus CRC-1 XOR 0xFF XOR CRC-2 (*1)
(*1) wobei ich grad merke das XOR 0xff hätte ich mir auch sparen können
Für mich sieht das erstmal gut aus ...
Also dass sich die Bits verschoben auf die Prüfsumme auswirken ist ganz
sicher. Zumindest bei den getesteten Telegrammen. Allerdings ist es
nicht so einfach passende Telegrammpärchen zu finden bei denen sich nur
ein Bit ändert.
Das vorletzte Tabellenblatt enthält Telegramme von Dir und Mir die wenig
änderungen haben. Das letzte Tabellenblatt sind Telegramme von 0x10 0x00
0x9c bei dennen das auch zutrifft.
die letzte Zeile in Rot ist nur ein XOR damit man sieht welches Bit sich
ändert.
Nach meiner Berechnung funktionieren bisher alle Telegramme von 0x10
0x00 0x14. Denke das ist schon mal ein kleiner Schritt in die richtige
Richtung..
Nur dass man bei Telegrammen mit >0x7f einen anderen Startwert nehmen
muss (>0x7f = 0x60 / <0x80 = 0x00)
Das Telegramm ist eigentlich nicht sooo gut geeignet die Prüfsumme zu
finden... Am besten wäre ein Telegramm bei der sich alle Werte ändern,
und das so häufig vorkommt dass man genug Rohmaterial hat um zu sehen
welches Bit sich wie auswirkt. Aber das gibt es ja nicht.. ABer
vielleicht kann man ja durch die Sendefunktion und die Antwort durch
irgendeinen Busteilnehmer so ein Telegramm finden.....
Diese Verschiebung durch eine Stelle bei jedem Byte kann doch nicht
durch ein Polynom kommen, oder? Kann es sein dass es doch irgendein
Polynom ist, bei der dann nach jedem Byte das Zwischenergebnis rotiert
wird? Aber dann würde ich doch nicht so eine "gute" CRC mit einem
simplen XOR nachrechnen können.
Also irgendeine Schweinerei außer das rotieren haben die noch eingebaut.
Der initiale Wert ist 0x00. Wenn bei der CRC das MSB gesetzt ist, dann
wird mit 12 xort, vor dem shiften. Bei der letzten Berechnung bzw. beim
letzten Byte muss vor dem XOR aufgehört werden. Damit stimmen dann ALLE
CRCs !
Ingo, gute Arbeit !
> Wie sieht denn Deine Schaltung mit den FETS und der Z-Diode aus?> Würde mich mal interessieren :-)
Ein P-MOSFET (20K am Gate Pullup) schaltet einen N-MOSFET (500 Ohm am
Gate Pulldown) der die Masse über die Z-Diode (10V) auf den Bus
schaltet. Ich habe 3 500mW parallel geschaltet, hatte keine "große".
Leider ist die steigende Flanke auf dem Bus etwas langsam (die fallende
Flanke nicht), evtl. gibt es da noch Probleme.
Also anstelle des Wertes, oder noch zusätzlich mit 0x12 XORen.
Funktioniert es dann auch bei allen anderen Telegrammen, oder nur bei
bei den Betriebstunden Telegrammen?
Welcher Teil wird denn verknüpft? Alles, oder nur der Datenbereich?
Kann die Flanken bei meiner Lösung leider nicht kontrollieren.. Habe
leider keine Möglichkeiten mehr dazu...
Gruß
Ingo
P.S. Hat ja auch eine Weile gedauert das rauszufinden.. nur mit den 0x80
Werten kam ich nicht so ganz weiter...
Ich habe mal versucht die 8 anzusprechen, aber leider nichts. Meine
Nachricht:
33 88 14 00 03 6C
Die Adresse kann natürlich auch falsch sein und Statusbits involvieren.
Vielleicht muss man sich ja auch erst anmelden oder die Teilnehmer
nehmen nur eine bestimmte Adresse an. Jede Adresse steht ja für einen
bestimmten Teilnehmer.
Schätze mal die 08 ist der Master und schickt das Polling los. Also
müsstest Du warten bis einmal das Telegramm 0xB3 0x00 auftaucht.
Was soll dass den für ein Telegramm sein? also 33 ist der ABsender die
88 der Empfänger (0x08) mit MSB gesetzt damit es antwortet. Dann
möchtest Du telegramm 0x14 (oder ist das nur ein Speicherbereich).
Dannach müsste dann die Prüfsumme kommen und anschließend 0x00 mit
Stopbit 0, oder
also 0x33 0x88 0x14 "CRC" 0x00
Fang doch erst mal mit was einfacheren an...
Versuch doch erst mal nur ein existierendes Polling zu beantwortet. Also
eine Adresse die noch nicht in der RC30 als Busteilnehmer eingetragen
ist. z.B die 0x21 oder 0x22 wenn die noch nicht vorhanden sind. Glaub
das sollten irgendwelchen Mischer sein, oder?
Also auf jedes 0xa1 0x00 mit 0x21 0x00 antworten. Also erst mal ganz
ohne Prüfsumme.. Dannach müsste das Polling öfter kommen und vielleicht
in der RC30 als Busteilnehmer auftauchen. Dann ist schon mal klar dass
das senden funktioniert.
Hoffe dass es schon reichen sollte um von der RC30 als Busteilnehmer
erkannt zu werden. Nicht dass noch mehr als "anmeldung" erwartet wird.
Oder vielleicht kommt dann aufeinmal eine Anfrage von irgendeinem
Busteilnehmer...
Gruß
Ingo
Ja, mal schaun. Ich stelle den Sklaven grad auf einen AVR644p um. Der
hat wenigstens 2 Uarts. Einen Timer für den Timeout will ich auch noch
programmieren und dann noch die UART-Break Geschichte in Software. Hoffe
das funktioniert soweit.
> Was soll dass den für ein Telegramm sein? also 33 ist der ABsender die> 88 der Empfänger (0x08) mit MSB gesetzt damit es antwortet. Dann> möchtest Du telegramm 0x14 (oder ist das nur ein Speicherbereich).
Das ist die Abfrage für die Betriebsstunden. Break hatte ich bisher über
einen Cortex gesendet, der kann das mehr oder weniger in Hardware. Den
will ich aber für den Sklaven aber nicht benutzen. Der 644er läuft jetzt
nebenher und hat die Sendefunktionalität. Ich kann dann also mit 2
Geräten den Bus loggen (der "alte" M8 und der 644).
> Hoffe dass es schon reichen sollte um von der RC30 als Busteilnehmer> erkannt zu werden. Nicht dass noch mehr als "anmeldung" erwartet wird.> Oder vielleicht kommt dann aufeinmal eine Anfrage von irgendeinem> Busteilnehmer...
Das sollte man ja beim einschalten der Anlage direkt sehen können.
Hat das mit der CRC bei dir funktioniert ?
Also. Ich warte auf ein 0x8F und antworte mit einem 0x0F
8F BRK
0F BRK
FC TIMEOUT
Danach kommt dann FC und ein Timeout, ist wohl sowas wie Busreset !? Das
ist also erstmal falsch nehme ich an.
Wenn ich kein Break sende dann bekomme ich ein Echo von der 0x0f und ein
Timeout.
8F BRK
0F 0F TIMEOUT
Wenn ich kein Break sende und 0x0f 0x00 sende bekomme ich:
8F BRK
0F 00 TIMEOUT
Wenn ich kein Break sende und 0x0f 0x00 0xFF sende bekomme ich:
8F BRK
0F 00 FF FF TIMEOUT
Also wieder ein Echo.
Hallo Rudi,
Laut dem Mitschnitt hier:
Beitrag "Re: Logamatic 2107 Schnittstelle"
müsste auf das Polling mit Adresse und 0x00 mit Stopbit 0 geantwortet
werden.
Als Antwort dürfte dann eigentlich garnichts kommen.
Vielleicht gibt es die Adresse ja ganricht. Versuch doch mal die 0x21
oder 0x22 wenn die Mischer nicht eingebaut sind.
Was ist das denn für ein Break? Wer sendet das denn? Also wenn das
Terminalprogramm am PC ein Break sendet dann wird der Sendepin für 3
Sekunden auf 0 gesetzt. Das könnte für den Bus oder den Busmaster
vielleicht zuviel sein. Keine Ahnung was der AVR-Uart für ein Break
sendet. Auf dem Bus wurden ja nur 9 Bit (937,5µs) lang Null gesendet
Vielleicht muss der UART vom Atmega8 (oder was auch immer) entsprechend
konfiguriert werden. Werde das irgendwann mal im Atmega8 in Assembler
programmieren. Dummerweise hatte die Festplatte den Wochenlangen
Dauerbetrieb nicht verkraftet und muss mir eine andere besorgen... Kann
das im Moment leider nicht selber testen.
Gruß
Ingo
> Laut dem Mitschnitt hier:> Beitrag "Re: Logamatic 2107 Schnittstelle"> müsste auf das Polling mit Adresse und 0x00 mit Stopbit 0 geantwortet> werden.
Ja, das habe ich versucht, aber ich bekomme auf der Leitung ein Echo.
> Als Antwort dürfte dann eigentlich garnichts kommen.
Hier nicht.
> Vielleicht gibt es die Adresse ja ganricht. Versuch doch mal die 0x21> oder 0x22 wenn die Mischer nicht eingebaut sind.
Das habe ich versucht, gleiches Verhalten.
> Was ist das denn für ein Break? Wer sendet das denn? Also wenn das> Terminalprogramm am PC ein Break sendet dann wird der Sendepin für 3> Sekunden auf 0 gesetzt. Das könnte für den Bus oder den Busmaster> vielleicht zuviel sein.
Ja, ist es. Das Break sollte in etwa 1 Frame (10Bit) lang sein, damit
die UART ein negiertes Stop-Bit sieht.
> Keine Ahnung was der AVR-Uart für ein Break> sendet. Auf dem Bus wurden ja nur 9 Bit (937,5µs) lang Null gesendet
Ja, die 937.5uS habe ich hier in etwa auch. Beim Mega ist das etwas
komplizierter, da muss TX abgeschaltet werden und dann gehts per GPIO
weiter.
> Vielleicht muss der UART vom Atmega8 (oder was auch immer) entsprechend> konfiguriert werden. Werde das irgendwann mal im Atmega8 in Assembler> programmieren. Dummerweise hatte die Festplatte den Wochenlangen> Dauerbetrieb nicht verkraftet und muss mir eine andere besorgen... Kann> das im Moment leider nicht selber testen.
Schade, bisher habe ich hier noch keine Probleme.
Anbei mal der Code in C. Ich habe intern einen Timer der mit etwa 100KHz
läuft und die timer_set_wait Funktion wartet die angegebenen Ticks. Ich
habe mit dem Oszi gemessen und es sieht ganz vernünftig aus. Bei der RX
Funktion (nicht anbei) habe ich mir noch ein Flag für ein Bus-Free
eingebaut, das wird nach einem Timeout oder Break gesetzt und beim
Empfang eines neuen Bytes gelöscht. So vermeidet man Kollisionen auf dem
Bus.
1
void uart0_send_data( uint8_t * data, uint8_t len, uint8_t flag )
Rudi schrieb:> Ja, die 937.5uS habe ich hier in etwa auch.
Denke mit "in etwa" meintest Du genau...
Allerdings
> /* wait 11 bit */
Müssten dann doch 9 Bit sein, oder? Waren doch 9600 8N1 wenn ich mich
recht erinnere. Also das Startbit High dann 1 Bit warten und dann 9 Bit
Low (8 Daten+1Stopbit. Keine Ahnung ob sich der Busmaster wegen so einer
kleinigkeit anstellt. Vielleicht sendest Du Die Bytes ja auch zu schnell
hintereinander? Soweit ich mich aber erinnere wurden von der RC30 auch
die Bytes hintereinander losgeschickt. Dürfte dann eigentlich auch nicht
sein.
Liegt das Signal denn selbsterzeugte Break denn auch richtig an? Weiß
jetzt ganricht mehr so genau ob jetzt 10V oder 15Volt auf dem Bus eine 1
oder 0 war. Normalerweise wird das Signal noch mal durch einen Treiber
wie MAX232 invertiert..
Kann leider auch nur im Dunkeln herumstochern...
Gruß
Ingo
Achso...
Wir haben ja nur im laufenden Betrieb das Polling mitgeschnibbelt..
Vielleicht ist die einmalige Anmeldeprozedur ja ganz anders und läuft
nur ganz kurz nach dem einschalten der Anlage ab.
Vielleicht kommt bei der erstmaligen Anmeldung ja noch irgendwas wie
eine Bestätigung als z.B. das 0xfc.
Kannst Du das den mal mit dem Oszilloskop vergleichen ob das gesendet
wird was Du auch senden möchtest..
Gruß
Ingo
> Wir haben ja nur im laufenden Betrieb das Polling mitgeschnibbelt..> Vielleicht ist die einmalige Anmeldeprozedur ja ganz anders und läuft> nur ganz kurz nach dem einschalten der Anlage ab.
Nein, da passiert nicht viel. Siehe unten, direkt die Einschaltsequenz.
Das zweite FF z.B. 98 FF bedeutet Timeout, das habe ich jetzt eingebaut.
> Vielleicht kommt bei der erstmaligen Anmeldung ja noch irgendwas wie> eine Bestätigung als z.B. das 0xfc.
Nein.
> Kannst Du das den mal mit dem Oszilloskop vergleichen ob das gesendet> wird was Du auch senden möchtest..
Das stimmt schon, ich logge mit unterschiedlichen CPUs den Bus und die
sehen das gleiche. Ich denke da hilft nur ein Log vom ServiceKey. So wie
ich das gesehen habe wandelt der das Protokoll von der 2107 UART auf
diesen Bus. Evtl. haben wir es auch noch nicht richtig verstanden wer
was sendet. Warum hat z.B. die 98 immer einen Timeout, die 88 z.B. auch,
und die anderen Adressen werden immer mit BRK gesendet bzw. bestätigt.
Das ist auch nicht klar.
>> Ja, die 937.5uS habe ich hier in etwa auch.>Denke mit "in etwa" meintest Du genau...
;-) Es geht an die eine Millisekunde.
>> /* wait 11 bit */> Müssten dann doch 9 Bit sein, oder? Waren doch 9600 8N1 wenn ich mich> recht erinnere. Also das Startbit High dann 1 Bit warten und dann 9 Bit> Low (8 Daten+1Stopbit. Keine Ahnung ob sich der Busmaster wegen so einer> kleinigkeit anstellt. Vielleicht sendest Du Die Bytes ja auch zu schnell> hintereinander? Soweit ich mich aber erinnere wurden von der RC30 auch> die Bytes hintereinander losgeschickt. Dürfte dann eigentlich auch nicht> sein.
Du musst den Bus für 10Bit auf Low ziehen, also START 8Bit STOP sind
Low. Das elfte Bit ist für den Clockjitter ;-)
> Liegt das Signal denn selbsterzeugte Break denn auch richtig an? Weiß> jetzt ganricht mehr so genau ob jetzt 10V oder 15Volt auf dem Bus eine 1> oder 0 war. Normalerweise wird das Signal noch mal durch einen Treiber> wie MAX232 invertiert..
Das liegt an, ich logge ja gleichzeitig den Bus. Mein Problem ist eher
dieses "mitsenden" vom Master.
Rudi schrieb:> 98 00
Also es ist ja nicht so dass die 98 immer ein Timeout bekommt. Bisher
habe ich auf meinem Bus noch nie ein Timeout sehen können. Aber ich habe
auch nicht so stark danach gesucht..
Vielleicht gibt es ja trotz Polling irgendwelche Kollisonen. Die 98 FF
würde ich jetzt einfach mal als Übertragungsfehler oder Kollision
einordnen. Soweit ich mitbekommen habe werde bekannte Busteilnehmer
häufiger abgefragt. Ein Polling für Adresse 88 habe ich z.B. noch nie
gesehen. Vermutlich weil das der Busmaster ist und das Polling sendet.
Warum soll er sich also selber anpollen. Danach werden fortlaufend die
Adressen angepollt die noch nie geantwortet haben.
Fing dann meistens mit 0x89 und dann kommen der Reihe nach 0x91, 0x92,
0x93, 0x94, 0x95, 0x96, 0x97, und 0x98. Dann war soweit ich mich
erinnere erst mal eine Zeitlang Ruhe beim Polling von bisher
unbeantworteten Pollings. Dann ging es nach einiger Zeit mit dem
nächsten Polling-Block weiter Als 0xA0, 0xA1, ..... 0xA8, dann wieder
Pause und der nächste Polling-Block war dran.
Demnach hätte das Polling 0x98 dort noch garnichts zu suchen. Deshalb
vermute ich wirklich einen Übertragungsfehler. Vielleicht haben die
beiden Sender mitgehört und mitbekommen dass die Daten falsch übertragen
wurden und haben dann die Übertragung beendet. Vielleicht gab es
deswegen kein <break>.
Vielleicht mal das im Auge behalten ob das Polling mit dem Timeout
immer, wie hier vermutlich, zur falschen Zeit kommt.
Glaub ich sollte mich mal schleunigst um eine Festplatte kümmern.
Vielleicht hatte die ja auch schon eine Vorschädigung. Hatte die
Festplatte gebraucht gekauft.
Rudi schrieb:> Du musst den Bus für 10Bit auf Low ziehen,
Ups, hatte doch glatt das Startbit vergessen... Vermutlich wird das eine
Bit "zuviel" wohl keine Probleme machen...
Gruß
Ingo
Ingo F. schrieb:> Ein Polling für Adresse 88 habe ich z.B. noch nie> gesehen.
Meinte damit das 0x88 <break> Polling und nicht das mit einem Telegramm
wie 0x10 0x88 .....
> Demnach hätte das Polling 0x98 dort noch garnichts zu suchen. Deshalb> vermute ich wirklich einen Übertragungsfehler. Vielleicht haben die> beiden Sender mitgehört und mitbekommen dass die Daten falsch übertragen> wurden und haben dann die Übertragung beendet. Vielleicht gab es> deswegen kein <break>.
So wie ich das sehe kommt nur bei diesen Adressen (18,88,98) ein
Timeout. Anbei mal ein Log mit Zeitstempel.
Hallo Rudi,
das habe ich ja nicht ausgeschlossen.. Ich habe nur gesagt dass genau
die 98 FF aus dem Log vermutlich ein übertragungfehler ist. Vielleicht
kommen ja gerade immer nur diese Adressen zustande bei
Übertragungsfehlern.
Vielleicht sollte ich auch mal auf meinem Bus genauer mitloggen.
Bei Dir ist das ja ziemlich oft, oder? Sind das Sekunden? oder was ist
das für eine Zeiteinheit?
Gruß
Ingo
> Vielleicht sollte ich auch mal auf meinem Bus genauer mitloggen.> Bei Dir ist das ja ziemlich oft, oder? Sind das Sekunden? oder was ist> das für eine Zeiteinheit?
Ja, sind Sekunden. Die Daten kommen kontinuierlich, aber nicht zyklisch.
Hallo Rudi,
in Bild 4 und 5 scheint das wohl keine Störung zu sein.
Das scheint wohl die RC30 zu sein (0x10). Die kleinen "Störungen" sehen
genauso aus wie das nachfolgende Byte. Also ob die RC30 die Bytes erst
zum Sendeteil überträgt und trotzdem den Weg auf den Bus finden. Und
dann wird erst das Byte übertragen. Beim lesen dürfte das Problem
vermutlich nicht auftreten. Die anderen Busteilnehmer scheinen ja nicht
so eine Pause zu machen.
In Bild 1 bist Du vermutlich in der Zeile verrutscht. Das sind 1,04 ms =
961,5 Hz also 10 Bit.
die letzten beiden Bilder sind vermutlich Deine Antwort, oder? Sieht so
aus als ob es da wirklich eine Kollision gibt. Kann das sein dass Du zu
langsam geantwortet hast und das nächste Telegramm oder eine
Fehlermeldung verschickt wird?
Gruß
Ingo
> in Bild 4 und 5 scheint das wohl keine Störung zu sein.> Das scheint wohl die RC30 zu sein (0x10). Die kleinen "Störungen" sehen> genauso aus wie das nachfolgende Byte. Also ob die RC30 die Bytes erst> zum Sendeteil überträgt und trotzdem den Weg auf den Bus finden. Und> dann wird erst das Byte übertragen. Beim lesen dürfte das Problem> vermutlich nicht auftreten. Die anderen Busteilnehmer scheinen ja nicht> so eine Pause zu machen.
Das sehe ich jetzt auch. Mhh, sehr merkwürdig.
> In Bild 1 bist Du vermutlich in der Zeile verrutscht. Das sind 1,04 ms => 961,5 Hz also 10 Bit.
Das ist das Byte mit dem Low Stopbit (Break).
> die letzten beiden Bilder sind vermutlich Deine Antwort, oder?
Ja, genau.
> Sieht so aus als ob es da wirklich eine Kollision gibt. Kann das sein dass > Du
zu langsam geantwortet hast und das nächste Telegramm oder eine
> Fehlermeldung verschickt wird?
Nein, eigentlich nicht. Die ersten beiden Bytes sind der Request und
kurz danach der Response mit "Fehler". Eigentlich wird ein normaler
Response etwas später verschickt. Das habe ich auch probiert, aber ohne
ersichtliche Besserung.
Den einzigen Fehler den ich noch sehe ist das falsche Timing nach dem
zweiten FET und der Diode in meiner Sendeschaltung. Beim abschalten
(Low/High-Flanke auf dem Bus) floated der Drain-Ausgang und
Diodeneingang. Bei dir wäre das zwischen Transistor und Diode. Da müsste
man einen Pullup dran hängen der durch eine Diode + C die Strecke auf
einen definierten Pegel zieht, wenn der FET abgeschaltet wird.
Das C wird über den Bus geladen und sollte dann bei etwa 15V hängen.
Denkst du das würde funktionieren ?
Rudi schrieb:> ein, eigentlich nicht. Die ersten beiden Bytes sind der Request und> kurz danach der Response mit "Fehler".
Achso, jetzt sehe ich das erst. Also das Polling dann eine kurze Pause,
Deine Antwort, dann eine Pause Dein Break.
Sieht so aus als ob kurz nach Deinem Break ein Break vom Busmaster
kommt, oder?Deine Sendeschaltung zieht den Signalpegel ja etwas tiefer
als in dem Polling vom Master. Das letzte Break scheint den selben
Low-Pegel zu haben wie das Polling. Der Master wartet ja kaum und
schießt sofort nach Deinem 0-Stopbit sofort los.
Was Du jetzt mit dem Floaten meinst verstehe ich jetzt nicht so ganz
Sieht doch ganz gut aus. Oder meinst Du dass das zweite Break dadurch
entsteht?
Gruß
Ingo
Vergiss es ;-) Das Problem hatte ich im Testaufbau gesehen, auf dem Bus
sieht es besser aus.
Anbei noch 3 Bilder von meinem Response und die Variationen. Sieht mir
irgendwie nach einem Timing-Problem aus. Ab und sieht es auch so aus wie
es soll.
Oben der Bus und unten der TX-Ausgang vom uC.
Wenn man jetzt Bild 04 und 10 miteinander vergleicht würde mir jetzt
Spontan einfallen das die RC30 nur mit 0,5Vss sendet und der Busmaster
das Signal aufarbeitet und für alle anderen Busteilnehmer aufarbeitet.
Bei beiden Signalen fällt mir auf dass die Daten doppelt vorhanden sind
und das Low-Level bei dem Echo anders ist.
Also nur durch ein floaten am FET kann ich mir sowas nicht vorstellen.
Habe bei meiner RC 30 mal die Platine von beiden Seiten fotografiert und
keinen Hinweis dafür gefunden dass dort irgeinde Schaltung zu finden ist
wie in unserem Sendeteil. Dort wurde nur irgendwie ein
CMOS-Logik-Baustein verwendet. Die Schaltung habe ich aber ignoriert
weil ich die nicht so ganz verstanden habe und nicht sicher war dass ich
die richtig entflechtet hatte. Mein Ergebnis hänge ich mal an.
Aber warum sollte es dann eine Prüfsumme geben wenn der Busmaster
sowieso alles widerholt. Dann könnte die RC30 doch einfach überprüfen ob
das Echo korrekt ist. Aber das würden die anderen Busteilnehmer ja nicht
mitbekommen wenn die RC30 feststellt dass das Echo falsch war. Und
müsste sich dann melden dass das letzte Telgramm fehlerhaft wäre..
Keine Ahnung....
Ist das denn bei allen anderen Busteilnehmer auch so, und nur bei
Telegrammen vom Busmaster ohne Echo?
Gruß
Ingo
> Wenn man jetzt Bild 04 und 10 miteinander vergleicht würde mir jetzt> Spontan einfallen das die RC30 nur mit 0,5Vss sendet und der Busmaster> das Signal aufarbeitet und für alle anderen Busteilnehmer aufarbeitet.
Das glaube ich nicht. Der Bus wird aufbereitet hört sich komisch an. Wir
sind ja nicht an der RC30 sondern an der ???BCXX??? am Klinkenstecker.
Die Schaltung wird dort sicherlich ganz anders sein als bei den internen
Busteilnehmern. Ich werde die mal zerlegen und Bilder machen.
> Bei beiden Signalen fällt mir auf dass die Daten doppelt vorhanden sind> und das Low-Level bei dem Echo anders ist.
Die doppelten Signale kann ich auch nicht erklären. Das Low-Level liegt
an der verwendeten Diode in der Sendeschaltung.
> ...> CMOS-Logik-Baustein verwendet. Die Schaltung habe ich aber ignoriert> weil ich die nicht so ganz verstanden habe und nicht sicher war dass ich> die richtig entflechtet hatte. Mein Ergebnis hänge ich mal an.
Ja, das ist ein Busteilnehmer und kein externes etwas mit einer 3m
Antenne ;-)
> Aber warum sollte es dann eine Prüfsumme geben wenn der Busmaster> sowieso alles widerholt. Dann könnte die RC30 doch einfach überprüfen ob> das Echo korrekt ist. Aber das würden die anderen Busteilnehmer ja nicht> mitbekommen wenn die RC30 feststellt dass das Echo falsch war. Und> müsste sich dann melden dass das letzte Telgramm fehlerhaft wäre..
Nein, die Prüfsumme ist für den Empfänger und ob der sich bei
fehlerhafter Prüfsumme meldet ist eine andere Geschichte. Da kommt es
drauf an ob er die Daten haben wollte/braucht oder ob es später auch
okay ist (Timeout).
> Ist das denn bei allen anderen Busteilnehmer auch so, und nur bei> Telegrammen vom Busmaster ohne Echo?
Ich habe bei einem Teilnehmer noch einen ripple gesehen, ich denke da
ist die Verdrahtung oder der Sendeteil etwas daneben. Ich werde da
nochmal messen und Knipsen.
Zu der Schaltung:
Tx geht über ein (R)C-Filter an den Inverter (Treiber) und dann wird nur
der Analoganteil ... Wohin gespeist ? Der muss doch wieder an den Bus ?
Rx geht an den Treiber, Diode, R-Filter und dann Pullup damit es nach
der Diode nicht floated, und dann den Doppelinverter und den RC-Filter,
der ist bei der Übertragungsrate okay.
Der RX und Tx-Pfad sollten noch direkt an den Bus gehen oder sehe ich
das nicht ???
Rudi schrieb:> Der RX und Tx-Pfad sollten noch direkt an den Bus gehen oder sehe ich> das nicht ???
Ja, aber ich habe nirgendwo etwas finden können wo es zum Bus geht. Habe
mich aber auch nicht getraut das LCD-Display von der Platine zu nehmen.
Habe das vor Tausend Jahren auch schon mal bei einer alten Uhr probiert
und hatte dannach nur Kontaktschwierigkeiten.
Rudi schrieb:> Die doppelten Signale kann ich auch nicht erklären. Das Low-Level liegt> an der verwendeten Diode in der Sendeschaltung.
Ist schon klar. Aber bei Bild 4 kann man sehen dass der Signal-Low-Pegel
vom Polling und dem Echo etwa gleich sind und Das Low-Level von Deinen
gesendeten Daten etwas niedriger liegt. Halte es auch für
unwahrscheinlich dass das Echo irgendwie von Deiner Schaltung erzeugt
wird. Irgendeiner schickt das Echo. Keine Ahnung wie und warum.
Und dass die RC30 die Signale vorher auf den Bus intern vor dem Senden
irgendo herumschiebt und die dabei ungewollt auf den Bus kommen kann ich
mir eigentlich auch nicht vorstellen.
Man könnte ja mal zum Spass ausprobieren was passiert wenn man auch nur
ein Signal mit 0,5Vss auf den Bus sendet. Wenn das bei der RC30 entsteht
dürfte sich ja dann am Bus nichts ändern. Aber ehrlich gesagt kann ich
mir auch nicht vorstellen dass nur mit einem so "schwachen" Signal
gesendet wird.
Rudi schrieb:> Wohin gespeist ? Der muss doch wieder an den Bus ?
Ich habe nirgendwo einen Hinweis gefunden. Habe allerdings auch keine
Ahnung wo der R17 hingeht. Der Pfeil nach oben soll keine
Versorgungsspannung sein.
Sind alles nur Vermutungen habe keine Ahnung was da so auf dem Bus
abgeht ....
Gruß
Ingo
Danke noch mal dafür dass Du den letzten Rest der CRC herausgefunden
hast. Ich glaub ich wäre da nie hinter gekommen. Bei mir funktioniert
die CRC-Prüfung jetzt auch einwandfrei.
Die Festplatte war übrigens nicht das Problem. MySQL hat mit anwachsen
der Datenmenge immer mehr Speicher benötigt , bis hinterher die
Auslastung permanent bei 100% lag. Hatte das schon eher auf mein
Java-Programm bezogen.
Bei 40MByte Daten war ein Arbeiten nicht mehr möglich. Habe bei MySQL
allerdings auch die InnoDB und nicht myISAM genommen. Angeblich sollte
InnoDB ja für viele Schreibzugriffe und wenig Lesezugriffe ausgelegt
sein.
Wieso hats Du denn die MyISAM genommen?
Deine Datenbank müste ja inzwischen ein vielfaches meiner Datenbank
haben. Was für eine Prozessorlast verursacht denn Deine MySQL? Und was
hast Du für einen Rechner,
Bei mir ist es nur ein IBMT43 Pentium M 750 1,86 GHz und 1,5GB RAM und
habe bei 40 MByte schon eine Auslastung von permanent 100%. Nach löschen
der ganzen Daten war ich wieder bei 10% Auslastung und weniger
> Deine Datenbank müste ja inzwischen ein vielfaches meiner Datenbank> haben. Was für eine Prozessorlast verursacht denn Deine MySQL? Und was> hast Du für einen Rechner,
Ich habe einen AMD Athlon(tm) XP 1800+ und 500MB Ram. Die CPU-Last liegt
bei etwa 25% im Durchschnitt. Es ist aber nur der Server der die Daten
in die DB schreibt und die Bilder generiert (siehe Anhang).
Ich speicher und generiere z.Z. für zwei Heizungen.
Für die eine habe ich etwa 400MB Daten und 400MB Index (12Mill.
Einträge) und für die andere etwa 300MB Daten und 300MB Index (9
Mil.Einträge) ;-) Ich will das ganze aber noch optimieren da die Abfrage
und das Einfügen zu lange dauert.
Wie Speicherst du die Daten, geparst, nur was du brauchst oder als blob
?
Ich speicher jede Temperatur usw. einzeln als Wert mit Datum, Sender und
Typ.
Noch etwas zur Datenbank. Für diesen Fall der "Datensicherung" ist die
myISAM einfach besser und schneller. Die Features der InnoDB braucht man
dabei einfach nicht.
Ich werde das Format soweit aufbrechen, das jeder Datentyp eine eigene
Tabelle bekommt. Das sollte die Abfragen zum Teil recht gut
beschleunigen und evtl. funktioniert das dann auch über Ajax in Realtime
...
Hast du dir schon etwas für den "späteren" nicht Frickelaufbau überlegt
?
Also bei
Rudi schrieb:> Für diesen Fall der "Datensicherung" ist die> myISAM einfach besser und schneller.
Habe ich auch festgestellt.. Satt permanent 100% und Absturz nach 2,5
Stunden habe ich jetzt nur noch durchschnittlich 80%. Das ändern der
Datenbankengine ging mit nur zwei Mausklicks.
Rudi schrieb:> Ich werde das Format soweit aufbrechen, das jeder Datentyp eine eigene> Tabelle bekommt.
Vielleicht ist das Problem dass ich zur Zeit noch keine Datenreduzierung
mache und alle Werte eines Telegramms abspeichere. Vielleicht sollte ich
das auch so wie Du handhaben und nur Tabellen nach Datentyp oder nur
eine einzige Tabelle mit allen Werten nehmen. Dadurch bräuchte ich viele
doppelte Werte nicht speichern... Vielleicht hilfts.
Bei Der CRC Berechung musste ich nur noch das XOR mit 0x0C einfügen.
Schätze mal dass sie einer Deiner beiden Berechnungen sehr ähnlich ist.
Habe meine Schwirigkeiten mit unbekannten Programmiersprachen ;-)
Mit der korrekten Prüfsumme kann man auch schnell sehen wieviele
Telegramme fehlerhaft sind. Bei mir an einem Tag teilweise bis zu 200.
Das kann aber auch an der Prozessorauslastung liegen.
Als Endgültige Version hätte ich schon gerne eine vernünftig geätzte
Platine mit Gehäuse. Eventuell sogar genau für die freien Steckplätze in
der Heizung. Vielleicht auch mit dem XPORT. Damit der "Server" nicht
neben dem Wandler stehen muss. Vielleicht könnte man ja auch zusammen
die Platine entwickeln wenn wir uns auf eine Hardware und Sendeschaltung
einigen könnten.
Gruß
Ingo
Achso... habe noch mal in Deiner WAV-Datei gesucht und soweit
festgestellt dass alle Busteilnehmer außer der Master selber immer nach
einem gesendeten Byte ein Byte Pause machen und manchmal das Telegramm
nach noch längerer Pause (etwa 15ms) weiter fortzusetzen.
Der Busmaster pustet seine Telegramme einfach ohne Wartezeiten raus.
Entweder kann die Sendestufe das nicht anders machen oder der Busmaster
oder irgendjemand anders sendet manchmal ein Echo. Gegen das Echo
spricht nur dass die Störungen vorher kommen.
> Habe ich auch festgestellt.. Satt permanent 100% und Absturz nach 2,5> Stunden habe ich jetzt nur noch durchschnittlich 80%. Das ändern der> Datenbankengine ging mit nur zwei Mausklicks.
Anbei meine Mysql Speicher-Konfiguration, evtl. bringt es noch etwas
Besserung.
> Als Endgültige Version hätte ich schon gerne eine vernünftig geätzte> Platine mit Gehäuse.
Ich auch ;-). Was hältst du von einem Hutschienengehäuse (eine Einheit)
? Da würden oben und unten etwa jeweils 5-6 Kontakte Platz haben.
> Eventuell sogar genau für die freien Steckplätze in> der Heizung. Vielleicht auch mit dem XPORT. Damit der "Server" nicht> neben dem Wandler stehen muss. Vielleicht könnte man ja auch zusammen> die Platine entwickeln wenn wir uns auf eine Hardware und Sendeschaltung> einigen könnten.
Wie breit ist der XPORT ? Dadurch das der nur eine Steckerleiste hat
wird das etwas wackelig. Kann der POE ? Die Stromversorgung braucht man
dann ja auch noch.
Für die Platine dachte ich mir einen Mega der mir den EMS-Bus auf CAN
umsetzt. Alles Mehrarbeit, aber ich will noch ein paar andere Sachen
steuern und für einen Bus habe ich nichts besseres gefunden. Ich denke
man könnte die Platine zweigleisig fahren. Einmal normales CAN Interface
mit normalen Steckverbindern und dann einen Platz für den XPORT, geht
der an die UART ? Das könnte funktionieren.
Hallo Rudi, Hallo Ingo,
wollte meine Stand sagen bzgl. der Telegramme UBA3. Mein NetIO hat beim
Empfang der UBA3 Telegramme Zeichen verloren. Somit ist auch bei mir das
Protokoll gleich. Die Checksummenberechnung habe ich auch gleich
getestet -funktioniert echt Klasse.
Gruss Matthias
Hurra!
habe doch tatsächlich den Fehler gefunden. Meine Logger läuft jetzt mit
vielleicht 10% Prozessorleistung und der Systemtakt ist auf 40%
reduziert.. Also statt 40Watt braucht das Notebook jetzt auch nur noch
geschätze 15 Watt.
Das Problem lag nicht an MySQL, sondern an meiner Programmversion hatte
irgendwo eine Zeile von einem Test nicht rausgenommen.
Es wurden also jeder decodierte und in MySQL abgespeicherter Wert
nochmals ausgelesen, decodiert und außerhalb von MySQL mitgeloggt.
Werde jetzt auch noch mal die Daten reduzieren und vermutlich auch alles
in einer Tabelle nach Datentyp abspeichern um doppelte Werte nicht
mitloggen zu müssen. Bei mir wurden bisher alle Werte die decodiert
werden konnten pro Telegramm komplett in MySQL mitgeloggt.
Rudi schrieb:> Ich auch ;-). Was hältst du von einem Hutschienengehäuse (eine Einheit)> ? Da würden oben und unten etwa jeweils 5-6 Kontakte Platz haben.
Na eigentlich doch eine gute Idee.. hoffe Du meinst ein Geäuse mit etwa
FI-Breite und nicht einer LS-Breite.
Dann könnte man eine Busplatine machen mit Steckplätzen und den
Kontaktklemmen und wenn es passt noch den ATMegaXY mit dem EMS-Bus-Teil.
ALs Steckplatz senkrecht könnte man dann die Plantine mit dem XPORT
machen und kann von oben die Ethernet-Buchse als Durchbruch ausführen.
Oder eine CAN-Platine, oder ......
Vielleicht auch nur eine Platine die man mit XPORT oder MAX232 oder
CAN-Controller bestückt werden kann.
Der XPort ist eigentlich nicht viel größer als so RJ-45-Buchse mit
Transceiver. Müsste eigentlich ziemlich stabil sein wenn man den auf der
Platine auflötet. Habe noch nie einen gehabt.
Der XPort wird eigentlich direkt an an die Pinn des Atmega gehangen und
läuft mit 3,3 Volt. Soll aber 5Volt tolerant sein. Vielleicht gibt es ja
auch eine 5Volt-Version.
Mit welcher Spannung wolltest Du den die Platine versorgen? bei 3,3 Volt
könnte man SD/MMC-Karten direkt ohne irgendwelche Pegelwandlung an den
ATmega hängen, genauso wie den XPort.
Rudi schrieb:> Mega der mir den EMS-Bus auf CAN> umsetzt. Alles Mehrarbeit, aber ...
Habe auch noch ein paar Sachen für die ich einen eigenen Hausbus
gebrauchen könnte. Bin da bisher auch bei CAN hängen geblieben. Aber
bisher noch nicht weiterverfolgt..
Gruß
Ingo
> Na eigentlich doch eine gute Idee.. hoffe Du meinst ein Geäuse mit etwa> FI-Breite und nicht einer LS-Breite.
Was ist LS ???
Die Platine würde in einer Einheit 86.5x14 sein. Hier mal ein Beispiel
von einem Sklaven in 2 Einheiten:
http://www.mikrocontroller.net/attachment/77294/can_ssr_b.pnghttp://www.mikrocontroller.net/attachment/77294/can_ssr_t.png
Die Bestückung ist in etwa 14mm Breit. Bei 2 Einheiten sind die Platinen
33mm Breit. Das wird/ist übrigens ein SSR mit CAN-Bus-Interface, z.Z.
mit Mega8 und externem EEProm und SRAM. Ich werde wohl auf den 328
wechseln, der M8 hat mir etwas zu wenig Speicher.
> Mit welcher Spannung wolltest Du den die Platine versorgen? bei 3,3 Volt> könnte man SD/MMC-Karten direkt ohne irgendwelche Pegelwandlung an den> ATmega hängen, genauso wie den XPort.
Mit 3V3, für 5V bekommt man kaum noch billige Periphery-Ics.
> Dann könnte man eine Busplatine machen mit Steckplätzen und den> Kontaktklemmen und wenn es passt noch den ATMegaXY mit dem EMS-Bus-Teil.> ALs Steckplatz senkrecht könnte man dann die Plantine mit dem XPORT> machen und kann von oben die Ethernet-Buchse als Durchbruch ausführen.> Oder eine CAN-Platine, oder ......
Die senkrechte Installation ist etwas heikel, ordentliche Steckverbinder
mit Verschraubung nehmen schon fast die komplette Platine ein.
Naja, mal schauen. Ich werde jedenfalls nicht direkt über Netz gehen,
sondern über CAN an einen Master der dann die SD-Karte hat und Netzwerk
unterstützt.
Rudi schrieb:> Was ist LS ???
Leitungsschutzschalter (Sicherung) Aber ist wohl die Größe die Du
meintest..
Rudi schrieb:> Mit 3V3,
schön...
Rudi schrieb:> SSR
Ist das jetzt die LS-Rache ;-)
Watt isn datt? Secondary Surveillance Radar (Sekundärradar) wird es wohl
nicht sein.. Schätze mal SolidStateRelais? Klingt interessant...
Rudi schrieb:> Naja, mal schauen. Ich werde jedenfalls nicht direkt über Netz gehen,> sondern über CAN an einen Master der dann die SD-Karte hat und Netzwerk> unterstützt.
Also so eine SD-Karte als Option fände ich schon ganz gut. Muss mann ja
nicht bestücken. Wenn mann noch einen Master mit ins Gehäuse stecken
könnte ware das auch ganz gut. Also dann wäre eine Steckplatzversion
schon ganz OK.
Rudi schrieb:> Die senkrechte Installation ist etwas heikel, ordentliche Steckverbinder> mit Verschraubung nehmen schon fast die komplette Platine ein.
Hat das Gehäuse denn keine Führungsnut oder ähnliches? Und wenn man so
flexible Leiterplattenverbinder nehmen würde? Ist jau auch auf der
SSR-Platine oder?
Gruß
Ingo
> Ist das jetzt die LS-Rache ;-)
Nein ;-)
> Watt isn datt? Secondary Surveillance Radar (Sekundärradar) wird es wohl> nicht sein.. Schätze mal SolidStateRelais? Klingt interessant...
Solid State Relais, ja.
> Also so eine SD-Karte als Option fände ich schon ganz gut. Muss mann ja> nicht bestücken. Wenn mann noch einen Master mit ins Gehäuse stecken> könnte ware das auch ganz gut. Also dann wäre eine Steckplatzversion> schon ganz OK.
Auf 86.5x14 ist nicht wirklich viel Platz. Ein SD-Karten-Slot mit Karte
hat etwa 17x15mm, also nicht geeignet. Mehr Speicher/Flash ist
eigentlich kein Problem, wenn es nicht grad Gigabyte sein müssen.
> Hat das Gehäuse denn keine Führungsnut oder ähnliches? Und wenn man so> flexible Leiterplattenverbinder nehmen würde? Ist jau auch auf der> SSR-Platine oder?
Der Verbinder ist für die Programmierung der CPU.
Schau dir mal die Gehäuse für Hutschiene an, dort kann man mehrere
Platinen unterbringen, z.B. die von axxatronic, die cnmb Serie.
IngoF schrieb:> Der XPort ist eigentlich nicht viel größer als so RJ-45-Buchse mit> Transceiver. Müsste eigentlich ziemlich stabil sein wenn man den auf der> Platine auflötet. Habe noch nie einen gehabt.
Ja, der XPORT sitzt bombenfest (hat zusätzlich zu den Pins auch noch 2
Lötfahnen an der Seite und 2 Kunststoffböbbel.
Abmessungen wie eine standard RJ45 Buchse mit LEDs, nur die Länge ist
anders: ca 35mm
> Der XPort wird eigentlich direkt an an die Pinn des Atmega gehangen und> läuft mit 3,3 Volt. Soll aber 5Volt tolerant sein. Vielleicht gibt es ja> auch eine 5Volt-Version.
Ja, so ist es:
Versorgung 3.3V
Datenleitungen 3.3V, 5V tolerant.
Stromaufnahme ist im Datenblatt leider nicht aufgeführt, habe aber mal
interessehalber gemessen: irgendwas zwischen 30 und 70 mA.
variiert halt je nachdem ob er daten uebertraegt, wie die leds leuchten
etc.
Gruss, Malte
Stimmt.. die Breite ist 18,25. Aber die Höhe ist inkl. Anschlüsse
16,75mm müsste also so gerade reinpassen inkl. Platine und Anschlüsse.
Hängt natürlich von der Wandstärke ab ob man 16,75mm innen hat.
Man kann ihn ja hochkant einbauen... Oder habe ich da noch irgendwas
übersehen?
Gruß
Ingo
Hi,
ich hoffe das schweift jetzt nicht zu sehr vom Thema ab, hat aber schon
etwas hiermit direkt zu tun:
In der Zwischenzeit sind mir noch ein paar zusätzliche Ideen gekommen,
so dass ich ausser des (noch ausstehenden) KM271 Nachbaus drei weitere
Meßstellen haben werde: Wärmezähler+Wasserzähler Impulsmessung und
mehrere SO-Hutschienenzähler für Energieverbrauch.
Die Stellen (Heizung, Wasserzähler, Zählerschrank) sind ca 4-10m
voneinander entfernt.
Im Prinzip will ich ja immer noch per Ethernet an die Messdaten ran,
will aber aus Kostengründen nicht an jede Einheit nen XPORT bauen.
Was haltet ihr generell von der Idee, dass ich an die AVRs TTL->RS485
Interfaces hänge und alle mittels RS485 Bus vernetze?
Am Server, der sowieso 24/7 läuft würde dann ein RS485->USB Wandler
hängen.
Gesamtlänge des Busses wären geschätzt etwa 100m.
Hat da jemand bedenken? Habe bisher noch nichts mit RS485 gemacht, aber
wenn ihr sagt das wäre kein Problem, würde ich es gerne so realisieren.
Das KM271 Board wird es dann mit 2 Schnittstellen geben (RS232 / 485).
Hatte nochmal einen Test mit dem XPORT direkt gemacht, aber jedes Mal
wenn ich den im Logamatic slot betreibe spinnen mir die analogpegel rum.
MAX232 macht hingegen keine Probleme. Scheint wohl an den höheren
Strömen zu liegen??
Gruss, Malte
@Malte Bayer
> Hat da jemand bedenken? Habe bisher noch nichts mit RS485 gemacht, aber> wenn ihr sagt das wäre kein Problem, würde ich es gerne so realisieren.
Das funktioniert, der Programmieraufwand ist aber nicht ohne für ein
funktionierendes Multisensor-System. Die RS485 ist zwar in Hardware
leicht zu realisieren, dafür steckt der Aufwand in der Software. Man
muss sich auch vorher überlegen ob man den Bus in Full- oder Half-Duplex
baut, da davon direkt die Software betroffen ist. Ich wollte den Bus
auch benutzen, aber der Softwareaufwand für OSI Layer2-Layer4 ist mir zu
hoch bzw. muss man diese Layer in Software realisieren
(http://de.wikipedia.org/wiki/OSI-Modell).
> Das KM271 Board wird es dann mit 2 Schnittstellen geben (RS232 / 485).> Hatte nochmal einen Test mit dem XPORT direkt gemacht, aber jedes Mal> wenn ich den im Logamatic slot betreibe spinnen mir die analogpegel rum.> MAX232 macht hingegen keine Probleme. Scheint wohl an den höheren> Strömen zu liegen??
Wie sieht denn deine bisherige Schaltung aus ?
Rudi schrieb:> Ich habe die CRC-Berechnung noch etwas vereinfacht:> for i in range(0,len(a)-1):> d = 0> if crc1 & 0x80:> crc1^=12> d = 1> crc1 = crc1 << 1> crc1 &= 0xfe> crc1 |= d> crc1 = crc1^int(a[i])
@Rudi
dass wäre ja super, wenn die CRC-Berechnung damit geht.
Ich habe Deine Lösung mal in Delphi übersetzt, komme aber nicht zu den
richtigen Ergebnissen. Siehst Du den Fehler?
Danke,
Mario
function Berechne_Checksumme(data: array of integer; TelLaenge:integer
): Integer;
var
crc1, crc2 : integer;
i, d : Integer;
begin
crc1 := 0;
for i:=0 to TelLaenge-4 do
begin
d := 0;
if crc1 AND $80 = 1 then
begin
crc1 := crc1 XOR 12;
d := 1;
end;
crc1 := crc1 SHL 1; //linksschieben
crc1 := crc1 AND $fe;
crc1 := crc1 OR d;
crc1 := crc1 XOR ord(data[i]);
end;
result := crc1;
end;
Mario schrieb:> for i:=0 to TelLaenge-4 do
Warum denn dass? Der Quelltext sieht eigentlich ganzgut (seoweit ich
mich noch an Delphi erinnere) Aber warum Telegrammlänge -4 sind das die
Rahmenbytes AA und 55? Dann müsste die Schleife doch von 2 bis -2
gehen..
Also bei mir hat es funtkioniert.. Schätzte mal mein JAVA-Quelltext
hilft Dir auch nicht weiter ;-)
Gruß
Ingo
@IngoF
die Rahmenbytes sind entfernt, nur das Byte für die Telegrammlänge hängt
noch an. Deshalb werden die letzten 3 Byte nicht in der CRC-Summe
berechnet.
Letztes Byte = Telegrammlänge
Vorletztes Byte = CRC HighByte
Vorvorletztes Byte = CRC LowByte
Berechnet werden soll ja der CRC von empfangenen Telegrammen, dann wird
mit dem Berechneten verglichen.
Bei manchen Telegrammen stimmt die errechnete CRC ja auch z.B.
data[0] := $08;
data[1] := $10;
data[2] := $14;
data[3] := $00;
data[4] := $0D;
data[5] := $D2;
data[6] := $F9;
data[7] := $29; //Checksumme LowByte
data[8] := $00; //Checksumme HighByte
data[9] := $09; //Telegrammlänge
TelZeiger := 10;
Bei anderen kommt 0000 raus z.B. bei
data[0] := $08;
data[1] := $00;
data[2] := $07;
data[3] := $00;
data[4] := $03;
data[5] := $03;
data[6] := $00;
data[7] := $02;
data[8] := $00;
data[9] := $00;
data[10] := $00;
data[11] := $00;
data[12] := $00;
data[13] := $00;
data[14] := $00;
data[15] := $00;
data[16] := $00;
data[17] := $37;
data[18] := $00; //Checksumme LowByte
data[19] := $13; //Checksumme HighByte
TelZeiger := 20; //Telegrammlänge
Rudi schrieb doch, dass die Berechnung mit allen Telegrammen passen
sollte.
Irgendwelche Ideen?
Meine Heizungsüberwachung läuft übrigens seit November 2009 als
Delphi-Anwendung recht stabil. Die SQL-Datenbank hat schon 650.000
Einträge, dass sind ca. 51 MByte. Die Auswertung und Anzeige erfolgt im
Browser per PHP.
Nur mal so, als positives Feedback.
bye,
Mario
> Bei manchen Telegrammen stimmt die errechnete CRC ja auch z.B.> data[0] := $08;> data[1] := $10;> data[2] := $14;> data[3] := $00;> data[4] := $0D;> data[5] := $D2;> data[6] := $F9;> data[7] := $29; //Checksumme LowByte> data[8] := $00; //Checksumme HighByte> data[9] := $09; //Telegrammlänge> TelZeiger := 10;
Da ist auch die 0x00 am Ende. Das ist das serielle Break-Zeichen und
geht nicht in die CRC-Berechnung mit ein, noch ist es Teil der CRC.
Also die Daten:
0x08 0x10 0x14 0x00 0x0d 0xd2 0xf9
die CRC
0x29
Bei deinem zweiten Bsp. stimmt etwas nicht. Die 0x13 gehört da nicht
hin. Bei diesem Bsp. sollte die CRC 0x37 sein, ich habe es jetzt nicht
nachgerechnet.
Mario schrieb:> if crc1 AND $80 = 1 then
Ganz übersehen. Eigentlich kann die Bedingung nie wahr sein... Denke das
sollte laufen:
if crc1 AND $80 = $80 then
IngoF schrieb:>> if crc1 AND $80 = 1 then>> Ganz übersehen. Eigentlich kann die Bedingung nie wahr sein... Denke das> sollte laufen:>> if crc1 AND $80 = $80 then
Danke, danke,
manchmal sieht man den Wald vor lauter Bäumen nicht.
Das war die Lösung, der Rest hat gepasst.
Hier nochmal meine Funktion mit der eingebauten Änderung, falls es
jemand braucht:
function Berechne_Checksumme(data: array of integer; TelLaenge:integer
): Integer;
var
crc1 : integer;
i, d : Integer;
begin
crc1 := 0;
for i:=0 to TelLaenge-4 do
begin
d := 0;
if crc1 AND $80 = $80 then
begin
crc1 := crc1 XOR 12;
d := 1;
end;
crc1 := crc1 SHL 1; //linksschieben
crc1 := crc1 AND $fe;
crc1 := crc1 OR d;
crc1 := crc1 XOR ord(data[i]);
end;
result := crc1;
end;
Nochmals danke,
Mario
@Rudi:
siehe http://wiki.neo-soft.org/index.php/Bild:Km271_schematic.gif
An Pin 12 habe ich uebrigens keine -24V sondern auch ein GND.
So sieht die Schaltung auf der Platine aus, funktioniert soweit ich das
beurteilen kann.
meine Pins 11+12 habe ich nicht verwendet, also ist der komplette ground
der Platine an Pin 1 angeschlossen (viel massefläche, aber das scheint
nicht das problem zu sein.
IN vom 3.3Vreg hängt direkt an +5V, der Ausgang gegen Masse mit 2
Kondensatoren (100n kerko und 10uf elko), danach gehts gleich zum xport,
dessen masse natuerlich auch mit K4/Pin1 verbunden ist.
Wenn ich nun den spannungsregler für den xport einsetze und diesen somit
mit dem rest vom KM271 verbinde, bekomme ich bei ALLEN temperaturen
falsche Werte (oft mit 12° Abweichung).
Zieht der Xport möglicherweise zuviel Strom von der 5v leitung?
Gruss, Malte
@Malte Bayer
Danke !
> Zieht der Xport möglicherweise zuviel Strom von der 5v leitung?
Das kann sein. Hast du mal den Strom gemessen ? Netzwerk sollte etwa
100mA ziehen, evtl. auch mehr. Bricht die Spannung zusammen oder kann
dein LDO evtl. zu wenig Strom liefern ?
Hast du das Problem mit den Temperaturen auch ohne Netzwerkkabel ?
Reinhard schrieb:> Hallo,> ich habe in Verbindung mit einem Buderus Service Key versucht meine> Heizung (GB-125) abzufragen.
Hallo falls Reinhard oder ein anderer Buderus-Service-Key Besitzer hier
mitliest bitte mal melden. Würde mir den gerne mal für ein paar Tage
ausleihen.
DANKE
Gruß
Ingo
Hi Rudi,
Habe an einem anderen Projekt mal den Strom vom xport gemessen, der
zieht an 5V (also vor dem 3.3v reg) ca 70-110mA je nach Laune (idle vs
Datenübertragung).
Ob die 5V Seite in der Logamatic zusammenbricht habe ich leider verpasst
zu messen, am regler liegts aber nicht, der ist überdimensioniert die 1A
Version.
Die Temperaturprobleme kommen sobald ich den Spannungsregler einstöpsle
und somit den xport mit dem Rest verbinde, egal ob Netzwerkkabel
angeschlossen ist oder nicht.
Hatte ich zuerst auch gedacht wegen Ethernet Shield = Xport Shield (der
auch auf GND der Logamatic liegt) und habe deshalb mal das Ethernet
abgestöpselt. bringt aber dieselben Fehler.
Ich warte mit dem KM217 noch ein bisschen, da ich sowieso bald noch
diverse SO-Zähler anbinden will. Irgendwie will ich das alles
miteinander verBUSen und dann auf einen gemeinsamen xport gehen (der
dann nicht auf dem km271 verbaut wird).
Habe da sowieso meine Bedenken. der xport ist zwar extended temp. range,
aber da wir im winter rohrleitungsbedingt den kessel hoch fahren wird es
in der logamatic schon recht warm drin.
Gruss, Malte
Moin.
ich habe jetzt mein erstes CAN-IO-Modul fertig. Die eigentliche
Funktionalität wird über Steckmodule realisiert, die dann auf die Ports
auf der rechten Seite geroutet werden. Auf dem Bild befindet sich ein
I2C-Steckmodul um externe Temperatursensoren auszulesen.
Für die RC30 kommt dann die entsprechende Funktionalität auf die
Steckmodule.
@IngoF
Gibt es etwas neues bei der Sendefunktionalität ?
Hallo Rudi, das sieht ja schon mal echt super aus.... Also habe auch mal
inzwischen überhaupt nachgedacht was ich so machen möchte, und da wäre
die Kommunikation über ein CAN-Modul echt klasse.
Würde Dir sofort so einen Satz abkaufen wenn das Möglich wäre...
Was ist das dort denn alles für Hardware drauf, Womit sind die
Erweiterungsstifte belegt? Wie sind die 4 Stifte auf beiden Seiten
belegt? die rechten 4 gehen vermutlich auf den Erweiterungsstecker.
links gehen zumindest zwei für den CAN-Bus raus und die anderen beiden
sind die Stromversorgung? Wie programmierst Du denn die Harware? ist der
Stecker auf der anderen Seite oder wird das über die Erweiterungsstecker
realisiert?
Wie würdest Du denn die EMS-Telegramme über den CAN-Bus übertragen? Hast
Du Dir da schon was überlegt?
Also mit der Sendefunktion muss ich gestehen dass ich mich damit aus
verschiedenen Gründen noch nicht mit beschäftigen konnte. Müsste also
noch Dein C-Programm auf Assembler umschreiben damit ich dann einen Pin
vom µC als Sendepin gebrauchen könnte.. (Also wäre die Information schon
ganz schön wie Dein Modul belegt ist.. Müsste dass dann ja nicht nochmal
neuerfinden...)
Unter anderen ist auch alle paar Tage ein Heizungsfachmann da und
tauscht wie wild alle Komponenten weil die Fehlermeldung 2L 266 von
Buderus alles andere als präzise ist. Und mit den Log habe ich auch noch
nicht viel bei dieser Störung anfangen können. Wäre ja auch zu einfach
wenn Buderus irgendwelche Daten zur Fehleranalyse über den Bus jagen
würde...
Gruß
Ingo
> Würde Dir sofort so einen Satz abkaufen wenn das Möglich wäre...
Ist noch alles Prototype, es gibt noch einige Fehler im Layout.
Theoretisch aber kein Problem.
> Was ist das dort denn alles für Hardware drauf
Ein ATMEGA328P, 23K256 SRAM/SPI, AT24C512B EEProm/I2C, MCP2551
CAN-Bus-Treiber, MCP2515 CAN-Bus-Controller, DC/DC für etwa 8-30V am
Eingang.
Die Schaltung soll dann mit 3V3 laufen.
> Womit sind die Erweiterungsstifte belegt? Wie sind die 4 Stifte auf> beiden Seiten belegt? die rechten 4 gehen vermutlich auf den> Erweiterungsstecker.
Auf der rechten Seite ist eine 4x4 Matrix die über die
Erweiterungsplatine belegt wird.
> links gehen zumindest zwei für den CAN-Bus raus und die anderen beiden> sind die Stromversorgung?
Ja, das ist die 4x Wago-Klemme die auch auf der rechten Seite passt wenn
man nur 4 oder weniger Leitungen braucht.
> Wie programmierst Du denn die Harware?
Auf der Unterseite befindet sich noch eine FFC, der dann per Kabel auf
einen Miniadapter geht und dann auf den 6-Pol AVR Programmieradapter. Im
Betrieb geht dann das Update über CAN-Bus. Deswegen auch das externe
EEProm.
> ist der Stecker auf der anderen Seite oder wird das über die> Erweiterungsstecker realisiert?
Der "kleine" Erweiterungsstecker links ist für das Frontpanel, also 4x
IO, VCC und dann für Debug noch UART.
> Wie würdest Du denn die EMS-Telegramme über den CAN-Bus übertragen? Hast> Du Dir da schon was überlegt?
Nein, das kommt dann aber später. Ich fange erstmal mit externen
Temperatursensoren an (I2C). Die Werte werde ich wohl alle einzeln
verschicken, mit Timestamp. Der CAN-Bus kann ja nur maximal 8 Bytes
Payload.
> Also mit der Sendefunktion muss ich gestehen dass ich mich damit aus> verschiedenen Gründen noch nicht mit beschäftigen konnte. Müsste also> noch Dein C-Programm auf Assembler umschreiben damit ich dann einen Pin> vom µC als Sendepin gebrauchen könnte.. (Also wäre die Information schon> ganz schön wie Dein Modul belegt ist.. Müsste dass dann ja nicht nochmal> neuerfinden...)
Ja, die Info kann ich nachreichen, ich denke ohne diesen ServiceKey wird
das erstmal nichts mit senden.
> Unter anderen ist auch alle paar Tage ein Heizungsfachmann da und> tauscht wie wild alle Komponenten weil die Fehlermeldung 2L 266 von> Buderus alles andere als präzise ist. Und mit den Log habe ich auch noch> nicht viel bei dieser Störung anfangen können. Wäre ja auch zu einfach> wenn Buderus irgendwelche Daten zur Fehleranalyse über den Bus jagen> würde...
Aha, dann soll er mal den ServiceKey für einen Tag da lassen, wenn die
den überhaupt haben.
Hallo Rudi,
die Antwort der Mail kam nicht an weil der Host nicht erreichbar ist.
Also meine Heizung läuft wieder.. es war die Pumpe.
Mein AVR Studi lies sich nicht mehr starten, updaten, deinstalllieren
oder reparieren. Hat einige Zeit gedauert bis ich mein AVR-Studio wieder
am laufen hatte. Inzwischen habe ich erfolgreich Deinen C-Code ähnlich
auf Assembler portiert.
Meine LED blinkt nur noch wenn Nutzdaten fließen. Habe eine Automatische
beatwortung der Pollings der Adress 0x21 eingebaut udn getestet. Nur
dumm dass ich Meine Schaltung dabei geschossen habe.. Werde mir das noch
mal ansehen müssen..
Ansonsten wäre ein Schaltplan Deiner Entwickling ganz interessant..
Gruß
IngoF
Hallo,
> die Antwort der Mail kam nicht an weil der Host nicht erreichbar ist.
Ja, eine alte E-Mail Adresse. Sollte wieder funktionieren.
> Also meine Heizung läuft wieder.. es war die Pumpe.
Aha, das hättest du am Druck sehen können ;-). Wenn beim Einschalten der
Druck nicht etwas hoch geht, dann ist da etwas faul. Ich sehe eine
Druckänderung auch beim Umschalten auf WW <=> HK.
> Meine LED blinkt nur noch wenn Nutzdaten fließen. Habe eine Automatische> beatwortung der Pollings der Adress 0x21 eingebaut udn getestet. Nur> dumm dass ich Meine Schaltung dabei geschossen habe.. Werde mir das noch> mal ansehen müssen..
Evtl. ist auch nur die Diode zu warm geworden und abgeraucht. Ich habe
da 3 parallel geschaltet um das Wäremeproblem zu lösen.
> Ansonsten wäre ein Schaltplan Deiner Entwickling ganz interessant..
Mal schaun, da muss ich noch aufräumen (Baustelle).
Denke die Shaltung ist doch schon ganz gut. Die Schaltung war nicht das
Problem. Hatte mich nur beim umlöten im Kabel vergriffen und deswegen
lief nichts mehr.
Nur habe ich im Moment ein Problem mit Assembler. Mit AVRStudio und
HAPSIM funktioniert die Simulation fehlerfrei. Aber auf der "echten"
Platine wird seltsamerweise immer ein zusätzliches 0x00-Byte gesendet
das eigentlich nie gesendet wird. Mit der älteren hex-Datei funktioniert
alles und habe nur keinen Quelltext mehr. Bin gerade bei der Fehlersuche
udn versuche die neue Version zurückzuentwickeln bis es wieder läuft.
Gruß
Ingo
Hallo Rudi,
Die Antwortfunktion habe ich jetzt getestet. Habe einfach alle Polling
von 0xA1 <break> mit 0x21 <Break> beantwortet und konnte in der RC30 den
Busteilnehmer "Mischer 33" im Display sehen können.
Allerdings gefällt mir die Schaltung noch garnicht. Mein Transistor
sperrt nicht richtig und zieht den Bus schon 1-2 Volt runter und der
Transistor hat etwa 70°C und die Z-Diode 90°C wenn nciht gesendet wird.
Irgendwie Schaltet der TRansistor schon teilweise bei 0,5 Volt durch.
Habe auch eine Diode davor gesetzt um die Ansprechspannung zu
reduzieren. Muss mir mal die Schaltung seperat aufbauen und durchtesten.
Eigentlich müsste der Basiswiderstand richtig berechnet sein. aber
irgendwie läuft da was schief.
Wenn der Transistor durchgeschaltet hat wird Busspannung wie gewünscht
auf 10 Volt heruntergezogen.
Die Telegramme die ich sende werden über den Bus automatisch eingelesen.
Kann dadurch erkennen dass größtenteils die Telegramme richtig
durchgehen, aber ab und zu die Adresse verfälscht wird. Als ob
irgendjemand dazwischen sendet.
Deine Mail scheint immer noch nicht zu funktionieren...
Gruß
Ingo
> Die Antwortfunktion habe ich jetzt getestet. Habe einfach alle Polling> von 0xA1 <break> mit 0x21 <Break> beantwortet und konnte in der RC30 den> Busteilnehmer "Mischer 33" im Display sehen können.
Nicht schlecht!
> Allerdings gefällt mir die Schaltung noch garnicht. Mein Transistor> sperrt nicht richtig und zieht den Bus schon 1-2 Volt runter und der> Transistor hat etwa 70°C und die Z-Diode 90°C wenn nciht gesendet wird.
Die Temperaturprobleme hatte ich nur an der Diode (jetzt sind es 3). Ich
bekomme demnächst eine 5W Diode die ich dort verbauen werde (die
Schaltung mit den Mosfet).
> Die Telegramme die ich sende werden über den Bus automatisch eingelesen.> Kann dadurch erkennen dass größtenteils die Telegramme richtig> durchgehen, aber ab und zu die Adresse verfälscht wird. Als ob> irgendjemand dazwischen sendet.
Das habe ich auch gesehen, siehe
Beitrag "Re: Logamatic 2107 Schnittstelle". Ich bin mir nicht
sicher ob die Sendeschaltung so richtig ist, denn auf der RC3X Platine
kann ich kein Bauteil finden das annähernd 1.5W verträgt.
Der Bus vom Klinkenstecker (BC10) ist direkt mit dem internen Bus
verbunden, also keine Schutzschaltung etc.. Die Schutzbeschaltung muss
dann unbedingt mit in die externe Schaltung.
> Deine Mail scheint immer noch nicht zu funktionieren...
Doch, die funktioniert jetzt.
Hallo Rudi,
das Problem mit der Sendeschaltung habe ich gelöst. War nur so blöd dass
ich Emitter und Collector vertauscht hatte. Ein Wunder dass die
Sendeschaltung überhaupt lief.
Die Z-Diode und Transistor werden jetzt wie erwartet garnicht mehr warm.
Wenn ich jetzt immer permanent die das Polling der Adress 33(0x21) mit
0x21 <brk> beantwort erscheint auch die Adresse im RC30 Bus-Status.
Die Adresse erscheint nach dem ersten Polling welches etwa alle 20-30
Sekunden widerholt wird. Sobald die erste Antwort kommt wird die 0x21
auch wie die anderen Busteilnehmer mehrmals gepollt.
Die RC30 versucht dann widerholt ein Kommando ohne Polling-Bit an die
0x21 zu schicken und erwartet vermutlich dass irgendwann die 0x21 auch
irgendwann mal ein Pieps sagt. Sonst kann ich mir nicht erklären warum
der wie bekloppt immer das selbe Telegramm an die 0x21 schickt.
Nur was mir nicht so ganz gefällt ist dass Byte UBA3/MC10 (0x08) oder
von der BC10 (0x09) immer widerholt wird.
Vermute mal ganz ohne Oskar kommt man da nicht weiter. Irgendwie muss
sich ja die Signalform der RC30 und meiner Sendeschaltung unterscheiden.
Jetzt wäre es mal ganz interessant von einem Service-Key-Besitzer zu
wissen mit welcher Adresse sich der Service-Key anmeldet.
hier jetzt mal ein kurzer Mitschnitt vom Bus:
> Die RC30 versucht dann widerholt ein Kommando ohne Polling-Bit an die> 0x21 zu schicken und erwartet vermutlich dass irgendwann die 0x21 auch> irgendwann mal ein Pieps sagt. Sonst kann ich mir nicht erklären warum> der wie bekloppt immer das selbe Telegramm an die 0x21 schickt.> {1A} 16:20:32 15.07.10: 10 21 AC 00 00 00 00 1A
Ich geh mal davon aus, das die 0x10 den Befehl absetzt. Es gibt eine
Nachricht die in etwa so aussieht. Dort ändert sich ab und zu nur ein
Bit, frag mich jetzt nicht welche ... :-/
Von Mario kam weiter oben noch diese Nachricht:
> 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
Hallo Mario, hast du noch ein paar Telegramme von Adresse 0x21 ???????
Mal schaun ;-)
Mathias K. schrieb:> Das habe ich auch gesehen, siehe> Beitrag "Re: Logamatic 2107 Schnittstelle".
Hallo Rudi,
das hatte ich ja damals auch an Deinen Oszillogrammen gesehen das dort
manchmal ein Byte widerholt wurde.
> Ich bin mir nicht sicher ob die Sendeschaltung so richtig ist,> denn auf der RC3X Platine kann ich kein Bauteil finden das> annähernd 1.5W verträgt.
Sieht so aus als ob Buderus das egal ist. Die MC10 ist da etwas
radikaler mit dem Bus. Der Transistor T1 hängt direkt am Bus und spielt
"regelbarer Kurzschluß".
Wenn T2 durch TX-Pin=0 sperrt liegt die Basis von T1 über 4,7 kOhm auf
+5V. Wenn mann mal 1 Volt für UBE abzieht fließen hier 0,85mA in die
Basis bei einem hfe von 200 bis 450 müssten dann etwa 170 bis 390mA
durch den armen Kerl gejagt werden. Laut Datenblatt liegt Ptot bei
200mW.
Wenn man jetzt mal den schlimmsten Fall annimmt liegen kurzzeitig 3,9W
an dem T1.
Da er aber wohl nur kurz angesteuert wird und längere Ruhepausen hat
wird der wohl noch überleben ohne gleich zu "verdampfen".
Also bevor ich meinen Collector/Emitter vertauscher bemerkt habe wurde
kein einziges Byte widerholt. Es kam nur mal vor dass manchmal ein Byte
nicht richtig gesendet wurde.
Nach der Korrektur des Fehlers wurde permanent die 0x21 widerholt.
Bei Deinen Oszillogrammen wurde teilweise was widerholt.
Deswegen vermute ich dass man den Bus garnicht soooo stark belasten muss
und auf 10 Volt herunterziehen muss. Werde das mal testen indem ich noch
ein paar Dioden dazwischen hänge...
Gruß
Ingo
Habe es noch mal getestet und scheint wirklich so zu sein. Habe noch
zwei 1N4148 dazwischen geschaltet und es lief ganz ohne irgendwelche
Echos.
Bei meiner Version habe ich alse 4x1N4148 und eine 8,2Volt Z-Diode inkl.
Transistor (im Moment BCP68). Wenn ich zwei 1N4148 weglasse kommen immer
Echos.
Gruß
Ingo
Rudi schrieb:> Also etwa 12V ? Versuch doch mal die 12V zu schalten und nicht GND !?
Habe noch nicht nachmessen können wieviel Volt es wirklich sind. Müssten
aber geschätzte 12 Volt sein.
Gegen 12 Volt kann ich nicht schalten weil ich nicht an der
Service-Buchse hänge sondern parallel zur RC30 im Wohnzimmer. Vielleicht
würde es ja auch mit drei Dioden laufen. Habe ich aber (noch) nicht
getestet.
Das wäre vielleicht eine Erklärung warum der T1 nicht abraucht weil nur
gegen 12 Volt geschaltet wird... Allerdings soll die RC30 doch den Pegel
auch auf 10 Volt herunterziehen? Oder war da noch irgendein Offset am
Oskar eingestellt?
Gruß
Ingo
> Das wäre vielleicht eine Erklärung warum der T1 nicht abraucht weil nur> gegen 12 Volt geschaltet wird... Allerdings soll die RC30 doch den Pegel> auch auf 10 Volt herunterziehen? Oder war da noch irgendein Offset am> Oskar eingestellt?
Nein, da war kein Offset. Das Signal liegt bei 12V +-2.5V. Evtl. springt
dein Komparator nicht mehr an und du siehst aus diesem Grund kein Echo
bzw. dein eigenes Signal?
Rudi schrieb:> bzw. dein eigenes Signal?
Verdammt.. habe ich nicht dran gedacht.. Nur ohne Oskar werde ich das
wohl nie feststellen können ob ich mein Telegramm nicht mehr sehe oder
das Echo.
Der komperator liegt ja rechnerisch genau in dem Bereich...
Gruß
Ingo
Hallo,
ich habe mal ein wenig mit meinem Master gespielt, der mir die Daten in
quasi Realtime visualisieren soll. Anbei ein paar Bilder mit dem
Flot-Renderer im Browser. Ganz nett das Teil, muss man ja mal sagen.
Grüße.
Hi Rudi,
Jepp das flot taugt schon was, hab das in meinem
Stromzaehler-Visualisierungs-Projekt drin.
Habe das Hardwarelayout nochmal überarbeitet für den KM271 Clone.
Also den analogpart schön zusammengepfercht, kurze Leiterbahnen und ohne
grosse Massefläche.
Dann den Xport mit Spannungsregler getrennt auf der anderen Seite.
RX/TX sind ueber Jumper verbunden, zum Test habe ich die beiden Pins
erstmal getrennt.
Eben getestet und ich könnte kotzen.
Zunächst waren die angezeigten Temperaturen mit am Ethernet
angeschlossenen xport "nur" um -3°C verfälscht.
"schön" dachte ich und bin ne weile neben dran gestanden.
Nach etwa einer Minute der Supergau:
* Kesseltemperatur von 58° auf 22° gefallen
* Warmwasser von 49° auf 16°
* Aussentemperatur von 22° auf 16° (die stimmt eh nicht immer, da das
Sensorgehäuse manchmal "besonnt" wird
So langsam habe ich das gefühl als ob die 80-120 mA vom xport zuviel für
die logamatic sind. Spannungseinbruch mit/ohne xport ist nur ca 50 mV.
An der Ethernet-Masseverbindung kann es nicht liegen (unshielded rj45
connector)
Falls jemand noch eine Idee hat, her damit, ansonsten werde ich
demnaechst viel Kaffee kochen und die verbindung zwischen xport und
logamatic per optokoppler trennen und dem xport eine eigene
spannungsversorgung verpassen.
Gruss, Malte
Hallo,
> Jepp das flot taugt schon was, hab das in meinem> Stromzaehler-Visualisierungs-Projekt drin.
Wie greifst du den Zähler ab ? Optisch ? Selbst gebaut ? Ich habe meinen
CAN-Bus am Zähler vorbei gezogen, mir fehlt da eigentlich nur die
richtige Optik.
> Falls jemand noch eine Idee hat, her damit, ansonsten werde ich> demnaechst viel Kaffee kochen und die verbindung zwischen xport und> logamatic per optokoppler trennen und dem xport eine eigene> spannungsversorgung verpassen.
Hast du das schon probiert ? Was passiert wenn du einen 42 Ohm / 1W
Widerstand, anstatt des X-Ports als Verbraucher benutzt ?
Optokoppler sind bei Heizungen immer eine gute Idee. In der KM271
benutze ich den ILD213T für 38400 Baud.
Grüße.
Hi,
> Wie greifst du den Zähler ab ? Optisch ? Selbst gebaut ? Ich habe meinen> CAN-Bus am Zähler vorbei gezogen, mir fehlt da eigentlich nur die> richtige Optik.
Ich habe hinter die Abrechnungszaehler diese Hutschienenzaehler mit SO
Impulsausgang montiert. Also digitale Impulszählung.
Rumgebastle mit Optokoppler zum Erfassen des "zählerrades" war mir zu
blöd. vor allem weil ich mich auf die werte verlassen will die da
gezaehlt werden ;)
> Hast du das schon probiert ? Was passiert wenn du einen 42 Ohm / 1W> Widerstand, anstatt des X-Ports als Verbraucher benutzt ?
nein, probiert hab ichs noch nicht. Ich wollte heute noch probieren was
passiert wenn ich dem xport ne externe spannungsversorgung gebe und nur
GND, RX/TX zur logamatic verbinde.
Das mit dem Widerstand als Last probier ich dann gleich mit...
wenns dann immer noch nicht haut trenne ich das ganze galvanisch.
> Optokoppler sind bei Heizungen immer eine gute Idee. In der KM271> benutze ich den ILD213T für 38400 Baud.
hab hier noch cny75, ltv 845 und ilq1 rumfliegen. einer davon wird wohl
für die 2400 baud taugen.
Gruss, Malte
Hallo,
habe inzwischen ein paar Omis die Handtaschen geklaut und mir inzwischen
ein DigitalOszilloskop gekauft und werde mal sehen wass denn so meine
Sendeschaltung mit dem Bus uberhäupt veranstaltet.
Malte Bayer schrieb:>> Wie greifst du den Zähler ab ? Optisch ? Selbst gebaut ? Ich habe meinen>> CAN-Bus am Zähler vorbei gezogen, mir fehlt da eigentlich nur die>> richtige Optik.> Ich habe hinter die Abrechnungszaehler diese Hutschienenzaehler mit SO> Impulsausgang montiert. Also digitale Impulszählung.
@Rudi
hatte irgendwie im Hinterkopf dass Du schon Deinen Stromzähler in deine
Kurven integriert hattest. Aber das war wohl der Gaszähler.
Wie hast Du die denn die Werte vom Gaszähler bekommen? Was
selbstgebautes? Oder vom Gasversorger schon was eltronisches bekommen?
Gibt es sowas denn in elektronisch?
Also bei Die Idee mit dem Stromzähler hinter dem Abrechnungszähler
gefällt mir schon ganz gut....
@Malte
Die Umwandlung des SO-Impulsausgang in Zählerwerte hast Du dann bestimmt
mit einer Eigenentwicklung realisiert, oder wie machst Du das?
Hatte auch mal überlegt den Stromversorger zu wechseln und mir einen
eletktronischen Stromzähler einbauen zu lassen. Allerdings hätten dann
die Mehrkosten für den elektronischen Zähler die Ersparnise vom Wechsel
wieder aufgefressen. Die Werte würde man dan über Google bekommen.
Allerdings war mir nicht so wohl dabei Google meine Stromzählerwerte zu
überlassen.....
Gruß
Ingo
Hi Ingo,
naja, das device von mir zaehlt einfach auf (momentan 8) kanaelen die
impulse.
ein daemon am server pollt diese zaehlerstaende alle 60 sek, beim pollen
werden diese dann auf 0 zurueckgesetzt.
Nachher in der Auswertung sehe ich so relativ genau über den tag
(woche/monat/jahr/whatever) den verbrauch als kurve.
Berechnung in "ca Watt" habe ich so realisiert:
#define FLUX_RESOLUTION><------>800<---><------>// SO Counter resolution
#define FLUX_LIVE_DELTA><------>60<----><------>// seconds interval for
calculating the live value
#define FLUX_LIVE_FACTOR<------>(1000UL * 3600UL / (FLUX_LIVE_DELTA) /
(FLUX_RESOLUTION))
Berechnung des relativen Last (über zb 60 sekunden gemessen) wäre dann:
P = 60_SEC_TICK_COUNT * FLUX_LIVE_FACTOR
Um den Zählerwert auszurechnen braucht man lediglich alle gezaehlten
ticks durch die Resolution teilen.
Idr. haben die Zähler 800/1000/2000 Ticks pro KWh
Gruss, Malte
@Ingo
> hatte irgendwie im Hinterkopf dass Du schon Deinen Stromzähler in deine> Kurven integriert hattest. Aber das war wohl der Gaszähler.> Wie hast Du die denn die Werte vom Gaszähler bekommen? Was> selbstgebautes? Oder vom Gasversorger schon was eltronisches bekommen?> Gibt es sowas denn in elektronisch?
Selbst gebaut. Die haben einen Magneten im Gehäuse und ich messe den
über einen Hal-Sensor, also auch wieder Impulse pro Umdrehung.
@Malte
Wieviel hast du denn in einen Stromzähler investiert ? Ich habe den
bisher billigsten (30€) hier gefunden:
http://www.energie-zaehler.com/epages/61422236.sf//de_DE/?ObjectPath=/Shops/61422236/Products/kwh-meter
Im Vergleich zu einem Selbstbau, ich bräuchte 4, noch im Preisrahmen.
Hallo
da ich selber Entwickler bin und und solche auch unterstützen möchte,
biete ich bei einer Bestellung der oben genannten Zähler, mit Angabe
"Logamatic 2107 Schnittstelle" im Bestelltext einen Rabat von 10%. Ich
hoffe das diese Information nicht gegen die Forum-Regeln verstößt.
Grüße
JoS0
Johann Stark schrieb:> biete ich bei einer Bestellung der oben genannten Zähler, mit Angabe> "Logamatic 2107 Schnittstelle" im Bestelltext einen Rabat von 10%.
Das Gilt vermutlich nicht für diesen den Drehstromzähler, oder?
http://www.energie-zaehler.com/epages/61422236.sf//de_DE/?ObjectPath=/Shops/61422236/Products/EEM34DLCRudi schrieb:> Selbst gebaut. Die haben einen Magneten im Gehäuse und ich messe den> über einen Hal-Sensor, also auch wieder Impulse pro Umdrehung.
Habe mich mal gerade Schlau gemacht und einen Reedkontakt genau für
meinen Gaszähler gefunden:
http://www.pipersberg.de/Gaszahler/RF1-Impulsnehmer.pdf
Habe die gerade mal angemailt. Was soll ich da selber ein Reed-Relais
reinbasteln wenn es schon was fertiges gibt. (Wenn der nicht zu teuer
ist)
Habe inzwischen etwas an meiner Sendeschaltung herumgebastelt und
versucht mein Signal soweit wie möglich an dem Sendesignal der anderen
Busteilnehmer anzupassen. Seltsamerweise werden aber immer die Bytes
widerholt. Na vielleicht wird die Sendeschaltung doch erst noch mal
vertagt.
Gruß
Ingo
Hallo
die Schell Count Zähler sind im Moment nicht lieferbar, aber die Saia
Burgess Zähler sind baugleich, bis auf den Wechselstrom/32 A der 2000
Imp/kWh hat.
Die anderen haben alle 1000 Imp./kwh.
Aber grundsätzlich, wenn es um dieses Projekt geht bitte um Anfrage und
ich sehe was ich tun kann. Wir sind mehr als nur ein Onlineshop.
Der zuletzt gennante Zähler ist ein Wechselstromzähler!
Grüße
J0S0
@IngoF
> Habe mich mal gerade Schlau gemacht und einen Reedkontakt genau für> meinen Gaszähler gefunden:> http://www.pipersberg.de/Gaszahler/RF1-Impulsnehmer.pdf> Habe die gerade mal angemailt. Was soll ich da selber ein Reed-Relais> reinbasteln wenn es schon was fertiges gibt. (Wenn der nicht zu teuer> ist)
Ich habe mir eine schmale Platine gebaut, mit einem digitalen HAL-Sensor
und 2 passiven Bauteilen. Das geht relativ einfach, passt auch bei
unterschiedlichen Zählern und läuft direkt mit 3V3. Mehr als 15€ würde
ich für einen fertigen mit Gehäuse und OpenDrain-Ausgang nicht bezahlen.
> Habe inzwischen etwas an meiner Sendeschaltung herumgebastelt und> versucht mein Signal soweit wie möglich an dem Sendesignal der anderen> Busteilnehmer anzupassen. Seltsamerweise werden aber immer die Bytes> widerholt. Na vielleicht wird die Sendeschaltung doch erst noch mal> vertagt.
Das gleiche Problem habe ich hier auch ...
Ich schreib grad einen Parser für die Nachrichten in C um die Werte auf
dem CAN-Bus zu haben. Anbei noch ein paar Erkenntnisse zu den
Nachrichten (Vervollständigung erwünscht):
Hi Rudi,
> Wieviel hast du denn in einen Stromzähler investiert ? Ich habe den> bisher billigsten (30€) hier gefunden:> http://www.energie-zaehler.com/epages/61422236.sf//de_DE/?ObjectPath=/Shops/61422236/Products/kwh-meter>> Im Vergleich zu einem Selbstbau, ich bräuchte 4, noch im Preisrahmen.
Bei mir waren es 8x 17€.
Allerdings wahrscheinlich nicht direkt mit dem von dir gefundenen Zähler
vergleichbar:
Meine verbauten Zähler sind 10A Typen,
http://www.top-messtechnik.com/jtlshop/index.php?a=475
Das Angebot von Johann Stark für die 25A Version -10% finde ich auch
interessant, wären dann +10€ für +15A ;)
Die Adresse werde ich mir auf jeden Fall merken für die nächste grössere
Bestellung (Rechnungszahlung und grössere Produktpalette in diesem
Bereich) :)
PS: um mal wieder komplett zum Thema zurück zu kommen:
Das Netzteil der Logamatic scheine ich nicht zu überlasten. Habe mal mit
einem Widerstand anstatt 3.3vreg+xport gespielt -> alles scheint
korrekt.
Entweder der Spannungsregler oder der xport ziehen mir die Masse hoch.
Ich tippe wohl eher auf den Spannungsregler.
Also, externes Netzteil ist der nächste Test...
Gruss, Malte
@Malte Bayer
> PS: um mal wieder komplett zum Thema zurück zu kommen:> Das Netzteil der Logamatic scheine ich nicht zu überlasten. Habe mal mit> einem Widerstand anstatt 3.3vreg+xport gespielt -> alles scheint> korrekt.> Entweder der Spannungsregler oder der xport ziehen mir die Masse hoch.> Ich tippe wohl eher auf den Spannungsregler.
Welchen Regler benutzt du ?
Anbei die Analog-Schaltung die ich aus den Bildern sehe. Die KL1 Nummern
stimmen nicht mit deinen überein. Mein S1 ist der linke Kontakt auf der
Oberseite und S2 auf der Unterseite usw..
@Malte Bayer
Ich seh grad die ist identisch zu deiner Schaltung. Der analoge Teil ist
also komplett unabhängig vom digitalen Teil. Du solltest die beiden
Teile auch unabhängig in Betrieb nehmen können.
Rudi schrieb:> Ich schreib grad einen Parser für die Nachrichten in C um die Werte auf> dem CAN-Bus zu haben.
Wie willst Du denn die Werte im CAN Bus übertragen? Der Zeitstempel muss
ja nicht mitgesendet werden. Reicht doch wenn man beim schreiben in die
Datenbank die aktuelle Zeit nimmt.
In meiner SQL-Datenbank habe ich nur zwei Tabellen einmal mit Tiny und
SmallInt. Darin wird nur der Zeitstempel, der Wert und eine ID
gespeichert.
Die Umrechnung passiert im Moment noch in meinem Programm. Wollte mir
eventuell noch eine Tabelle basteln in der ich dann zu jeder Werte-ID
die Berechnung und weitere Informationen wie Bemerkungen u.s.w
speichere.
Man könnte doch einfach in einem Telegramm mehrere Werte übermitteln die
sich geändert haben. Ungeänderte Werte werden natürlich nur gesendet
wenn sie sich nach einer Virtelstunde immer noch nicht geändert haben
sollten.
Also Einfach im CAN-Telegramm als erstes die Werte-ID und dann den Wert.
Vielleicht könnte man ja eine gemeinsame Werte-ID-Tabelle erstellen.
Dann könnte man einfach in einer Tabelle die Werte sammeln und neue
ergänzen wenn man neue Werte gefunden hat.
Hier mal ein Beispiel der ersten Daten deines Beispieltelegrammes:
1
ID Quelle Ziel Telegrammtyp Start Bit Bytes Divisor Linie Bemerkung
2
01 08 00 34 4 0 1 1 1 SollTemperatur
3
02 08 00 34 5 0 2 10 1 Warmwasser Temperatur
4
03 08 00 34 7 0 2 10 1 Warmwasser Temperatur #2
5
04 08 00 34 9 1 1 0 2 Tag/Nachtbetrieb
6
05 08 00 34 9 4 1 0 2 Heizen
7
06 08 00 34 9 6 1 0 2 Betriebsart
Oder was haltet Ihr davon? Denke das ist eine relativ einfache
Darstellungsform. Gut ohne viel Aufwand zu dokumentieren, oder?
Die Tabelle dürfte selbsterklärend sein und für so ziemlich aller Werte
verwendbar sein.
@Rudi?
Also der Impulgeber für meine Gasuhr soll inkl. Versand 34 Euro kosten.
Überlege ob ich mir den doch bestelle. Habe heute mal mit einem simplen
Reed-Kontakt versucht irgendein ergebnis zu bekommen. Allerdings scheint
das Magnetfeld dafür zu schwach zu sein? Was hast Du denn für einen
Hall-Sensor genommen? Gibt ja massenhaft Type von 1€ bis 40€ mit
verschiedenen Ausgängen.
> Wie willst Du denn die Werte im CAN Bus übertragen? Der Zeitstempel muss> ja nicht mitgesendet werden. Reicht doch wenn man beim schreiben in die> Datenbank die aktuelle Zeit nimmt.
Die ID wird im CAN-Header übertragen. Im Payload steht die Zeit und der
eigentliche Wert. Die Zeit ist mir eigentlich sehr wichtig. Falls
Buskollisionen auftreten kommen die Nachrichten nicht direkt an, sondern
zeitversetzt. Für diesen Fall werden die zu sendenden Daten im externen
SRAM gehalten und später gesendet. Für den Gaszähler (Impulsgeber) z.B.
wichtig, für Temperaturen nicht unbedingt nötig.
> Man könnte doch einfach in einem Telegramm mehrere Werte übermitteln die> sich geändert haben. Ungeänderte Werte werden natürlich nur gesendet> wenn sie sich nach einer Virtelstunde immer noch nicht geändert haben> sollten.
Wenn du mehrere Werte überträgst, sendest du zwangsläufig auch Werte die
sich nicht geändert haben. Du hast nur eine 24Bit ID und dann 8 Bytes
Payload. Ich habe die ID etwas verkleinert und benutze die freien Bits
als Kontrollbits. Dadurch kann ich die eigentlichen Daten, Befehle auf
die Daten (Offset, Skalierung etc. für einen Temperatursensor mit einer
bestimmten ID), einfache Befehle an eine CAN-Bus Modul verschicken und
mir jede Nachricht optional bestätigen lassen (ACK).
Ich kann über den Bus die einzelnen Module Parametrisieren und mit einer
neuen Firmware bespielen und ich kann alle Sensoren an so einem Modul
parametrisieren.
> Also der Impulgeber für meine Gasuhr soll inkl. Versand 34 Euro kosten.> Überlege ob ich mir den doch bestelle. Habe heute mal mit einem simplen> Reed-Kontakt versucht irgendein ergebnis zu bekommen. Allerdings scheint> das Magnetfeld dafür zu schwach zu sein? Was hast Du denn für einen> Hall-Sensor genommen? Gibt ja massenhaft Type von 1€ bis 40€ mit> verschiedenen Ausgängen.
34€ ist doch schon was ;-). Ich benutze den AN48820a. Ich kann dir in
etwa 2 Wochen meinen alten Sensor geben. Ich habe mir neue Platinen
gebaut, aber noch nicht bestückt.
> Oder was haltet Ihr davon? Denke das ist eine relativ einfache> Darstellungsform. Gut ohne viel Aufwand zu dokumentieren, oder?> Die Tabelle dürfte selbsterklärend sein und für so ziemlich aller Werte> verwendbar sein.
Sieht doch gut aus. Was bedeutet Linie ? Divisor würde ich Skalierung
nennen.
Rudi schrieb:> Wenn du mehrere Werte überträgst, sendest du zwangsläufig auch Werte die> sich nicht geändert haben.
Nicht wie ich das meinte. wenn mann z.B. 6Byte Payload hätte könnte man
zwei zweiByte Werte (Temperatur z.B.) übertragen mit der dazugehörigen
ID senden.
Wenn sich zwei Werte geändert haben werden mehrere gesendet. Kann ja
sein dass sich in einem Telegramm mehrere Werte geändert haben.
Aber wenn Du ja bei den Zeitstempel mitsendest wird es schon knapp mit
den 8 Byte Payload.
Rudi schrieb:> Ich kann dir in> etwa 2 Wochen meinen alten Sensor geben. Ich habe mir neue Platinen> gebaut, aber noch nicht bestückt.
musst mir dann mal sagen was Du dafür bekommst. Würde ich glatt
zuschlagen.
Rudi schrieb:> Sieht doch gut aus. Was bedeutet Linie ? Divisor würde ich Skalierung> nennen.
Das ist die Verbindungsart zwischen den Punkten. Bei Temperaturen ändert
sich ja die Temperatur mehr oder weniger gleichmaßig und ändert sich
nicht Stufenförmig.
Bei gesetzten Werten wie die aktuelle Leistung oder Binären Werten
ändert sich der Zustand ja Sprungartig. Also wird dort erst mal die
Linie mit dem alten Wert gezeichnet und dann eine Linie nach oben oder
unten.
Rudi schrieb:> Du hast nur eine 24Bit ID
Nein, im Moment habe ich nur eine 8Bit-ID. (erste Spalte) Bisher gibt es
ja nur knapp über 20 auswertbare Werte der Heizung. Könnte vielleicht
auf die Dauer etwas zu klein sein wenn noch andere Sensoren/Aktoren
dazukommen
Gruß
Ingo
Hallo
Soory für die "Zwischenrufe", Stromzähler und so interessieren mich
auch.
Frage:
>Habe das Hardwarelayout nochmal überarbeitet für den KM271 Clone.
Ich hätte interesse für eine KM271 oder einen Clone.
Gibt es diesen irgendwo zu beziehen odern einen Plan ?
(Der einigermassen zu dem Ergebnis führt)
Frage: Hat das "interne" Protokoll etwas mit dem E-Bus zu tun ?
Gruss Karl
Huhu...
Das zusammengefasste Zeug dazu ist hier:
http://wiki.neo-soft.org/index.php/Heizungsschnittstelle/Logamatic2107/K4
Die Platine "Rev. C" funktioniert soweit, wenn man den kompletten
Spannungsregler- und XPORT Teil nicht bestückt.
RS232 funktioniert komischerweise.
Schaltplan auf der Wikipage ist an sich auch okay (auf dem basiert das
layout)
Beziehen kann man das ding nicht (also von mir zumindest nicht)...
Gruss, Malte
Rudi schrieb:> Die Zeit ist mir eigentlich sehr wichtig. Falls> Buskollisionen auftreten kommen die Nachrichten nicht direkt an, sondern> zeitversetzt. Für diesen Fall werden die zu sendenden Daten im externen> SRAM gehalten und später gesendet. Für den Gaszähler (Impulsgeber) z.B.> wichtig, für Temperaturen nicht unbedingt nötig.
Also sooo lange wird es keine Buskollisionen geben, es sei denn der Bus
wird mit langeren Firmwareuploads vollgepumpt.
Für den Gas-/Stromzähler wollte ich die "intelligenz" in den SO-Bus
Controller hängen der über den CAN-Bus angebunden ist. Er soll die
Impulse zählen die in einer Minute eingegangen sind und dann daraus die
richtigen Werte Berechnen. Entweder aus den Impulsabständen und/oder der
Impulsanzahl innerhalb einer Minute.
Aber ich kann erst sagen wenn ich richtige Signale vom Gas/Stromzähler
bekomme ob das so geht.
Mein Gaszähler gibt nur alle 0,1m³ ein Impuls. Wenn ich allerdings die
"Spiegelfläche" auf der letzten Nachkommastelle auswerte würde ich alle
0,01m³ ein Impuls bekommen.
Wieviel Impulse hast Du denn pro m³ Gas?
Gruß
Ingo
> musst mir dann mal sagen was Du dafür bekommst. Würde ich glatt> zuschlagen.
Die Versandkosten von 2€. Würde es dann als Großbrief verschicken, dann
muss ich nicht die Kabelage ablöten.
> Für den Gas-/Stromzähler wollte ich die "intelligenz" in den SO-Bus> Controller hängen der über den CAN-Bus angebunden ist. Er soll die> Impulse zählen die in einer Minute eingegangen sind und dann daraus die> richtigen Werte Berechnen. Entweder aus den Impulsabständen und/oder der> Impulsanzahl innerhalb einer Minute.
Ich speicher z.Z. die Impulse pro Minute. Der Zähler ist relativ
gemütlich, auch im Winter, und wenn ich mich recht erinnere hatte ich
kaum Werte über 10 gesehen.
> Mein Gaszähler gibt nur alle 0,1m³ ein Impuls. Wenn ich allerdings die> "Spiegelfläche" auf der letzten Nachkommastelle auswerte würde ich alle> 0,01m³ ein Impuls bekommen.>> Wieviel Impulse hast Du denn pro m³ Gas?
Ich habe an dem Gaszähler alle 0.01m³ einen Impuls. Die Auflösung der
mechanischen Anzeige beträgt 0.001m³.
@Rudi: So mache ich es auch, nur eben dass das ganze dann per Ethernet
im Minutentakt gepollt wird.
Bei den Stromzaehlern ist es auch nicht viel anders: Grundlast auf der
Phase wo der ganze Serverkram bei mir draufhängt sind auch gemütliche
10-12 Impulse pro Minute (1k / KWh)...
Habe gerade eine andere Baustelle, Stromverbrauchsermittlung zentral an
der Einspeisung. Die muss ich allerdings optisch machen, da dort 3x 150A
Shunts mit extra Messwandler verbaut sind.
Zum glück habe ich am Messwandler 2 rote LEDs für Wirkleistung und
Blindleistung, beide mit 333,33 Imp/KWh (was für ne krumme Zahl ;).
Die Erfassung mittels Phototransistor/100k Widerstand funktioniert
problemlos.
Ein weiterer Zähler für PV Einspeisung hat 2 grüne LEDs, eine mit 1k Imp
und eine mit 10k Imp.
Hierbei habe ich noch mit dem Wellenlängenbereich des Phototransistors
zu kämpfen. grün liegt halt arg an der Grenze ;)
Laborversuch mit 600k Widerstand anstatt 100k hat schon brauchbare
Ergebnisse geliefert, allerdings darf es dann so gut wie kein
"Fremdlicht" geben :->
BTW: sollten wir diesen Thread hier mal mit einem Fortsetzungsthread
beenden? für meine Begriffe ist hier mittlerweile ganz schön viel
Lesestoff angesammelt...
Achja. Ich habe im Wiki den Ansatz mit dem "ServiceKey" Interface nur zu
anfangs versucht zu dokumentieren, irgendwann bin ich bei dem Thema
geistig ausgestiegen, wäre nett wenn sich jemand daran vergnügen könnte
:)
Gruss, Malte
@IngoF
Bzgl. Impulsmessung von Gasuhr. Habe bei mir einen Actaris G4 RF1
verbaut. Ein normaler Reed-Kontakt tut. Allerdings keiner mit Gehäuse
sondern ich musste das Glasrohr ganz hinten am Anschlag befestigen(bzw.
hab vom Gehäuse den Deckel weg gemacht damit das Röhrchen direkt
aufliegt). Es schaltet bei mir die vorletzte Ziffer wenn die 7 am
Zählerfester sichtbar ist (die Mitte des Glasrörchens liegt bei mir also
etwa zwischen der letzten und vorletzten Ziffer)
Nur zur Info...
Gruss Matthias
Hallo Matthias,
Matthias schrieb:> Habe bei mir einen Actaris G4 RF1 verbaut.
Ich habe das selbe Modell. Bei mir steht allerdings Schlumberger drauf.
Der Zähler von Pipersberg hat auch das Schlumberglogo. Auf dem
Impulsnehmer den ich kaufen wollte steht allerdings auch Actaris daruf.
Scheint also alles das selbe zu sein.
Matthias schrieb:> Ein normaler Reed-Kontakt tut.
Habe von Conrad den billigsten und kleinsten Reedkontakt genommen
(503770). Der zieht bei 15-35 AW an. Vermutlich ist der dann zu
unempfindlich oder ich habe nicht genau die Position genau erwischt.
Hatte auf der letzen und vorletzten stelle eigentlich alle Positionen
ausprobiert. Aber zwischen den Zahlen hatte ich es noch nicht versucht.
Laut dem gelinkten Impulsnehmer-PDF kann man gut sehen dass man das
beste Ergebnis hat wenn man ganz hinten in der unteren Ecke den Kontakt
anbringt.
Habe aber das selbe Problem wie Du. Eben dass der Magnet in der
vorletzten Zahl eingebaut ist. Auf dem Anzeigefeld steht auch 0,1Imp/m³
Also wird man genauere Ergebnisse nur mit der optischen Abtastung der
letzten Stelle bekommen.
Der Impulsnehmer gibt es für drei verschiedene Ziffern der Gasuhr. Also
fü 1m³, 0,1m³ und 0,01m³. Laut Pipersberg funktioniert aber nur der
Impulsnehmer der auch auf dem Anzeigefeld angegeben ist. Hatte es
einfacher gefunden in alle drei Nachkommastellen einen Magnet einzubauen
und man könnte sich aussuchen welche Genauigkeit man benötigt.
Meiner Meinung nach hätten die der letzten Stelle drei oder vier Magnete
spendieren können dass mann alle 0,00333m³ oder 0,0025m³ einen Impuls
bekommt.
Matthias schrieb:> (bzw.> hab vom Gehäuse den Deckel weg gemacht damit das Röhrchen direkt> aufliegt)
Na dann will ich mal hoffen dass Du nicht den Deckel vom Gaszähler
gemeint hast ;o)
Gruß
Ingo
Hallo Ingo
das mit der Auflösung vom Zähler find ich auch doof, aber wenigstens ist
überhaupt ein Magnet drin verbaut...
Ich hab auch ewig probiert bis der Reed-Kontakt ansprach. Versuch mal
die heizung zu stoppen wenn Ziffer 2 auf der 7 steht und teste dann.
Mein Anfangsfehler war das ich die Mitte des Kontakts (überlappende
Zungen) auf der 2. Ziffer positioniert habe, der Kontakt schaltet aber
nur rechts oder links davon (hatte beste Empfindlichkeit bei mir mit
externen Magneten getestet zwecks Einbauposition)
Gruss Matthias
Hallo Matthias,
ich werde mit den Reed-Kontakten nicht mehr herumexperimentieren. Habe
jetzt eine gut funktionierende Lösung gefunden ;o)
Rudi schrieb:> 34€ ist doch schon was ;-). Ich benutze den AN48820a. Ich kann dir in> etwa 2 Wochen meinen alten Sensor geben.
Das Problem bei den Reed-Kontakten ist ja das das Magnedfeld durch den
Kontakt muss damit der Kontakt schaltet. Habe auch bei meinen starken
Pinwandmagneten nur ab und zu Kontakt wenn der Reed-Kontakt den Magnet
direkt berührt, Am besten hat es am Rand des Magneten geklappt. Bei dem
Hall-Sensor kann ich auch 15mm Platz lassen und ich bekomme noch einen
guten Impuls.
Wenn dann werde ich noch mal mit einer Reflexlichtschranke auf die 6 in
der letzten Ziffer versuchen.
Matthias schrieb:> Ziffer 2 auf der 7 steht
Bei mir ist es bei der 6, das wird aber daran liegen dass mein Sensor
fast an der Vorderkante liegt und nichtr wie Dir an der Hinterkante.
Matthias schrieb:> Ich hab auch ewig probiert bis der Reed-Kontakt ansprach.
Was hast Du denn für einen Reedkontakt genommen? Was hat der denn für
eine Ansprechschwelle?
Bei Conrad habe ich noch einen gefunden der eine halb so große
Ansprechschwelle hat (185026) und einen der sogar nur ein drittel davon
braucht aber dann auch gleich über 8€ kostet (185067)
Wenn Du den letzten mit 5-10AW hast erklärt sich auch warum Du ein
Signal bekommst und ich nicht... meiner hat 15-35AW (503770)
Hallo Ingo,
die Daten von meinem Reed-Kontakt weiß ich nicht. Der war mal von Pollin
und ziemlich billig, kann also eigentlich nichts extra Tolles gewesen
sein.
Gruss Matthias
Hallo zusammen,
dies ist mein erster Post in diesem Forum. Nachdem ich schon soviel hier
gelernt habt, wird es Zeit mal was zurückzugeben...
Mit den hier verfügbaren Infos habe ich eine KM271 mit folgenden
Eigenschaften nachgebaut, die jetzt auch sehr stabil läuft. Eagle
Schaltplan (mit lbr, die das KM271 Modul mit Platinenstecker als Bauteil
definiert. Achtung, da fehlt noch das mechanische Sicherungsloch!) und
SW für AVR644P und AVR Studio anbei.
Der Schaltplan ist aktuell und funktioniert soweit klasse, das Board
Layout muss noch angepasst werden (ich habe noch einiges am Prototypen
hinterher "gepatched").
HW
KM271 Schnittstelle hängt optogekoppelt an einem AVR644P zur
Vorverarbeitung der Daten. Ziel war es, die Schnittstelle zur Heizung so
wenig wie möglich zu beeinflussen, daher Opto-Kopplung und eigenes 3,3V
Netzteil (gibt es für ein paar Euro in der Bucht) für den Digitalteil.
Die Z-Doide am FG Fühlereingang ist nicht bestückt, sonst geht die
Temperatur nicht unter 80°. Passenden NTC als FG Fühler gibt es bei
Farnell, alle Spezialbauteile sind im Schaltplan mit Farnell
Bestellnummern versehen, da gibt es auch Datenblätter...
Digitalteil mit SD-Kartenanschluss (Speicherung der Daten als Backup,
falls WLAN Verbindung ausfällt), FRAM (für non-volatile Daten, die man
sehr oft schreiben muss, sehr schnell, keine Beschränkung der
Schreibzyklen) und ConnectOne Nano WiReach WLAN Modul als Anbindung zum
Netz. Alles über SPI verbunden (was für das Nano WiReach ein ganz
schönes gefrickel ist...)
SW
Basierend auf FreeRTOS (ich weiss, es geht auch einfacher aber ich hatte
den ganzen Setup schon von einem anderem Projekt). Von Interesse hier
ist wohl insbesondere die Datei KM271Task.c, die den Treiber für das
3964 Protokoll enthält.
Alle 10 Minuten werden die Temperaturdaten in eine Internet Datenbank
gestellt (Langzeitspeicherung), Ereignisse werden im Minutentakt (falls
nötig) in die Internetdatenbank gegeben. Die Auswertung erfolgt dann mit
html/sql/php und Chart Tools auf Webseiten Basis (mach ich schon für
andere Daten, siehe wetter.naehwerkstatt.de). Alle aktuellen Daten der
Heizung sind im Webserver des Nano WiReach als Java-Script Variablen in
Echtzeit verfügbar.
Danke für eure ganzen Infos. Ohne die hätte ich meine Heizung (übrigens
eine 2105, nicht 2107) nicht "anzapfen" können.
Michael
Hallo Michael,
das Layout schaut etwas strange aus aber wenns funktioniert ok. Du sagst
du musstest an der Platine selbst noch etwas "patchen" hast du das im
Layout jetzt schon berücksichtigt?
Ich denk ich werde mir so was ähnliches für meine Heizungssteuerung
bauen, nur ohne die komplette Intelligenz auf dem Board. Gibts die
Optokoppler nur bei Farnell?
Grüße
Thomas
Hallo Thomas,
stimmt, das Layout ist strange, ich habe einfach den Autorouter von
Eagle benutzt und was da rauskommt ist nicht wirklich super. Zudem ist
die Platine darauf ausgelegt bei mir in der Küche produzierbar zu sein,
nicht um sie einem professionellen Leiterplattenhersteller zu liefern.
Ist halt ein Bastel-Hobby Projekt, der Weg ist das Ziel...
Wie gesagt, der Schaltplan ist aktuell und funktioniert so. Alle
"Patches" sind da eingearbeitet, was dazu führt, das beim Board
Verbindungen aufgelöst sind und einzelene Bauteile noch nicht plaziert
sind.
Ich hatte mir alles bei Farnell zusammengesucht, daher weiss ich nicht,
ob es genau diesen Optokoppler auch woanders gibt. Dieser Typ hat den
Vorteil, dass er 3,3V und 5V beherrscht. Da könnte man aber auch zwei
unterschiedliche Typen für RX und TX einsetzen.
Die SW ist natürlich auch nur ein Snapshot. Da geht es noch bei mir
weiter. Allerdings funktinieren alle Blöcke schonmal sauber und das ist
als Grundlage für andere besser als wenn das ein riesiges Sammelsurium
wird.
MfG
Michael
Ach und mir ist gerade noch etwas aufgefallen:
Der Schmitt Trigger hat doch 5V Supply. Wenn du da die 5V auf der TX
Leitung hast gefällt das dem Logamatic Controller sicher nicht oder
täusch ich mich da jetzt?
P.S: Vielleicht setz ich mich später mal hin und route das mal von Hand.
;)
Hallo Thomas,
nein, das sollte passen. Die Logamatic-Seite ist die 5V Seite. Der
Digitalteil ist die 3,3V Seite. Der Schmitt-Trigger dient auf der
Logamatic Seite hauptsächlich dazu, das TX von der Logamatic in Richtung
Digital nur mit einem logischen Eingang zu belasten und ihm das Treiben
der Optokoppler LED abzunehmen (was so 7mA ausmacht).
MfG
Michael
@Michael M.
Das WLAN-Modul ist ja mal nett. Ich sehe du benutzt den teuren FRAM von
Ramtron. Ich bin davon ab und benutze jetzt die 23K256 von Microchip.
Die sind um Längen billiger wenn 32K ausreichend sind.
Hallo Rudi,
danke für den Tipp! Werde ich mir mal anschauen!
Ach, hier hab ich ein paar Bilder hinterlegt:
http://wetter.naehwerkstatt.de/BilderHz/index.html
Wie gesagt, schaut bloss nicht auf das Board, Küchenware mit händischer
Durchkontaktierung. Mach ich aber schon seit Jahren so und reicht für
meine Zwecke und Einzelstücke...
MfG
Michael
Hi Michael,
das sieht ja schonmal top aus!
Werde da etwas geringfuegig anpassen und eine ethernetvariante draus
basteln...
Vielen Dank für das Posting!
Gruss, Malte
Hallo,
um die Funktion meiner Heizung zuvisualisieren versuche ich gerade die
ServiceKey Schnittstelle nach zubauen. Bei der Menge an Informationen
kein leichtes unterfangen ;-)
Ich habe mir folgendes Atmega8 Entwicklungskit zugelegt, wie es Ingo F.
wohl auch hat( http://www.olimex.com/dev/pdf/AVR/AVR-P28.pdf ). Bei
diesem Board müssen noch die Pin's 2 & 3 vom Atmega mit dem MAX232
verbunden werden für die UART Funktion, was für den SK perfekt ist, da
ja nur der TX Pfad über den D-Sub Stecker geht. RX wird ja an den 3,5
Klinkestecker des SK angeschlossen.
Im Thread Buderus Bedieneinheit RC30 wird von folgender Pinbelegung
gesprochen:
>LINKS : GND>RECHTS: SIGNALOFFSET +12V, +-2.5V Signalpegel (etwa)>GND : +12V
Wenn ich die Posts hier richtig verstanden habe, muss ich also "Rechts"
und "GND" vom 3,5 Klinkestecker nehmen, um ein 2,5V Signalpegel für den
RX Eingang vom Atmega8 zuhaben. Richtig?
Kann man "Links" und "GND" zur Spannungsversorgung des Atmegas
verwenden?
Das Entwicklerkit hat am Pin 28 (PC5) eine LED, wenn ich mir die main.c
von Rudi ansehe, liegt dort die LED auf dem PortC. Reicht es im
Quelltext PORTB gegen PORTC und DDRB gegen DDRC auszutauschen? Muss ich
sonst noch was im Quelltext anpassen (Taktfrequenz, etc.)? Oder beim
Programmieren beachten (Bits die evtl. gesetzt werden müssen um den
externen Quarz zuverwenden?).
Vielen Dank schon mal für diesen Thread und die vielen Informationen!
Gruß
Kay
Hallo Kay,
hatte ursprünglich auch ganz ohne Controller dazwischen ein Adapterkabel
gebaut das die +12V und das Signal vom Klinkenstecker benötigt. Hatte
nur +12V auf Pin 5 (GND) gelegt und das Signal auf RX vom 9 poligen
Stecker.
Allerdings sollte man dann darauf Achten dass man nicht irgendwie eine
Masseverbindung zwischen Heizung und der Schaltung bekommt.
Ich würde Dir empfehlen den RX-Pfad über einen Komperator machen der bei
+12V schaltet. Das hätte den Vorteil dass Man die Schaltung auch am Bus
betreiben kann und nicht unbedingt neben der Heizung bleiben muss. Den
Schaltplan mit Dimensionierung für den RX-Pfad hatte ich ja schon
gepostet
Also über die 12V kann ich keine Aussage über die Belastung machen.
Denke aber dass es direkt auf die 12V der MC10/BC10 geht. Also wenn es
aus irgendwelchen Gründen einen Kurzen geben sollte hat die MC10/BC10
auch schön zu leiden.
Soweit ich weiss reicht es einfach nur den Die Bits in den Registern zu
entsprechend zu setzen. Das tauschen müsste aber auch gehen...
Wenn überhaupt musst du die richtige Taktfrequenz eingeben und die
Baudrate wird automatisch korrigiert.
Soweit ich weiß habe ich den externen Quartz genommen.
Habe mal das Hex-File und die Fuses aus dem AVR-Studio angehangen.
Im Moment ist es so Das an Port C5 die LED nur so lange leuchtet wie
Nutzdaten empfangen werden. Beim Polling nicht.
Port C4 toggelt immer wenn die Schaltung eine Polling für 0x21 (Mischer)
empfängt. Wenn kein Mischer vorhanden ist etwa alle 20-30 Sekunden. Mit
vorhandenem Mischer etwa jede Sekunde.
Auf Port B1 wird immer eine Antwort auf das Polling für den Mischer
gesendet...
Also am besten nichts an PortB1 anschließen...
Bei mir habe ich die Schaltung mit dem Komperator verwendet müsste aber
eventuelle auch mit dem MAX232 gehen.
Gruß
Ingo
Hallo Ingo,
vielen Dank für deine Antwort und die Hex Datei. Ich muß leider
gestehen, das ich noch einige Fragen habe, bevor ich den Lötkolben
wieder anheize ;-)
>Den Schaltplan mit Dimensionierung für den RX-Pfad hatte ich ja schon
gepostet
Ich habe leider nur die folgende Schaltung von dir gefunden (EMSlog.gif)
mit RX & TX Pfad wobei ich den Eindruck hatte, das der TX Pfad noch in
der Entwicklung ist ;-) Hast du schon Daten senden können?
Ist die negative Spannung für den MAX232 notwendig? Bei meinem Olimex
Board ist der MAX232 nur an die 5V angeschlossen.
Da ich primär die Daten aufzeichnen möchte, hatte ich überlegt ob nicht
auch ein Optokoppler aus reicht. Dafür wäre aber interressant wie stark
man den Bus belasten kanm. 10-15 mA bräuchte man schon....
>Also über die 12V kann ich keine Aussage über die Belastung machen.>Denke aber dass es direkt auf die 12V der MC10/BC10 geht. Also wenn es>aus irgendwelchen Gründen einen Kurzen geben sollte hat die MC10/BC10>auch schön zu leiden.
Denke ein Kurzschluss sollte für den Bus kein Problem sein, da man den
Klinkestecker am ServiceKey nicht ohne Kurzschluss einstecken kann ;-)
Nur was der Bus dauerhaft verträgt ist noch offen. Wobei bei auf der
Buderus HP zum orginal ServiceKey steht "Spannungsversorgung über
angeschlosse- nes Regelgerät" -> Betriebsspannung 5-24 VDC (über
Regelgerät) -> Leisungsaufnahme 5 VA
Gruß
Kay
Kay F. schrieb:> Ich habe leider nur die folgende Schaltung von dir gefunden (EMSlog.gif)> mit RX & TX Pfad wobei ich den Eindruck hatte, das der TX Pfad noch in> der Entwicklung ist ;-) Hast du schon Daten senden können?
Sicher habe ich schon mal auf das Polling auf 0x21 geantwortet und es
wurde auch in der RC30 angezeigt dass ein Mischer vorhanden ist. Aber
der TX-Pfad ist wirklich noch in Bearbeitung. Wird jetzt wohl ganz
anders aussehen. Mehr hatte ich noch nicht versucht.. Wollte erst mal
eine vernünftige Sendeschaltung haben.
Kay F. schrieb:> Denke ein Kurzschluss sollte für den Bus kein Problem sein, da man den> Klinkestecker am ServiceKey nicht ohne Kurzschluss einstecken kann ;-)
Doch zumindest keinen Kurzschluss zwischen GND und 12 Volt.
Kay F. schrieb:> "Spannungsversorgung über> angeschlosse- nes Regelgerät" -> Betriebsspannung 5-24 VDC (über> Regelgerät) -> Leisungsaufnahme 5 VA
ALso das habe ich noch nciht gelesen. Dann müsste man ja die 12 Volt
auch mit 5VA belasten können. Mit den Gleichrichter müsstest Du den
SPannungsteiler aus R1 und R2 noch mal anpassen. Bei der Schaltschwelle
muss an R2 2,5Volt liegen.
Gruß
Ingo
Habe das noch nicht ausprobiert da ich parallel zur RC30 hänge und da
keine +12 Volt habe
Kay F. schrieb:> Ist die negative Spannung für den MAX232 notwendig? Bei meinem Olimex> Board ist der MAX232 nur an die 5V angeschlossen.
Also die positive und negative Spannung am Maxim ist der Ausgang vom
Spannungswandler. Hatte da mal einen OP angeschlossen der mindestens 5
Volt Symetrische Speisung brauchte. War aber nur testweise und keine
gute Idee. Der LM393 kommt aber mit 5V Single-Supply aus.
Die Berechnung der Widerstände war aber auf den Bus bezogen ohne den
Brückengleichrichter bezogen.
@Mario, Ingo:
Könntet ihr (bzw. einer von euch beiden ;-) ) eine Protokollbeschreibung
für das EMS-Protokoll zur Verfügung stellen? Etwas Code in irgendeiner
Programmiersprache würde mir auch völlig reichen. Bislang habe ich
leider nur Rudis (nicht kompletten) Python-Code gefunden. Mario schrieb
weiter oben schon mal, dass er die relevanten Daten alle schon decodiert
hat.
Vielen Dank schonmal,
Danny
Danny schrieb:> Könntet ihr (bzw. einer von euch beiden ;-) ) eine Protokollbeschreibung> für das EMS-Protokoll zur Verfügung stellen? Etwas Code in irgendeiner> Programmiersprache würde mir auch völlig reichen. Bislang habe ich> leider nur Rudis (nicht kompletten) Python-Code gefunden. Mario schrieb> weiter oben schon mal, dass er die relevanten Daten alle schon decodiert> hat.
Inzwischen habe ich auch das Telegramm-XLS gefunden ;-)
Sieht ja schon mal sehr gut aus, allerdings sind dann ja später noch ein
paar Telegramme, z.B. von MM10 hinzugekommen...wenn also noch was
aktuelleres existiert, wäre es schön, wenn das jemand posten könnte :)
Danke,
Danny
Hallo,
ich habe jetzt mal meinen Quelltext durchwühlt und alles in einer
Tabelle dokumentiert. Am besten alles vorherigen Dateien vergessen.
Wenn noch jemand Werte hat die nicht aufgeführt sind bitte hier posten
oder zumailen. Werde dann die Datei aktualisieren.
Die PDF sollte iegentlich selbsterklärend sein.
Die ersten Spalte Index ist eigentlich für andere nicht soooo wichtig.
Das ist in meinem Programm der Index in dem Auswahlfeld.
Die zweite Spalte Wert ist die Eindeutige ID für die Kurve in meiner
SQL-Datenbank. Wie man sieht noch nicht so ganz aktualisiert.
Beim Divisor bedeutet eine 0 gleich keine Berechnung (Digitalwerte).
Bit ist das Bit in dem Wert. 0 bedeutet kein Digitalwert.
Gruß
Ingo
Hi,
> ich habe jetzt mal meinen Quelltext durchwühlt und alles in einer> Tabelle dokumentiert. Am besten alles vorherigen Dateien vergessen.>> Wenn noch jemand Werte hat die nicht aufgeführt sind bitte hier posten> oder zumailen. Werde dann die Datei aktualisieren.
Spitze, genau das, was ich gesucht habe - das nenne ich Service :)
Ich werd dann mal die Reichelt-Bestellung für MAX232 usw. absetzen.
Polling-Erkennung und Checksummen-Check soll dann in den Atmega8 mit
rein, damit der sich nicht so langweilt ;-) Auswertung dann in 'nem
Plug-Computer. Wenn ich fertig bin (kann noch ein Stück dauern ;-) ),
poste ich Quellcode.
Vielen Dank nochmal,
Danny
Danny Baumann schrieb:>> Wenn noch jemand Werte hat die nicht aufgeführt sind bitte hier posten>> oder zumailen. Werde dann die Datei aktualisieren.>> Spitze, genau das, was ich gesucht habe - das nenne ich Service :)
Das ist natürlich noch nicht alles. Falls jemand noch andere Werte hat
gerne zumailen und werde dass dann aktualisieren...
Gruß
Ingo
IngoF schrieb:> Danny Baumann schrieb:>>> Wenn noch jemand Werte hat die nicht aufgeführt sind bitte hier posten>>> oder zumailen. Werde dann die Datei aktualisieren.>>>> Spitze, genau das, was ich gesucht habe - das nenne ich Service :)>> Das ist natürlich noch nicht alles. Falls jemand noch andere Werte hat> gerne zumailen und werde dass dann aktualisieren...
Ich hab mal ein paar Fragen dazu ;-)
- Deine Tabelle listet die Telegramme '10 00 3A' und '10 00 3D'. Hast du
die bei dir schon mal gesehen oder wo kommt diese Information her? Ich
sehe die nämlich bei meiner Heizung nicht, und ich habe hier im Thread
auch keinen Verweis darauf gefunden...leider habe ich die gedämpfte
Außentemperatur auch noch in keinem anderen Telegramm gefunden.
- Byte 10 und 11 von '08 00 18' scheinen vertauscht zu sein
Und noch als Info:
Ich möchte wetten, dass die Bytes 9, 10, 11 und 15 in '10 00 3E' und '10
00 48' irgendwelche Solltemperaturen sind (HK1/Wasser/Kessel/HK2?) Im
Tagbetrieb habe ich da die Werte 39/52/65/32 bzw. 26/33/40/27. Im
Nachtbetrieb ist es 5/5/19/5 bzw. 5/5/7/5. Die Kombination 27/5 (d.h. 10
00 48, Byte 16) ist mit Sicherheit Soll HK2, weil das auch in '21 00 AB'
vom Mischer kommt.
Das ganze muss ich mal noch genauer prüfen.
Danny
Hallo Danny,
Also die gedämpfte Außentemperatur habe ich igrendwann mal
herausgefunden. Einige Telegramme kommen relativ selten und muss schon
ziemlich lange warten.
Das Telegramm ist in den Ergänzungen von Matthias zu meiner früheren
Excel-Tabelle. [[Beitrag "Re: Logamatic 2107 Schnittstelle"]]
Ist ziemlich weit oben aufgeführt. Er hatte allerdings das erste Byte
nicht mitgeloggt. Ist ziemlich oben in der Tabelle.
Dort ist auch das Telegramm 10 00 06 aufgeführt mit den der aktuellen
Zeitinformation. Es gibt noch ein Byte was dort in diesem Telegramm
nicht aufgeführt ist. Das Byte ist der Wochentag *0=Montag* bis
*6=Sonntag*
Teilweise hatte ich auch Werte die immer doppelt vorkamen und dann nur
eine in meinem Quellcode verwendet. Kann sein dass bei einem anderen
Heizungsausbau dort andere Werte angezeigt werden.
Beim Flammenstrom ist das z.B. auch so es werden zweimal die selben
Werte hintereinander im Telegramm gesendet. Vielleicht gibt es ja
irgendwelche Heizungen die zwei Brenner haben und dann werden zwei
verschiedene Werte angezeigt.
Noch mal was zum generellen Telegrammaufbau:
1. Byte: Absenderadresse
2. Byte: Zieladresse
3. Byte: Telegrammart
4. bis
(n-2). Byte: Daten
(n-1). Byte: CRC Prüfsumme
(n). Byte: Break (10 Bit lange "0")
Die Quell und Zieladresse sind 7 Bit lang.
Wenn bei der Zieladresse im Telegramm das Bit7 (8te Bit) gesetzt ist
erwartet der Absender eine Antwort auf dieses Telegramm.
Sonst gibt es nur noch das Pollingtelegramm. das nur aus einem Byte mit
folgendem BREAK besteht. Dabei ist immer das Bit 8 gesetzt.
Auf das Polling muss in bestimmter Zeit reagiert werden. Bei mir sendet
die RC30 als erstes auf das Polling(0x90) erst mal seine Adresse (0x10)
und sieht dann nach ob es gerade irgendwelche Daten zum senden hat und
sendet dann das Break oder eben die Daten mit Prüfsumme und dann zum
Abschluss das Break.
Wer das Polling einmal bekommen hat kann so wie es aussieht soviel
Telegramme schicken wie er will. Erst duch eine Antwort ohne Daten
signalisiert er dass er nichts mehr zu senden hat.
Wie anfangs vermutet wurde senden die Busteilnehmer nicht mit
15/10Volt auf den Bus. Sondern belasten den Bus nur mit etwa 40mA. Das
macht eine Pegeländerung von 0,5 bis 1V. Jedes Empfangene Byte wird vom
Busmaster wiederholt und es kann kontrolliert werden ob die Daten
richtig verstanden wurden.
Wenn man den Bus zu stark belastet (Einbruch auf knapp über 7 Volt
(180mA??) sendet der Busmaster noch zusätzlich nach dem Break ein 0xFE.
Vermute mal dass eine generelle Fehlermeldung ist. Vielleicht ist das
auch eine Bestätigung dass die Prüfsumme vom Busmaster als fehlerhaft
empfunden wurde.
Ein Timeout das Rudi auf seinem Bus festgestellt hat konnte ich bisher
kein einziges mal auf meinem Bus feststelle. Oder vielleicht meinte er
das 0xFE Byte. Das bei mir bisher nur aufgetreten ist wenn ich den Bus
gequält habe. Wäre mal abzuwarten bis ich mal testweise Telegramme mit
fehlerhafter Prüfsumme auf den Bus gesendet habe. Werde Vermutlich eine
Konstantstromquelle aus einem 08/15-Transistor und einem
Emitterwiderstand von 82 oder 100 Ohm parallel zum Bus anklemmen. Das
dürfte eine geschätze Belastung von 40-45 mA geben.
Habe mal ein Screenshot von meinem DSO angehangen. Dort kann man gut das
Sendesignal mit Echo erkennen. Die RC30 lässt sich bei diesm Telegramm
100ms Zeit bis es die Daten sendet. Das kann man ganz gut am ersten Bild
sehen. Beide Bilder stammen aus dem selben Oszillogramm. Oben ist das
ganze Signal blau hinterlegt. Der schwarze Bereich ist darunter
vergrößert dargestellt.
Gruß
Ingo
Edit: falls sich jemand fragt was die rote Linie ist.... Das ist die
zweite Port-LED aus meiner letzten geposteten HEX-Datei für das
Experimentierboard. Die LED fängt nach dem zweiten Byte an zu leuchten
und erlischt zwei Bytes nach dem Break.
Habe noch ein Sceenshot mit einem von der RC30 gesendeten Byte
gefunden....
Wie man sieht ist die Pegeländerung zwischen High und Low nur 360mV. Bei
meiner Sendeschaltung wurde das Signal aber erst mit etwa 35mA Last
verstanden das war irgendwas zwischen 0,5 und 1,0V.
Gruß
Ingo
@Ingo:
> Sonst gibt es nur noch das Pollingtelegramm. das nur aus einem Byte mit> folgendem BREAK besteht. Dabei ist immer das Bit 8 gesetzt.
Bei mir wird bei der 0x89 z.B. kein Break gesendet. Ich hatte damals
extra mit dem Oszi. danach gesucht. Aus diesem Grund habe ich oft
Pollingtelegramme wie 0x89 0x90 die natürlich so nicht stimmen und ein
Timeout eingebaut.
Ach stimmt... kann mich noch schwach dran erinnern... Hattest ja mal
dieses Log mit den ganzen FF's. Allerdings habe ich bei mir noch kein
einziges Polling/Telegramm gefunden dass ohne Break gesendet wurde.
Also nehme ich mal an dass das nicht vorgesehen ist. Vielleicht ein
Softwarefehler oder Übertragungsfehler.
Oder ich habe einfach nicht gründlich gesucht.. Will das ja auch nicht
ausschließen...
Wie sieht denn Dein EMS-Bus aus? Bei mir liegt das Kabel alleine in
einem Extra Rohr zum Wohnzimmer und ist ein ganz normales 08/15
ungeschirmtes etwa 0,7mm² Durchmesser. Bis auf meine mitlauschende
Schaltung direkt an der RC30 habe ich nichts angeschlossen. Aber die
0x89 oder 0x90 werdem ja vom Busmaster geschickt und könnten dann ja
nicht verschluckt werden, oder?
Gruß
Ingo
> Wie sieht denn Dein EMS-Bus aus?
Alles direkt in der Heizung bis auf den Logger (~50cm ungeschirmt an der
Klinke).
> Aber die> 0x89 oder 0x90 werdem ja vom Busmaster geschickt und könnten dann ja> nicht verschluckt werden, oder?
Nach der 0x89 kommt einfach nichts. Es ist kein sporadischer Timeout
sondern immer auf einer Adresse. Die BC10 (Addr. 0x09) scheint da nicht
zu antworten. Evtl. weil sie schon angemeldet ist. Man kann hier nur
Vermutungen anstellen.
Hi,
> Also die gedämpfte Außentemperatur habe ich igrendwann mal> herausgefunden. Einige Telegramme kommen relativ selten und muss schon> ziemlich lange warten.
Hab sie inzwischen gefunden ;-)
'0x10 0x00 0xa3 0x00 0x0d 0x11 0x01'
Byte 5 ist die gedämpfte Außentemperatur
Byte 6 + 7 sind mit Sicherheit irgendwelche Flags (beim Wechsel
Tag->Nacht gehen die auf 0x00 0x00)
Und noch ein paar mehr Infos:
'0x10 0x00 0x3e 0x00 0x04 0x02 0x28 0x00 0xd4 0x00 0x00 0x27 0x34 0x41
0x00 0x00 0x00 0x11 0x22'
Byte 7 ist die Raum-Solltemperatur (durch 2 dividieren)
Byte 8 + 9 sind die Raum-Isttemperatur (durch 10 dividieren)
Bytes 12 - 14 sind die Heizkurve für HK1 (Byte 12 = Solltemp. bei 10°C,
Byte 13 dito für 0°C, Byte 14 dito für -10°C
Byte 18 sind irgendwelche Flags, wahrscheinlich Pumpe HK1
Byte 19 ist die Solltemperatur Vorlauf HK1
'0x10 0x00 0x48 0x00 0x04 0x02 0x28 0x00 0xd4 0x00 0x00 0x1a 0x21 0x28
0x00 0x00 0x00 0x11 0x17'
ist exakt das gleiche für HK2
Der einzige Wert, der mir jetzt noch fehlt, ist der Servicecode ;-)
> Dort ist auch das Telegramm 10 00 06 aufgeführt mit den der aktuellen> Zeitinformation. Es gibt noch ein Byte was dort in diesem Telegramm> nicht aufgeführt ist. Das Byte ist der Wochentag *0=Montag* bis> *6=Sonntag*
Ist das Byte 11? Sieht zumindest so aus...
> Wie anfangs vermutet wurde senden die Busteilnehmer nicht mit> 15/10Volt auf den Bus. Sondern belasten den Bus nur mit etwa 40mA. Das> macht eine Pegeländerung von 0,5 bis 1V. Jedes Empfangene Byte wird vom> Busmaster wiederholt und es kann kontrolliert werden ob die Daten> richtig verstanden wurden.
Sicher, dass das nur über die Belastung gemacht wird? Meinen
EMS-auf-UART-Konverter (basierend auf deiner Schaltung) betreibe ich
bus-powered, und der zieht um die 30mA. Das scheint den Bus aber nicht
zu stören, d.h. die Busteilnehmer detektieren nicht den Spannungslevel,
sondern Differenzen?
Danny
Danny Baumann schrieb:> Der einzige Wert, der mir jetzt noch fehlt, ist der Servicecode ;-)
... und der steht in '08 00 18' an Stelle 23 und 24 (z.B. 0x30 0x59 =
'0Y').
Danny Baumann schrieb:> Und noch ein paar mehr Infos:> '0x10 0x00 0x3e 0x00 0x04 0x02 0x28 0x00 0xd4 0x00 0x00 0x27 0x34 0x41> 0x00 0x00 0x00 0x11 0x22'> Byte 7 ist die Raum-Solltemperatur (durch 2 dividieren)> Byte 8 + 9 sind die Raum-Isttemperatur (durch 10 dividieren)> Bytes 12 - 14 sind die Heizkurve für HK1 (Byte 12 = Solltemp. bei 10°C,> Byte 13 dito für 0°C, Byte 14 dito für -10°C> Byte 18 sind irgendwelche Flags, wahrscheinlich Pumpe HK1> Byte 19 ist die Solltemperatur Vorlauf HK1
Ups.. die habe ich im Quelltext wohl übersehen... Die werden bei mir
eigentlich auch mitgeloggt. Nur die -10/0/10°C Werte sind mir neu.
Danny Baumann schrieb:> Ist das Byte 11? Sieht zumindest so aus...
Wird wohl so sein. ist das einzige Byte was in der Ergänztung von
Matthias nicht aufgeführt wurde bei dem Telegramm....
Danny Baumann schrieb:>> Also die gedämpfte Außentemperatur habe ich igrendwann mal>> herausgefunden. Einige Telegramme kommen relativ selten und muss schon>> ziemlich lange warten.>> Hab sie inzwischen gefunden ;-)
Ups.. war mir auch sicher dass ich die dokumentiert hatte... Hatte das
von Dir auch falsch verstanden.
Danny Baumann schrieb:> Sicher, dass das nur über die Belastung gemacht wird?
Keine Ahnung wie das in der RC30 gemacht wird. Aber wenn ich das Signal
über eine 40mA Stromsenke erzeugt habe sah das Signal genauso wie aus
dern RC30 aus, nur dass es etwas mehr Amplitude hat.
Deine Schaltung belastet den Buss ja gleichmßig und bewirkt daher keine
Spannungsschwankungen. Hast auch garantiert einen entsprechenden
Bufferkondensator eingebaut, oder?
Danny Baumann schrieb:> Das scheint den Bus aber nicht> zu stören, d.h. die Busteilnehmer detektieren nicht den Spannungslevel,> sondern Differenzen?
das meinte ich ja damit.. vielleicht auch nur ungünstig von mir
ausgedrückt. Duch diese Belastung habe ich die Spannungsschwankungen
erreicht...
Ingo F. schrieb:> Ups.. die habe ich im Quelltext wohl übersehen... Die werden bei mir> eigentlich auch mitgeloggt. Nur die -10/0/10°C Werte sind mir neu.
Die -10/0/10 ist das, was RC30 bei mir zu den entsprechenden Werten
anzeigt. Es sagt sowas wie
39 52 65
10 / 0 /-10
HK1
(das ganze im Servicemenü -> Heizkennlinie)
> Deine Schaltung belastet den Buss ja gleichmßig und bewirkt daher keine> Spannungsschwankungen. Hast auch garantiert einen entsprechenden> Bufferkondensator eingebaut, oder?
Ich hab 10µF eingebaut, ich bin mir aber nicht sicher, ob das
"entsprechend" ist. Für 400mV Spannungshub für die Dauer von ein paar ms
sollte es evtl. reichen ;-)
Danny
Na ich meinte ja damit es eine gleichmäßige Belastung ist und keine
Spannungsschwankungen hervorruft... Für die Sendeschaltung soll ja
gerade nicht den Strom aus dem Kondensator saugen.. Das wäre dann ja
Sinnlos..
IngoF schrieb:> Na ich meinte ja damit es eine gleichmäßige Belastung ist und keine> Spannungsschwankungen hervorruft... Für die Sendeschaltung soll ja> gerade nicht den Strom aus dem Kondensator saugen.. Das wäre dann ja> Sinnlos..
Ähm, ich habe bei mir keine Sendeschaltung verbaut...nur Atmega8 +
MAX232 + OPV für den RX-Pfad. Stromversorgung via 78L05.
Senden war mir dann doch zu heikel ;-)
Danny Baumann schrieb:> Hab sie inzwischen gefunden ;-)> '0x10 0x00 0xa3 0x00 0x0d 0x11 0x01'
Ups.. hatte ich dokumentiert.. Allerdings hatte ich einen Zahlendreher
und habe 3A statt A3 geschrieben. So wie es aussieht sind wohl alle
meine Byteangaben einen zu hoch.. Muss das noch mal nachsehen...
Danny Baumann schrieb:> Senden war mir dann doch zu heikel ;-)
Also bisher habe ich bis auf eine Simple Polling-Antwort auch noch
nichts gesendet. Wusste ja nicht dass das Echo sein muss und kein Fehler
ist.
Werde mich da mal in der nächsten Zeit ein wenig dran versuchen wenn ich
die neue Software mit CAN fertig habe.
Habe mal meine Tabelle aktualisiert und angehangen. Hatte bei 0
angefangen zu zählen und die beiden Framing-Bytes die der Atmega einfügt
auch mitgezählt. Dadur hatte ich überall einen zuviel.
Das 3A Telegramm war das A3 Telegramm ;o)
Das 11.Byte war also richtig mit dem Wochentag. Den Service-Code habe
ich auch bei mir gefunden
Gruß
Ingo
Die Versionen der Module wäre mal nicht schlecht. Evlt. sind wir genug
und können die Nachrichten vergleichen ? Anbei nochmal meine Versionen.
Es lohnt sich nur wenn die Versionen unterschiedlich sind:
UBA3/MC10 (Universeller Brennerautomat/Mastercontroller) - 8 - V3.02
BC10 (Basiscontroller) - 9 - V2.02
RC30 (Raumcontroller) - 16 - V2.08
Version 3
KIM (Kesselidentifikationsmodul) 1051
Ich habe
UBA3/MC10 - 2.03
BC10 - 2.00
RC30 - 2.05
Version 12 / KIM-Nummer 1003
Danny Baumann schrieb:> Rudis Anlage ist offensichtlich neuer als meine (Ende 2004) ;-)
Meine kommt ja dann fast aus der Steinzeit ;o)
Hallo,
ich lese aus Interesse etwas mit und da ich eine nun eine MC10, BC10 und
RC35 erworben habe, um meine alte Steuerung zu ersetzen, bin ich sehr
gespannt, wie sich das hier entwickelt.
Mir ist noch nicht klar, welche Schnittstellenhardware geeignet ist aber
ich verfolge den Thread weiter. Bisher habe ich nur einige Erfahrungen
mit AVR-NET-IO und dem AVR Webmodul von Radig.
Schön wäre es, wenn ich die Daten nicht nur lesen (was schon ein
Fortschritt wäre), sondern auch senden könnte. Ich nutze die Software
IP-Symcon zur Hausautomation.
Tolle Arbeit Jungs. Danke
Ihr könnt ja mal schauen ob die Werte stimmen. Index 4 in den Typ 0x02
Nachrichten ist wohl die Identifikation der Module.
UBA3/MC10 (Universeller Brennerautomat/Mastercontroller) - 8 - V3.02
Hallo Leute,
habe mir im Mai eine Buderus GB162-25 T40S zugelegt mit:
UBA3.5 - 3.06
RC 35 - 1.11
KIM 1076
und möchte natürlich auch den EMS-Bus anzapfen - zum Lesen.
Deshalb verfolge ich Euren Thread schon seit einigen Monaten, ist aber
nicht einfacher für mich geworden :-*).
Was das Bus-Interface betrifft, geht es mir ähnlich wie meinem
Vorredner/Schreiber. Man/ich weiss eigentlich nie so genau, was der
neueste Stand ist. Versteht das bitte nicht als Kritik! Ich denke nur,
dass es hier eine Vielzahl von stillen Mitlesern gibt, denen es ähnlich
geht. Und ich finde es schade, dass Eure tollen Erkenntnisse im "Nebel"
des Threads unterzugehen drohen.
Deshalb meine Bitte an Euch: Alle ein bis zwei Monate Eure neuesten
Ergebnisse als Schaltplan, Code, etc. anhängen. Ja, ich weiss, es ist
zusätzliche Arbeit, aber nach meinem Geschmack würde sich der Überblick
über den Thread deutlich erhöhen.
In der Hoffnung, keine Fehlbitte geäussert zu haben, bin ich auf die
weiteren Erkenntnisse gespannt - und hoffe in nicht all zu ferner
Zukunft mit meinen eigenen Ergebnissen weiteres Licht ins Dunkel des
EMS-Bus zu bringen ;-).
---
Eigentlich gehört es vom Thema nicht hierher, aber weiter oben war schon
mal vom Auslesen des Gaszählerstandes die Rede. Deshalb hier mal meine
eigenen Erfahrungen, vielleicht interessiert es jemanden.
Habe hier einen Elster/Kromschröder Gaszähler BK4. Der hat in der
letzten Zählerrolle (1 Ltr.) einen Magneten bei der Ziffer 9. Also kann
man die 0,01 cbm (10 Ltr.) zuverlässig bestimen. Als Reedkontakt habe
ich bei Frau R. einen MK 1471B um 2,55 Euronen bestellt. Der passt prima
in ein 3cm-Stück Schutzhülle für DIL-ICs. Darum 3 Lagen Panzerband
gewickelt und das Sandwich passt haargenau in die Zähleraussparung. Und
weil sich das Sandwich echt easy Ein- und Ausstecken lässt, ist auch
sichergestellt, dass bei einem Zählerwechsel nicht ein neuer Reedkontakt
beschafft werden muss. Also kann der Gasmann ruhig 2 mal klingeln ;-).
Das Zählen übernimmt bei mir ein DS2423, also ein 1-Wire Counter. In
diesem Chip sind aber zwei 32-bit Zähler integriert, so dass noch ein
Zähler frei war.
Der zählt jetzt das Kondenswasser über einen Regenmesser. Habe ich auch
bei Frau R. bestellt. Kostet ca. 25 Euronen und nennt sich WS 73003. -
Und nein, ich bekomme keine Tandieme von R.! - Das Teil besteht aus dem
eigentlichen Regensammler für den Garten und einer Auswertestation fürs
Haus, verbunden per Funk. Die Auswertestation steht jetzt auf meinem
Schreibtisch und zeigt mir Temperatur, Datum und Uhrzeit; für die
Applikation habe ich sie nicht benötigt.
Was zum Einsatz gekommen ist, ist der Regensammler. Jepp, die Dinger
funktionieren mit einer Wippe ------|------ , das Wasser kommt
gedrosselt von oben, wenn die linke oder rechte "Schaufel" voll ist,
kippt die Wippe. Der Mengeninhalt der "Schippe" ist bekannt, ein in der
Wippe befestigter Magnet steuert den Reedkontakt. Für einen Liter kippt
die Wippe 210 mal. Das gibt eine relativ gute Genauigkeit, Meteorologen
haben eben hohe Ansprüche.
Also Batterien raus, damit die Kiste nicht funkt und auf der Platine
direkt an den Reedkontakt, bzw. an zwei Leiterbahnen, die lötfreundlich
in einem Pad enden. Diesen Reedkontakt habe ich mit dem zweiten Zähler
verbunden, so dass ich jetzt synchron Gasverbrauch und
Kondenswasseranfall zähle. Das hat den Vorteil, dass ich über diese
beiden Parameter den Netto-Abgasverlust meiner Heizungsanlage bestimmen
kann.
Da gibt es einen schlauen Doktor an der Uni des Saarlandes, der hat in
einer Patentschrift vorgerechnet, dass der Netto-Abgasverlust (qA) von
Gas-Brennwertgeräten (GBWG) sich wie folgt bestimmen lässt:
qA=( 1,6 * G – W )/( 1,6 * G ) * 13,5 [%]
oder vereinfacht:
qA = ( 1 – W /( 1,6 * G) ) * 13,5 [%]
wobei:
qA = Netto-Abgasverlust in %
W = Kondenswasser in Liter
G = Gas in cbm (m³)
Wen die Herleitung interessiert 8-/, der wird hier fündig:
http://www.uni-saarland.de/fak7/fze/KFA.htm
Achso, die Auswertung der Zähler und weiterer 1-Wire Bauteile erfolgt in
meinem FLI4L mit Opt-OW.
O.k. - ist ein bisschen lang geworden, hoffe Ihr seid nicht ermüdet und
forscht weiter ;-).
Schönen Sonntag noch und Gruß
Karl M.
Hallo Rudi,
konnte leider nur die KIM-Version in den Telegrammen finden.
Da Du ja eine ganze Version bei Deiner RC30/35 weiter bist kann es
durchaus sein dass die Telegramme anders abgefragt werden.
Habe Dir mal meine ganzes Log angehangen. Irgendwo müssen die ja
versteckt sein. Allerdings wohl nicht ganz so einfach im BCD Format wie
in Deinen Telegrammen. Konnte sie jednfalls nicht finden.
Gruß
Ingo
IngoF schrieb:> Habe Dir mal meine ganzes Log angehangen.
Etwas unglücklich formuliert...
Habe sie in der Mail an Dich angehangen. Müsste schon angekommen sein.
Gruß
Ingo
Hallo,
ich habe nur meine alte 3220 Steuerung ersetzt und reiche mal die
Versionsdaten nach:
RC 35 V1.06
MC 10 V2.07
BC 10 V2.03
SAFe V5.20
BIM V1
BIM Nummer 7000
Gruß
Andy
Rudi schrieb:> @Andreas F.>> Wie lauten die Busadressen von deiner Anlage ?
Ich habe leider noch keinen Zugriff auf den Bus (siehe
Beitrag "Re: Logamatic 2107 Schnittstelle" ), denn mir fehlt
noch die passende Schnittstellenschaltung. Ich warte noch auf Euch. ;-)
Ne andere Möglichkeit, diese anzuzeigen, kenne ich nicht.
Gruß
Andreas
Andreas F. schrieb:> Ne andere Möglichkeit, diese anzuzeigen, kenne ich nicht.
Ist auch im "Sondermenü" zu finden.
Unter "Monitordaten" und dann "Bus-Status".
Gruß
Ingo
IngoF schrieb:> Ist auch im "Sondermenü" zu finden.> Unter "Monitordaten" und dann "Bus-Status".
gefunden unter Diagnose/Monitorwert/Busteilnehmer
MC 10/SAFe Adr. 8
BC 10 Adr. 9
RC 35 Adr. 16
Gruß
Andreas
Rudi schrieb:> hat dein SAFe keine Adresse
Hallo Rudi,
wenn ich dass richtig verstanden habe ist dass das selbe wie UBA3. Keine
Ahnung wodrin der Unterschied ist.
Vielleicht auch nur der Vorgänger der UBA3
Gruß
Ingo
IngoF schrieb:> wenn ich dass richtig verstanden habe ist dass das selbe wie UBA3. Keine> Ahnung wodrin der Unterschied ist.> Vielleicht auch nur der Vorgänger der UBA3
Ich bin kein Heizungsbauer, aber das BRM 10 ist doch, wenn ich das
richtig verstehe, kein richtiger SAFe. Es ist eine Schnittstelle, um
ältere oder andere Brenner an einer EMS-Regelung zu betreiben und SAFe
wohl nachzuahmen. Gibt es erst seit 2007. Alle Möglichkeiten hat man
damit wohl nicht.
Meine Angaben stehen genau so wie angegeben im Display.
Gruß
Hallo,
Ich hab gemäß dem Thread und den beiden Schaltungsvorschlägen Rx und Tx
am Modulsteckplatz für KM271 abgegriffen, UART auf 2400bd stehen,
bekomme aber keine Antwort (auch kein STX) von der 2107.
Nun die Frage: Muss man damit überhaupt die RS232 aktiviert wird noch
Bauteile für den FG bestücken? Wenn ja welche? oder muss/kann das Modul
in der Steuerung aktiviert werden.
vielen Dank für eure Super Arbeit und viele Grüße
jens
ok, der 10k R zwischen 5 und 7 scheint zu reichen, nun ist Abgas
einstellbar und das Modul wohl erkannt. Aber Daten bekomm ich trotzdem
noch keine ... Hat jemand noch eine Idee?
vg jens
tx und rx vertauscht ... :-) schon immer mein Problem. Obwohl ich es an
sich schon 10mal gecheckt hatte.
nun werd ich mal weiter sehen was so an Daten kommt.
vg und noch mal Danke für alle Infos im Forum und wiki
jens
Hallo,
ich habe noch mal ein wenig am Bus herumgespielt und stumpf ein paar
Pollings beantwortet und darauf gewartet was meine RC30 anzeigt.
0x08 = MC10
0x09 = BC10
0x10 = RC30/35
0x11 = Hydr. Weiche
0x12 = ZM EED
0x13 = Gerät (4x)
0x17 = RC20 Heizkreis
0x18... = RC20 (8x)
0x20... = Mischer (8x)
0x28... = Warmwasser (8x)
0x30... = Solar (8x)
0x38... = Gerät (40x)
Laut meinem Pollingmitschnitt scheinen Adressen über 0x60 nicht gepollt
zu werden. Ausnahmen scheinen 0x61 und 0x68 zu sein.
Habe auch nicht alle Adressen überprüft und teilweise nur
stichprobenartig meine Tabelle überprüft.
Ist ja fast alles selbsterklären. Gerät ist wohl so eine Art Platzhalter
für irgendwelche Module die der RC30 noch nicht bekannt waren. Oder
Busteilnehmer wie Fernwirkmodem, ServiceKey, RS232-Gateway, ....
Also wer sowas haben sollte bitte einfach mal nachsehen und mir
irgendwie eine Info zukommen lassen. Bin von Natur aus neugierig ;o)
Muss ja nicht im Forum sein...
Aber was zum Teufel ist "ZM EED"??? ZM = ZentralModul oder ZusatzModul?
Was soll denn EED sein? Hat jemand irgend eine Idee?
Gruß
Ingo
Ingo F. schrieb:> Aber was zum Teufel ist "ZM EED"??? ZM = ZentralModul oder ZusatzModul?> Was soll denn EED sein? Hat jemand irgend eine Idee?
Bei Buderus bedeutet ZM einfach Zusatzmodul. Aber EED !?
Wie sieht deine jetzige Sendestufe mit dem Transistor aus ? Ich will mir
demnächst eine neue Platine mit Opto. usw. bauen.
Grüße.
Rudi schrieb:> Wie sieht deine jetzige Sendestufe mit dem Transistor aus ? Ich will mir> demnächst eine neue Platine mit Opto. usw. bauen.
Also sie wird sehr wahrscheinlich einfach nur ein 82 oder 100 Ohm
Emitterwiderstand für die Stromregelung haben und mit dem Basis am
PIC/Atmega8 hängen. Dann sollte der Strom passen.
Die Busadressen habe ich noch mit der "alten" Schaltung ermittelt. Bin
dabei die Software noch mal neu zu schreiben. Wenn das fertig ist mach
ich mit der Sendeschaltung weiter...
Hinter soll es möglich sein per Jumper aus mehreren Seriellen
Protokollen auszuwählen.
1) EMS (EMS-Bus)
2) 3964R
3) ASCII HEX-codiert
4) das bisherige Format mit AA 55 gerahmt
5) nur geänderte Werte
6) .....
mal sehen wieviel es wirklich werden. Die ersten beiden auf jeden Fall.
3964R verwendet ja Buderus für die Fernwirkmodems. Vielleicht ja auch
für den ServiceKey und RS232-Gateway. Das mit dem AA 55 Rahmen fand ich
nicht ganz sooo gut. rein theoretisch wäre es ja möglich dass die Werte
AA 55 irgendwann mal in den Daten vorkommen. Bei 3964R kann das ja nicht
passieren.
Gruß
Ingo
Karl M. schrieb:> EED ist ein "Externe Störungsanzeige (EED)"-Modul.
Danke...
Also die Abkürzung von:
Zusatzmodul External Error Detection :o)
Hätten sich ja auch für eine Sprache entscheiden können...
Na dann kann ich die Adresse ja schon mal vergessen. Der Gateway oder
Service-Key muss dann wohl eines von den "Geräten" sein.
Dann muss es ja ein ähnliche externe Fehleranzeige auch (irgendwann) für
den EMS-Bus geben. Die ist vermutlich für das 4000er Bussystem?
Ingo F. schrieb:> 3964R verwendet ja Buderus für die Fernwirkmodems. Vielleicht ja auch> für den ServiceKey und RS232-Gateway.
Ja, zumindestens der Service-Key arbeitet damit.
Ingo F. schrieb:> Das mit dem AA 55 Rahmen fand ich> nicht ganz sooo gut. rein theoretisch wäre es ja möglich dass die Werte> AA 55 irgendwann mal in den Daten vorkommen.
;-). Es ging mir damals eher darum, den Anfang und das Frameende zu
markieren. Durch die Längenangabe würde es auch bei doppelten AA 55
funktionieren.
Ich lese z.Z. die Daten über die UART mit einem 50MHz Cortex. Die
CRC-Berechnung und das Parsen der Werte sind relativ CPU-Lastig. Die CPU
muss auch noch andere Dinge erledigen (Loggen/SD-Karte, Netzwerk,
CAN-Master). Ich werde hauptsächlich aus diesem und anderen Gründen
einen 72MHz STM für die Parsergeschichte einsetzen. Der Platzbedarf auf
der Platine ist durch die integrierte CAN-Hardware auch noch kleiner im
Vergleich zu einem ATMEGA323P. Der STM kann dann den Stream parsen und
bei Änderungen auf dem CAN-Bus brüllen.
Grüße.
Nachtrag:
Evtl. hat ja jemand Lust und Laune und kann für die CRC Berechnung die
Tabelle, für eine Tabellen basierte CRC, erstellen. Das sollte dann noch
einiges an CPU-Zeit sparen, wenn genug Speicher vorhanden ist.
Grüße.
Rudi schrieb:> Evtl. hat ja jemand Lust und Laune und kann für die CRC Berechnung die> Tabelle, für eine Tabellen basierte CRC, erstellen.
Hallo Rudi,
Das wird leider nicht gehen. Die EMS-Prüfsumme ist ja kein wirkliches
CRC mit Generatorpolynom. Es ist ja nur ein XOR mit verschiebung und ein
paar Bits setzen wenn der bisherige Wert einen bestimmten Wert
überschritten hat. Also nichts was man mit Tabelle machen könnte, oder?
Bei der CRC mit Generatorpolynom wird die CRC ja immer Bitweise
"errechnet". Durch die Tabelle erspart man sich dann acht Schritte und
hat dann ein Byte was man XORen kann, oder? Die EMS-Prüfsumme ist ja
schon auf Byte ebene und wird nicht für jedes Bit errechnet.
Allerdings habe ich auch im Moment keine Ahnung wie die Tabelle bei
einer CRC mit Generatorpolynom wirklich erstellt wird und angewendet
wird. Habe nur mal am Rande davon irgendwas mitbekommen. Vielleicht geht
es mit ein wenig Gehirnschmalz ja doch...
Gruß
Ingo
Rudi schrieb:> Ich lese z.Z. die Daten über die UART mit einem 50MHz Cortex. Die> CRC-Berechnung und das Parsen der Werte sind relativ CPU-Lastig.
Wie sieht denn das Parsen bei Dir aus? Machst Du wie bei Deiner MySQL
einen "String" raus, der komprimiert wird?
Ich hatte vor einfach wie bei meiner SQL einfach einen 16Bit-Wert daraus
zu machen und eine ID mitzusenden. Je nach dem welches Frame ankommte
wird nur ein entprechendes Unterprogramm ausgeführt.
Die Werte werden im Buffer zwischengespeichert (z.B. ID*3+Bufferanfang).
Bei änderungen wird der Wert übertragen. 2*8Bit +8Bit für einen
primitiven Zeitstempel. Das klingt eigentlich so als ob dass parrallel
mit dem Empfang mitlaufen könnte.
Allerdings macht meine CPU nichts anderes als empfangen und weiterleiten
und dann auch irgendwann mal die Werte auslesen.
Ingo F. schrieb:> Wie sieht denn das Parsen bei Dir aus? Machst Du wie bei Deiner MySQL> einen "String" raus, der komprimiert wird?
Schon lange nicht mehr. Ich habe in der DB die eigentlichen Werte als
Float gespeichert und den Rest als Integer (ID/Timestamp). Das bringt
etwas mehr Performance. Leider kann mysql noch keinen Timestamp mit
Millisekunden, da gibt es aber ein Workaround, falls man diese Auflösung
benötigt.
Aus Performance-Gründen tendiere ich eher dazu, für jeden Sensorwert
eine eigene Tabelle anzulegen. Ich habe es aber noch nicht getestet.
> Ich hatte vor einfach wie bei meiner SQL einfach einen 16Bit-Wert daraus> zu machen und eine ID mitzusenden. Je nach dem welches Frame ankommte> wird nur ein entprechendes Unterprogramm ausgeführt.
Ja, so in etwa mache ich es jetzt auch. Frame empfangen, CRC prüfen und
je nach Absender an die entsprechende Unterfunktion übergeben. Dann
parsen und ab hier wird jeder Wert als Sensor gesehen und entsprechend
weiterverarbeitet. Also wenn ich von der Buderus zwei Temperaturen
bekomme sind das nach dem Parsen einfach 2 Sensoren die die Temperatur
messen. Das ist erstmal mein Ansatz für die Handhabung der einzelnen
Daten.
Ich versuche alles in ein Schema F zu bekommen, je nach Sensor
verallgemeinern, damit ich später bei einer zusätzlichen Regelung
weniger Probleme habe.
Ich denke die CRC-Berechnung würde man schon in eine Tabelle bekommen.
Es gibt ein Poly. und ein paar mal gedrehe mit Bitabhängigkeiten. Nichts
anderes als bei einer "normalen" CRC denke ich.
Grüße.
hi alle zusammen,
erstmal an alle fettes danke, super arbeit habt ihr hier alle
geleistet!!!
zu meinem prob: habe die Schaltung exakt nachgemacht, kriege aber keine
daten von meiner logamatic 2107.
interface habe ich gemäss update von chipsuffler nachgebaut. habe schon
viele interfaces im OBD (Automotive) Bereich gelötet, bin nicht ganz
anfänger und finde auch keinen fehler in meiner arbeit.
habe rx/tx auf beiden seiten schon wild hin und her getauscht. nix....
versuche die ganze zeit immer nach einem versuch fhem zu starten, debug
modus laufen zu lassen (verbose und loglevel auf 5 und 6) und logmode zu
setzen. nix...
(in der fhem.cfg ist natürlich auch "define KM271 KM271 /dev/ttyS0"
eingetragen)
wie testet ihr manuell? sprich senden von 0x02? mit nem PERL
write("\x02") sehe ich aller höchstens mal ne 00 aufm ttyS0 aber nix
gescheites.... und schon gar nicht irgendne antwort.....
interface wird natürlich mit abgas erkannt (bei nem 1k widerstand an FG
ca 150°C) und im service menü kann ich ne abgastemperaturschwelle
einstellen.
bin bischen verzweifelt, ist ja echt keine kunst das interface
eigentlich.
wisst ihr was sein könnte? typischer fehler auf den ihr auch gestossen
seid?
-die pegel an tx und rx nachmessen und dabei merken ob es wirklich
richtig verbunden ist (war mein fehler)
- mit einem seriell-usb Adapter und einem Terminal-programm erste
Tuchfühlung nehmen.
Ansonsten ist wohl eine genauere Beschreibung der gebauten Variante
noitwendig, den thread kann wohl niemand mehr auseinander halten weil
sich da verschiedene Stränge und Varianten durchmischen ...
vg jens
was für pegel soll ich da erhalten? reicht ein voltmeter?
mit was für einem terminalprogram kann ich sicher die einstellung 2400
vornehmen und hex 0x02 senden? bzw. wie machst du das?
Pegel messen (hier Logikpegel, keine RS232):
- Verbindung auftrennen (also nichts anklemmen)
- Am zu messenden Anschluß einen Widerstand ca. 4.7k gegen Masse legen.
Ein Empfänger (Eingang) sollte dann gegen 0V zeigen, ein Ausgang knapp
unter 5V
Terminalprogramm: Realterm. Kann man alle Baudraten einstellen und auch
senden.
vg jens
Hallo Chris,
Das ist ja super. Genau das nach dem ich gesucht habe.
Die Kommunikation läuft wie schon fast vermutet über das
3964R-Protokoll.
Leider hilft die Aufzeichnung von Dir leider garnichts da Du im
ASCII-Mode aufgezeichnet hast. Zeichne doch mal im HEX-Mode auf. Wäre
sehr interessant wie das genau abläuft. Einfach mal so eine Minute Log
dann hier am besten als Datei anhängen.
Und Bitte schau doch mal in der RC30/35 nach mit welcher Adresse und
Namen er sich am Bus anmeldet. Bin echt neugierig.
Bei der RC30: Service-Menü >> MonitorDaten >> Bus-Status.
Bei der RC35: Diagnose >> Monitorwert >> Busteilnehmer
Hier sind schon mal alle Daten die wir bisher herausgefunden haben:
Beitrag "Re: Logamatic 2107 Schnittstelle"
Die meisten Daten sind schon bekannt. Wir haben aber alle einen
selbstgebastelten Controller und keinen Service-Key. Deswegen haben wir
ein anderes Datenformat. Müsste bei Dir am Service-Key aber sehr ähnlich
sein....
Gruß
Ingo
P.S.: Die Daten in Deinem Log, die nach HEX-Daten aussehen ist das Datum
mit Uhrzeit und Millisekunden. Die eigentlich Daten sind dazwischen
versteckt und werden evtl nicht komplett angezeigt weil es im ASCII-Mode
von dem Programm aufgezeichnet wurde.
Gruß
Ingo
Hallo Chris_be
Danke für die Info... Der Service-Key versteckt sich also hinter der
0x0b ;o)
Also zu den Daten....
Der Service-key sendet die Daten mit vorangestellter 0x04.
dannach kommt die Adresse des EMS-Modul (0x10 für RC35)
und dann der Telegrammtyp.
Das hier aus Deinem Log ist das Telegramm 0x18 von der MC10:
04081900006101EE0225FFFFFF0000B9DA04786E02EA4803BAFF00AB590000100335
Mit der Tabelle kannst Du dann die Daten "decodieren".
das 6.Byte ist die Außentemperatur 0x61 > 97 > 9,7°C
Was die anderen Telegramme mit 0x39 und 0x00 sind kann ich jetzt auch
nicht sagen. Würde mal vermuten dass die 0x00 Daten vom Service-Key
selber sind.
Ganz am Schluss sind noch Telegramme die mit 0x20 anfangen. Wird
vermutlich nichts ganz so wichtiges sein.
Die Telegramme mit der 0x39 am Ende kommen nicht vom Service-Key oder
von der Software und sind nur ein Hinweis auf die Beschränkungen der
TrialVersion.
Vielleicht kannst Du ja noch mit hilfe der Buderus Software noch andere
Daten herausfinden, was uns leider nicht möglich ist.
Falls Du noch irgendwas herausfindest bitte dann noch mal posten oder
mailen.
Gruß
Ingo
Ist ja fast ein Kinderspiel mit OpenOffice die unützen Daten
herauszulöschen ;o)
Für alle die es interessiert hier mal die reinen Daten ohne Ballast...
Nun ist ja echt Bewegung in der Sache.
Ich habe mir auch mal spaßhalber einen original Service Key zugelegt.
Nun ist der Stecker etwas klobig und ich benötige eine Verlängerung zu
meinem Hausautomationsserver. ;-)
Was ist sinnvoller? Den Bus direkt zu verlängern (also am Klinkenstecker
oder die RS232 Schnittstelle, die ich wohl noch über RS232 zu USB
konvertieren muss?
Gruß
Andreas F. schrieb:> Nun ist der Stecker etwas klobig und ich benötige eine Verlängerung zu> meinem Hausautomationsserver. ;-)
Genau deswegen habe ich mich bisher geweigert den Service-Key zu kaufen
;o)
Eigentlich ist es egal.Der EMS-Bus darf ja 50 Meter lang sein. Mit der
seriellen Schnittstelle kommt kan bei 9600 laut Wikipedia bis zu
152Meter.
Würde ich von dem Verkabelungsaufwand/-kosten abhängig machen.
Das USB-Kabel zu verlängern halte ich nicht für eine gute Idee. Bei USB
sind das ja mindestens 1,5MBit die über das Kabel gehen müssen.
Bei 1 Meter würde vielleicht ein USB-Verlängerungskabel gehen. Halte ich
aber trotzdem für keine gute Idee.
Gruß
Ingo
Hello Chris.
Hier eine kleine Anleitung um die Daten automatisisert zu bereinigen:
[code]
###########################
1) unnütze Daten löschen:
###########################
bei "Mehr Optionen" "Regulärer Ausdruck" anklicken.
Ohne "" kopieren und in OpenOffice einfügen und jedes mal "Ersetzen
alle" anklicken.
suchen nach: ersetze durch:
(search for:) (replace by:)
----------------------------- --------------
"[[]len=[:digit:]+\x005d"
"1003[01234567890ABCDEF]{2}"
"<[RTX]{2}>$"
"<[RTX]{2}>[:digit:]{2}$"
"<[RTX]{2}>[:digit:]{4}$"
"^$"
"[01234567890ABCDEF]{2}" "& "
"10 10 " "10 "
###########################
2) alles Markieren:
###########################
"bearbeiten" "alles auswählen STRG+A" auswählen
###########################
3) in Zwischenablage:
###########################
"bearbeiten" "kopieren Strg+C" auswählen
###########################
4) in Wordpad einfügen:
###########################
WordPad öffnen
[STRG]+[V]
[\code]
und im Anhang die bereinigte Version.
Am besten die TXT-Datei gleich mit OpenOffice öffnen und die
Markroaufzeichnung starten. Alles bis Punkt 3 ausführen,
Makroaufzeichnung beenden und Makro abspeichern.
Dann geht alles beim nächsten mal viel schneller.
Aber dann nicht mehr das Ausgabeformat umstellen.
Gruß
Ingo
schon wieder Anhang vergessen....
@Chris poste doch mal Deine Programmeinstellungen vom "Advanced Serial
Port Monitor" wie Du die Datei erstellt hast.
Werde mich jetzt mal wieder um meine Hardware kümmern. Werde mir
irgendwann mal ansehen was da in Deinem letzten Mittschnitt überhaupt
drinsteht....
Gruß
Ingo
@IngoF
Wo ist deine Fernbedienung an der Heizung angeschlossen ? Bekommt die
Fernbedienung nur GND und die Datenleitung oder zusätzlich noch die 12V
?
Zum "get config": Die Daten sehen mir an einigen Stellen nach einem
einfachen EEProm-Dump aus. Jedes Modul hat ja ein EEProm am I2C.
Jetzt könnte man eine UART-Simulation schreiben und schauen was da so
alles in der Software passiert ;-)
@chris_be
Is there a way to get pictures from inside the key ? Anyway, thanks for
the log data !
Rudi schrieb:> Wo ist deine Fernbedienung an der Heizung angeschlossen ? Bekommt die> Fernbedienung nur GND und die Datenleitung oder zusätzlich noch die 12V> ?
Also die RC30 und mein ATMega8 hängt im Wohnzimmer am Bus. Dann geht es
an der Heizung vorbei ins Computerzimmer wo mein 18F2585 und hinter dem
4cm langen CAN BUS noch ein PIC.
Der Bus hat keine 12 Volt also nur GND und 10/15Volt. Die 12 Volt gibt
es nur an der Diagnosebuchse für den Service-key.
Rudi schrieb:> Zum "get config": Die Daten sehen mir an einigen Stellen nach einem> einfachen EEProm-Dump aus. Jedes Modul hat ja ein EEProm am I2C.
Also auf jeden Fall kommen einige Telegramme zerstückelt über den
EMS-Bus. Der Service-Key klebt die zusammen und schickt die zum PC.
Ansonsten sind die Telegramme alle gleich. Also am EMS-Bus sieht das
Telegramm so aus:
<Absender> <Empfänger> <Offset> <Daten ..... Daten> <"CRC"> <Break>
Als Empfänger steht endweder 0x00 für alle, die "normale" Adresse
(0x08=MC10) oder das Polling (0x88 für MC10)
an dem Service-key zum PC (3964R):
0x04 <Absender> <Daten> <DLE(0x10)> <ETX(0x03)> <BCC(XOR)>
Dabei werden alle 0x10 in den Daten gedoppelt damit sie von dem DLE
unterschieden werden können.
Vom Service-Key ein Telegramm mit den Schaltzeiten und anderen Daten:
RX: 04 10 10 3F 00 01 21 00 84 21 21 ........ 10 03 <BCC>
^^^^^^ gedoppelt wegen 3964R
sieht auf dem EMS-Bus dann so aus:
10 00 3F 00 ........ <CRC>
10 00 3F 1B ........ <CRC>
10 00 3F 36 ........ <CRC>
...
...
...
Rudi schrieb:> Jetzt könnte man eine UART-Simulation schreiben und schauen was da so> alles in der Software passiert ;-)
Also ich werde das auf jeden Fall mal in meine Hardware packen und evtl.
mal testen ob es dann auch mit der Originalsoftware läuft... Vermute mal
dass es dort keine Probleme gibt.
Wie man sieht fragt die OriginalSoftware erst mal die Versionsnummern
mit dem Telegrammtyp 02 ab. Dannach werden alle Telegramme vom
Busteilnehmer abgefragt.
Also scheint der Servicekey verschiedene Abfragemethoden zu haben.
Spezielle Telegramme, oder alle Telegramme.
04 10 02 fragt also die Seriennummern ab (Telegramm 0x02)
04 10 fragt dann alle Telegramme ab (auch noch mal 0x02)
Wie man ja sieht gibt es also dann noch einige Telegrammtypen die bei
mir noch nie auf dem Bus aufgetaucht sind..
Beim Konfig senden sieht man sogar noch mehr Telegramme die Teilweise
nur aus Nullen bestehen...
Gruß
Ingo
Achso... Ob das Offset bei dem EMS-Beispiel jetzt stimmt kann ich nicht
garantieren. Müsste noch mal auf dem BUS mitlesen. Meine aber mich an
die 0x1B als erstes zu erinnern.
Es gibt aber auch eine Möglichkeit nur einzelne Werte zu setzen. Die
kommen eigentlich nur von der RC30 bei mir und gehen zur MC10 oder
seltener zu der 0x09...
IngoF schrieb:>> Jetzt könnte man eine UART-Simulation schreiben und schauen was da so>> alles in der Software passiert ;-)>> Also ich werde das auf jeden Fall mal in meine Hardware packen und evtl.> mal testen ob es dann auch mit der Originalsoftware läuft... Vermute mal> dass es dort keine Probleme gibt.
Ja, ich hatte es damals über VirtualBox und über eine externe Loop
versucht, aber da kannte ich das Format noch nicht. Jetzt sollte es,
auch ohne Hardware, einfacher sein ... ;-)
Verstehe nur Bahnhof :o)
Wie oder was wolltest Du denn machen?
Hast Du die Originalsoftware und möchtest dann den Service-Key
simulieren? Dann an irgendwelchen Parametern herumdrehen und sehen was
sich in der Original-Software ändert?
In die andere Richtung experimentiern und irgendwelche Wert umzustellen
um zu sehen was sich an der Heizung ändert ist bestimmt nicht so eine
gute Idee.. Aber das könnte man auch direkt am EMS-Bus machen.
Ich habe vor das direkt in meine Hardware zu programmieren dass sie sich
auch wie ein Service-Key verhält. Oder eben irgend ein beliebiges
anderes Protokoll. Nur muss ich dann doch wohl irgenwie externen
Speicher für meinen Controller spendieren. Mit dem internen 1,5K RAM
wirds dann eng.
Und dann kann ich mir immer noch die Original-Software mal ansehen ;o)
IngoF schrieb:> Wie oder was wolltest Du denn machen?> Hast Du die Originalsoftware und möchtest dann den Service-Key> simulieren? Dann an irgendwelchen Parametern herumdrehen und sehen was> sich in der Original-Software ändert?
Ich hatte damals zwei serielle Schnittstellen verbunden und an einer
Seriellen die Software und an der anderen ein Terminal bzw. ein kleines
Skript um zu sehen was dort passiert.
> In die andere Richtung experimentiern und irgendwelche Wert umzustellen> um zu sehen was sich an der Heizung ändert ist bestimmt nicht so eine> gute Idee.. Aber das könnte man auch direkt am EMS-Bus machen.
Ja, dann aber nur im Sommer ;-)
> Ich habe vor das direkt in meine Hardware zu programmieren dass sie sich> auch wie ein Service-Key verhält. Oder eben irgend ein beliebiges> anderes Protokoll. Nur muss ich dann doch wohl irgenwie externen> Speicher für meinen Controller spendieren. Mit dem internen 1,5K RAM> wirds dann eng.
Es gibt 32K externes SPI-SRAM von Microchip.
Ich werde einen STM32 zum parsen benutzen. 20K SRAM sollten reichen,
ansonsten hat er noch etwas externes SRAM.
IngoF schrieb:
Nur muss ich dann doch wohl irgenwie externen
> Speicher für meinen Controller spendieren. Mit dem internen 1,5K RAM> wirds dann eng.>> Und dann kann ich mir immer noch die Original-Software mal ansehen ;o)
Ich habe eine PIC zum hause mit eine Ethernet connection.
Es registriert data (Onewire, Serial, ...) und sended UDP packet zum
Synology NAS.
On synology brauche ich Netcat UDP port >file.txt
so brauche ich keine speicher am PIC
Wenn ich zeit habe wollte ich neue Serial data logs senden, diese abend.
Acho, erst werden einmal alle Werte abgefragt z.B. 04 08 18 .....
und hinterher kommen die einzelwerte 20 04 08 18 ...
<TX>20 04
<RX>20 04 08 18 02 D0
<RX>20 04 08 18 02 D5
<RX>20 04 08 18 05 09
<RX>20 04 08 18 1E 82
<RX>20 04 08 18 1F 74
<RX>20 04 10 06 04 0C
<RX>20 04 10 06 05 3A
<RX>20 04 08 34 02 E1
<RX>20 04 08 18 1E 80
<RX>20 04 08 18 1F 75
<RX>20 04 08 18 02 DA
<RX>20 04 08 18 1E 82
<TX>20 04
interessant ist auch dass nur einzelne geänderte Werte übertragen
werden. z. Beispiel an der Kesseltemperatur mit dem Offset 01 und 02.
Auch dort wird nur ein Byte übertragen. also so bald sich ein Byte
ändert wird nur das Byte übertragen und nicht beider Werte der
Temperatur.
Also hat die Software und der Servicekey irgendwo einen Buffer wo alle
alten Werte zwischengespeichert werden.
@Chris_be
Die Software pollt also in einem bestimmten Abstand den Service-Key an
(<TX>20 04 ). Kannst Du in dem original-Log noch erkennen in welchem
Zeitabstand das passiert? Oder sieht das nur so aus als obe das
regelmäßig passiert?
Gruß Ingo
Hallo Ingo,
Ingo F. schrieb:> Also sie wird sehr wahrscheinlich einfach nur ein 82 oder 100 Ohm> Emitterwiderstand für die Stromregelung haben und mit dem Basis am> PIC/Atmega8 hängen. Dann sollte der Strom passen.
Hast du schon einen konkreten Wert ? Welche Kapazitäten benutzt du um
den Bus zu glätten (Stromversorgung hinter den Dioden).
Grüße.
Rudi schrieb:> Hast du schon einen konkreten Wert ?
Nö, leider nicht. Muss noch fleissig programmieren und finde nicht
wirklich oft Zeit dafür. Allerdings müssten beide funktionieren
Im Moment hört mein Controller garnicht mehr auf zu senden und hängt in
einer Endlosschleife die mir unerklärlich ist :o)
Kann ja schlecht an der "Sendestufe" basteln wenn nichts zu senden ist.
@Chris ich meinte den Abstand zwischen dem senden dieses Telegramme, das
vermutlich immer in bestimmten abständen kommt:
> <20101109202134.215 TX>> 2004100337
Gruß
Ingo
Hi,
ich bin grad mal wieder mit dem Oszi an der Heizung um die Sendefunktion
zu implementieren. So wie ich das sehe kommt die abzufragende Adresse
mit bit 7 gesetzt und danach das Break. Wenn der Buspegel auf 1 ist,
sendet die angefragte Station mit genau 1 Byte und wartet auf das
"Busecho", wenn alles stimmt das nächste usw.. Am Ende der Übertragung
schickt die Station ein Break.
Ich benutze einen FET und 50 Ohm Serienwiderstand.
Wenn die Anfrage nicht beantwortet werden kann, fliegt die Station aus
der Liste und bei der nächsten erfolgreichen Anfrage ist sie wieder
dabei.
Grüße.
IngoF schrieb:> cool...>> wie hast Du dass denn hinbekommen? Welches Telegramm war das denn?
Ich warte auf das 0x8B BRK und antworte danach so schnell wie möglich
mit 0x0B BRK. Nach jedem gesendeten Zeichen musst du den Bus auslesen,
um das Echo (dein gesendetes Zeichen) zu verifizieren. Wenn der Bus auf
Low liegt, kann man wohl nicht senden.
Das Zurücklesen habe ich bisher nur durch ein Delay realisiert (etwas
länger als ein Frame) und ich schau auch nicht ob ich zu spät sende
(Kollision mit einer anderen Station), weswegen die Station ab und zu
aus der Liste rausfliegt.
Grüße.
Rudi schrieb:> Ich warte auf das 0x8B BRK und antworte danach so schnell wie möglich> mit 0x0B BRK. Nach jedem gesendeten Zeichen musst du den Bus auslesen,> um das Echo (dein gesendetes Zeichen) zu verifizieren. Wenn der Bus auf> Low liegt, kann man wohl nicht senden.
Ja, das war mir schon klar....
Wie hast Du denn das "COMPUTER" auf die RC-30 gezaubert? Bei mir steht
bei unbekannten Adressen nur "GERÄT". Liegt dann wohl vermutlich an
Deiner neueren Firmware der RC30 und nicht an einem Telegramm in der man
den Namen des Busteilnehmers übergeben kann...
Gruß
Ingo
Hallo,
IngoF schrieb:> Wie hast Du denn das "COMPUTER" auf die RC-30 gezaubert? Bei mir steht> bei unbekannten Adressen nur "GERÄT". Liegt dann wohl vermutlich an> Deiner neueren Firmware der RC30 und nicht an einem Telegramm in der man> den Namen des Busteilnehmers übergeben kann...
Kennt deine Firmware den Servicekey noch nicht ?
Grüße.
Hallo,
ich klinke mich hier auch mal ein, da wir in den nächsten Wochen eine
neue GB172 Heizung mit RC35 Steuerung bekommen. Ich denke, dass ist doch
EMS-Bus, oder?
Ich möchte gern einige Daten der Heizung dauerhaft mitloggen und da bin
ich auf diesen Beitrag gestoßen.
Was empfehlt Ihr mir, wo ich die Daten abgreife? An der
Service-Schnittstelle oder am 2-adrigen Kabel zur RC35?
Was brauche ich da an Pegelwandler? Wie ich das verstanden habe
verwendet der EMS-Bus 9600 Baud?
Sorry, ich bin Windows-Softwareentwickler, werde mir eine passende
Windows-Software schreiben, aber von der Elektronik habe ich nicht so
eine tiefgreifende Ahnung. Vielleicht kann mir auch jemand so einen
Pegelwandler anbieten mit einer seriellen Schnittstelle, wo ich dann
"nur noch" meine Software horchen lassen kann.
Danke schonmal.
Dirk
Noch eine andere Frage: Was steckt in dem Original Service-Key? Ich
würde den sonst nachbauen oder vielleicht hat den jemand gebraucht
abzugeben. Die Software hat mein Heizi als Demo-Version, das würde mir
erstmal reichen, bräuchte nur den Service-Key...
Hallo,
Dirk Janssen schrieb:> Was empfehlt Ihr mir, wo ich die Daten abgreife? An der> Service-Schnittstelle oder am 2-adrigen Kabel zur RC35?
Ich habe zuerst mit der 3-Draht Lösung gearbeitet und benutze jetzt die
2-Draht Lösung, die funktioniert soweit. Mich stört aber noch die
fehlende galvanische Trennung, weil ich die Heizung nicht mit der
Hausinstallation verbinden will.
Dirk Janssen schrieb:> Was brauche ich da an Pegelwandler? Wie ich das verstanden habe> verwendet der EMS-Bus 9600 Baud?
Du brauchst einen Komparator. Ingo hat die Schaltung weiter oben schon
gepostet.
Dirk Janssen schrieb:> Noch eine andere Frage: Was steckt in dem Original Service-Key? Ich> würde den sonst nachbauen oder
Siehe oben.
> vielleicht hat den jemand gebraucht> abzugeben. Die Software hat mein Heizi als Demo-Version, das würde mir> erstmal reichen, bräuchte nur den Service-Key...
Tja, wenn es den so "billig" geben würde, würde es diesen Thread nicht
geben.
Rudi schrieb:> Ich habe zuerst mit der 3-Draht Lösung gearbeitet und benutze jetzt die> 2-Draht Lösung, die funktioniert soweit.
Warum hast du dich denn umentschieden? Gibt es da Vorteile?
Habe meine "Servicekeylösung" nun am laufen und parse einige Daten mit
einem Arduino-Clone (Jeenode) und funke die zu meinem Server.
Kann man den Servicekey eigentlich "emulieren"? Wie schmeisst der denn
die Daten an den Rechner raus? Steige langsam nicht mehr durch bei der
Mischung hier ;-)
Fred Granna schrieb:> Rudi schrieb:>> Ich habe zuerst mit der 3-Draht Lösung gearbeitet und benutze jetzt die>> 2-Draht Lösung, die funktioniert soweit.>> Warum hast du dich denn umentschieden? Gibt es da Vorteile?
Ein Vorteil (und Grund für mich, die 2-Draht-Variante zu nehmen) ist auf
alle Fälle, dass man den Bus irgendwo zwischen Brenner und RC30/35
abgreifen kann. Dadurch hat man keine komisch rumhängenden Kabel - im
Keller mag das ja ok sein, bei mir steht die Heizung aber im HWR, da
soll es schon ordentlich aussehen ;-)
Hallo,
Fred Granna schrieb:> Warum hast du dich denn umentschieden? Gibt es da Vorteile?
Hauptsächlich wegen der offenen Klappe. Im Keller staubt die schön.
Außerdem musste ich immer den Stecker ziehen, damit die Heizungsleute
hinter die Abdeckung kommen.
Ich suche jetzt eigentlich noch eine Isolationsmöglichkeit für die
RX/TX-Leitung. Durch die 2-Draht Lösung gibt es nicht mehr viel Strom.
Fred Granna schrieb:> Kann man den Servicekey eigentlich "emulieren"? Wie schmeisst der denn> die Daten an den Rechner raus? Steige langsam nicht mehr durch bei der> Mischung hier ;-)
Schau dir die Posts von chris_be und IngoF an, dort steht einiges
darüber.
Rudi schrieb:> Hallo,>> Fred Granna schrieb:>> Warum hast du dich denn umentschieden? Gibt es da Vorteile?>> Hauptsächlich wegen der offenen Klappe. Im Keller staubt die schön.
Ahso. Ich hab gleich einen abgewinkelten Stecker genommen. Klappe ist
bei mir also zu :)
Hi Fred,
kannst Du bitte mal was zu deiner Jeenode-Lösung posten ?
Fred Granna schrieb:> Habe meine "Servicekeylösung" nun am laufen und parse einige Daten mit> einem Arduino-Clone (Jeenode) und funke die zu meinem Server.
Gruss
Guenne
Würde ja auch gerne was neues erzählen :o(
... dummerweise funktioniert mein Programm auf dem PIC im MPLAB-Debugger
einwandfrei aber nicht im Betrieb. Und meinen Debugmode im PIC selber
mit PicKit3 kann ich im MPlab nicht aktivieren.
Falls irgendjemand irgendwann eine Idee haben könnte wie man in den
Debugmode beim PIC18F258 kommt wäre ich für jeden Hinweis dankbar.
Vielleicht verirrt sich ja mal ein PIC-Nutzer in diesen Thread ;o)
Rudi schrieb:> Ich suche jetzt eigentlich noch eine Isolationsmöglichkeit für die> RX/TX-Leitung. Durch die 2-Draht Lösung gibt es nicht mehr viel Strom.
@Rudi,
meintest Du damit eine galvanische Trennung? Wäre das einfachste nicht
jeweils ein Optokoppler für die RX und TX-Leitung direkt am Controller?
Der Strom für die Sende/Empfangsschaltung sollte ja kein Problem sein...
Gruß
Ingo
Hallo,
ich habe keinen PIC aber schau mal dort, evtl. ist es das schon:
Beitrag "Debugging mit PICKIT3?"IngoF schrieb:> meintest Du damit eine galvanische Trennung? Wäre das einfachste nicht> jeweils ein Optokoppler für die RX und TX-Leitung direkt am Controller?> Der Strom für die Sende/Empfangsschaltung sollte ja kein Problem sein...
Ja, eine galvanische Trennung. Mit LDO und Optokoppler funktioniert es
bei mir nicht mehr, der Bus spinnt dann rum (mit der 2-Draht Variante).
Mit der 3-Draht Variante habe ich es nur mit einem Funktionsgenerator
und externer VCC probiert. Offensichtlich reicht der Strom nicht aus.
Hallo,
mal etwas Semi-OT. Wurde bei euch in der Logomax schonmal der Lüfter für
den Brenner getauscht ? Nach einer längeren Wartungsarbeit gabs nur 6L /
229 und keine Flamme. Der Lüfter ist auch etwas laut, meinte der
freundliche Heizungsfachmann. Nach mehreren Versuchen der
Heizungsanlage, von Flamme an auf Fehlermeldung, lief es dann irgendwann
wieder wie geschmiert.
Grüße.
hi rudi,
was hast du denn genau für ein gerät? logamax ist nur so eine art
familienname für wandhängende heizgeräte.
@ all
bei der gelegenheit möchte ich mich auch gleich in sachen ems an bord
melden. im gegensatz zu den meisten hier, habe ich nicht das ziel daten
zu loggen, sondern meinen Brennwertkessel (gb142) durch die vorgabe eine
brennerleistung anzusteuern. am ende soll eine außentemperaturgeführte
rücklaufregelung dabei herauskommen.
ich habe vor das telegramm des moduls em10 zu ermitteln um es dann mit
einem avr zu emulieren. das em10 hat die fähigkeit ein ems-heizgerät
temperatur- oder leistungsgeführt anzusteuern, wobei es selbst ein 0-10v
signal als führungsgröße hat.
an dieser stelle auf jeden fall schon mal einen herzlichen dank an die
beiden ems-hauptakteure rudi und ingo. soweit wäre ich aus mangel an
equipment und know-how nie gekommen.
ich arbeite übrigens seit 18 jahren als servicetechniker des
werkskundendienstes von buderus.
achso ... ich habe mal das bus interface eines moduls mm10 aufgedröselt
und zu 'papier' gebracht (siehe anhang).
//niffko
Niff Ko schrieb:> was hast du denn genau für ein gerät? logamax ist nur so eine art> familienname für wandhängende heizgeräte.
Das ist die GB152.
Niff Ko schrieb:> achso ... ich habe mal das bus interface eines moduls mm10 aufgedröselt> und zu 'papier' gebracht (siehe anhang).
Das ist doch mal etwas. Hast du zufällig Angaben für den maximalen Strom
für die einzelnen Komponenten am Bus ? Werden die 5V aus der VREF
erzeugt ?
Niff Ko schrieb:> am ende soll eine außentemperaturgeführte> rücklaufregelung dabei herauskommen.
Du willst über die Temperaturdifferenz Vorlauf/Rücklauf (Wärmeabgabe)
den Brenner steuern ? Ohne das Wissen der momentanten Zirkulation wird
das nicht funktionieren, es sei denn du zapfst noch einen
Wärmemengenzähler an. Wenn ich dich richtig verstanden habe ;-)
Danke & Grüße.
hi rudi,
> Das ist die GB152.
das gebläse gehört bei 6L/229 erst mal nicht zu den üblichen
verdächtigen. abnormale geräusche kommen in der regel vom lager, hatte
ich hin und wieder schon. fehler 6L bedeutet, dass das flammensignal
(ionisation) vorhanden war aber dann zusammengebrochen ist. hier hätte
man sich bei auftreten des fehlers mal den wert des flammenstromes im
monitor anschauen können. evtl. schwächelt deine ionisationselektrode,
die zeigen manchmal erst bei längerer auskühlung ihr wahres gesicht.
>Hast du zufällig Angaben für den maximalen Strom>für die einzelnen Komponenten am Bus ?
negativ.
>Werden die 5V aus der VREF erzeugt ?
nein. U_REF -> ~0,6V, die geht lediglich auf die komparatoren. 5V
kommen vom netzteil des moduls.
> Du willst über die Temperaturdifferenz Vorlauf/Rücklauf (Wärmeabgabe)> den Brenner steuern ? Ohne das Wissen der momentanten Zirkulation wird> das nicht funktionieren, es sei denn du zapfst noch einen> Wärmemengenzähler an. Wenn ich dich richtig verstanden habe ;-)
du meinst, die abgegebene wärmemenge berechnen und dann eine
entsprechende brennerleistung vorgeben? nein. anstatt wie üblich
abhängig von der aussentemperatur die vorlauftemperatur auszuregeln,
wird bei der rücklaufregelung - du ahnst es bereits - die
rücklauftemperatur als führungsgröße benutzt. das hat ein paar vorteile,
googel das mal.
//niffko
Niffko schrieb:> du meinst, die abgegebene wärmemenge berechnen und dann eine> entsprechende brennerleistung vorgeben? nein. anstatt wie üblich> abhängig von der aussentemperatur die vorlauftemperatur auszuregeln,> wird bei der rücklaufregelung - du ahnst es bereits - die> rücklauftemperatur als führungsgröße benutzt. das hat ein paar vorteile,
Die Vorteile sind mir schon klar, aber schau dir mal das Bild im Anhang
an. Die Rücklauftemperatur sinkt, da die Thermostate zu gemacht haben,
es gibt so gut wie keine Zirkulation mehr. Der Vorlauf fährt brav seine
Kurven, durch Mikrozirkulation etc..
Wenn du nun die Rücklauftemperatur als Führungsgröße nimmst, würde der
Vorlauf ansteigen ohne nennenswerte Änderung der Führungsgröße
(Rücklauftemperatur).
Wie willst du das Problem ohne weitere Regelgrößen erschlagen ?
Grüße.
Gibts eigentlich noch mehr Informationen über die Telegramme des
Servicekeys? Habe schon einiges raus (anhand der Listen und PDFs hier).
Mir fehlt allerdings z.B. noch die RÜcklauftemperatur.
IngoF schrieb:> Na dann hast Du nicht richtig gesucht:> Beitrag "Re: Logamatic 2107 Schnittstelle">> Gruß> Ingo
Hallo und Danke. Das hatte ich auch schon gefunden. Allerdings bekommen
ich die Daten für Druck und Rücklauf nicht (nur werte von 128 oder 255
die sich nicht ändern). Die anderen Werte bekomme ich ordentlich raus.
Bissl komisch
Fred schrieb:> Hallo und Danke. Das hatte ich auch schon gefunden. Allerdings bekommen> ich die Daten für Druck und Rücklauf nicht (nur werte von 128 oder 255> die sich nicht ändern). Die anderen Werte bekomme ich ordentlich raus.
Werden die digitalen Werte an der Anlage richtig angezeigt ?
Ja, alles ok. Brennerstatus, Flamme,Zündung, Pumpe HKx, Ventile,
Flammenstrom, Kessel-Soll,Kessel-Ist, WW etc.pp. das geht soweit alles.
Rudi schrieb:> Fred schrieb:>> Hallo und Danke. Das hatte ich auch schon gefunden. Allerdings bekommen>> ich die Daten für Druck und Rücklauf nicht (nur werte von 128 oder 255>> die sich nicht ändern). Die anderen Werte bekomme ich ordentlich raus.>> Werden die digitalen Werte an der Anlage richtig angezeigt ?
Fred schrieb:> Allerdings bekommen> ich die Daten für Druck und Rücklauf nicht (nur werte von 128 oder 255> die sich nicht ändern). Die anderen Werte bekomme ich ordentlich raus.> Bissl komisch
Hallo Fred,
kann dann ja eigentlich nur mit dem Softwarestand Deiner Busteilnehmer
zusammenhängen oder mit Deiner Anlage. Wie sieht dass denn bei Dir aus?
Gruß
Ingo
Fred schrieb:> Ja, alles ok. Brennerstatus, Flamme,Zündung, Pumpe HKx, Ventile,> Flammenstrom, Kessel-Soll,Kessel-Ist, WW etc.pp. das geht soweit alles.
Ich meinte die beiden Werte die du per ServiceKey nicht richtig siehst.
@Ingo F.
Wie sieht was bei mir aus? :-) Ist eine Logamax Plus GB172 mit BC10 und
RC35.
@rudi
Was meinst du genau?
Die Softwareversionen kann ich erst heute Abend abfragen.
Fred schrieb:> @rudi> Was meinst du genau?
Zeigt die Anlage den Druck und den Rücklauf richtig an ? Also die beiden
Werte bei denen du nur 128 und 255 auf der seriellen Schnittstelle
siehst.
Rudi schrieb:> Fred schrieb:>> @rudi>> Was meinst du genau?>> Zeigt die Anlage den Druck und den Rücklauf richtig an ? Also die beiden> Werte bei denen du nur 128 und 255 auf der seriellen Schnittstelle> siehst.
Ah, das meinst du. Zu finden ist das im Servicemenü der BC10? Muss ich
nachher gleich mal schauen.
Fred schrieb:> Allerdings bekommen> ich die Daten für Druck und Rücklauf nicht (nur werte von 128 oder 255> die sich nicht ändern).
... das ist schon o.k. so - der gb172 hat weder rücklauf- noch
drucksensor.
Fred schrieb:
> Ist eine Logamax Plus GB172 mit BC10 und RC35.
der bc10 heißt beim 172er bc25 ;-)
//niffko
Rudi schrieb:> Die Vorteile sind mir schon klar, aber schau dir mal das Bild im Anhang> an. Die Rücklauftemperatur sinkt, da die Thermostate zu gemacht haben,> es gibt so gut wie keine Zirkulation mehr. Der Vorlauf fährt brav seine> Kurven, durch Mikrozirkulation etc..
hmm ... was meinst du mit mikrozirkulation? evtl. die zirkulation im
gerät über einen bypass (überströmventil), wenn der heizkreis dicht
gemacht hat? deine rücklauftemperatur dürfte sich normalerweise nicht
wie von dir beschrieben verhalten. der rücklauffühler sitzt innerhalb
des bypasskreises, die rücklauftemperatur müsste also bei geschlossenen
thermostatventilen mit nur geringem delta der vorlauftemperatur folgen.
Rudi schrieb:> Wie willst du das Problem ohne weitere Regelgrößen erschlagen ?
das problem stellt sich bei mir nicht. ich habe die heizkreise meiner
fußbodenheizung abgeglichen und die heizkennlinie entsprechend
angepasst. so benötige ich keine zonenventile, die heizkreise sind also
immer offen.
//niffko
Niffko _ schrieb:> hmm ... was meinst du mit mikrozirkulation? evtl. die zirkulation im> gerät über einen bypass (überströmventil), wenn der heizkreis dicht> gemacht hat?
Das warme Wasser steigt nach oben und Zirkuliert oder ein Ventil ist
nicht 100%ig zu etc.. Das meinte ich damit. Meine Temperatursensoren an
den Rohren sehen ab und zu etwas zuviel bzw. sind nicht träge genug.
> deine rücklauftemperatur dürfte sich normalerweise nicht> wie von dir beschrieben verhalten. der rücklauffühler sitzt innerhalb> des bypasskreises, die rücklauftemperatur müsste also bei geschlossenen> thermostatventilen mit nur geringem delta der vorlauftemperatur folgen.
Das ist eine Rücklauftemperatur von 3 Heizkreisen, ob es einen Bypass
gibt, kann ich nicht sagen. Wie es sich mit dem Hauptrücklauf verhält,
wenn alle 3 Heizkreise dicht gemacht haben, weiss ich noch nicht. Ich
werde das demnächst mal ausprobieren.
Grüße.
Rudi schrieb:> Das ist eine Rücklauftemperatur von 3 Heizkreisen ...
ich war davon ausgegangen, dass es sich um einen ems-wert handelt. dann
hätte es nur der kesselrücklauf sein können, da keine heizkreisrückläufe
erfasst werden. ob an deinen heizkreisen überströmventile vorhanden
sind, weiß ich natürlich nicht. deine gb152 jedenfalls ist mit einem
internen überströmventil ausgestattet.
ich habe nur einen ungemischten heizkreis, daher ist kesseltemperatur
gleich heizkreistemperatur und ich kann den ems-wert des
kesselrücklaufes als führungsgröße benutzen.
//niffko
Hallo,
ich hab seit ein paar Monaten eine GB 162 und würde gern zur Optimierung
der Anlage die Daten zumindest wochenweise mit einem alten Notebook
aufzeichnen und mit der Buderus Software auswerten.
Laut Buderus kostet der dazu erforderliche Service Key 214.-€.
Wenn ich mir den Thread so durchlese scheinen es einige unter euch
geschafft zu haben einen "ServiceKey" selbst zu basteln.
Funktionieren diese Lösung tatsächlich so, dass die gleichen
Monitorwerte wie mit dem original ServiceKey ausgelesen werden können ?
Mit welchen Kosten ist so ein Eigenbau zu realisieren, sprich rechnet
sich der Aufwand im Vergleich zu Originalteil ?
Viele Grüße
buddi
Hallo,
buddi schrieb:> Funktionieren diese Lösung tatsächlich so, dass die gleichen> Monitorwerte wie mit dem original ServiceKey ausgelesen werden können ?
Nein, dort siehst du direkt den EMS-Bus.
> Mit welchen Kosten ist so ein Eigenbau zu realisieren, sprich rechnet> sich der Aufwand im Vergleich zu Originalteil ?
Ich denke nicht mehr als 10€ für die Bauteile.
Hallo,
> Funktionieren diese Lösung tatsächlich so, dass die gleichen> Monitorwerte wie mit dem original ServiceKey ausgelesen werden können ?
Nein, dort siehst du direkt den EMS-Bus.
...ähm - wie muss ich mir das vorstellen, welche Daten bekomm ich da
geliefert und werden die mit der Buderus-Software angezeigt ?
> Mit welchen Kosten ist so ein Eigenbau zu realisieren, sprich rechnet> sich der Aufwand im Vergleich zu Originalteil ?
Ich denke nicht mehr als 10€ für die Bauteile.
...bekomm ich das als normaler Bastler mit einer kleinen Anleitung hin ?
Gruß
buddi
Hallo,
buddi schrieb:> ...ähm - wie muss ich mir das vorstellen, welche Daten bekomm ich da
Die Daten/Telegramme vom EMS-Bus (siehe weiter oben).
Mit Service Key sieht es etwa so aus:
EMS-Bus (EMS-Telegramme) -> ServiceKey (Service Key Protokoll) ->
Buderus Software oder Terminal
Mit dem Nachbau so:
EMS-Bus (EMS-Telegramme) -> Nachbau (EMS-Telegramme) -> Terminal
> geliefert und werden die mit der Buderus-Software angezeigt ?
Nein, die versteht das Format nicht direkt, nur wenn die Daten
aufbereitet werden, wie durch den ServiceKey.
> ...bekomm ich das als normaler Bastler mit einer kleinen Anleitung hin ?
Ich denke das sind alles Teile die du bei R. bestellen kannst. Es gibt
hier im Thread mindestens 3 Schaltungen.
Das EMS-Protokoll ist hier auch etliche male beschrieben worden,
zumindestens alle wichtigen Teile zur Überwachung der aktuellen Werte
und Einstellungen.
Grüße.
Nabend,
ich habe jetzt das Senden an die Anlage hinbekommen :=) ServiceKey ist
in der Geräteliste aufgeführt, also alles bingo :-D
Jetzt versuche ich die ganze Sache mit der ECO-SOFT zu verbinden. Dazu
schnüffel ich grad ein wenig am COM-Port des Rechners rum.
Nun meine Fragen:
1. Ist es richtig das die Software als erstes ein 0x02 sendet?
2. Wenn ich auf dieses 0x02 mit 0x10 antworte bekomme ich
0x00 0x00 0x10 0x03 0x13; Was bedeuten diese Werte überhaupt?
3. Auf den obigen String antworte ich mit 0x10 0x02. Daraufhin bekomme
ich 0x10 von der Software zurück. Da ich dann nichts mehr antworte, gibt
mir die Software die Fehlermeldung "Keine ComKarte gefunden !!!"
Woher weiss ich eigentlich das ein "Telegramm" von der Software komplett
gesendet wurde? Kommt z.B. nach "0x00 0x00 0x10 0x03 0x13" ein
UART-Break? Trennzeichen habe ich da nirgends :-/
Das sollte die Prozedur 3964R sein.
Habe mal meine Erkenntnisse aus den Logs von Chris_be hier gepostet:
Beitrag "Re: Logamatic 2107 Schnittstelle"Beitrag "Re: Logamatic 2107 Schnittstelle"
generell kommt ein 04 davor. Bei einzelnen geänderten Werten zusätzlich
noch eine 20.
Die Originalsoftware fragt erst alle Seriennummern der Busteilnehmer und
anschließend alle Telegramme ab.
Dannach könnte man mit den Monitorwerten, die ja änderungen der
einzelnen Bytes im Telegramm sind, alle Änderungen verfolgen,
Gruß
Ingo
Hm, das hatte ich schon gesehen.
Derzeit sende ich allerdings nichts an den Bus sondern habe als
Gegenstelle zur ECO-SOFT einen Atmega zur Analyse.
Das erste was ich von der ECO-SOFT bekomme ist einfach nur 0x02. Mehr
nicht, auch leider keine Trennzeichen.
Wenn ich darauf nicht antworte kommen noch 2x "0x02" nacheinander und
dann 0x15 (ist wohl der Abbruch).
Das mit den nicht vorhandenen Telegrammstrennern stört mich ein wenig.
Wenn ich das dann später auf den Bus schicke muss ich doch wissen wann
ich ein BREAK setzen muss oder?!
Das ist das Handshake vom 3964R-Protokoll. Es gibt dort kein Break. Das
wird alles über das 3964R-Protokoll gemacht.
Einfach mal googeln. Die eigentlichen Daten kommen dann erst. Erst mal
fragt die Ecosoft alle Busteilnehmer nach den Serienummern und den
Telegrammen ab.
Und wenn auf die Abfrage keiner antwortet wird die Eco-Soft auch wohl
keine Lust mehr haben weiter zu reden.
Oder habe ich irgendwas falsch verstanden.?
Gruß
Ingo
So, das war schonmal recht erfolgreich.
- EMS-Verbindung Heizung <-> uC läuft
- Verbindung PC(Ecosoft) <-(3964R)-> uC läuft
Nun aber wieder ein paar Fragen g. Ich möchte ja nun beides
zusammenbringen :)
Wenn ich die Kommunikation in der Ecosoft starte sendet diese als erstes
"0x00 0x00".
Darauf Antworte ich dann mit "0x00 0x00 0x00 0x00 0x53 0x02 0x31".
Nun hat die Ecosoft schomal meinen "ServiceKey" identifiziert.
Laut dem Log hier aus dem Forum (serial_logamatic_0911_.txt) müsste ich
dann noch folgendes an die Ecosoft schicken?!
<RX>00 00 01 00 00 00 03 00 01 03
<RX>00 00 02 00 08 0A 0C 0E 10 12 14 16 18 1A 1C 1E
Das Abfragen der werte beginnt offenbar ja erst danach:
<TX>04 08 07 .. .. ......
TX: 00 00
RX: 00 00 00 00 53 02 31
RX: 00 00 01 00 00 00 03 00 01 03
RX: 00 00 02 00 08 0A 0C 0E 12 14 16 18 1A 1C 1E
TX: 04 08 07
RX: 04 08 07 00 0B 01 01 02 00 00 00 00 00 00 00 00 00 00 00
TX: 04 08 02
TX: 04 09 02
RX: 04 08 02 00 48 02 04 4B 02 14 00 00 00
RX: 04 09 02 00 44 02 00
Also ich vestehe dass so dass mit der "00 00" alle Telegrammtypen vom
Gateway selber abgerufen werden. Fragt sich nur was passiert wenn man
diese Telegramme weglässt. Vielleicht steht ja auch drin welche
Busteilnehmer am Bus hängen. Oder muss man bei der EcoSoft vorher
angeben welche Busteilnehmer in der Anlage sind?
Irgend eine Bedeutung müssen die Werte ja haben. Notfalls einfach mal
ausprobieren ob sich die Ecosoft dann anders verhält wenn man andere
Werte oder keine Werte schickt.
Wenn die "00 00 00" gekommen wäre würde sich die Ecosoft ja nur für die
Seriennummer interessieren. Also müsstest Du demnach auch alle
Telegramme schicken...
Gruß
Ingo
Man KANN wohl vorher angeben welche Geräte verbaut sind. Man muss aber
nicht.
Was ich schonmal gefunden habe:
00 00 00 00 53 02 31
0x53 = ServiceKey, 0x52 = "EcoTool"
0x02 = DEC 2 = Version 2
0x31 = DEC 49 = Version.49
Ich sende da 0x53 0x00 0x63, da meint die EcoSoft dann ich habe einen
Servicekey in der Version 0.99 :-)
Ich probier da morgen mal weiter!
Hallo an alle,
ich habe es endlich geschafft meine Software für die Hardware so langsam
in den Griff zu bekommen ;-)
Ich möchte eine Platine für meine Hardware fertigen lassen.
Darauf befindet sich ein PIC18F2585. Die Hardware soll dann über
DIP-Schalter konfiguriert werden können.
Je nach Hardwarebestückung und DIP-Schalterstellung gibt es verschieden
Modes:
1) nur mitlesen und ausgeben der Telegramme über die serielle
Schnittstelle. Ausgabe im Textmodus oder als RAW-Daten mit "0xaa 0x55
0xaa 0x55" anstelle des <Break> was auf dem EMS-Bus. Beim Textmodus wird
ein CR&LF gesendet damit nur ein Telegramm in einer Zeile steht.
2) mitlesen und senden. Dazu würden dann zwei Platinen benötigt und die
Kommunikation läuft über den CAN-Bus. Hat den Vorteil dass man dann
später mehrere Module anschließen könnte. Z.B. ein eigenes Display für
Fehleranzeige oder alles andere.
Ich würde die Platine fertigen lassen. Es gibt auch eine möglichkeit die
Platinen schon fertig bestücken zu lassen. Die Platinen gäb es dann zum
Selbstkostenpreis+Versand
Wer hätte interesse daran. Den Preis müsste ich noch erst in Erfahrung
bringen.
Dazu wäre ganz interessant welche Möglichkeiten Ihr habt und was Ihr für
eine bestückte SMD-Platine ausgeben möchtet oder könntet. Will nichts
verdienen...
*) Firmwäre brennen
*) Platine bestücken/löten (DIP)
*) Platine bestücken/löten (SMD)
Allerdings ist die Software für den CAN-Bus noch in der Entwicklung und
würde die Platinen natürlich erst fertigen lassen wenn die Software
fehlerfrei funktioniert.
Die Preise für die Bestückung lohnt sich allerdings erst ab einer
größeren Menge weil eine einzelne Platine sonst 200€ kosten würde und
sinnlos wäre.
Wer will kann ja mal dazu hier posten. Wenn es an die Bestellung geht
gibt dann hier noch mal eine e-Mail oder URL. Kann allerdings nichts
über den Zeitplan sagen. Ist eben nur ein Hobby von mir und habe nicht
immer Zeit um daran zu arbieten.
Gruß
Ingo
Die Emulation eines ServicKey wird erst mal nicht funktionieren aber
vielleicht auch irgendwann mal damit funktionieren.
Servus Ingo,
ja, das klingt gut :-)
An einer solchen, möglichst unbestückten Platine hätte ich Interesse.
Da ich schon was älter bin und gerne zittere ;-), wäre mir persönlich
eine dip Version lieber. Aber ich würde auch bei einem smd Board nicht
nein sagen, abhängig vom Preis natürlich.
Danke für Deine Mühe und Arbeit und
einen guten Rutsch
an alle EMS-Bus-Freaks ;-).
Guten Morgen und frohes neues Jahr :)
@ingo: Das hört sich interessant an!
An der emulation eines Servicekeys arbeite ich ja grad. Das ganze läuft
derzeit auf einem Arduino-Klon. Auf EMS-Seite nutze ich einen i2c-UART.
Der kann per Registersetting astreine Breaks auf den Bus zaubern :-)
Die Kommunikation über 3964R läuft super.
Ich habe offenbar noch ein paar Probleme beim Senden auf den EMS-Bus.
:-(
Die Anmeldung an das System als ServiceKey (Warten auf 0x8B und dann
Antwort mit 0x08) funktioniert.
Probleme gibt es aber wenn es weitergeht. Die Buderus-Software versucht
ja ersteinmal die angeschlossenen Bausteine zu identifizieren (per 0x04
<geräteid> 0x02). Bei den Abfragen bekomme ich aber nur Müll zurück.
Worauf muss ich beim Senden achten?
>Nach jedem gesendeten Zeichen musst du den Bus auslesen,>um das Echo (dein gesendetes Zeichen) zu verifizieren. Wenn der Bus auf>Low liegt, kann man wohl nicht senden.
Ich muss also mit dem Senden warten bis der Bus frei ist. Wie erkenne
ich das am besten in der Software? Warten bis ein Break auf dem Bus
auftaucht (also ein Abschluss eines Telegramms auf dem Bus) und dann
einfach lossenden?
Zusatzfrage: Mein Sender läuft derzeit über einen OP der das TX-Signal
vom UART invertiert und dann über einen Transitor der eine Z-Diode
"durchschaltet". Ist das hier noch "state-of-the-art" oder gibt es
besseres?
Fred Granna schrieb:> Die Anmeldung an das System als ServiceKey (Warten auf 0x8B und dann> Antwort mit 0x08) funktioniert.
Na das ist vermutlich ein Tippfehler. Antworten müsstest Du auf das
Polling vom Servicekey 0x8b mit Der ServiceKey Adresse 0x0B und nicht
0x08 ;o)
Fred Granna schrieb:> Probleme gibt es aber wenn es weitergeht. Die Buderus-Software versucht> ja ersteinmal die angeschlossenen Bausteine zu identifizieren (per 0x04> <geräteid> 0x02). Bei den Abfragen bekomme ich aber nur Müll zurück.
Wichtig wäre zu wissen was Du bekommst und was Du sendest.
Vermute mal dass Du auf das Polling 0x8b mit 0x0b beantwortest und dann
das Telegramm schickst. Das ist meiner Meinung nach falsch.
Der Busmaster 0x08 sendet das Polling und übergibt somit die Kontrolle
jeweils einem einzigen Slave mit der Adresse. Und wartet eine bestimmte
Zeit. Wenn nichts kommt existiert der Busteilnehmer nicht und wird erst
mal für eine Zeit nicht mehr abgefragt. Wenn der Busteilnehmer beim
nächsten mal abgefragt bekommt er die Adresse des Slave zurück. Der
Busmaster weiss jetzt dass der Busteilnehmer vorhanden ist und und fragt
den Busteilnehmer jetzt viel öfter ab.
Wenn der Slave Daten zum senden hat antwortet er wieder mit der eigenen
Adresse. Dann sendet er die Zieladresse. Es gibt dann folgende drei
Möglichkeiten für eine Zieladresse:
1) 0x00
... Telegramm ist an alle gerichtet er will keine Antwort.
2) <Busadresse> (z.B. 0x08)
... Telegramm ist an einen einzigen Empfänger gerichtet und keine
Antwort erwartet.
3) <Busadresse + 0x80)
... Telegramm ist an einen einzigen Empfänger gerichtet und eine Antwort
wird erwartet.
Danach wird dann die Telegrammadresse gesendet. Wenn der Slave jetzt
Daten mitsendet folgen diese. Das erste Byte ist dann das Offset des
Telegramms. und danach folgen die Daten mit der Prüfsumme.
Wenn der Slave seine Kontrolle über den Bus abgibt weil alle Telegramme
gesendet wurden sendet er anschließend noch ein <Break>
Dann geht das Polling weiter bis zum anderen Busteilnehmer. Dieser kann
dann antworten. Es kann auch sein dass der Busteilnehmer auch erst
später antwortet und nicht sofort auf das nächste Polling mit der
Antwort reagiert.
Also in Deinem Fall würde ich erst mal folgendes Versuchen:
RX: 0x8b <Break>
TX: 0x0b <Break>
.
.
.
RX: 0x8b <Break>
TX: 0x0b 0x88 0x02 0x00 <"CRC"> <Break>
TX: 0x0b <Break>
.
.
.
Vermutlich kann man auch im ersten Durchgang sofort mit dem Telgramm
antworten und muss nicht erst mal nur seine Anweseheit zeigen. Weiss
leider nicht mehr ob der Busmaster sofort mit dem verstärkten Polling
anfängt oder erst drei mal auf eine Antwort vom Busteilnehmer erwartet.
Ist schon zu lange her...
Wenn das nicht so will wie von mir erwartet würde ich auch mal mit
Zieladresse ohne das gesetzte "Antwortbit" versuchen (0x08)
Kann auch sein dass man das Offset (0x00) bei einer Abfrage nicht
mitsenden muss oder darf.
ALso
TX: 0x0b 0x08 0x02 0x00 <"CRC"> <Break>
TX: 0x0b 0x08 0x02 <"CRC"> <Break>
Es kann auch sein dass man nicht wirklich noch zusätzlich mit einer
leeren Antwort am Schluss die Übertragung beenden muss und nach einer
bestimmten Zeit einfach der nächste Busteilnehmer angepollt wird.
Aber wenn mann Pech hat muss man zusätzlich noch irgendwelche Daten
übergeben. Habe gerade mal aus meinem Log ohne Polling die folgen Zeilen
gefunden:
10 89 29 00 01 90
09 10 29 00 6B DF
10 08 35 00 01 01 00
10 88 14 00 03 6E
08 10 14 00 39 AA 1C EC
Meine Vermutung ist aber eher dass z.B. beim ersten Telegramm die RC30
(0x10) die 0x09 auffordert im Telegramm 0x29 mit dem Offset 0x00 das
Byte auf 0x01 zu setzen. Wird dann wohl ein Steuerparameter sein.
Poste doch einfach mal Deine Versuche und die Antwort. Habe selber noch
keine "echten" Sendeversuchen unternommen. Habe nur mal alle Adressen
beantwortet um die Service-Key Adresse herauszufinden. Habe Dummerweise
erst nach der RC30 angefangen zu suchen und die 0x0b also übersehen.
Fred Granna schrieb:> Worauf muss ich beim Senden achten?>>>Nach jedem gesendeten Zeichen musst du den Bus auslesen,>>um das Echo (dein gesendetes Zeichen) zu verifizieren. Wenn der Bus auf>>Low liegt, kann man wohl nicht senden.>> Ich muss also mit dem Senden warten bis der Bus frei ist. Wie erkenne> ich das am besten in der Software? Warten bis ein Break auf dem Bus> auftaucht (also ein Abschluss eines Telegramms auf dem Bus) und dann> einfach lossenden?
Ups ich glaube das habe ich schon mit meiner viel zu ausführlichen
Antwort erschlagen ;o)
Fred Granna schrieb:> Zusatzfrage: Mein Sender läuft derzeit über einen OP der das TX-Signal> vom UART invertiert und dann über einen Transitor der eine Z-Diode> "durchschaltet". Ist das hier noch "state-of-the-art" oder gibt es> besseres?
Das war auch die Methode die ich das letzte mal beim scannen der
Busadressen verwendet habe.
Habe aber danach herausgefunden dass die RC30 und andere "Externe"
Busteilnehmer nicht so "brutale" Sendeversuche unternehmen, sondern nur
der Busmaster 0x08 und evtl die 0x09 die am "internen" Bus hängen.
Beitrag "Re: Logamatic 2107 Schnittstelle"Beitrag "Re: Logamatic 2107 Schnittstelle"
Es reicht also eine schaltbare Stromquelle mit ~40mA (wenn ich mich
recht erinnere) dafür zu nehmen.
Der nächste Versuch ist also bei mir eine Sendestufe bei der der TX-Pin
auf die Basis vom NPN-TRansistor geht und einen Emistterwiderstand gegen
Masse von 80-100 Ohm. Der Kollektor geht dann direkt mit an den EMS-Bus.
Denke das dürfte schon ganz gut gehen.
Rudi hat wohl schon sowas ähnliches mit einem FET aufgebaut.... steht
irgendwo in diesem Thread ;o)
Poste doch mal Deine Versuche und das Ergebnisse... Bin halt neugierig
:o)
Gruß
Ingo
Ui, danke für diese "Ausarbeitung" ;-)
Das bedeutet ja, wenn ich das richtig verstehe, das der Busmaster durch
das Polling eine Art "Sendefreigabe" weiterreicht. Also muss ich mit dem
Senden so lange warten bis der Busmaster mir diese Freigabe per "0x8B
<break>" erteilt.
Das mit dem TX ohne Z-Diode werd ich auch mal ausprobieren.
Sobald das Senden nicht mehr in einem Bus-Chaos endet werd ich berichten
;-)
Fred Granna schrieb:> Das bedeutet ja, wenn ich das richtig verstehe, das der Busmaster durch> das Polling eine Art "Sendefreigabe" weiterreicht.
So könnt man das auch formulieren.
Mann kann auch in den Telegrammdaten eine längere Pause gesehen. Die
RC30 bei mir legt auch mal nach einem Datenhäppchen eine 100ms Pause
ein.
Fred Granna schrieb:> Sobald das Senden nicht mehr in einem Bus-Chaos endet werd ich berichten> ;-)
Ich bin gespannt....
Werde meine Senderversuche erst unternehmen wenn der Empfang und
übertragung über CAN-Bus erst mal problemlos läuft. So weit scheint der
Weg nicht mehr zu sein :o)
Was ich ncoh vergessen habe.
Das Telegramm was man sendet muss man zwischen den Bytes eine Pause von
einem Byte machen damit der Busmaster dieses Byte wiederholen kann (auf
10 V heruntergezogen). Er spielt also so eine Art Repeater damit auch
der in der letzte Reihe auch noch alles mitbekommt. Also genauso wie
beim Polling auch. Vielleicht macht es ja Sinn später nach jedem
gesendeten Byte die eigenen Daten zu vergleichen.
Wenn man irgendwann mal die Schaltung über den EMS-Bus speisen möchte
sollte man die Strombelastung gut Buffern damit nicht ausvershen Daten
gesendet oder der Bus gestört wird.
Gruß
Ingo
Hallo Leute,
kurze Zwischenfrage zum Thema Sendestufe: Warum groß herum
experimentieren, wenn eine original Buderus-Lösung bekannt ist?
Beitrag "Re: Logamatic 2107 Schnittstelle"
Wenn es etwas gibt, was gegen diese Variante spricht, würde mich das
schon interessieren.
Gesundes neues Jahr,
//niffko
Niffko _ schrieb:> Wenn es etwas gibt, was gegen diese Variante spricht, würde mich das> schon interessieren.
Ups, Die Lösung habe ich komplett vergessen :-)
Also ich hatte versucht die RC-30 Sendestufe zu entflechten. Ist mir
allerdings nicht gelungen (Multilayer Platine)
Bin dann zu der gerade geposteten Lösung gekommen.
Allerdings ist diese Lösung auch so etwa der selbe Weg....
Bei der Buderus-Lösung sind vier 910 Ohm Wiederstände parallel und haben
also einen Gesamtwiderstand von 227 Ohm. Der Bus wird also mit ~60mA
belastet. Das wäre auf meine Schaltung übertragen also rechnerisch ein
Emitterwiderstand von ~71 Ohm (68 Ohm).
Den LM393 habe ich zufällig auch in meiner Schaltung und reinzufällig
auch noch eine Hälfte frei. :o)
Spricht also nichts dagegen diese zu übernehmen. Der OP soll wohl noch
dafür sorgen dass man einen saubereren Pegel zur Ansteuerung hat.
DANKE für den Hinweis :o)
Die Buderus-Empfangsschaltung muss ich mir irgendwann noch mal genauer
ansehen. Vermutlich wird die besser sein...
Noch mal zu dem Senden auf dem EMS-Bus.
Habe gerade noch mal im Log mit Polling einen kleinen Ausschnitt gesehen
dass die RC30 bei mir erst das Telegramm sendet und dannach dann eine
leere Antwort. (0x10 <Break>)
Also beendet die RC30 Ihre Buskontrolle mit einem eigenen leeren
Telegramm am Ende.
Gruß
Ingo
Fred Granna schrieb:> Ich muss also mit dem Senden warten bis der Bus frei ist. Wie erkenne> ich das am besten in der Software? Warten bis ein Break auf dem Bus> auftaucht (also ein Abschluss eines Telegramms auf dem Bus) und dann> einfach lossenden?
Wenn du ein Zeichen sendest wird dieses Zeichen vom Master wiederholt,
danach kannst du das nächste Zeichen senden oder eben ein Break für die
Busfreigabe von deiner Seite.
Das sollte in etwa so aussehen:
RX: 8B BRK
TX: 08
RX: 08
TX: Zeichen
RX: Zeichen
....
TX: BRK
RX: BRK
Grüße.
Rudi schrieb:> Wenn du ein Zeichen sendest wird dieses Zeichen vom Master wiederholt...
Stimmt.. ist wohl in der Textflut untergegangen :)
Ingo F. schrieb:> Das Telegramm was man sendet muss man zwischen den Bytes eine Pause...
Rudi schrieb:> Wenn du ein Zeichen sendest wird dieses Zeichen vom Master wiederholt,> danach kannst du das nächste Zeichen senden oder eben ein Break für die> Busfreigabe von deiner Seite.
... ist Dir bekannt wie groß der Zeitraum zwischen einem Echo und dem
nächsten gesendeten Byte sein darf, bevor das Ganze in's Timeout rennt?
//Niffko
Niffko _ schrieb:> ... ist Dir bekannt wie groß der Zeitraum zwischen einem Echo und dem> nächsten gesendeten Byte sein darf, bevor das Ganze in's Timeout rennt?
Pausen von 100ms nach der ersten Antwort mit der eigenen Adresse sind
kein Problem:
Beitrag "Re: Logamatic 2107 Schnittstelle" (Bild1)
Also Pausen von 190ms gibt es mehrere, 200ms habe ich noch keine
gesehen. Bei mir jeweils bei der RC30 die solche Pausen einlegt.
Ingo F. schrieb:> Pausen von 100ms nach der ersten Antwort mit der eigenen Adresse sind> kein Problem:
ja, danke ... dann werde ich wohl auch einfach mit einem 1 Byte + x
Delay senden, anstatt extra den Bus zu überwachen.
//Niffko
Gesundes neues Jahr erstmal ;-)
Niffko _ schrieb:> ja, danke ... dann werde ich wohl auch einfach mit einem 1 Byte + x> Delay senden, anstatt extra den Bus zu überwachen.
Besser wäre senden und auf RX warten mit einem Timeout. Wenn das
empfangene Byte nicht identisch zum gesendeten Byte ist, musst du auf
das nächste 0x8b BRK warten, ansonsten kann die Anlage in eine Störung
gehen -> keine Heizung ;-). Ein Delay wäre dann nicht mehr notwendig und
mit einem RX-Timeout wärst du auch gleich schneller beim Senden, da der
Master in der Regel relativ schnell antwortet.
Rudi schrieb:> Besser wäre senden und auf RX warten mit einem Timeout.
Hmm ... da stehe ich jetzt etwas auf dem Schlauch. Also, ich sende ein
Byte, der Master repeatet und bevor ich das nächste Byte sende, warte
ich auf ... was? Könntest Du mich da noch mal erhellen?
Rudi schrieb:> ... ansonsten kann die Anlage in eine Störung> gehen -> keine Heizung ;-).
... glaube ich nicht, das würde die CRC dann schon richten.
//Niffko
Niffko _ schrieb:> ja, danke ... dann werde ich wohl auch einfach mit einem 1 Byte + x
So groß muss das Timeout ja nicht sein. Meistens kommt die Antwort ohne
Pause oder unter einer Bitlänge. Zwei Bit reicht immer.
Mann müsste einfach sofort das Byte einlesen und vergleichen. Das ist
vermutlich einfacher als ein Delay. Bei einem Fehler sofort mit Break
abbrechen und nochmal neu senden. Denke das dürfte kein Problem sein. Ab
und zu senden die Busteilnehmer ja auch zwei Telegramme hintereinander.
Meine RC30 habe ich schon mal im Log dabei erwischt wie sie ein
Telegramm widerholt hat :o)
Bei einem erneuten Fehler würde ich dann aufs zweite Polling warten.
Rudi schrieb:> Besser wäre senden und auf RX warten mit einem Timeout.
Na das ist eine gute Idee. Hätte erst mal keins eingebaut.
Niffko _ schrieb:> Hmm ... da stehe ich jetzt etwas auf dem Schlauch. Also, ich sende ein> Byte, der Master repeatet und bevor ich das nächste Byte sende, warte> ich auf ... was? Könntest Du mich da noch mal erhellen?
Ups die Antwort hatte ich noch nicht gesehen..
Sicherlich würde es reichen auf 12Bitlängen zu warten. Würde ich aber
nur als Notlösung ansehen.
Am besten auf die Widerholung warten. Wenn nach zwei Bitlängen keine
Antwort kam unterwegs ist dann abbrechen und noch mal neu senden.
vermutlich bekommt man aber nicht mit wenn der UART schon ein Bit
empfangen hat.
Als Timeout wurde ich dann 14 (vielleicht 15) Bitlängen nehmen falls die
MC10 mal nichts wiederholen sollte.
Niffko _ schrieb:> und bevor ich das nächste Byte sende, warte> ich auf ... was?
Vielleicht noch genauer auf Deine Frage. Wenn der Master wiederholt dann
einfach das nächste Byte senden. Rudi meinte das Timeout für den Fall
das der Master nicht antwortet.
Gruß
Ingo
IngoF schrieb:> Rudi meinte das Timeout für den Fall> das der Master nicht antwortet.
Ah jetzt ja ... das war der entscheidende Hinweis, danke. Wobei es bei
mir nicht so tragisch wäre, wenn ein Telegramm mal nicht ankommt, da ich
sie für die Leistungssteuerung eh' periodisch versende.
//Niffko
Hallo Leute,
nachfolgend mal meine Variante des RX-Zweiges als Anregung für eigene
Lösungen.
Die Grundidee ist, zur Signalgewinnung den internen Analog Comparator
eines AVR's zu nutzen und diesen dann mit einer Soft-UART mit FIFO zu
verheiraten. Letzteres stellt in sofern kein Problem dar, da es
Soft-UART Lösungen gibt, die über Input Capture eines Timers getriggert
werden und der Ausgang des Analog Comparators so konfiguriert werden
kann, dass er besagten Input Capture auslöst.
Die Vorteile liegen auf der Hand: der externe Comparator entfällt und
man hat den Hard-UART für die Kommunikation mit dem PC frei. Da man zur
Erzeugung eines Breaks eh' Hand anlegen muss, ist so ein Soft-UART
diesbezüglich auch nicht gerade unpraktisch. Externe Beschaltung siehe
Anhang.
Empfehlenswerter Soft-UART mit FIFO:
Beitrag "Software UART mit FIFO"
//Niffko
Niffko _ schrieb:>> ... ansonsten kann die Anlage in eine Störung>> gehen -> keine Heizung ;-).> ... glaube ich nicht, das würde die CRC dann schon richten.
Jein, wenn du die anderen Teilnehmer zu oft störst, werden diese einfach
abgemeldet und die Anlage geht auf Störung, wenn z.B. der Brenner
verschwunden ist. Aus diesem Grund muss auch jedes z.B. 0x8B BRK
beantwortet werden. Die genaue Anzahl der tolerierten Fehler kenne ich
nicht, müsste man mal austesten.
Niffko _ schrieb:> Da man zur> Erzeugung eines Breaks eh' Hand anlegen muss, ist so ein Soft-UART> diesbezüglich auch nicht gerade unpraktisch. Externe Beschaltung siehe> Anhang.
Damit verbaust du dir eine Entkopplung von E-Heizungskreis und
E-Hausnetz. Ich würde die Konvertierung von den "analogen" Signalen auf
digitale Signale so einfach wie möglich halten, sprich über eine passive
Schaltung.
Ein weiterer Nachteil einer Soft-Uart ist die extreme CPU-Last, da jede
Flanke/jedes Bit vergoldet wird.
Grüße.
Niffko _ schrieb:> nachfolgend mal meine Variante des RX-Zweiges als Anregung für eigene> Lösungen.
Eigentlich auch eine gute Lösung.
Allerdings ist mir ein externer Komperator doch irgendwie lieber. Und
sooo viel kostet der auch nicht.
Sieht gefährlich aus. Würde den Gleichrichter als Verpolschutz dringend
wieder reinnehmen. Wenn der Bus verpolt angeschlossen wird gibt es zwei
Probleme:
1) Der Komperator funktioniert nicht wie gewünscht.
2) Die BAT46 schließt den EMS-Bus kurz.
Habe keine Ahnung was die BAT46 soll. Vermute mal dass sie die Schaltung
vor Überspannungen vom EMS-Bus schützen soll.
Ich habe mir jetzt nochmal einige unbekannte Werte vom EMS-Bus
angesehen. Erkennt jemand den Zusammenhang von Nachricht:
08 00 19 Index 13
und der Brennerleistung
08 00 18 Index 8 ?
Anbei ein Plot der beiden Werte.
Hi Rudi,
das sieht mir nach der Modulation der internen Gerätepumpe aus. Wird in
Prozent angegeben, bezieht sich auf die Drehzahl und wird abhängig von
der Brennerleistung variiert. Wenn ich mich richtig erinnere ist die
minimale Pumpenmodulation bei deinem Gerät 55% - sollte also passen.
//Niffko
Rudi schrieb:> Jein, wenn du die anderen Teilnehmer zu oft störst,
ok ... stattgegeben.
> ... werden diese einfach abgemeldet und die Anlage geht auf Störung,
Was wiederum nicht so tragisch wäre. Kommunikationsfehler generieren im
EMS-System nur blockierende Störungen, keine verriegelnden. D.h. die
Anlage geht nach Wiederherstellung der Kommunikation wieder in Betrieb.
Hilft natürlich nicht wenn die Störungen im Minutentakt auftreten ...
schon klar.
> Aus diesem Grund muss auch jedes z.B. 0x8B BRK beantwortet werden.
hmm ... 0x8B wird bei mir definitiv nicht beantwortet.
> Damit verbaust du dir eine Entkopplung von E-Heizungskreis und> E-Hausnetz. Ich würde die Konvertierung von den "analogen" Signalen auf> digitale Signale so einfach wie möglich halten, sprich über eine passive> Schaltung.
Wobei letzteres aufgrund der geringen Strombelastbarkeit ja
offensichtlich nicht so einfach ist. Mal abgesehen davon, dass in meinem
Fall eine Trennung nicht notwendig ist (Heizungsregelung), was spricht
dagegen, den Sklaven in das Heizungsnetz zu integrieren und von ihm aus
entkoppelt zu kommunizieren?
> Ein weiterer Nachteil einer Soft-Uart ist die extreme CPU-Last, da jede> Flanke/jedes Bit vergoldet wird.
Hast' ja prinzipiell recht, wird aber durch einen interrupt-beschickten
FIFO schon deutlich entschärft. Außerdem läuft man dann nicht Gefahr,
dass der AVR beim Empfangen und Weiterleiten der 9600baud Daten, an
Langeweile stirbt.
IngoF schrieb:
> Sieht gefährlich aus. Würde den Gleichrichter als Verpolschutz dringend> wieder reinnehmen.
Komm schon ... Du machst hier mit Mikrocontrollern rum und willst mir
erzählen, dass du die Polarität von zwei Leitungen nicht vor dem
Anschließen feststellen kannst. Wenn Buderus Brückengleichrichter
einbaut, dann deshalb, weil die Verdrahtung von Heizungsbauern
vorgenommen wird ... wenn Du weißt was ich meine.
//Niffko
Niffko _ schrieb:> hmm ... 0x8B wird bei mir definitiv nicht beantwortet.
OK... dann aber eben dass Polling für das Modul dass Du emulieren
möchtest. Wenn Du Das Polling nicht beantwortest wird diese Adresse viel
seltener gepollt und musst länger auf das versenden der Nachrticht
warten.
Vielleicht ignoriert auch die MC10 Telegramme die von einem
"unbekannten" Busteilnehmer kommen.
Niffko _ schrieb:> ... dass du die Polarität von zwei Leitungen nicht vor dem> Anschließen feststellen kannst.
Sicher bin ich dazu fahig. Macht aber die Sache einfacher mit
Gleichrichter. Anstöpseln und fertig.
Dann würde ich jedenfalls die Diode entfernen die den Bus kurzschließt
wenn man verpolt.
IngoF schrieb:> OK... dann aber eben dass Polling für das Modul dass Du emulieren> möchtest. Wenn Du Das Polling nicht beantwortest wird diese Adresse viel> seltener gepollt und musst länger auf das versenden der Nachrticht> warten.
ja, weiß ich doch. Hatte bloß in Rudis Text das 0x8B im Kontext mit
Brenner gelesen und dann hätte es bei mir auch als Antwort auftauchen
müssen.
> Dann würde ich jedenfalls die Diode entfernen die den Bus kurzschließt> wenn man verpolt.
Nö, die bleibt drin ;-). Scheint als schnelle Clamp-Diode gegen negative
Spikes gedacht zu sein. Ich denke hier muss der jeweilige Anwendungsfall
betrachtet werden. Wenn das Interface ständig an- und abgestöpselt wird,
kann man sicherlich über einen Brückengleichrichter reden. In meinem
Fall wird einmal angeschlossen und gut is'. Deshalb hatte ich in meinem
Post auch extra geschrieben: "als Anregung für eigene Lösungen".
//Niffko
Niffko _ schrieb:> das sieht mir nach der Modulation der internen Gerätepumpe aus.
@Rudi
Habe jetzt bei mir noch mal Telegramm und Monitorwert verglichen - es
ist die Pumpenmodulation. Bin mir aber fast sicher, dass der Wert bei
Dir (GB152) nicht im Monitor angezeigt wird.
//Niffko
Dieses "BusEcho" lässt mir ja irgendwie keine Ruhe. Warum existiert
dieses Echo nur wenn man über die Servicekey-Schnittstelle etwas sendet?
Ich habe dieses Echo noch nicht einmal bei anderen Stationen gesehen.
Oder täuscht mich das?
Ich habe folgende Komponenten:
MC10 Master-Controller (0x08) (UBA3) (Also die "Backplane" des Systems
und Busmaster)
BC25 Basis-Controller (0x09)
RC35 Raum-Controller (0x10)
Wenn z.B. nun 0x10 an 0x09 irgendwelche Daten sendet dann sehe ich das
genau ein einziges mal. Keine Wiederholungen vom MC10.
In den Buderus Planungsunterlagen für EMS ist ein Busdiagram. Im Zentrum
steht der MC10 als Master. Von dort sieht man einen EMS-Baum wo die
ganzen Zusatzmodule wie RC35, RC25, EM10, MM10 etc angeschlossen sind.
Und daneben, einen einzigen dedizierten EMS-Zweig wo nur das BC10/25
angeschlossen ist.
Und an diesen Modulen hängt ja der ServiceKey.
Meine Vermutung wäre nun das das BC10/25 als Repeater/Gateway zum
Internen EMS-Bus auftritt und diese "Echos" nur auf die
ServiceKey-Kommunikation zutrifft. Die Echos werden also möglicherweise
nicht vom BusMaster generiert sondern vom BasisController BC10/25.
Könnte das wer bestätigen? Habt ihr diese "Echos" auch von anderen
Modulen?
Fred Granna schrieb:> Wenn z.B. nun 0x10 an 0x09 irgendwelche Daten sendet dann sehe ich das> genau ein einziges mal. Keine Wiederholungen vom MC10.
Die Daten die Du siehst sind die Wiederholungen. Wiederholt wird Byte
für Byte. Die Telegramme die direkt von den Modulen kommen wirst Du
nicht sehen können, da diese mit deutlich geringerer Amplitude senden.
Fred Granna schrieb:> Meine Vermutung wäre nun das das BC10/25 als Repeater/Gateway zum> Internen EMS-Bus auftritt ...
Ein klares Jain. Ich habe bereits die Interna von BC10, UBA und MC10 in
Augenschein nehmen können - die dicken Transistoren hängen nur bei UBA
und MC10 am Bus. Beim BC25 sieht die Sache aber anders aus, in ihm sind
sozusagen BC10 und UBA vereint.
//Niffko
Niffko _ schrieb:> Habe jetzt bei mir noch mal Telegramm und Monitorwert verglichen - es> ist die Pumpenmodulation. Bin mir aber fast sicher, dass der Wert bei> Dir (GB152) nicht im Monitor angezeigt wird.
Danke! Im Monitor wird der Wert nicht angezeigt.
Fred Granna schrieb:> Und daneben, einen einzigen dedizierten EMS-Zweig wo nur das BC10/25> angeschlossen ist.
Richtig, der ServiceKey bekommt noch 12V VCC, also ein 3-Draht-Bus und
kein 2-Draht-Bus.
> Meine Vermutung wäre nun das das BC10/25 als Repeater/Gateway zum> Internen EMS-Bus auftritt und diese "Echos" nur auf die> ServiceKey-Kommunikation zutrifft. Die Echos werden also möglicherweise> nicht vom BusMaster generiert sondern vom BasisController BC10/25.
Nein, wie ich weiter oben schon geschrieben hatte: Der Klinkenstecker
hängt mit den 2 Leitungen (GND,DATA) direkt am internen EMS-Bus.
Fred Granna schrieb:> Wenn z.B. nun 0x10 an 0x09 irgendwelche Daten sendet dann sehe ich das> genau ein einziges mal. Keine Wiederholungen vom MC10.
Du siehst die Wiederholung. Als TX-Slave arbeitet das ganze als
Stromschnittstelle und als RX-Slave Level-Sensitiv. Dreh mal dein Oszi.
auf dann siehst du es.
Niffko _ schrieb:>> Wenn z.B. nun 0x10 an 0x09 irgendwelche Daten sendet dann sehe ich das>> genau ein einziges mal. Keine Wiederholungen vom MC10.> Die Daten die Du siehst sind die Wiederholungen. Wiederholt wird Byte> für Byte. Die Telegramme die direkt von den Modulen kommen wirst Du> nicht sehen können, da diese mit deutlich geringerer Amplitude senden.
Das würde ja bedeuten, das wenn ich zu heftig in den Bus schreie, die
anderen Module alle Zeichen doppelt empfangen und daher nur Müll
zurückkommt?
Das würde evtl. erklären warum meine Antworten auf das Polling "0x8B"
funktionieren, die Kommunikation mit anderen Modulen aber nicht.
Fred Granna schrieb:> ... dass wenn ich zu heftig in den Bus schreie ...
ich denke, dein 'Umgangston' würde sich, durch den Austausch der Z-Diode
in Deiner Senderstufe gegen einen 220R Widerstand, erheblich verbessern
;-)
//Niffko
Niffko _ schrieb:> .....durch den Austausch der Z-Diode> in Deiner Senderstufe gegen einen 220R Widerstand.....
Ja, das wird es garantiert ändern.
Hoffe Ihr könnt mir noch mal verzeihen wenn ich schon wieder den Link
bringe:
Beitrag "Re: Logamatic 2107 Schnittstelle"
Auf dem ersten Bild kann man gut das Polling von der MC10 an die RC30
sehen.
Die MC10 brüllt rum und dann ein kleines flüstern von der RC30 das dann
die RC30 noch mal in den letzten Winkel brüllt. Der Rest der Antwort
kommt dannn von der RC30 nach etwa 100ms wenn sich die RC30 wieder
gesammelt hat. Was dann genauso wie auch das Break widerholt wird.
Wenn man eine zu kleine Z-Diode nimmt und die Spannung noch tiefer als
die MC10 herunter zieht gibt es teilweise richtige Ausfälle am Bus Bei
der nach dem Break noch ein 0xFE gesendet wird. Ob das jetzt eine
Absichtliche Fehlermeldung oder eine Fehlfunktion kann ich nicht
beurteilen.
Gruß
Ingo
Okay, also vereinfacht gesagt:
Keiner Spricht direkt sondern immer über den Chef.
Jeder flüstert dem Chef was zu wenn er dran ist (Aufforderung kommt vom
Chef) und der wiederholt das Laut so das es dann alle hören.
Rudi schrieb:> Dann darf ich aber auch mal ;-)
Tja, der Thread ist ja schon etwas länger... Da kann man noch viel
ausgraben was inzwischen schon fast untergegangen ist.
Fred Granna schrieb:> Könnte das wer bestätigen? Habt ihr diese "Echos" auch von anderen> Modulen?
Wenn man nicht mit einem Oszilloskop auf dem Bus hängt ist es auch nicht
soo leicht dies mit zu bekommen. Das Problem ist dass der größte Teil
von der Adresse 0x08 kommt und die MC10 sich selber natürlich nciht
widerholt. Wenn das jemand selber nachvollziehen möchte kann am besten
am Oszilloskop die Triggerschwelle knapp über die Maximale Spannung
stellen und triggert dann auf das Überschwingen.
So jetzt werde ich mal lieber wieder an meiner Software spielen und
versuchen mich hier zurück zu halten.
Fred Granna schrieb:> Ich peil es nich. Kann mir kurz einer schildern was für z.B. senden muss> um z.B. eine Versionsabfrage an ein Modul zu richten?
0x0B 0x10 0x02 <CRC>
Ansonsten schalte deine Anlage aus/ein und schau dir die ersten
Nachrichten an.
Rudi schrieb:> Ansonsten schalte deine Anlage aus/ein und schau dir die ersten> Nachrichten an.
Hm, darauf hät ich auch kommen können facepalm
bzgl. Sendepfad:
Ich hab mir nun das hier zum Vorbild genommen:
Beitrag "Re: Logamatic 2107 Schnittstelle"
Ich invertiere mein UART-TX über nen OpAMP und denn auf einen Transistor
der zieht den Bus über 220 Ohm auf Masse.
Zwei Fragen dazu:
- Wozu ist der 4K7 PUllup dort?
- Ist der 1,5n Kondensator wichtig?
Fred Granna schrieb:> Zwei Fragen dazu:> - Wozu ist der 4K7 PUllup dort?
Damit der Transistor einen ordentlichen Pegel sieht, falls mal nichts
passiert oder der OP nicht beschaltet ist (dauersenden).
> - Ist der 1,5n Kondensator wichtig?
Rechnen das mal durch (Tiefpass), siehe:
http://de.wikipedia.org/wiki/RC-Glied
Die Kurve für den Tiefpass sieht in etwa so aus. Ich denke die hohen
Frequenzen der Anlage (CPU etc.) sollen sich nicht durch das ganze Haus
verteilen ;-)
Hm, ich glaub meine CRC-Berechnung haut nicht hin.
Habe diese Funktione hier genommen:
Beitrag "Re: Logamatic 2107 Schnittstelle"
Und dann mal probiert:
uint8_t tempbuffer[]={0x10,0x21,0xac,0x0,0x0,0x0,0x0};
uint8_t crc=buderus_ems_crc(tempbuffer,7);
da bekomme ich als CRC: 0x0D
Laut dem hier müsste es aber 0x1A sein oder?
Beitrag "Re: Logamatic 2107 Schnittstelle"
Fred Granna schrieb:> Hm, ich glaub meine CRC-Berechnung haut nicht hin.
Und ich weiss das sie funktioniert ;-)
Versuch mal Länge 8 und nicht 7. Die Berechnung geht von der Datenlänge
mit CRC aus.
Jo, hab ich auch zur sekunde festgestellt.
Bekomme aber trotzdem keine Antworten...
Befürchte das da mit dem Timing was nicht hinhaut. Denke mal mit meinem
i2c-UART am EMS-Bus kann ich das ganze vergessen. Hat hier einer von
euch spezis nen bissl C-Code zum durchforsten für mich? Ihr seit doch da
bestimmt schon weiter als ich...
Moin,
hat eigentlich schon jemand eine richtige Abfrage auf den EMS-Bus
gemacht? Ich meine jetzt nicht einfach ein Byte auf eine Pollinganfrage
senden :)
Mal ein paar Tests:
Ich warte jeweils auf "0x8B <brk>". Nach meinen Telegrammen sende ich
jeweils "0x08 <brk>" zum Abschluss
Ich sende "0xB 0x8 0x2 0x3E <brk>" und bekomme "80 0B <brk>".
Ich sende "0xB 0x8 0x2 0x00 0x3E <brk>" und bekomme "80 0B <brk>"
Ich sende "0xB 0x8 0x2 0x3E <brk>" und bekomme "80 0B <brk>".
Ich sende "0xB 0x8 0x0 <brk>" und bekomme "80 0B <brk>".
Ich sende "0xB 0x8 <brk>" und bekomme "80 0B <brk>".
Fred Granna schrieb:> Warum geht das?
Wie schon einmal gesagt, schalte deine Anlage aus/ein und schau dir die
initialen Nachrichten an .........
> Was bedeutet die 0x06 vorm CRC?
K.A., evtl ein Index.
Was hängt denn bei dir an Adresse 0x08 und mit welcher Version ?
Fred Granna schrieb:> Ich sende "0B 88 02 00 06 9A"> Ich bekomme "08 0B 02 00 7B 04 05 00 00 00 FC 00"
Gratuliere!
Darf ich fragen, mit welchem Prozedere du sendest - ich meine im
Speziellen die Pausen zwischen den Bytes?
//Niffko
Fred Granna schrieb:>> Was hängt denn bei dir an Adresse 0x08 und mit welcher Version ?>> Das ist UBA4, Version 4.5. Die Version sieht man ja im Telegram.
Das sehe ich. Mich wundert nur die Länge der Antwort. Bei mir sieht es
so aus wenn die 0x10 anfragt:
10 88 02 00 06 33
08 10 02 00 40 03 02 3d
Niffko _ schrieb:> Darf ich fragen, mit welchem Prozedere du sendest - ich meine im> Speziellen die Pausen zwischen den Bytes?
Nach jedem Byte hole ich mir die Antwort. Also ich sende nicht weiter
bis ich das "echo" vom Master habe.
Fred Granna schrieb:> Nach jedem Byte hole ich mir die Antwort. Also ich sende nicht weiter> bis ich das "echo" vom Master habe.
Joa ... danke!
Rudi schrieb:> Mich wundert nur die Länge der Antwort. Bei mir sieht es> so aus wenn die 0x10 anfragt:>> 10 88 02 00 06 33> 08 10 02 00 40 03 02 3d
Bei mir sieht's so aus (UBA3 V2.07):
10 88 02 00 09 3C
08 10 02 00 40 02 07 3A
UBA3 und UBA4 haben technisch gesehen nicht mehr viel gemein, daher
evtl. die unterschiedlichen Antworten.
//Niffko
Mich würde ja interessieren was der ServiceKey intern so alles anstellt.
- Der Servicekey empfängt die Anfrage
"04 08 02"
-- Der Key sendet auf dem Bus
"0B 88 02 00 06 <crc> <brk>"
-- Der Key empfängt vom Bus
"08 0B 02 00 7B 04 05 00 00 00 <crc> <brk>"
- Der Key sendet zur Software
"04 08 02 00 7B 04 05 00 00 00".
Man bräuchte mal einen parallelen Log vom ServiceKey und vom EMS-Bus um
mal zu sehen was da wie angestellt wird...
Fred Granna schrieb:> Mich würde ja interessieren was der ServiceKey intern so alles anstellt.
Also zumindest packt er auch mehrere Teiltelegramme zusammen oder
splittet die. Das Telegramm 0x3f besteht beim Service-Key aus etwa 100
Byte.
Auf dem EMS-Bus sind die gesplittet und haben nach dem Telegrammtyp das
Offset.
Die Logamatic fragt ja erst mal alle Telegramme der Busteilnehmer ab.
Dannach kommen nur noch geänderte Werte mit einem 0x20 noch vor der 04.
Mich würde auch mal ein paralleles Log interessieren. Nur bräuchte
irgendjemand einen Service-Key und gleichzeitig eine Möglichkeit die
Daten aufzuzeichenen. Für das Log würde es ja auch reichen wenn man dies
mit einem Programm wie hTerm z.B. Hexadezimal evtl mit dem Zeitstempel
mitloggt.
Eigentlich muss mann nicht unbedingt eine großartige Empfangsschaltung
haben. Es reicht aus Die Masse (Pin 5) von der Seriellen Schnittstell
auf die 12 Volt von der Service-Key Buchse zu gehen und die Daten auf
die Empfangsleitung der Schnittstelle (Pin 3). Oder umgekehrt.
Am besten mit einem Laptop das keine Verbindung zum Stromnetz hat.
Habe das damals auch gemacht und keine Probleme damit gehabt.
Dadurch hat man dann einen Signalpegel von +-2,5Volt. Eigentlich
benötigt man mindestens +-3 bis +-12Volt als Pegel. Hat bei mir aber
einwandfrei funktioniert.
Was dies 0x00 0x06 soll interesssiert mich auch. Eigentlich wäre das
Offset 0 mit den Daten 0x06. Es gibt auch viele Telegramme von der RC30
(0x10, 0x11) die auch irgendwelche Daten an die MC10 senden. Vermute mal
das sind irgendwelche Parameter/Stellwerte für die Heizungsregelung.
Hatte bei mir gestern schon mal das simple beantworten der 0x8b mit 0xb
programmiert und werde dann in der nächsten Zeit endlich auch mal
"echte" Sendeversuche unternehmen können wenn ich dazu Zeit finde.
Gruß
Ingo
IngoF schrieb:> Auf dem EMS-Bus sind die gesplittet und haben nach dem Telegrammtyp das> Offset.>> Die Logamatic fragt ja erst mal alle Telegramme der Busteilnehmer ab.> Dannach kommen nur noch geänderte Werte mit einem 0x20 noch vor der 04.
Und das ist genau die Frage! Fragt der wirklich AKTIV in den Bus oder
hat der Key intern "nur" einen Puffer in dem die Telegramme "<gerät>
0x00 <telegramtyp> ..." die so über den Bus schwirren eingelagert und
dann daraus geholt werden?
Ich glaube ohne "Doppellog" kommt man da wirklich nicht weiter. Ich habe
vorhin mit dem Offset vor der CRC ein wenig gespielt; die Heizung hat
dann plötzlich nen Fehler ausgegeben...
Fred Granna schrieb:> Ich glaube ohne "Doppellog" kommt man da wirklich nicht weiter. Ich habe
Das stimmt. Ohne Log geht garnichts. Würde aber vermuten dass der
ServiceKey alles im Speicher vom anfang an mitpuffert und dann nur noch
Änderungen überwacht und diese dann über die serielle Schnittstelle
mitsendet. Vielleicht werden ja auch mal am Anfag alle Telegramme
abgefragt ohne dass sich die Logasoft dies anfragt. Und wenn eine
Anfrage auf ein spezielles Telegramm kommt aus dem Speicher sendet.
Vielleicht hängt das auch vom Telegrammtyp ab wie er sich verhält....
Wollte ja eigentlich auch nur sagen dass ein Log auch jeder ziehen kann
der eine zweite serielle Schnittstelle frei hat und sich nur ein Kabel
RS232 auf Klinke basteln muss. (1x Service-Key und 1x Diagnose-Buchse)
Vermute mal dass jemand der einen ServiceKey hat sich nicht noch extra
irgend eine Schaltung zusammenlötet oder sogar irgendwas programmiert..
Also mit dem Offset einfach so herumexperimentieren werde ich mich erst
mal nicht trauen :-) Wer weiss denn schon was man da so alles verstellen
kann...
Für mich reicht erst mal wenn ich die Telegramme mitlogge und nur die
Schaltzeiten verändern kann. Also dass mein Server dynamisch die Zeiten
ändern kann. Z.B. wenn ich schon weiss dass der Arbeitstag länger dauern
wird eine eMail an meinen Server schicken und der ändert die Heizzeiten.
Vielleicht auch schnell mal für ein Jahr im vorraus meinen Urlaub
eintrage und alles automatisch umgestellt wird :o)
Und natürlich dass ich sehen kann was meine Heizung denn da so
veranstaltet und sich irgendwie Energie einsparen lässt.
Gruß
Ingo
Fred Granna schrieb:> Und das ist genau die Frage! Fragt der wirklich AKTIV in den Bus oder> hat der Key intern "nur" einen Puffer in dem die Telegramme "<gerät>> 0x00 <telegramtyp> ..." die so über den Bus schwirren eingelagert und> dann daraus geholt werden?
Alle Module haben ein EEProm mit festen Daten und volatile Daten
(Temperaturen etc.). Wie diese beiden Datentypen unterschieden werden
ist nun die große Frage.
Der ServiceKey wird sich wohl alle EEProm Daten von den Modulen holen
und speichern. Die volatilen Daten bzw. die nicht volatilen Daten die
geändert werden (z.B. durch die RC3X) bekommt er direkt vom Bus.
Rudi schrieb:> Die letzten 3 0x00 deuten auf eine fehlende Erweiterung hin !?
Das könnte ein Platz für eine weitere Versionsnummer (Erweiterung?)
sein. Die MC10 übermittelt ja seine eigene Version und die SAFe-Version.
Die Seriennummer scheinen ja immer aus drei Byte sein
Rudi schrieb:> Die letzten 3 0x00 deuten auf eine fehlende Erweiterung hin !?
Kann es vielleicht sein dass sich die MC10 je nach Absender anders
verhält?
Beides mal wenn die 0x00 0x00 0x00 auftaucht war die Adresse 0x0b im
Spiel. bei der 0x10 sind die nciht aufgetaucht. Die untere UBA wird
vermutlich auch eine UBA3 sein. Die Version liegt ja genau in dem
Bereich von den anderen beiden UBA.
Keine Ahnung ob da was dran ist..
Mensch so langsam wird das ja konkret.
Ich lese so nebenbei mit. Habe schon ein schlechtes Gewissen, weil ich
nen Servicekey besitze aber momentan keine Möglichkeit zum mitloggen
habe. Mist.
Und jetzt pass auf:
"0B 88 18 03 01" => "08 0B 18 03 64 DA"
Das ist auslesen eines Registers:
18 = Register
03 = Offset (Start)
01 = Anzahl der Zeichen die gelesen werden
Also lese ich aus Register 18 das dritte Zeichen
@Fred Granna
Kannst du mal versuchen ob es sich bei dem dritten und vierten Byte um
einen Offset in einen statischen Speicher handelt ?
10 88 15 00 05 <crc>
10 88 1c 00 0b <crc>
Und dann mal bei der 0x15 schauen ob du die Antwort der 0x1c durch
ändern der Längenangabe mit empfängst.
Fred Granna schrieb:> Was würdet ihr sagen was dieser "Offset" wirklich ist? ;-)IngoF schrieb:> Also mit dem Offset einfach so herumexperimentieren werde ich mich erst> mal nicht trauen :-)
Also bei der Seriennummer kann vermutlich nicht viel passieren...
Fred Granna schrieb:> Was würdet ihr sagen was dieser "Offset" wirklich ist? ;-)
Hey, bitte sagen falls ich hier herumtrolle....
Also das Offset habe ich von einigen Telegrammen wie z.B. das 0x39 das
ich gerade mitgeloggt habe und die Daten hinter einander kopiert habe.
Wenn mann z.B. beim ersten Telegramm nur die Datenbytes zählt kommt mann
auf 26 = 0x1A. Das nächste Telegramm fängt mit 0x1B im "Offset" an.
in der Zeile darunter mit dem RX: das Telegramm von Chris_be was ich aus
seinen Logs zusammengestellt habe...
Ich finde diese beiden Telegramme sehen doch sehr gleich aus.. Ist das
nur Zufall??
Allerdings scheint es auch wohl teilweise andere Bedeutungen zu haben.
Vielleicht ist das nach Sollwerten, Veränderlichen Daten oder
Seriennummern anders.
Bei dem Telegramm 0x10 und 0x11 sind das Telegramme von der RC30 an die
MC10. vielleicht ist dass dann dort kein Offset und ist vielleicht ein
Befehl. Was mich daran stört ist dass die Antwort unterschiedlich lang
ausfällt.
Dann noch das "Versionsnummernproblem" warum wird da bei einigen die
0x06 und bei anderen 0x09 an das "Offset" 0x00 gesendet??? Ist das ein
Befehl, EIne Prüfsumme?? Was soll das? Dort scheint es kein Offset zu
sein.
Hoffe ich kann mit meinen "Spekulationen" helfen...
Gruß
Ingo
Fred Granna schrieb:> Oder hab ich die Frage nicht richtig verstanden?
Doch, alles okay. Das scheint so nicht zu funktionieren. Es wird wohl
wie bei ECO-CAN über Typen gehen, also was du als Register bezeichnest
und einen Offset, den es bei ECO-CAN auch gibt.
IngoF schrieb:> Also das Offset habe ich von einigen Telegrammen wie z.B. das 0x39 das> ich gerade mitgeloggt habe und die Daten hinter einander kopiert habe......
Sorry, glatt das wichtigste vergessen.. Hier die dazugehörigen Daten als
TXT-Datei:
IngoF schrieb:> Hoffe ich kann mit meinen "Spekulationen" helfen...
Es ist ja nicht so das wir die Daten nicht ändern können, es soll nur
etwas komfortabler werden ;-). Am besten hält man sich erst einmal an
die RC3X, so wie die die Daten ändert. Bisher hat sich leider noch
niemand die Mühe gemacht das Protokoll für die Änderungen zu erfassen.
Fred Granna schrieb:> "0B 88 02 00 02 <crc> <brk>" => "08 0B 02 00 7B 04 05 93"> "0B 88 02 00 03 <crc> <brk>" => "08 0B 02 00 7B 04 05 93"> "0B 88 02 00 04 <crc> <brk>" => "08 0B 02 00 7B 04 05 00 3F"> Was würdet ihr sagen was dieser "Offset" wirklich ist? ;-)
ALso das Offset meinte ich mit dem dritten Byte was bei Dir immer 0x00
ist.
Aber das Byte dannach ist wohl die Antwortlänge. Allerdings scheint die
MC10 das nach Belieben anzupassen. Die 0x02 ist der MC10 zu wenig
gewesen und hat dann einfach 3 Datenbyte gesendet.
Bei den Seriennummer
Rudi schrieb:> UBA3 V3.2> ---------> 10 88 02 00 06 33> 08 10 02 00 40 03 02 3d>> UBA3 V2.7> ---------> 10 88 02 00 09 3C> 08 10 02 00 40 02 07 3A
Bei den Seriennummern wurden nur 3 Datenbyte gesendet obwohl einmal 6
und einmal 9 Datenbyte abgefragt wurden.
Fred Granna schrieb:> 18 = Register> 03 = Offset (Start)> 01 = Anzahl der Zeichen die gelesen werden>> Also lese ich aus Register 18 das dritte Zeichen
ALso da bin ich nicht mit zufrieden.. ich stimme für Telegramm 0x18 also
die schnell veränderbaren Messwerte.
Könnt Ihr denn mal vergelichen ob das mit dem Offset auch wirklich
stimmt?
Wenn ich richtig verstanden habe sind die Daten die dann gesendet
identisch mit den Daten aus dem letzten Telegramm 0x00 ab dem Offset
0x03??
Gruß
Ingo
Fred Granna schrieb:> Ich habe eben mal eine Zeile aus deinem Log genommen:> {52} 19:49:38 06.01.11: 10 88 11 18 1B 52> {CF} 19:49:38 06.01.11: 08 10 11 18 00 00 00 00 00 00 00 00 00 00 00 00> CF>> Habe dann gesendet "11 88 11 18 1B <crc>"> Resultat: "08 0B 11 18 00 00 00 00 00 00 00 00 00 00 00 00 3C"
OK. Leider ist ja nicht bekannt was das "Telegramm" 0x10 und 0x11
überhaupt für eine Bedeutung hat. Dass die Prüfsumme ja anders ist liegt
an der unterschiedlichen Adresse. Oder habe ich Dich falsch verstanden?
Habe hier mal die beiden Telegramm von Chris_be:
RX: 04 08 10 00 34 55 02 09 89 0A 12 17 2A 00 BF 4B 34 55 02 09 89 0A 14
12 22 00 1E 4B 33 43 02 1A 86 05 10 1E 18 00 02 4B 36 4C 02 24 80 01 00
01 27 00 01 4B 36 59 01 FE 00 00 00 0F 00 00 01 4B 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00
RX: 04 08 11 00 37 41 02 26 8A 02 08 1A 25 00 01 4B 36 4C 02 05 87 0C 0A
14 22 00 01 4B 36 4C 02 05 87 0B 15 11 06 00 01 4B 36 4C 02 05 87 0B 15
07 1C 00 01 4B 36 4C 02 05 87 02 0D 0C 21 00 01 4B
Wenn das ja mit dem Offset stimmt wunder mich nur warum dort bei mir
alles 0x00 angezeigt wird und bei Crhis_be ganz andere Werte stehen...
Muss dann eine andere Hardware sein oder vielleicht sind das
irgendwelchen geloggten Werte von der MC10 die erst nach einer
bestimmten Laufzeit in diesen "Speicherplätzen" abgelegt werden...
Gruß
Ingo
Rudi schrieb:> Hast du deine Anlage nicht programmiert (Heizzeiten) ?
Doch, aber nur HK1. Die restlichen (WW und Zirkulation) übernehmen diese
Einstellung.
Rudi schrieb:> Hast du deine Anlage nicht programmiert (Heizzeiten) ?
Also die Heizzeiten sind doch die Telegramme 0x3f soweit ich das mal
gesehen habe.. Oder sind das vielleicht die Temperaturen für die
Schaltpunkte? Kann ja eigentlich auch nicht sein. es gibt doch nur
zwei...
Fred Granna schrieb:> Doch, aber nur HK1. Die restlichen (WW und Zirkulation) übernehmen diese> Einstellung.
Also bei mir ist HK1 und die Zirkulation mit einem eigenen Programm
versehen.
Zirkulation nur morgens zwischen 5:00 und 6:00 soweit ich mich erinnere.
Sorry, habe nicht verstanden was Du damit sagen wolltest...
Hatte nur meine Einstellungen hier genannt falls hier irgendjemand eine
Idee mit der Zuordnung der Daten zu den Schaltzeiten hat..
Hatte Rudi so verstanden dass die 0x00 dort stehen weil Du nur einen HK
und sonst keine Zeiten programmiert hast.
Wollte nur sagen dass ich für die Zirkulation ein eigenes Zeitprogramm
erstellte habe und nicht von dem Heizkreis1 die Zeiten übernommen
wurden. Also demnach müssten dann ja bei mir andere Daten
auftauchen....
IngoF schrieb:> Also demnach müssten dann ja bei mir andere Daten> auftauchen....
oder besser gesagt mehr Daten... weil ich ja noch zusätzlich ein
Schaltprogramm für die Zirkulation eingestellt habe...
Fred Granna schrieb:> Wie veranlasse ich die Module ihre kompletten Daten auf> einmal auszugeben?
Also ich hatte gehofft dass das Telegramm auch auf dem EMS-Bus anwendbar
wären...
Also:
für alle Telegramme die vorhanden sind:
0b 08 <Break>
für alle Daten zu dem Telegramm/Datentyp 0x18
0b 08 18 <Break>
für die Daten von Telegramm 0x18
0b 08 18 1B <CRC> <Break>
für die 10 Bytes ab Adresse 0x1b vom Telegramm 0x18
0b 08 18 1B 0A <CRC> <Break>
Aber leider scheint das nicht so auf dem EMS-Bus funktionieren. Die
Hoffnung war wohl zu blauäugig..
Eventuelle muss man alle Datentypen/Telegramm aufeinmal abfragen..
Da hilft nur ein Log am EMS-Bus wenn der Service-Key angeschlossen wird.
@Andreas F. (Gast)
könntest Du denn evtl. mal einen Log-Versuche starten wenn Du Zeit und
die Möglichkeit hast?
Also die beschriebene Version mit dem Kabel habe ich am Anfang auch
gehabt und Du benötigst keine selbstgeschriebene Software oder
irgendwelche andere Hardware außer das Kabel.
Eventuell könnte ich Dir das Kabel zuschicken oder evtl. Eine kleine
Testplatine mit Programm dafür erstellen und dir zuschicken. Mit der
Hardware könnte etwas dauern. das Kabel könnte ich sofort losschicken.
liegt hier bei mir auf dem Tisch.
Es würde für den Anfang auch erst mal ein serieller Port auch schon
reichen.. man könnte dann zumindest sehen ob der Service-Key beim Start
ohne EcoSoft-Programm alle Telegramme abfragt und wie er das macht..
Oder wohnt zufällig jemand mit Hardware zum loggen in Deiner Nähe?
Ich bin in der Nähe von Münster.
hatte damals auch nur ein Kabel ohne Software genommen:
Beitrag "Re: Logamatic 2107 Schnittstelle"
Gruß
Ingo
IngoF schrieb:> Ich bin in der Nähe von Münster.
Leider weit entfernt. Mein Nachbar fährt morgen nach Münster übers WE
aber das hilft Dir auch nichts.
Momentan habe ich keinen verfügbaren Laptop mit geeigneter Schnittstelle
zur Verfügung und die anderen Rechner sind wenig portabel. Ich überlege
mal am WE, wie ich vielleicht doch was tun kann. Könnte ich die Heizung
transportieren, stünde mir ein ganzer Meßpark zur Verfügung. Aber im
Winter wäre meine Frau nicht wirklich begeistert.
Mhmmm
IngoF schrieb:> Da hilft nur ein Log am EMS-Bus wenn der Service-Key angeschlossen wird.
Komme gerade vom Training, sonst hätte ich schon früher Laut gegeben.
Ich habe Service-Key, Logasoft und einen RX-Slave ... werde sobald ich
Zeit habe die Key-Telegramme mal mitloggen.
//Niffko
So, noch nebenbei eine allgemeinere Frage zum Senden:
Mein derzeitiger Ablauf:
1. Ich warte auf "0x8B <brk>"
2.1 Nun sende ich meine Abfrage mit einem abschliessenden <brk>
2.2 Danach ein "leeres" Telegram "0x0B <brk>" als Abschluss.
Mein Problem:
Teilweise bekomme ich die erwartete Antwort. Teilweise aber auch nur
"0x80 0x0B <brk>"
Ist das überhaupt das richtige Vorgehen zum Senden?
Fred Granna schrieb:> Ist das überhaupt das richtige Vorgehen zum Senden?
Das siehst du doch selbst auf dem Bus. Woher hast du überhaupt diesen
Ablauf mit Punkt 2.2 ?
Rudi schrieb:> Das siehst du doch selbst auf dem Bus. Woher hast du überhaupt diesen> Ablauf mit Punkt 2.2 ?
Den hab ich mir so zusammengereimt. Ich habs nun ohne das leere
"Abschlusstelegram" gemacht. Geht auch, ist also nicht nötig.
Ich glaube ich habe noch ein paar Timingprobleme...
So ... habe mal den Key eingestöpselt und mir vom Interface nur schicken
lassen, was 8B oder 0B auf den ersten beiden Bytes hat - das Ergebnis
findet Ihr im Anhang.
Das ist wie gesagt nur der blanke Key, ohne Verbindung zur Ecosoft -
hierfür bräuchte ich einen zweiten Laptop ... mal sehen.
Viel Spaß bei der Lektüre ...
//Niffko
Niffko _ schrieb:> So ... habe mal den Key eingestöpselt und mir vom Interface nur schicken> lassen, was 8B oder 0B auf den ersten beiden Bytes hat - das Ergebnis> findet Ihr im Anhang.
Das ist ja schonmal nicht schlecht :) Kannst du da evtl. noch
Zeitstempel mit einfügen?
> Das ist wie gesagt nur der blanke Key, ohne Verbindung zur Ecosoft -> hierfür bräuchte ich einen zweiten Laptop ... mal sehen.
Das ist so schonmal ganz gut. So sieht man das im SK wohl eine eigene
Logik inkl. Zwischenspeicher drinhängt.
Fred Granna schrieb:> Kannst du da evtl. noch Zeitstempel mit einfügen?
Hatte ich versucht. Das Problem ist, Hterm setzt die Zeitstempel nicht
immer am Anfang eines Telegrammes sondern immer spätestens nach 16 Bytes
- so zerhackt es dann immer die längeren Telegramme. Man kann die
überflüssigen Zeitstempel zwar über 'Suchen & Ersetzen' herausoperieren,
es fehlen dann aber immer noch die Zeitstempel die nicht gesetzt wurden.
Sollten Dich irgendwelche Zeiten im Speziellen interessieren, sag'
Bescheid - ich schaue dann mal nach.
//Niffko
Gute morgen,
ich habe eine andern PC nur Serial Comm, und habst von Conrad eine USB
RS232 converter gekauft.
Ich habe mit die Ecosoft und Service Key geprobierd, aber kann keine
kommunikation starten.
Ich habe die Spannungen gemessen und die sind OK, auch eine Scope
gebraucht und kann sehen dass das Signal is nicht gleich wenn sendet bei
RS232 port. (und dan keine antwort von ServiceKey...)
Wo habst eine gleiche setup ?
Ins driver kann ich latency, timeouts, ... parameters andern ...
vielen danke
Hallo,
Andreas F. schrieb:> vielleicht kann ich ja mit ein paar Detailbildern des Servicekey ein> wenig aufklären.
Danke für die Bilder. Eine Frage hätte ich da noch. Sind die beiden
Optokoppler auf der Seite Heizung<->Schaltung oder PC<->Schaltung ?
Grüße.
Hallo,
natürlich habe ich nun alles schön wieder zugeschraubt und alle
Aufkleber wieder drauf. ;-(
Wahrscheinlich hilft Dir das schon weiter.
Auf Bild 1 ist der komplette Key dargestellt. Links oben ist der
Mini-USB Stecker als Schnittstelle zum PC. Die kleine Platine links
unten steckt über dem Controller M306...
Unter der kleinen Platine erkennt man die dicken Leiterbahnen. Dort
werden die verschiedenen Adapter(Klinkenstecker) aufgesteckt.
Viel Spaß
@Andreas F.
Okay danke. Dort wird also nur der USB-Teil galvanisch getrennt und der
Rest der Schaltung läuft über die ServiceKey Versorgung (12V). So etwas
habe ich mir schon gedacht.
@all
Falls es jemanden interessiert, Junkers benutzt wohl einen
vergleichbaren Bus in ihren Geräten mit dem Namen "HT-Bus". Hier der
Link zu den Leidgenossen:
Beitrag "Junkers HT-Bus Heatronic 3 Schnittstelle"
Grüße.
Hallo zusammen!
Hab mir jetzt mal den Thread so durchgelesen.
Ich habe eine Junkers ZSB 14 Therme im Keller mit der Heatronic 3 und
würde auch gerne Daten mitloggen und eventuell die Therme steuern.
Funktioniert die Schaltung damit oder ist es nur eine Vermutung?
Was würde ich alles dazu brauchen oder "bietet" jemand eine fertige an?
Bin zwar Elektriker aber mit Platinen/Elektronik hab ich so keine
Erfahrung.
Liebe Grüße,
Christian.
Also ich habe zumindest geplant so eine Platine als "Sammelbestellung"
zu machen. Allerdings ist meine Hardware noch in der Entwicklung.
Evtl. würde die auch mit der Heatronic laufen. Das einzige was die
Platine macht ist die Telegramme in ein PC-Verständliches Format zu
bringen (0xAA 0x55 am Anfang und Ende oder eben nach 3964R)
Meine PC-Software würde nur funktionieren wenn auch das selbe
"Protokoll" darauf läuft und die einzelnen Datenbytes die selbe
Bedeutung haben.
Eventuelle müsste man dann noch die PC-Software selber entwickeln.
Aber erst mal abwarten wie die Telegramm/Daten denn dort eigentlich
ausshen...
Allerdings habe ich im Moment nicht gaanz so viel zeit an der
Hard/Software zu arbeiten.
Gruß
Ingo
Bin ab sofort auch unter den 'Sendenden'. Schaltung siehe Anhang.
Basiert, wie weiter oben schon geschrieben, auf einem Soft-UART. Daher
auch kein externer Inverter für die Ansteuerung des TX-Transistors, wird
per SW erledigt.
Habe festgestellt, dass es nicht nötig ist, zwischen dem Senden der
Bytes, auf das Echo des Masters zu warten. Man kann die Zeichen einfach
hintereinander abfeuern. Könnte das bitte nochmal jemand testen und
bestätigen?
@IngoF oder Rudi
Wenn ihr etwas Zeit übrig habt, könntet ihr euch das ja auch mal mit dem
Oszi anschauen.
//Niffko
Hallo,
Niffko _ schrieb:> Habe festgestellt, dass es nicht nötig ist, zwischen dem Senden der> Bytes, auf das Echo des Masters zu warten. Man kann die Zeichen einfach> hintereinander abfeuern. Könnte das bitte nochmal jemand testen und> bestätigen?
Wenn es funktioniert ist es doch okay. Bei der Byteweisen TX/RX-Methode
werden Buskollisionen schneller erkannt und der Transfer kann direkt
abgebrochen werden. Das Vorgehen halte ich für die bessere Wahl, da wir
keine weiteren Informationen zu diesem Bus haben (Verhalten bei
Buskollision, Timing etc.) und die Busbelegung bei Fehlern minimiert
wird.
Grüße.
@Niffko
Das ist der Vorteil eines Soft-Uart. Du kannst dadurch den
invertierenden Komperator/OP einsparen. Beim internen UART würde Die
Schaltung ja nicht so funktionieren...
Was würdest Du denn gerne am Oszillopgramm überprüft wissen? Also das
Echo kommt eigentlich immer sofort am Anschluss an jedes gesendete Byte.
Wenn man das nicht überprüfen will ist das ja auch OK. Allerdings hat
man dann keine Ahnung ob das Telegramm verstanden wurde und muss dann
eben auf die entsprechende Reaktion warten. Eine Garantie dass es
verstanden wurde gibt es ja sowieso nicht.
@all
Hat schon mal jemand irgendwann gesehen was am Bus passiert wenn man ein
Telgramm mit der falschen CRC auf den Bus schiebt?
Hatte ja gemerkt dass nach dem Break ein 0xFE gesendet wird wenn man
selber mit einem Low-Pegel unter 10 Volt sendet. Vermute aber schon dass
das nicht eine gewollte Reaktion ist und keine Fehlermeldung vom
Busmaster.
Meine Sendehardware ist soweit auch schon betriebsbereit und
funktioniert soweit ganz gut. Die Software sollte auch schon zu fertig
sein, aber habe im Moment nicht Zeit daran weiter zu basteln...
Gruß
Ingo
Niffko _ schrieb:> Habe festgestellt, dass es nicht nötig ist, zwischen dem Senden der> Bytes, auf das Echo des Masters zu warten. Man kann die Zeichen einfach> hintereinander abfeuern. Könnte das bitte nochmal jemand testen und> bestätigen?
Achso.. hatte das wohl falsch verstanden...
Der Busmaster bekommt ja nicht mit ob Du die Bytes einliest/prüfst oder
einfach das Echo ignorierst. Also wird das warten nicht nötig sein...
Oder wolltest Du wissen WANN das Echo kommt? Das Echo kommt immer sofort
ohne große Wartezeiten oder Pausen.
Fred Granna schrieb:> Wenn du Anfragen sendest: Bekommst du immer sofort eine Antwort zurück?
Kann ich (noch) nicht sagen, ich habe keine Anfragen gesendet, sondern
eher Mitteilungen.
Rudi schrieb:> hier noch bei paar Oszi.-Bilder vom Bus:>> ...>> Bis auf den Master senden die Slaves immer nur ein Byte und warten auf> das Echo.
Korrigiere mich bitte - aber auf den Beispielbildern mit Echos sind samt
sonders nur Polling Antworten ('Ja, ich lebe noch!') zu sehen. Ein
Daten-Telegramm eines Busteilnehmers ist nicht dabei, daher reicht mir
das noch nicht als 'Beweis' ;-)
//Niffko
IngoF schrieb:> Das ist der Vorteil eines Soft-Uart. Du kannst dadurch den> invertierenden Komperator/OP einsparen. Beim internen UART würde Die> Schaltung ja nicht so funktionieren...
jep ... Recht hast Du. Ist zwar etwas mehr Programmieraufwand, aber wenn
ich dadurch Hardware einspare, ist das o.k.
IngoF schrieb:> Der Busmaster bekommt ja nicht mit ob Du die Bytes einliest/prüfst ...
Das nicht, aber er würde mit seinem Echo mein nächstes Byte plattbügeln,
wenn er stur nach jedem empfangenen Zeichen ein Reply sendet.
IngoF schrieb:> Oder wolltest Du wissen WANN das Echo kommt?
Ich würde gerne wissen, wie das Oszillogramm aussieht, wenn man ein
Daten-Telegramm 'am Stück' auf den Bus gibt. Theoretisch müsste dann
darauf ja auch ein Echo 'am Stück' folgen.
Das Echo kommt immer sofort
> ohne große Wartezeiten oder Pausen.
Eine kleine Pause gibt es lt. den Oszi-Bildern aber schon. Die würde
auch ausreichen um zu erkennen ob noch ein Zeichen folgt, da auf das
Stop-Bit(H) des gesendeten Bytes sofort das Start-Bit(L) das nächsten
Bytes kommen würde.
//Niffko
Hallo zusammen
ich bin erstmalig hier im Forum.
Zuerst zu meiner Person: ich besitze eine Anlage mit folgenden
Eigenschaften:
GB 142 (Bj 2004)
UBA3/MC10: Version 2.05
BC10: Version 2.00
RC30: Version 2.05
Nach Kauf im Jahr 2004 und grober Analyse des EMS-Bus-Protokolls hatte
ich
damals eine ansatzweise Betriebsdatenaufzeichnung mit 16bit uC
aufgebaut. Allerdings konnte ich die Prüfsumme nicht herausfinden. Auch
der Polling-Mechanismus war mir im Detail unklar geblieben (besitze kein
Oszi).
Deshalb hier an alle vielen Dank für die Arbeit, insbes. an Rudi
(24.10.2010) und auch IngoF für die CRC-Berechnung. Mit dem Wissen ist
es jetzt viel einfacher, Logging-Informationen zuverlässig auszuwerten.
Allerdings sind meine Kenntnisse von damals (2004) schon fast wieder
vergessen.
Zur Frage der Schaltprogramme von IngoF (06.01.2011):
IngoF schrieb:> Hatte nur meine Einstellungen hier genannt falls hier irgendjemand eine> Idee mit der Zuordnung der Daten zu den Schaltzeiten hat..
Nach Veränderung eines Schaltprogramms am RC30 sendet der RC30 offenbar
einmalig vier Telegramme mit dem kompletten Inhalt des jeweils
geänderten Schaltprogramms.
Die entsprechenden Telegramme sind (bei meiner RC30):
10 00 3f für Heizkreis 1
10 00 38 für Warmwasser
10 00 39 für Zirkulation.
Beispiel für ein geändertes Schaltprogramm am Heizkreis 1 (Log incl.
CRC)
Msg: 10 00 3f 00 01 1e 00 82 21 1f 20 82 41 1f 40 82 61 1f 60 82 81
1f 80 82 a1 20 a0 82 c1 20 c0 11
Msg: 10 00 3f 1b 82 e7 90 e7 90 e7 90 e7 90 e7 90 e7 90 e7 90 e7 90
e7 90 e7 90 e7 90 e7 90 e7 90 b0
Msg: 10 00 3f 36 e7 90 e7 90 e7 90 e7 90 e7 90 e7 90 e7 90 e7 90 e7
90 e7 90 e7 90 e7 90 e7 90 e7 23
Msg: 10 00 3f 51 90 e7 90 00 00 00 11 08 0a 0a 09 0a 01 01 00 01 01
00 97
Die vier Telegramme enthalten den Speicherbereich des Schaltprogramms
(99 Bytes Nutzdaten):
Byte 4: Startadresse des Speicherbereich-Blockes
Byte 5-Ende (vor CRC): Nutzdaten (3 x 27 Bytes und 1 x 18 Bytes).
Die Nutzdaten enthalten nach meiner Einschätzung:
42 * 2 Bytes mit Schaltzeiten und weitere 15 Bytes (Inhalt unklar).
Ein Schaltpunkt enthält die beiden Bytes:
0xXY 0xZZ mit X = Tag (0=Mo, 2=Di, C=So, E=Schaltpunkt undefiniert),
Y = Schalten (0=Aus, 1=Ein, 7=Schaltpunkt
undefiniert),
ZZ = Zeitpunkt (00=00:00, ... 8f=23:50,
90=undefiniert).
Beispiel:
01 1e : Montag, Ein, 5:00
Vielleicht findet jemand noch die Bedeutung der restlichen Bytes heraus
?
Niffko _ schrieb:> daher reicht mir> das noch nicht als 'Beweis' ;-)
Na wenn Du Beweise brauchst.... ;o)
Beitrag "Re: Logamatic 2107 Schnittstelle"
Gut, man kann es nicht wirklich 100% erkennen. Aber als ich noch näher
herangezoomt habe konnte man gut sehen dass nach jedem gesendeten Byte
ein EchoByte vom Master kommt. Beide Bilder sind aus der selben Messung.
Niffko _ schrieb:> Das nicht, aber er würde mit seinem Echo mein nächstes Byte plattbügeln,> wenn er stur nach jedem empfangenen Zeichen ein Reply sendet.
habs mir doch fast gedacht dass Du es nicht so vertanden hast wie ich es
gemeint hatte. Die RC30 wartet immer auf ein Echo bevor das nächste Byte
kommt. Kann sein dass der Master erkennt wenn jemand ein ganzes Paket
ohne Pause sendet und dann keine Echo sendet.
Allerdings würde ich empfehlen es genau so zu machen wie die RC30. Also
nach jedem Byte ein Byte Pause machen oder das Echo einlesen und zu
vergleichen.
Der einzige der ohne die 1-Byte-Pause zwischen den Sendebytes sendet ist
der Busmaster.
Habe allerdings auch mal ein Telegramm am OSzillioskop gesehen das in
mehreren Bröckchen gesendet wurde. Kann das allerdings nicht mehr
nachfollziehen.
Wäre möglich dass auf dem EMS-Bus nur gesendet werden darf wenn ein Echo
gesendet wurde. Kann ja sein dass der Busmaster kurz beschäftigt ist und
dadurch dem Sender eine Pause aufzwingen kann.
Vielleicht funktioniert ja auch das Dein "drauflospusten" und macht erst
Probleme wenn irgendwelche Komponenten z.B. mit neuerer Firmware in der
Heizung ausgetauscht werden.
MartinQ schrieb:> ... insbes. an Rudi ... und auch IngoF für die CRC-Berechnung. ...
Danke, sieht man nicht wirklich wieviel Zeit ich mit der
Tabellenkalkulation verbracht habe um das erste Ergebnis zu bekommen.
Aber der Entscheidende Hinweis kamm dann von Rudi, dass bei gesetzten
Bit7 der CRC nochmal mit einem Wert (0x12?) geXORed wurde. Hätte ich
vermutlich nie herausgefunden! Hab schon echt verzweifelt ;o) Wusste nur
dass es mit den getesteten Telegrammen ohne >0x80 funktioniert hatte.
Aber gut dass es das Internet und Mikrocontroller.net gibt....
MartinQ schrieb:> Vielleicht findet jemand noch die Bedeutung der restlichen Bytes heraus ?
Das ist nur eine Frage der Zeit. Das ist ja einer der Hauptgründe warum
ich an den EMS-Bus wollte....
Denke aber dass da noch jemand schneller sein wird als ich.
Gruß
Ingo
00 11 08 0a 0a 09 0a 01 01 00 01 01
0 Stunden Party Funktion
17.08.2010
Urlaubstart Tag
Urlaubstart Monat
Urlaubstart Jahr
10.09.2010
Urlaubende Tag
Urlaubende Monat
Urlaubende Jahr
01.01.2010
Feiertagstart Tag
Feiertagstart Monat
Feiertagstart Jahr
01.01.2000
Feiertagende Tag
Feiertagende Monat
Feiertagende Jahr
Hallo,
Niffko _ schrieb:> Korrigiere mich bitte - aber auf den Beispielbildern mit Echos sind samt> sonders nur Polling Antworten ('Ja, ich lebe noch!') zu sehen. Ein> Daten-Telegramm eines Busteilnehmers ist nicht dabei, daher reicht mir> das noch nicht als 'Beweis' ;-)
Könntest du einfach mal senden und dir die empfangenen Daten anzeigen
lassen ? Wenn du deine gesendeten Daten nicht siehst, dann funktioniert
es nicht, bzw. erkennt der Busmaster deine Daten nicht.
Grüße.
IngoF schrieb:> 01.01.2010> Feiertagstart Tag> Feiertagstart Monat> Feiertagstart Jahr>> 01.01.2000> Feiertagende Tag> Feiertagende Monat> Feiertagende Jahr
musste eigentlich heissen:
10.01.2001
00.01.2001
Keine Ahnung warum dort 00 als Tag steht...
IngoF schrieb:> Keine Ahnung warum dort 00 als Tag steht...
Da gibt es mehrere Variationen ;-). Je nachdem wann der erste des
Monats und der erste Monat anfängt, mit der Zeit das gleiche, steht da 0
oder 1. Bei den Wochentagen gibt es glaube ich auch nette Variationen,
einmal fängt er Sonntags an, einmal Montags ....
Ingo F. schrieb:> habs mir doch fast gedacht dass Du es nicht so vertanden hast wie ich es> gemeint hatte. ... Kann sein dass der Master erkennt wenn jemand ein> ganzes Paket ohne Pause sendet und dann keine Echo sendet.
... habe dich schon verstanden und der letzte Satz ist genau der Punkt.
Es ist ja offensichtlich so, dass der Master nicht dogmatisch darauf
besteht, nach jedem Zeichen ein Echo zu senden. Sonst hätte ich ja mein
gesendetes Telegramm nicht auf dem Bus sehen können.
Ingo F. schrieb:> Allerdings würde ich empfehlen es genau so zu machen wie die RC30.
Naja ... aber ein gutes Pferd springt immer nur so hoch wie es muss ;o)
Ingo F. schrieb:> Vielleicht funktioniert ja auch das Dein "drauflospusten" ...
uhhh ... drauflospusten klingt irgendwie so negativ! **schmoll**
Rudi schrieb:
>Könntest du einfach mal senden und dir die empfangenen Daten anzeigen>lassen ?
Hatte ich natürlich gemacht. Wie hätte ich auch sonst feststellen
sollen, dass keine Pausen notwendig sind. Ursprünglich wollte ich
austesten wie weit man es mit den Sendepausen treiben kann und habe die
Zeit zwischen Polling-Antwort und Break immer weiter ausgedehnt. Als
dann bei 255 Bitlängen immer noch niemand gemeckert hat und ich ohne
Weiteres nicht mehr erhöhen konnte, war der nächste logische Schritt, es
auch mal ganz ohne Pause zu versuchen. Meine Sendungen wurden immer
ordnungsgemäß vom Master auf den Bus geschoben.
//Niffko
Niffko _ schrieb:> war der nächste logische Schritt, es> auch mal ganz ohne Pause zu versuchen. Meine Sendungen wurden immer> ordnungsgemäß vom Master auf den Bus geschoben.
Na dann war dass wohl ein Missverständnis.
Du hast vermutlich Pausen eingelegt zwischen dem Echo vom Busmaster und
dem nächten Byte...
Man muss garkeine Pausen machen. Also Byte senden. Master sendet ohne
Pause das Echo. Sofort wenn das Echo empfangen wurde kann das nächste
Byte gesendet werden.
Niffko _ schrieb:> Naja ... aber ein gutes Pferd springt immer nur so hoch wie es muss ;o)
Ist nur dumm wenn das Pferd nur gerade so hoch springen kann um gerade
so über die Hürden zu kommen.
Wenn jetzt aus irgendwelchen Gründen die Hürden 1mm höher werden hat
Dein Pfer aber ein Problem und bleibt hängen.
Oder Dein Pferdchen hat mal einen schlechten Tag oder ist mit dem
falschen Fuß aufgestanden.... Wer weiss ;o)
Niffko _ schrieb:> uhhh ... drauflospusten klingt irgendwie so negativ! **schmoll**
Hatte es so verstanden dass Du nach dem ersten Byte sofort ohne auf das
Echo zu warten das nächste hinterher schickst. Denke der Busmaster
dürfte aber mehr Puste haben, und Dein nächstes Byte mit seinem Echo
wegpusten....
Gruß
Ingo
IngoF schrieb:> Na dann war dass wohl ein Missverständnis.> Du hast vermutlich Pausen eingelegt zwischen dem Echo vom Busmaster und> dem nächten Byte...
Oh mann, hier hat das geschriebene Wort wohl mal wieder so richtig seine
Tücken. Ich versuch's jetzt nochmal:
mit Pause
Master sendet : 8X <brk>
Ich sende : 0X P XX P XX P XX P XX P XX P <BRK>
Ich empfange : 0X XX XX XX XX XX <BRK>
ohne Pause
Master sendet : 8X <brk>
Ich sende : 0X XX XX XX XX XX <BRK> kontinuierlicher Stream, auf
Stop-Bit folgt Start-Bit, keine Pausen
Ich empfange : 0X XX XX XX XX XX <BRK>
> Niffko _ schrieb:>> Naja ... aber ein gutes Pferd springt immer nur so hoch wie es muss ;o)>> Ist nur dumm wenn das Pferd nur gerade so hoch springen kann um gerade> so über die Hürden zu kommen.
Ich schrieb: so hoch wie es muss, nicht wie es kann.
> Wenn jetzt aus irgendwelchen Gründen die Hürden 1mm höher werden hat> Dein Pfer aber ein Problem und bleibt hängen.
Ein gutes Pferd sieht das und springt dann ebend höher.
> Oder Dein Pferdchen hat mal einen schlechten Tag oder ist mit dem> falschen Fuß aufgestanden...
Wenn es schlechte Tage hat, ist es kein gutes Pferd.
So ... jetzt ist aber gut ;o)
IngoF schrieb:> Hatte es so verstanden dass Du nach dem ersten Byte sofort ohne auf das> Echo zu warten das nächste hinterher schickst.
ja ... richtig ... geht doch.
IngoF schrieb:> Denke der Busmasterdürfte aber mehr Puste haben, und Dein nächstes> Byte mit seinem Echo wegpusten....
Genau das ist der Punkt ... er pustet ebend nicht ... obwohl er könnte.
//Niffko
Hallo,
Niffko _ schrieb:> IngoF schrieb:>> Denke der Busmasterdürfte aber mehr Puste haben, und Dein nächstes>> Byte mit seinem Echo wegpusten....> Genau das ist der Punkt ... er pustet ebend nicht ... obwohl er könnte.
Du kannst aber nicht wissen wann der Master senden will und das ist das
Problem. Wenn der Bus auf Low gehalten wird darf nicht gleichzeitig
gesendet werden. In den Scope Bildern von mir siehst du auch wie der
Master gleichzeitig sendet, okay mein Sendepegel war etwas zu groß, aber
das sollte erst einmal egal sein.
Grüße.
Nur mal eine Vermutung von mir:
An anderer Stelle hat mal einer erwähnt, das der Empfänger des Masters
auf die durch den Transistor und den 220 Ohm Widerstand erzeugten
Stromschwankungen reagiert, anstatt auf die eher geringen
Spannungsschwankungen.
Der Strom ist bei 15V damit beim Senden um 68mA höher, bei 10V (Low) um
45mA höher als der Ruhestrom.
Warum soll der Master also nicht auch unabhängig von seiner eigenen
Sendeaktivität gleichzeitig in der Lage sein zu empfangen? Es reicht
doch, wenn die Ansprechschwelle des Empfängers z.B. bei 30mA liegen
würde!
Damit könnte ich mir vorstellen das der Master brav nach jedem
empfangenen Byte sofort das Spannungsecho sendet und parallel dazu auf
seiner Stromschnittstelle das nächste Byte empfängt. Der Sendeschaltung
ist es auch schitegal ob sie mit statisch 15V oder mit modulierten
10/15V beaufschlagt wird.
BTW: Nachdem ich jetzt auch mal mitrede zu meiner Person:
Buderus GB162
Windhager Logwin
UVR1611
Den GB162 steuere ich über Leistungsmodulation (10V mit Original EM10,
hallo Niffko :-) )
Bislang hab ich nur mitgelesen (und werd es wohl auch im wesentlichen
auch in Zukunft tun) da ich momentan mich eher darauf konzentiere zu
versuchen das LON-Protokoll zu entschlüsseln weil ich das was ihr hier
macht mit dem Logwin machen möchte.... Am Ende sollen sowohl der Logwin
als auch der GB162 mit entsprechenden Interfaces direkt via OpenCAN von
der UVR1611 gesteuert/ausgelesen werden.
rkoch schrieb:> Warum soll der Master also nicht auch unabhängig von seiner eigenen> Sendeaktivität gleichzeitig in der Lage sein zu empfangen? Es reicht> doch, wenn die Ansprechschwelle des Empfängers z.B. bei 30mA liegen> würde!
Das wäre vielleicht die Erklärung warum es bei Niffko so funktioniert.
IngoF schrieb:>> Warum soll der Master also nicht auch unabhängig von seiner eigenen>> Sendeaktivität gleichzeitig in der Lage sein zu empfangen? Es reicht>> doch, wenn die Ansprechschwelle des Empfängers z.B. bei 30mA liegen>> würde!>> Das wäre vielleicht die Erklärung warum es bei Niffko so funktioniert.
Dann bräuchte der Master aber 2 Empfänger bzw. eine Umschaltung der
beiden bei TX und RX, denn das LOW bekommt er nicht durch Luft und Liebe
auf den Bus. Zusätzlich ist der Bus nicht Taktsynchron, ergo
funktioniert das so nicht.
Grüße.
IngoF schrieb:> Hat schon mal jemand irgendwann gesehen was am Bus passiert wenn man ein> Telgramm mit der falschen CRC auf den Bus schiebt?
Was Telegramme angeht, die für den Busmaster(08) bestimmt sind, kann ich
hierzu Folgendes sagen. Grundsätzlich werden auch Telegramme mit
falscher CRC auf den Bus 'ge-echot'. Beim Senden mit Unterbrechung ist
das natürlich logisch und nicht zu verhindern. Aber auch wenn mann das
Telegramm im Paket absetzt und der Busmaster vor dem Wiederholen die
Möglichkeit zur Prüfung hätte, wird das fehlerhafte Telegramm auf den
Bus gegeben. Ein fehlerhaftes Telegramm wird dann allerdings vom Master
mit 0x04 <brk> quittiert, wogegen ein korrektes Telegramm ein 0x01 <brk>
bekommt. Somit wäre das auch eine gute Möglichkeit eine abgesetzte
Sendung zu verifizieren.
//Niffko
> Dann bräuchte der Master aber 2 Empfänger bzw. eine Umschaltung der> beiden bei TX und RX, denn das LOW bekommt er nicht durch Luft und Liebe> auf den Bus. Zusätzlich ist der Bus nicht Taktsynchron, ergo> funktioniert das so nicht.
Wenn ich mich nicht irre wissen wir über die Sendeschaltung des Masters
recht wenig. Da es möglich ist auf einer Busleitung eine
spannungsgesteuerte und eine stromgesteuerte Übertragung mit annähernd
100%iger Kanaltrennung zu fahren könnte ich mir sehr wohl vorstellen das
das funktioniert. So lange unser System nicht Multi-Master-Fähig ist
(ist es das ?) bräuchte der Master genausowenig wie die Clients 2
Kanäle. Bei ihm wäre nur die Sende/Empfangsschaltung genau konplementär
zu der der Clients...
Da man der Sendeschaltung des Masters offenbar einiges an Strom zumuten
kann würde ein zweiter Master mit Spannungssignalisierung IMHO nicht
funktionieren. Insofern wäre Multi-Master IMHO nur möglich, wenn man den
Master in zwei Funktionalitäten trennt: Bus-Master und Device Master,
d.h. der Bus Master ist der einzige am Bus mit Spannungssender, Device
Master senden und empfangen (solange sie nicht zugleich Bus-Master sind)
wie Clients, aber machen das Polling für ihre Clients.
Ob es so was wie Multi-Master gibt kann ich aus den bisherigen Beiträgen
auf die Schnelle nicht herauslesen. I.d.R. kommen hier wohl nur entweder
Logamatic oder BC10 als Master vor....
Falls es doch mehrere Master am Bus gibt müssen diese aber eigentlich
nur im Moment des Einschaltens sich einig werden wer den Bus-Master
macht - im simpelsten Fall einfach indem derjenige der beim Einschalten
0V auf dem Bus sieht seine Treiber aktiviert. Der Verlierer in dieser
Selektion schaltet dann einfach sein RX/TX auf das Client-Interface.
Ich weiß zwar absolut nicht ob das so läuft, aber vorstellbar wäre es -
gibt es schließlich in anderen Systemen nicht viel anders.
Die Master-Sendeschaltung stelle ich mir relativ primitiv vor: 2
Spannungsquellen (15V/10V), die 10V einfach über eine Diode (oder einen
Transistor) auf den Bus geschaltet, die 15V immer über Transistor.
Eventuell auch noch einfacher: 15V und Spannungsdrop von ~5V durch eine
5V-Leistungs-Z-Diode die mit einem Transistor überbrückt wird. Als
Stromempfänger dann einfach ein Widerstand (ca. 6 Ohm), deshalb der
Spannungsabfall von ca. 0,5 V bei ~70mA, der Ruhestromwert über Tiefpass
auf Comparator, der Impulsstromwert direkt.
Vieleicht fabiluiere ich hier nur ins Blaue hinein, aber technisch
vorstellbar wäre so was.
Fred Granna schrieb:> Bekomme das mit dem Software-UART leider nicht> richtig hin :-(
Denke da kann Dir wohl nur Niffko weiterhelfen. Hier noch mal der Link
mit dem Soft-UART-Link von Niffko:
Beitrag "Re: Logamatic 2107 Schnittstelle"
Sonst verwenden hier ja wohl alle die hier gepostet haben einen Hardware
UART.
Was hast Du denn für ein Problem mit dem Soft-UART? Der i2c-UART ist
Geschichte??
Niffko _ schrieb:> Grundsätzlich werden auch Telegramme mit> falscher CRC auf den Bus 'ge-echot'.
Das hatte ich mir auch schon fast gedacht. Der Master kann die Prüfsumme
ja erst vergleichen wenn das Telegramm zu ende ist und das letzte Break
gesendet wurde.
Niffko _ schrieb:> Ein fehlerhaftes Telegramm wird dann allerdings vom Master> mit 0x04 <brk> quittiert, wogegen ein korrektes Telegramm ein 0x01 <brk>> bekommt.
Habe die Quittierung bisher noch nie gesehen. Kann aber sein dass die im
Polling untergegangen ist. Kommt das sofort nach dem Telegramm, oder
erst nach dem 0x0b <break> wenn Die "Kontrolle" zurück gegeben wird?
Gruß
Ingo
IngoF schrieb:> Denke da kann Dir wohl nur Niffko weiterhelfen. Hier noch mal der Link> ...
Hatte Niffko ne PM geschickt aber keine Antwort bekommen...
> Sonst verwenden hier ja wohl alle die hier gepostet haben einen Hardware> UART.
Nehme ich ungern, der Atmega328 von meinen Boards ja nur eine.
> Was hast Du denn für ein Problem mit dem Soft-UART? Der i2c-UART ist> Geschichte??
Mit dem i2c-Uart hab ich leider Timingprobleme. Die Break-Erkennung ist
zu langsam da ich den Chip nur über Polling ansprechen kann.
@Fred Granna
Hast Du Dir die App-Note AVR304
(http://atmel.com/dyn/resources/prod_documents/doc0941.pdf bzw.
http://atmel.com/dyn/resources/prod_documents/avr304.zip) schon mal
angeschaut? Ist doch eigentlich ganz gut dokumentiert und auch nicht
wirklich kompliziert. Die einzige Änderung wäre doch anstatt des
externen Interrupts den Comparator-IRQ zum Starten des Empfangs zu
verwenden und dann natürlich anstatt des IO-Ports den Ausgang des
Comparators zum Empfang zu verwenden.... und natürlich ggf. den IAR-Code
an z.B. gcc (WinAVR) anzupassen.
Fred Granna schrieb:> Hatte Niffko ne PM geschickt aber keine Antwort bekommen...
öhmm, sorry ... war keine böse Absicht. Das Motherboard von meinem Dell
ist mal wieder im Eimer und auf dem Laptop habe ich keinen Email-Krams
drauf.
Meinen AVR-Code möchte ich aber momentan keinem zumuten, der ist noch zu
'Baustelle'.
Formuliere doch mal die Probleme die Du hast, dann kriegen wir das schon
hin. Vielleicht hilft's ja auch dem Ein oder Anderen mit ähnlichen
Problemen.
Ich habe z.B. einen Gutteil Zeit investiert um herauszufinden, dass ich
die Anzahl der Timertakte für eine Bitlänge von 417 auf 400 korrigieren
muss (F_CPU 4MHz). Längere Telegramme wurden zum Schluss hin immer
falsch eingelesen, da die Abtastung zeitlich aus dem Ruder lief.
Wenn Du den Soft-UART von P.D. in alles Einzelheiten verstanden hast,
solltest Du das eigentlich hinbekommen.
Also ... lass mal hören, wo die Säge klemmt.
//Niffko
Niffko _ schrieb:> Ich habe z.B. einen Gutteil Zeit investiert um herauszufinden, dass ich> die Anzahl der Timertakte für eine Bitlänge von 417 auf 400 korrigieren> muss (F_CPU 4MHz). Längere Telegramme wurden zum Schluss hin immer> falsch eingelesen, da die Abtastung zeitlich aus dem Ruder lief.
417 wäre aber definitiv richtig... Kann es sein, das Du den Timer immer
wieder neu aufsetzt anstatt ihn einfach im PWM Mode mit IRQ bei Overrun
laufen zu lassen? Dann musst Du natürlich die Zeit die der AVR zum
Setzen des Zählers braucht abziehen... Trotzdem gibt das u.U. immer noch
genug Jitter um aus dem Ruder zu laufen, je nachdem ob Du noch andere
IRQs aktiv hast.
rkoch schrieb:> 417 wäre aber definitiv richtig...
tja ... wem sagst Du das. Vielleicht geht mein Quarz ja 'etwas' nach. :D
rkoch schrieb:> Kann es sein, das Du den Timer immer wieder neu aufsetzt anstatt> ihn einfach im PWM Mode mit IRQ bei Overrun laufen zu lassen?
Negativ. Timer1 wird bei Programmstart einmal auf volle Bitzeit
initialisiert und läuft danach permanent im CTC-Mode. Der TX-Algo läuft
in der OutputCompareA ISR. RX wird über InputCapture gestartet
(Startbit) und OutputCompareB einmalig so gesetzt, dass die Abtastung in
der OutputCompareB ISR eine halbe Bitzeit später beginnt. Von daher
dürften eigentlich keine Abweichungen entstehen.
//Niffko
IngoF schrieb:> Habe die Quittierung bisher noch nie gesehen. Kann aber sein dass die im> Polling untergegangen ist. Kommt das sofort nach dem Telegramm, oder> erst nach dem 0x0b <break> wenn Die "Kontrolle" zurück gegeben wird?
Hallo Ingo,
nachfolgend ein Paar Snippets zum Thema Quittierung.
Quittierung 'standard':
Folgendes ist mir erst kürzlich aufgefallen. Es widerlegt meine These,
dass nur Telegramme an den Master(08) quittiert werden und wirft die
Frage auf, wer überhaupt quittiert - der Master oder der jeweilige
Empfänger!? Ich wäre ja fast für Letzteres.
Niffko _ schrieb:> der Master oder der jeweilige> Empfänger!? Ich wäre ja fast für Letzteres.
Na das wird sich ganz einfach feststellen lassen...
Allerdings habe ich noch einen Bug in meiner Senderoutine. Irgendwie
gibt es noch Probleme mit dem Vergleich der gesendeten Bytes.
Wenn die Quittierung von der MC30 kommt wenn ich ein Telegramm an sie
sende sollte man erst den Sendepegel der RC30 sehen und anschließend das
Echo vom Busmaster.
Wenn der Busmaster die Telegramme quittiert fehlt der.
Wenn irgendjemand die Telegramme quittiert die man von anderen
Busteilnehmern bekommt, dann kann es nur der Master sein.
Bin auch für die Vermutung dass der Empfänger quittiert. Aber bisher
natürlich nur eine Vermutung.
Mir ist gerade aufgefallen dass nur Telegramme bestätigt werden in denen
das Bit7 nicht gesetzt ist. Also nur Telegramme auf die sonst keine
Antwort vom Empfänger kommt.
Vermutlich auch ein Zeichen dafür dass der Empfänger bestätigt....
Gruß
Ingo
Hallo,
habe noch mal meine alten LOG-Files durchsucht.
Es sieht so aus als ob Das Telegramm 10 00 06 ..... immer bestätigt
wird.
Telegramme an die 21 wurden nicht bestätigt. An die 08 allerdings
schon.. Also hat das nicht nur was mit dem Polling zu tun...
Allerdings war das beim herausfinden der Adressen am EMS-Bus und die
0x21 bin ich gewesen (Hatte nutr Polling beantwortet)
Einmal kam die 01 ohne dass das Polling an die 10 rausgegangen ist und
dannach Antwortet die 10 (MC30)
Oder ist das ein Check ob die die RC30 noch da ist? Macht ja auch wenig
Sinn.. es gibt ja das Polling.
Die "Quittierung" kommt sogar mal ganz spontan ohne irgendwelche
Telegramme. Vielleicht wird es zusätzlich jede Minute die keine
Telegramme versendet wurden auch auf den Bus gegeben. Allerdings hatte
ich damals noch einen großen Buffer und die Zeiten ändern sich selten.
Kann also im Moment nicht sagen wie lange die Pause sein kann....
Die Qutittierung 04 habe ich allerdings garnicht gefunden.
Hier mal ein paar Ausschnitte die ich Beispielhaft aus meinen Log-File
geschnibbelt habe:
Niffko _ schrieb:> ... sagt jemand, der ein DSO sein Eigen nennt - wer hat der kann ^^
Genau das hatte ich auch damit gemeint.. Allerdings ärgert mich noch
meine Senderoutine. Der Vergleich will nicht immer klappen...
Also wenn ich soweit bin werde ich mal danach gezielt suchen...
Bis dahin kann ich nur dannach in meinen Log-Files suchen und wild
herumspekulieren ;o)
Gruß
Ingo
IngoF schrieb:> Telegramme an die 21 wurden nicht bestätigt ... und die> 0x21 bin ich gewesen (Hatte nutr Polling beantwortet)
ok ... das spricht dafür, dass der Empfänger quittiert. Denn als solcher
wärst Du offensichtlich dafür verantwortlich gewesen, hast es aber nicht
getan.
IngoF schrieb:> Die Qutittierung 04 habe ich allerdings garnicht gefunden.
... hierfür wirst Du ein Telegramm mit einer falschen CRC schicken
müssen. Wie es aussieht, ist der Bus, was Fehler angeht, ziemlich
robust.
//Niffko
Niffko _ schrieb:> ok ... das spricht dafür, dass der Empfänger quittiert.
Mich stört nur noch das ab und zu die 01 Grundlos mitten im Polling
auftaucht.. Aber vermute mal das war irgend ein Fehler in meiner
Software. Es trat immer vereinzelt auf und danach kam eine Antwort von
der 10 (MC30) ohne Polling.. Hätte also eigentlich eine 90 sein
müssen...
Niffko _ schrieb:> Wie es aussieht, ist der Bus, was Fehler angeht, ziemlich> robust.
Also in 137 MByte (60Stunden) kein einziges fehlerhaftes Telegramm ist
doch auch schon mal was
Hallo,
ich sehe die 0x01 auch ;-).
Die Bestätigung wird offensichtlich nur gesendet, wenn "Werte" gesetzt
werden:
=> 10 08 1a 00 38 64 64 00 09
=> 01
=> 10 08 35 00 11 11 30
=> 01
Wenn in der Bedienung ein paar Werte geändert werden, sollte die 0x01
auch zu sehen sein !?
Grüße.
Hallo an alle...
im Moment tut sich ja nicht mehr viel in diesem Thread. Aber eigentlich
ist ja inzwischen schon fast alles bekannt.
Habe schon mal das 3964R-Protokoll "eingebaut". Falls jemand sowas
ähnliches vorhat und das noch testen will kann ja mal mein kleines
3964R-Terminal Programm ausprobieren.
Zu finden http://modelledit.rc-sim.de unter Downloads.
Den Trace kann man nur sehen wenn das Programm über die Batchdatei oder
über Console mit java -jar Terminal-3964R aufgerufen wird. der
"löschen"-Knopf hat noch keine Funktion.
Als Paramter kann man noch den seriellen Port übergeben.
Sollte auch unter Linux oder auf dem MAC laufen. Habe es allerdings noch
nciht getestet. Einfach "COM1" auf den entsprechenden Namen ändern.
Java 1.6 ist Mindestvorraussetztung.
Wer das Programm hilfreich findet kann ja eine Kleinigkeit an Unicef
spenden.
Installation: Entpacken und starten :-)
Gruß
IngoF
Hallo, erstmal an alle Lob und Anerkennung, ich lese schon längere Zeit
mit. Da es aber sehr viel ist, finde ich es gut wenn man eine
Zusammenfassung vom heutigen Stand hätte. Ich selbst habe eine Buderus
Heizungsanlage aus dem Jahr 2003:
GB142-24
RC30
MM10
WM10
da ich den PIC 18F2550 / 18F4550 programmiere bin ich an ein Programm
für diesen interessiert. Also die Schnittstelle zum EMS Bus. Ich möchte
zuerst nur einmal die Störmeldungen abfragen falls das Gerät ausfällt.
Später möchte ich evtl. der RC30 Temperatur-Sollwerte vorgeben. Ich
denke das ist nach dem heutigen Stand möglich.
IngoF schrieb:> Also ich habe zumindest geplant so eine Platine als "Sammelbestellung">> zu machen. Allerdings ist meine Hardware noch in der Entwicklung.
@IngoF an eine Sammelbestellung bin ich interessiert, soll es ein PIC
sein?
mich würde auch deine Firmware interessieren (für PIC). Welche
Programmiersprache benutze Du? Macht es einen Sinn die
Komperatoreingänge zu benutzen?
Gruß pic18f
F. F. schrieb:> da ich den PIC 18F2550
Ich habe den 18F258 bisher verwendet und nehme jetzt den 18F2580. Der
18F2550 hat keine eingebaute CAN-Schnittstelle.
Mit den Komperatoreingängen habe ich mich nicht beschäftigt. Wenn man
diese beutzen möchte kann man den eingebauten EUSART nicht nutzen und
müsste auf einen Soft-UART zurückgreifen.
Aber irgendwie sind mir persönlich externe Komperatoren lieber. Notfalls
kann man die auch austauschen.
Vermutlich werde ich aber auch noch einen SoftwareUART zusätzlich
verwenden damit ein PIC zwischen EMS-Bus und PC läuft. Vielleicht wird
es ja auch ein externer UART oder auch ein anderer PIC. Im Moment habe
ich einen PIC der den EMS-Bus mit CAN verbindet. Der zweite verbindet
dann den CAN mit dem PC.
Ich bin Assembler Anhänger weil ich kein C kann und mir einbilde dass
ich dann mehr Kontrolle über die Hardware habe.
Werde später dann den Eagle-Schaltplan und die Firmware als Download
anbieten und natürlich eine Art Sammelbestellung machen. Wird vermutlich
SMD sein die selber bestückt werden muss. Wenn natürlich genug
zusammenkommen würde eine fertig bestückte Platine sich auch rechnen.
Das Sollwert vorgeben sollte wirklich kein Problem mehr sein... Die
Prüfsumme, das Telegrammformat sind ja soweit eigentlich bekannt...
Bin allerdings noch nicht mit meiner Empfangsschaltung zufrieden und
werde demnächst mal die gepostete Buderus-Lösung ausprobieren.
Vermutlich wird die besser als meine "Standartbeschaltung".
Im Moment kämpfe ich noch mit den letzten Feinarbeiten an dem
3964R-Protokoll herum.
Werde mich hier auf jedenfall noch mal zu Wort melden wenn eine
Sammelbestellung in Sicht ist.
Gruß
IngoF
Hallo,
endlich jemand der einen PIC programmiert.
Der 18F2580 hat gegenüber den 18F2550 zwei Nachteile. Es fehlt der
USB-Bus sowie die Komperatoreneingänge, diese hat laut Datenblatt nur
der große Bruder 18F4580. Falls man diesen nimmt, dann dürfte es mit der
EUSART keine Probleme geben.
Der Vorteil des 18F2580 ist, daß wenn 32Mhz Taktfrequenz genügen man
keine Quarzbeschaltung benötigt, da man den internen Takt über der der
PLL hochtreiben kann. Sowie der CAN-Bus.
Habe ich es richtig verstanden, daß der CAN-Bus nur für die Verbindung
der zwei PIC's genommen wird? Könnte da man nicht den I2C-Bus nehmen
oder ist da die Reichweite zu klein. Welche Schnittstelle wird denn zum
PC genommen? Eine RS232? Diese Schnittstelle haben die meisten neuen
Rechner nicht mehr, hier wäre eine USB-Schnittstelle von Vorteil. Zum
EMS-Bus wird wohl die Eusart-Schnittstelle mit dem 3964R Protokoll
genommen, welches ich nicht kenne.
Von SMD bin ich kein Freund, ich weiß nicht ob ich dies mit einem
normalen Lötkolben löten kann. Außerdem, falls man mal was ändert, dann
ist die Beschaltung doch sehr klein.
Die PIC's habe ich immer mit einen Bootloader, welcher ich mit einen
einfachen Brenner programmiert hatte, versehen. Die Firmware hatte ich
dann mit den USB-Bus geladen hatte. Pitkit oder ähnliches besitze ich
nicht.
Assembler ist Ok, ich programmiere zwar mehr in C18 wegen der
Übersichtlichkeit, aber schnelle Interruptprogramme habe ich meistens in
Assembler geschrieben.
Ich bin auf jeden Fall auf den Schaltplan sowie der Firmware
interessiert und freue mich wenn eine Sammelbestellung in Sicht ist.
Viele Grüße
F. F.
Hallo F.F.
habe mal einen neuen Thread für dieses Thema gemacht:
Beitrag "Buderus EMS-"Gateway" mit PIC18F / Sammelbestellung"
Alles zu der Sammelbestellung, Schaltungs- und Softwareentwicklung gibt
es dann dort.
Hat ja schon lange nichts mehr mit der Buderus 2107 zu tun.
Gruß
IngoF
Niffko _ schrieb:> achso ... ich habe mal das bus interface eines moduls mm10 aufgedröselt> und zu 'papier' gebracht (siehe anhang).
Hallo Niffko,
deine Schaltung ist so nicht richtig. An den Eingangskomparator muss an
- die Uref. Die 1nF/100k/10k sollten da nicht sein, wofür sind die? Ich
habe die Schaltung mal aufgebaut und mit einem Funktionsgenerator
getestet und gemessen. Funktioniert ganz ordentlich mit der Änderung.
Grüße.
Rudi schrieb:> deine Schaltung ist so nicht richtig.
Gut gebrüllt, Löwe.
> An den Eingangskomparator muss an - die Uref.
Da am (+) Eingang über den 47K Widerstand ebenfalls Uref. anliegt,
hättest Du damit IMHO den gleichen Gleichspannungspegel an beiden
Eingängen, hältst Du das bei einem Komparator für sinnvoll?!
So wie ich das sehe, wird Uref. über einen Spannungsteiler (10K/100K)
auf den (-) Eingang gelegt. Somit ist der "Ruhepegel" an (-) geringfügig
unterhalb dem von (+) und der Komparator damit definiert auf High.
Den 1nF Kondensator sehe ich als eine Art Störunterdrückung. Kurze
(Stör)Impulse führen nicht zu einer "Fehlzündung" des Komparators, da
die Pegel zunächst an beiden Eingängen abgesenkt werden und somit kein
Delta entsteht. Ist der Low-Impuls aber länger als die Umladezeit des
1nf Kondensators, schaltet der Komparator.
Soweit meine Theorie ... sollten hier Profis mitlesen, bitte ich ggf. um
Berichtigung.
Besagte Schaltung arbeitet übrigens in meinem Projekt 'Rücklaufgeführte
Heizungsregelung' bereits über mehrere Monate sowohl im Rx- als auch im
TX-Betrieb einwandfrei.
// Niffko
Niffko _ schrieb:> Rudi schrieb:>> deine Schaltung ist so nicht richtig.>> Gut gebrüllt, Löwe.
Ja ;-).
Die Signale sehen an +/- in etwa gleich aus, bei dem 1nF Kondensator
etwas verzerrter. Ich kann mal Bilder mit dem Oszi machen, wie gesagt
ich habe das mit einem Signalgenerator getestet (Offset 9.5V und dann
ein 5V Signal) ohne ordentliches Signal am Ausgang. Es gab nur Spikes an
den Flanken.
Grüße.
Anbei das Bild. Oben das Signal am 10uF und unten das Signal am 1nF. Wie
man sieht kann der Komparator bei diesen Signalen nicht schalten.
Niffko _ schrieb:> Da am (+) Eingang über den 47K Widerstand ebenfalls Uref. anliegt,> hättest Du damit IMHO den gleichen Gleichspannungspegel an beiden> Eingängen, hältst Du das bei einem Komparator für sinnvoll?!
Der Widerstand arbeitet als Pullup für das Signal am Kondensator, siehe
Bild, ansonsten würde der Kondensatorausgang bei DC-Signalen floaten.
> So wie ich das sehe, wird Uref. über einen Spannungsteiler (10K/100K)> auf den (-) Eingang gelegt. Somit ist der "Ruhepegel" an (-) geringfügig> unterhalb dem von (+) und der Komparator damit definiert auf High.
Auch hier wird das Signal hinter dem Kondensator über die beiden
Widerstände konditioniert, siehe Bild, nur ist die Ladung bei diesem
Kondensator relativ gering und das Signal fällt relativ schnell ab.
> Den 1nF Kondensator sehe ich als eine Art Störunterdrückung. Kurze> (Stör)Impulse führen nicht zu einer "Fehlzündung" des Komparators, da> die Pegel zunächst an beiden Eingängen abgesenkt werden und somit kein> Delta entsteht. Ist der Low-Impuls aber länger als die Umladezeit des> 1nf Kondensators, schaltet der Komparator.
Nein. Die Kondensatoren übertragen den AC-Anteil vom Signal. Sprich nur
sich ändernde Signale.
> Besagte Schaltung arbeitet übrigens in meinem Projekt 'Rücklaufgeführte> Heizungsregelung' bereits über mehrere Monate sowohl im Rx- als auch im> TX-Betrieb einwandfrei.
Das ist seltsam. Kannst du die Signale mit einem Oszi. messen?
Grüße.
Hallo Rudi,
vorab, die Signalhübe und Offsets unbekannterweise jetzt mal außen vor
gelassen - warum schaltet der Komparator nicht spätestens bei Markierung
II (siehe Anhang)? Zu diesem Zeitpunkt liegt das Signal an (+) noch auf
Low und an (-) ist durch die geringe Kapazität des 1nF Kondensators
bereits keine AC-Einkopplung mehr vorhanden. Die Spannung an (+) müsste
sich also unterhalb der an (-) befinden, was ein Schalten des
Komparators zur Folge hätte.
> Niffko _ schrieb:>> ... über den 47K Widerstand ebenfalls Uref. anliegt...>> Der Widerstand arbeitet als Pullup ...
Sozusagen. Und auf welche Spannung pullt er up ... auf Uref.
> ... als Pullup für das Signal am Kondensator, siehe> Bild, ansonsten würde der Kondensatorausgang bei DC-Signalen floaten.
Das ist nicht unrichtig, aus meiner Sicht ist der Hintergrund aber ein
anderer. Wie Du richtig angemerkt hast, wird über die Kondensatoren nur
der AC-Anteil des Signals eingekoppelt. Durch die Widerstände werden die
Eingänge des Komparators auf ein gewisses DC-Niveau vorgespannt - über
den Daumen, (+) auf 0,6V und (-) auf 0,55V. Der eingekoppelte AC-Anteil
bewirkt dann das Auslösen des Komparators. Beim Anliegen eines Null-Bits
gibt es bis zum Schalten des Komparators eine Totzeit (Bereich zwischen
I und II), da das Signal zunächst auf beide Eingänge wirkt, die Spannung
an (-) durch die schnellere Umladung des 1nF Kondensators aber relativ
fix wieder auf 0,55V steigt (siehe Bild).
>> So wie ich das sehe, wird Uref. über einen Spannungsteiler (10K/100K)>> auf den (-) Eingang gelegt.>> Auch hier wird das Signal hinter dem Kondensator über die beiden> Widerstände konditioniert, siehe Bild, nur ist die Ladung bei diesem> Kondensator relativ gering und das Signal fällt relativ schnell ab.
Wie gesagt, m.E. keine Signalkonditionierung, sondern ein Vorspannen der
Komparatoreingänge.
>> Den 1nF Kondensator sehe ich als eine Art Störunterdrückung...>> Nein. Die Kondensatoren übertragen den AC-Anteil vom Signal. Sprich nur> sich ändernde Signale.
Du hast mich nicht richtig verstanden. Das es hier um AC-Kopplung geht,
sollte klar sein. Das Ding ist, dass der 10µ das Signal 1:1 durch
reicht, der 1nF aber nur kurze Spikes auf den (-) Eingang koppelt.
Daraus ergibt sich eine Art Schaltverzögerung, wodurch kurze Störimpulse
dann keinen Schaltvorgang auslösen.
>> Besagte Schaltung arbeitet übrigens ... einwandfrei.>> Das ist seltsam. Kannst du die Signale mit einem Oszi. messen?
Aus Mangel an einem Funktionsgenerator, könnte ich das nur am Bus
machen. Weiß nicht ob das viel Sinn macht. Ist auch alles ziemlich
fummelig, da SMD. Mal sehen ...
// Niffko
Edit sagt: Zumindest ein Kollege aus dem Junkers-Thread scheint die
Schaltung auch erfolgreich anzuwenden.
Hallo,
Niffko _ schrieb:> vorab, die Signalhübe und Offsets unbekannterweise jetzt mal außen vor> gelassen - warum schaltet der Komparator nicht spätestens bei Markierung> II (siehe Anhang)? Zu diesem Zeitpunkt liegt das Signal an (+) noch auf> Low und an (-) ist durch die geringe Kapazität des 1nF Kondensators> bereits keine AC-Einkopplung mehr vorhanden. Die Spannung an (+) müsste> sich also unterhalb der an (-) befinden, was ein Schalten des> Komparators zur Folge hätte.
Ja, wenn der Komparator schnell genug ist sollte man am Ausgang Spikes
sehen. Der schaltet den Ausgang auf High wenn das Signal (+) über oder
auf Low wenn das Signal unter der Schwelle (-) liegt. Und hier schaltet
der nicht weil das Signal nie unter der Schwelle liegt.
>> Niffko _ schrieb:>>> ... über den 47K Widerstand ebenfalls Uref. anliegt...>>>> Der Widerstand arbeitet als Pullup ...>> Sozusagen. Und auf welche Spannung pullt er up ... auf Uref.
Genau, wenn am Kondensator mal kein Signal anliegt bzw. nur ein High auf
dem Bus anliegt, liegt das Signal über der Schwelle und am Ausgang vom
Komparator liegt das Signal stabil auf High. Ansonsten würde sich der
Kondensator mit der Zeit entladen und gegen 0V laufen, unter die
Schwelle und am Ausgang wäre ein Low zu sehen.
Das spricht eigentlich dafür, das der Kondensator nicht an das
Eingangssignal geht sondern dort an Masse (Blockkondensator) und die
beiden Widerstände als Widerstandsteiler arbeiten um die Uref etwas zu
senken.
Grüße.
Niffko _ schrieb:> Wie ist denn die Spannungsauflösung (V/cm) auf Deinem Oszi-Bild und sind> die Offsets real oder hast Du vertikal verschoben?
Der Auflösung lag bei 200mV, wenn ich mich recht erinnere. Die Offsets
sind vertikal verschoben.
Ich werde für den RX-Pfad wie bisher den ADCMP370 benutzen, der hat bis
jetzt funktioniert und die Bauteile halten sich in Grenzen. Den TX-Pfad
werde ich wie bei dir in der Schaltung aufbauen, aber ohne Komparator.
Die Versorgung werde ich auf 3V3 legen, aus einem LDO und die Anbindung
wird dann Isoliert (ISO7421D).
Grüße.
Hallo,
Niffko _ schrieb:> Besagte Schaltung arbeitet übrigens in meinem Projekt 'Rücklaufgeführte> Heizungsregelung' bereits über mehrere Monate sowohl im Rx- als auch im> TX-Betrieb einwandfrei.
könntest Du dein Projekt etwas näher beschreiben? Ich werde demnächst
etwas ähnliches regeln. Leider ist die Heizung z.Z. nicht mehr
operational, da in diesem Raum eine Bodensanierung anliegt.
Ich will den Rücklauf über einen Speicher anheben, der von der
Holzheizung geladen wird und evtl. später auch von Solar.
Grüße.
Hi Rudi,
Rudi schrieb:> könntest Du dein Projekt etwas näher beschreiben?
Ich habe die Heizkreisregelung komplett aus dem RC35 herausgenommen. Die
Brenneransteuerung erfolgt im Grunde über zwei Kennlinien -
Außentemperatur vs. Rücklaufsolltemperatur und Außentemperatur vs.
Brennerleistung. Die Führungsgrößen Rücklauftemperatur und
Außentemperatur werden vom Bus genommen, Brenneransteuerung erfolgt über
außentemperaturabhängige Vorgabe der Brennerleistung. Für Logging- und
Monitorzwecke wird über UART ein Telegramm mit relevanten EMS-Daten
bereitgestellt, EMS-Kommunikation läuft über Soft-UART. Momentan bin ich
dabei, mit C# eine GUI zu stricken, über die dann Monitoring,
Logging(.csv) und Parametrierung des Reglers möglich ist.
> Ich will den Rücklauf über einen Speicher anheben, der von der> Holzheizung geladen wird und evtl. später auch von Solar.
Hmm ... eigentlich brauchst Du für so was nicht an den EMS-Bus. Macht
man üblicherweise mit einem Differenztemperatur-Regler welcher
Anlagenrücklauf und Puffertemperatur überwacht. Ist der Anlagenrücklauf
kälter als der Puffer, wird er über ein Dreiwegeventil in den Puffer und
das Pufferwasser zum Heizkesselrücklauf geführt. Sollte die
Puffertemperatur noch nicht deckend sein, heizt der Heizkessel
entsprechend seiner Kennlinie nach.
//Niffko
Hallo,
Niffko _ schrieb:> Hmm ... eigentlich brauchst Du für so was nicht an den EMS-Bus. Macht> man üblicherweise mit einem Differenztemperatur-Regler welcher> Anlagenrücklauf und Puffertemperatur überwacht. Ist der Anlagenrücklauf> kälter als der Puffer, wird er über ein Dreiwegeventil in den Puffer und> das Pufferwasser zum Heizkesselrücklauf geführt. Sollte die> Puffertemperatur noch nicht deckend sein, heizt der Heizkessel> entsprechend seiner Kennlinie nach.
Ja, klassische Zweipunktregelung die den Brenner zum oszillieren bringt
und ich vermeiden wollte. Ich werde ein "richtiges" Mischerventil
benutzen und versuchen den Brenner auf Sparflamme zu fahren und nicht
volle Pulle umschalten. Wenn die Speichertemperatur größer als die
Sollvorlauftemperatur ist, verbrät mir die Zweipunktregelung zu viel
Energie.
Grüße.
Hallo :)
Hat hier einer eigentlich mal einen längeren Mitschnitt was sich
zwischen Servicekey und "Servicebuchse" so tut nachdem man das Teil
eingesteckt hat?
Hoch eine Frage bzgl. KM271-Schnittstelle:
Habe mir grad mal die "Baupläne" für die Nachbauten angesehen. Wozu
benötigt man den Analogpart? UART_RX, UART_TX, GND und +5V reichen doch
für die Kommunikation oder?
Fred Granna schrieb:> Hat hier einer eigentlich mal einen längeren Mitschnitt was sich> zwischen Servicekey und "Servicebuchse" so tut nachdem man das Teil> eingesteckt hat?
Weiter oben sind doch welche. Das Problem ist eher die Kommunikation
bzw. Umsetzung von PC<=>SERVICEKEY.
Grüße.
Fred Granna schrieb:> Habe mir grad mal die "Baupläne" für die Nachbauten angesehen. Wozu> benötigt man den Analogpart? UART_RX, UART_TX, GND und +5V reichen doch> für die Kommunikation oder?
In der Schaltung wird angeblich(tm) der GND verschoben, also alle
Temperaturen stimmen nicht mehr. Desweiteren hat die KM-Platine einen
Anschluss für einen Abgassensor.
Grüße.
Rudi schrieb:> Weiter oben sind doch welche. Das Problem ist eher die Kommunikation> bzw. Umsetzung von PC<=>SERVICEKEY.>>> Grüße.
Hm, bin ich blind? Da habe ich einen Log gefunden. Der ist aber nicht
vollständig. PC<->SK ist doch "nur" 3964R. Frage ist eher: Wie setzt der
SK da was um.
Rudi schrieb:> In der Schaltung wird angeblich(tm) der GND verschoben, also alle> Temperaturen stimmen nicht mehr. Desweiteren hat die KM-Platine einen> Anschluss für einen Abgassensor.>>> Grüße.
ALso könnte der Analogteil eigentlich wegfallen?
Fred Granna schrieb:> ALso könnte der Analogteil eigentlich wegfallen?
Die bist mit GND wohl schon direkt am analogen Teil und ohne den Sensor
(dein analoger Teil) erkennt er die Platine/Erweiterung nicht.
Grüße.
Fred Granna schrieb:> Hm, bin ich blind? Da habe ich einen Log gefunden. Der ist aber nicht> vollständig. PC<->SK ist doch "nur" 3964R. Frage ist eher: Wie setzt der> SK da was um.Beitrag "Re: Logamatic 2107 Schnittstelle" und folgende etwas
zerstreut.
Grüße.
Rudi schrieb:> Beitrag "Re: Logamatic 2107 Schnittstelle" und folgende etwas> zerstreut.>
Das hatte ich gesehen. Das ist aber die Kommunikation PC<->SK in 3964R
soweit ich das verstanden habe.
WÜrde aber gerne mal sehen was der SK auf dem EMS-Bus treibt.
Ansonsten hier:
Beitrag "Re: Logamatic 2107 Schnittstelle"
Dort ist ein Log vom Service-Key. Der Key arbeitet selbständig, sammelt
die Daten und schickt sie auf Anfrage an den PC.
Wie ist bei dir eigentlich der Stand?
Rudi schrieb:> Wie ist bei dir eigentlich der Stand?
Hatte nun über 6 Monate meine Bastellösung am laufen: Arduino mit
externem UART über i2c. Schwenke grad um auf einen Arduino mit 4 eigenen
UARTS.
Habe dazu deine Code genommen. Das Lesen vom Bus läuft. Habe nur massive
Probleme beim schreiben: Der Code fehlt mir komplett (und das Wissen
dazu auch)...
Der TX ist nicht weiter problematisch, da du das sehr schön im
RX-Interrupt machen kannst.
Kann die UART vom AVR ein Break senden?
Mein Handling um auf dem Bus bekannt zu werden sieht in etwa so aus:
1
dr = rx_data;
2
3
/* sending */
4
if ( ems_flag & 1 )
5
{
6
if ( dr == 0x0b )
7
{
8
/* send uart break */
9
}
10
ems_flag &= ~1;
11
}
12
13
if ( ems_cnt == 0 )
14
ems_adr = dr;
15
if ( (ems_cnt == 1) && (dr!=0) && (ems_adr&0x80) )
Hallo Leute,
sorry wenn ich mich hier einmische, aber ich bin über Google in den wohl
längsten Thread der Welt geraten :) Stichwörter: "Buderus Protokoll"
Ich verstehe nicht so ganz, worum es hier geht, aber vielleicht bewegt
ihr euch ja in der Nähe meines Problems.
Ich habe hier einen Raumthermostat namens Sieger eS71, innen auf der
Platine steht Buderus RC10/RC20. Das Ding ist aber nur halb bestückt, es
hat nur eine simple Thermostatfunktion und sonst nichts, und es werden
nur zwei der vier Anschlussdrähte benutzt. Auf einem Aufkleber steht
"RC10 V1.04 OK".
Mein Problem ist, dass ich meine Gasheizung gern ferngesteuert ein- und
ausschalten möchte, während aber heißes Wasser immer zur Verfügung
stehen soll.
Eine Lösung habe ich schon: eine Zusatzelektronik simuliert
Knopfdrehungen durch Schalter, die parallel zu den Knopfkontakten
liegen. Damit kann ich die Temperatur auf 11° bzw. 30° stellen, was in
der Praxis Aus- bzw. Einschalten bedeutet. Ist aber ziemlich aufwändig
und nicht gerade elegant.
Aus den Impulsen, die mein Oszilloskop an den beiden Steuerdrähten
anzeigt, werde ich nicht schlau. Handelt es sich dabei um das Protokoll,
das oben erwähnt ist? Ist vielleicht sogar das Know-How vorhanden, wie
man die Information "Zimmer ist zu kalt/heiß" auf die Drähte gibt?
Hallo Rudi, Matthias, Mario und IngoF,
könnte jemand eine/mehrere µP-Schaltung mit Hex-File zur Decodierung zur
Verfügung stellen?
Möglichst gängige µProzessoren.
Muß kein Layout da sein, mache ich und stelle es hier rein.
Muß auch kein Quellcode dabei sein, wer es nicht freigeben will.
Hauptsache alle kommen mal weiter mit dem EMS-Bus.
Gruß Helmut
Hallo Helmut,
bei mir läuft das Ding wie Stand 1,5 Jahre und ich nehme es nur zum
Loggen.
Verwendet wird der Pollin NetIo (Atmega644), auf dem ich mich per Telnet
von meiner Haussteuerung verbinde. Das Protokoll schicke ich
ASCII-kodiert rüber und parse es auf der Steuerung. Empfangen wird mit
der kleinen Schaltung ähnlich Rudi (aber mit LM393).
Softwarebasis ist der Webserver von U. Radig mit der Empfangsroutine von
Rudi und einigen Anpassungen. Problem am Hex ist, das die IP fest
einprogrammiert ist. Den Code kann ich gerne posten. Ich krame den am
Wochenende mal wieder aus.
Das Modul läuft schön stabil, hatte in der ganzen Zeit vielleich 2..3
Hänger nach kurzen Netzspannungseinbrüchen.
@all
Interessieren würde mich, das EM10-Modul nachzubauen. Kennt da jemand
ansatzweise das Protokoll? Weiß jemand, ob/wie man das Signal zur
einmaligen WW-Aufheizung abschicken kann?
Grüsse Matthias
Danke Dir Matthias,
ich habe gar kein Auto....
Ich oute mich mal, ich habe so eine Buderus-Steuerung nicht, auch kein
E-Bus-Gerät, wofür der Adapter eigentlich gedacht war.
Ich sah nur, dass es Ähnlichkeiten beim Bussystem gibt.
Dann hat mich gestört, das es 890 Eintragungen gibt aber keine Lösung,
die als brauchbar erkennbar ist.
Das muß doch mal fertig werden. Es gibt soviele Anwender für den
EMS-Bus.
Wäre nett von Dir: Bitte poste Deine Hard und Software.
Gruß Helmut
... gibts aber leider nur einmal als Prototyp ;P
Ich hatte ein defektes Solarmodul SM10 in die Hände bekommen, welches
hier als Organspender diente. Als Defektursache war ein zerstörter
Komparator der Eingangsbeschaltung relativ schnell ausfindig gemacht und
ausgetauscht. Anschließend alles, außer Signalformung, Quarz, LED,
Spannungsversorgung und 230V-Peripherie, von der Platine geräumt.
Atmega8 und FT323RL wurden rücklinks auf der Platine befestigt und mit
AWG#30 Kabel angeschlossen. Der 0.65mm Pitch des FT232 war hierbei -
sagen wir mal - anspruchsvoll. Auf der Platine sind mehr Kabel als man
eigentlich vermuten sollte, aber das meiste ist hier GND und VCC -
hiervon gibts ja bei SMD-Ausführung immer reichlich Pins und an ein
Brücken direkt am IC war nicht zu denken. Zum Schluss noch eine Mini-USB
Buchse aufgelötet und fertig war meine Hardware für die kommende
Heizsaison.
//Niffko
Tolle Sache, nur warum zeigst Du sowas?
Bringt niemanden so richtig weiter. Einer von 816 Beiträgen mit Null
Ergebniss.
Oder glaubst Du dass regt jemanden an es auch so zu machen?
Ich verstehe es nicht, wenn wenigstens ein Schaltplan dabei gewesen
wäre...
Oder ein Hex-File eines Prozessors für die Filterung von plausiblen
Daten......
Hallo Leute!
Mein umgebautes Solarmodul läuft ab sofort 'buspowered'. Schaltung wie
folgt:
1
120R _____
2
___ | |
3
Bus(+) ---|___|--o--|78L05|--o-----o---- VCC
4
| |_____| | | +
5
--- | --- ###
6
--- | --- ---
7
|100n | |100n | 22µ
8
| | | |
9
=== === === ===
10
GND GND GND GND
Versorgt wird ein Atmega8 incl. TX-LED. FT232 läuft von der Versorgung
über USB und der LM393 hängt direkt am EMS-Bus. Bei permanent
eingeschalteter LED fließen ca. 17mA. Busstörungen habe ich bisher keine
erkennen können, das Gerät arbeitet wie gewohnt. Das bedeutet
eigentlich, dass in Sachen Potentialtrennung auch Optokoppler möglich
sein sollten.
//Niffko
hallo,
habe letzte woche diesen thread per google gefunden und bin echt
erstaunt über eure erkenntnisse zum ems-bus. besten dank dafür!
daraufhin habe ich jetzt auch zwei tage bastelt und möchte auch meine
ergebnisse nicht vorenthalten.
ich habe hier noch einen rc20 controller rumliegen gehabt, an dem ich
die rx und tx leitung eines sparkfun ftdi board angeschlossen habe, um
auf den bus zuzugreifen. die tx-leitung des rc20 microcontrollers habe
ich gekappt, um mit dem ftdi board auch schreiben zu können. das ftdi
board ist per usb an einem linux pc angeschlossen. dort habe ich ein
perl script gebaut, um das polling für die adresse 0xb (service key) zu
beantwortet. für das break ziehe ich mit der dtr leitung per transistror
den tx-pin für den nötige dauer auf gnd. der service key wird nun
bus-monitor angezeigt und ein umschalten von nacht/tag/auto betrieb des
rc30 funktioniert schon damit.
falls jemand interesse an details hat, dann einfach melden.
besten dank,
picknicker
Hallo Helmut,
ich bin seit einer Woche Besitzer einer Logamatic 172 Anlage.
Da ich ein neugierer Mensch bin, würde auch ich gern
die Daten der Anlage via EMS-Bus mitloggen.
Du scheinst so eine ähnliche Konfiguration am Start zu
haben, wie ich Sie gerne hätte.
Magst Du mir bitte Deine Schaltung und Deinen Kode
für das Pollin NetIo (Atmega644) Board zur Verfügung
stellen ?
Ist es ein Problem, das meine Anlage mit einem Solarmodul
ausgestattet ist ? Ich meine hierzu etwas gelesen zu haben.
Viele Grüße
Jörg
> Hallo Helmut,>> bei mir läuft das Ding wie Stand 1,5 Jahre und ich nehme es nur zum> Loggen.> Verwendet wird der Pollin NetIo (Atmega644), auf dem ich mich per Telnet> von meiner Haussteuerung verbinde. Das Protokoll schicke ich> ASCII-kodiert rüber und parse es auf der Steuerung. Empfangen wird mit> der kleinen Schaltung ähnlich Rudi (aber mit LM393).> Softwarebasis ist der Webserver von U. Radig mit der Empfangsroutine von> Rudi und einigen Anpassungen. Problem am Hex ist, das die IP fest> einprogrammiert ist. Den Code kann ich gerne posten. Ich krame den am> Wochenende mal wieder aus.> Das Modul läuft schön stabil, hatte in der ganzen Zeit vielleich 2..3> Hänger nach kurzen Netzspannungseinbrüchen.
Ich würde auch gerne mitmachen. Hab auch ein Pollin AVR-Net-IO.
Da finden sich bestimmt noch mehr Leute mit Interesse.
Ich habe eine Buderus GB152-Therme und würde gerne mitloggen.
Viele Grüße
Norbert
> Hallo Helmut,> ich bin seit einer Woche Besitzer einer Logamatic 172 Anlage.> Da ich ein neugierer Mensch bin, würde auch ich gern> die Daten der Anlage via EMS-Bus mitloggen.> Du scheinst so eine ähnliche Konfiguration am Start zu> haben, wie ich Sie gerne hätte.> Magst Du mir bitte Deine Schaltung und Deinen Kode> für das Pollin NetIo (Atmega644) Board zur Verfügung> stellen ?>> Ist es ein Problem, das meine Anlage mit einem Solarmodul> ausgestattet ist ? Ich meine hierzu etwas gelesen zu haben.>> Viele Grüße> Jörg>>> Hallo Helmut,>>>> bei mir läuft das Ding wie Stand 1,5 Jahre und ich nehme es nur zum>> Loggen.>> Verwendet wird der Pollin NetIo (Atmega644), auf dem ich mich per Telnet>> von meiner Haussteuerung verbinde. Das Protokoll schicke ich>> ASCII-kodiert rüber und parse es auf der Steuerung. Empfangen wird mit>> der kleinen Schaltung ähnlich Rudi (aber mit LM393).>> Softwarebasis ist der Webserver von U. Radig mit der Empfangsroutine von>> Rudi und einigen Anpassungen. Problem am Hex ist, das die IP fest>> einprogrammiert ist. Den Code kann ich gerne posten. Ich krame den am>> Wochenende mal wieder aus.>> Das Modul läuft schön stabil, hatte in der ganzen Zeit vielleich 2..3>> Hänger nach kurzen Netzspannungseinbrüchen.
Hallo,
zunächst einmal: Respekt an alle, die hier mitgewirkt haben!
Ich bin recht neu in Sachen Elektronik und deshalb mag folgende Frage
auch bei einigen von euch zu Stirnrunzeln führen:
Ich würde gerne den ServiceKey Ausgang nutzen um an den Bus zu kommen.
Jedoch würde ich hier gerne per Optokoppler galvanisch trennen. Mein
eigentliches Problem ist jetzt, dass an diesem Klinkenstecker nur 2x GND
und einmal das Signal anliegen. Nur einmal angenommen, ich schalte
direkt hinter den Bus einen Operationsverstärker als Impedanzwandler für
das Signal(der spätere Aufbau ist anders aber das Beispiel hier reicht),
woher kann ich dann die Versorgungsspannung für den Operationsverstärker
beziehen? GND kann ich hier zwar anschließend, aber mir "fehlt" in
meinem Gedankenkonstrukt dann entweder VCC(>12V), oder, wenn ich die GND
vom Klinkenstecker als VCC für den Optopkoppler nehme, ein zweites
GND(<12V) für an den Optokoppler. Wenn ich für dieses zweite GND die 0V
meiner dahinterliegenden, galvanisch getrennten Schaltung verwenden
würde, wäre diese Trennung ja wieder hinfällig?
Müsste ich hier noch einmal separat sonst wo an der Heizung etwas
abgreifen? Das wäre mehr als unschön.
Desweiteren: Kann der Bus genug Strom liefern um meinen Optokoppler zu
versorgen? So wie ich das Ganze bisher verstanden habe, scheint er ja
belastbar genug zu sein.
Ich hoffe man kann das halbwegs nachvollziehen was mein Problem ist..
Danke schonmal! :)
Gruß
Olaf
OlafTezlaf schrieb:> Ich würde gerne den ServiceKey Ausgang nutzen um an den Bus zu kommen.> Jedoch würde ich hier gerne per Optokoppler galvanisch trennen. Mein> eigentliches Problem ist jetzt, dass an diesem Klinkenstecker nur 2x GND> und einmal das Signal anliegen.
Hm? An meinem Klickenstecker hab ich 12V,SIGNAL und GND. Benutze die 12V
auch um meine Schaltung inkl. dem Funksender für die Daten zu betreiben.
Was für eine Anlage hast du denn?
Fred Granna schrieb:> Hm? An meinem Klickenstecker hab ich 12V,SIGNAL und GND. Benutze die 12V> auch um meine Schaltung inkl. dem Funksender für die Daten zu betreiben.>
Ohje, sagt jetzt nicht ich hab die Belegung des Klinkensteckers
missverstanden. Ich habe mich auf
http://wiki.neo-soft.org/index.php/Heizungsschnittstelle/ServiceKey
bezogen. Dann hat das GND bei dem Eintrag unter "links" wohl nichts mit
dem GND +12V zu tun?
Hatte das ganze jetzt gar nicht nachgemessen.
> Was für eine Anlage hast du denn?
Mir ist die genaue Kennung leider entfallen, werde nachschauen sobald
ich wieder in der Heimat bin. Aber falls ich diese Tabelle
missverstanden habe hat es sich damit wohl gelöst :)
Gruß
Olaf
OlafTezlaf schrieb:> Ohje, sagt jetzt nicht ich hab die Belegung des Klinkensteckers> missverstanden. Ich habe mich auf> http://wiki.neo-soft.org/index.php/Heizungsschnitt...> bezogen. Dann hat das GND bei dem Eintrag unter "links" wohl nichts mit> dem GND +12V zu tun?> Hatte das ganze jetzt gar nicht nachgemessen.
Ah! Ja, in der Tabelle hast du auf der linken Seite die STECKERBELEGUNG
des Klinkensteckers. Auf der rechten Seite dann eben das was anliegt.
Hallo zusammen,
anbei mein Code für das NetIo. Basis ist der URadig-Webserver. In der
usart.c ist die Empfangsroutine drin und in der telnet.c das versenden.
Ist quick and dirty drin, könnte man natürlich viel schöner machen.
Das Telegramm wird als ASCII im Hex-Format versendet, damit das
Auswerten mittels Telnet schön einfach war.
Aus den cpp-Dateien sollte ersichtlich sein, wie ich das auswerte. Ein
kompletter Quelltext des Programms nutzt leider nicht viel, weil man
dazu das Framework eines bestimmten Automatisierungssystems braucht.
Mein Empfangsplatine ist der erste Entwurf von Rudi, allerdings mit
LM393.
Da musste ich dann mittels Spannungsteiler die Eingangssignale auf <5V
bringen, da sie für die korrekte Funktion des LM393 kleiner als die
Versorgungsspannung des IC's sein müssen. Data und 12V hatte ich
getauscht, damit ich ein invertirtes Signal vom Komparator bekommen habe
welches ich dann auf die RS232 des NetIO gegeben habe.
Matthias
Weil wir gerade beim Posten von Code sind, hier mal noch meine Lösung.
Die Empfangshardware entspricht weitestgehend der von Ingo geposteten
EMSlog.gif (hab noch ein paar zusätzliche LEDs). Die Daten werden von
einem auf einem Plug-Computer laufenden Daemon (C++ + Boost, siehe
Anhang) übernommen und in eine MySQL-DB geschrieben.
Die Telegramm-Auswertung in meinem Daemon sollte das Wissen dieses
Threads komplett wiederspiegeln - wenn jemand noch etwas fehlendes
sieht, bitte Bescheid sagen ;-)
Danny Baumann schrieb:> Die Empfangshardware entspricht weitestgehend der von Ingo geposteten> EMSlog.gif (hab noch ein paar zusätzliche LEDs).
Hallo Danny,
liest sich sehr interessant, Dein Projekt.
Gibt's denn zu der Verschaltung des ATmega 8 und der Eingangsstufe auch
eine Schaltplanskizze?
Noch ne Frage: "Den PlugPC hast Du als 'reinen EMS-PC' in Deinem HWR und
fragst über LAN die Daten ab?"
Vielen Dank für Deine Arbeit!
Gruß aus der Wetterau
Karl M.
Hi,
> liest sich sehr interessant, Dein Projekt.>> Gibt's denn zu der Verschaltung des ATmega 8 und der Eingangsstufe auch> eine Schaltplanskizze?
Hab ich jetzt nicht sofort zur Hand, ich kann aber nochmal kramen.
Meine Schaltung ist aber - wie gesagt - praktisch die selbe wie die
EMSlog.gif hier im Thread.
> Noch ne Frage: "Den PlugPC hast Du als 'reinen EMS-PC' in Deinem HWR und> fragst über LAN die Daten ab?"
Nein. Der Plug-PC ist mein 'Home-Server', d.h. unter anderem auch File-,
Print- und Musik-(Squeezebox-)Server. Den EMS-Daemon und die MySQL-DB
frühstückt der nebenbei mit ab ;-) Der Apache, mit dem ich mit etwas
gehacktem PHP die Daten anzeige, läuft da auch drauf.
Der Plug-PC ist ja hardwaremäßig auch recht gut ausgestattet:
http://de.wikipedia.org/wiki/SheevaPlug ... und das bei ~4W
Stromverbrauch.
Hallo,
versuche schon einige Zeit die Induktivitäten L3/L4 auf zu finden. Es
wurde ja schon mal vermutet dass es 4700µH sind. Allerdings sind die
größten induktivitäten die ich finden konnte nur 1000µF. Jetzt habe ich
irgendwo eine Induktivität gefunden die mit 472K in der Bezeichnung
trägt und 47µ bei 1kHz hat.
Hier noch mal der Link zum Bild:
Beitrag "Re: Logamatic 2107 Schnittstelle"
Was habt Ihr denn für die Spule L3/L4 genommen?
Gruß
Ingo
Hallo Ingo,
Du musst nach "4,7 mH" und nicht nach "4700 uH" suchen:
http://www.segor.de/#Q=4,7mH-09P Festinduktivität 4,7mH
+/-5% 130mA 11,5R RM5
http://www.segor.de/#Q=4,7mH-SD75 Festinduktivität 4,7mH
+/-10% 70mA 48R RM5
oder bei Conrad Best.-Nr.: 535508 - 62 bzw 501596 - 62
http://www.conrad.de/ce/de/product/535508/DROSSEL-47-MH/SHOP_AREA_17429&promotionareaSearchDetail=005http://www.conrad.de/ce/de/product/501596/HF-DROSSEL-LBC-4700-UH-5/5418133&ref=list
Die 4,7mH-SD75 hatte ich zufällig noch daheim und auch eingebaut, wobei
nach den Daten sollte man wohl die 4,7mH-09P bevorzugen (kleinerer
Widerstand, höherer Strom).
Beim Anschliessen eines 7805 nach dem Brückengleichrichter (ohne
Kondensator am Eingang) und einem nachgeschalteten Class 1 BTM-222
Bluetooth Moduls hat mein Multimeter Spannungen bis 200 V hinter dem
Brückengleichrichter angezeigt. Ich warte jetzt auf meinen Step-Down
Converter aus Hongkong und hoffe, dass der keine solche Stromspitzen
erzeugt.
Senden habe ich noch nicht probiert und beim Empfangen spielen die
Induktivitäten keine große Rolle.
Michael
Hallo Danny,
> ich kann aber nochmal kramen
schon gekramt? Falls ich Deinen Quelltext im framer richtig
interpretiere, ist Deine Belegung anders als in der EMS-log.gif?
Beim compilieren des collectors hatte ich zunächst eine fehlende
"common.h". Da ich vermutete, dass es sich hierbei um die common.h aus
"mysql++" handelt, habe ich dorthin gelinkt. Jetzt ergibt ein "make all"
folgenden Fehlertext:
Message.cpp: In member function ‘virtual void StatsMessage::parse()’:
Message.cpp:481: error: ‘rx_stats_t’ was not declared in this scope
Message.cpp:481: error: expected ‘;’ before ‘stats’
Message.cpp:487: error: ‘stats’ was not declared in this scope
make: *** [Message.o] Fehler 1
Meine config hier:
VirtualBox-4.1.6 mit Debian-6.02, Kernel 2.6.32 mit installiertem
libboost, mysql, libmysql++ und build-essential.
Irgendeine Idee, was ich hier falsch mache?
Danke im Voraus und Grüße aus der Wetterau
Karl M.
charlie schrieb:> Hallo Danny,>>> ich kann aber nochmal kramen>> schon gekramt?
Nein, noch nicht. Ich versuche heute abend mal dran zu denken.
> Falls ich Deinen Quelltext im framer richtig> interpretiere, ist Deine Belegung anders als in der EMS-log.gif?
Das könnte sein ... evtl. hab ich die Belegung so angepasst, dass die
Verdrahtung einfacher ist.
> Beim compilieren des collectors hatte ich zunächst eine fehlende> "common.h". Da ich vermutete, dass es sich hierbei um die common.h aus> "mysql++" handelt, habe ich dorthin gelinkt. Jetzt ergibt ein "make all"> folgenden Fehlertext:>> Message.cpp: In member function ‘virtual void StatsMessage::parse()’:> Message.cpp:481: error: ‘rx_stats_t’ was not declared in this scope> Message.cpp:481: error: expected ‘;’ before ‘stats’> Message.cpp:487: error: ‘stats’ was not declared in this scope> make: *** [Message.o] Fehler 1
common.h ist in framer/ - siehe collector/Makefile, Zeile 2.
Danny
Danny Baumann schrieb:> common.h ist in framer/ - siehe collector/Makefile, Zeile 2.
jetzt wo Du es sagst :-*) - Läuft einwandfrei durch, tolle Arbeit!
Über den Schaltplan würd' ich mich freuen :-)
Vielen Dank für Deine Geduld!
Gruß
Karl M.
Michael Dreher schrieb:> Du musst nach "4,7 mH"
Habe ich natürlich auch. Aber alles was ich finde ging nur bis 1mH. Die
Bauteile habe ich auch gefunden. Suche allerdings die SMD-Versionen.
Die Suche bei Conrad ist sowieso absolut unbrauchbar. Man kann nicht
nach einem Wert suchen, sondern nur alle SMD-Induktivitäten durchsuchen.
Dummerweise steht dann überall in der Überschrift 1-1000µH.
Bei anderen Herstellen habe ich auch keine SMD-Versionen gefunden. Oder
die liefern nur an Gewerbliche Kunden und nicht an Endabnehmer.
vielleicht nehme ich dann doch die Nicht-SMD-Induktivitäten.
Rudi schrieb:> warum benutzt du nicht einfach Ferritbeads? Die sollten die Störungen> auch ausreichend unterdrücken.
Muss gestehen dass ich von Entstörung nicht soviel Ahnung habe. Habe
auch keine Messtechnik um dabei Unterschiede selber zu sehen. Wenn
Buderus ja so eine Schaltung hat würde ich die schon gerne klauen ;o)
Bei der RC 30 sind ja erst kleiner Induktivitäten und dann die großen.
Dazwischen ist eine Durchkontaktierung und kann selbst beim
durchleuchten eine Leiterbahn erkennen.
Vermute mal dass dazwischen der Abriff für die Sende/Empfangsschaltung
ist und hinter den Spulen nur der Abgriff für die
Spannungs/Stromversorgung ist und die Induktivitäten den
"Einschaltstrom" der Bufferkondensatoren vom 78L05 begrenzen sollen.
Gruß
Ingo
Ingo F. schrieb:> Vermute mal dass dazwischen der Abriff für die Sende/Empfangsschaltung> ist und hinter den Spulen nur der Abgriff für die> Spannungs/Stromversorgung ist und die Induktivitäten den> "Einschaltstrom" der Bufferkondensatoren vom 78L05 begrenzen sollen.
Okay, beim Einschaltstrom macht es natürlich Sinn. Kann das mal jemand
für die originale Schaltung berechnen? :-). Was brauchst du denn genau
(was hast du gefunden) in SMD?
Grüße.
Hi Ingo,
als ich die Schaltung seinerzeit reverseingeneered habe, hatte ich
Probleme die Induktivität zu identifizieren. Du hast ja auch schon
gemerkt, dass es hierzu im Netz widersprüchlich Angaben gibt. Ich hatte
mir die Teile aber von einem defekten Modul ausgelötet und deshalb war
der Leidensdruck für eine Recherche bis zum Letzten nicht groß genug.
Das habe ich jetzt nachgeholt und mein jetziger Wissensstand ist
folgender:
472 -> 4700µH -> 4,7mH
472K -> 4700nH -> 4,7µH
Die Induktivitäten dürften somit nur 4,7µH haben. Der mit einem
Multimeter gemessen DC-Widerstand von 0.5 Ohm passt dann auch eher.
So ... ich geh' dann mal, mir etwas Asche aufs Haupt streuen.
//Niffko
PS: An deine Theorie "Einschaltstrom, Kondensator, 78L05" glaube ich
nicht so recht. Die Buderus Module haben alle ein separates Netzteil -
sind also nicht buspowered - und haben trotzdem auch eine kleine und
eine große Induktivität.
Niffko _ schrieb:> Die Induktivitäten dürften somit nur 4,7µH haben. Der mit einem> Multimeter gemessen DC-Widerstand von 0.5 Ohm passt dann auch eher.Niffko _ schrieb:> Die Induktivitäten dürften somit nur 4,7µH haben.
Na das beruhigt mich ja schon mal... Und deswegen kann ich seit einem
Monat nicht schlafen :oD
Niffko _ schrieb:> PS: An deine Theorie "Einschaltstrom, Kondensator, 78L05" glaube ich> nicht so recht. Die Buderus Module haben alle ein separates Netzteil -> sind also nicht buspowered - und haben trotzdem auch eine kleine und> eine große Induktivität.
Habe leider keine Buderus Module. konnte nur von der RC30 ausgehen die
ich an der Wand hängen hatte. War nur eine Vermutung warum es zwischen
den Spulen einen Abgriff gibt....
Rudi schrieb:> Was brauchst du denn genau> (was hast du gefunden) in SMD?
Hatte diese hier gefunden.... Allerdings steht nur in der Titelzeile
4,7mH. In der Beschreibung steht auch nur 4,7µH...
Also habe ich dann doch keine gefunden...
Gruß
Ingo
Hallo,
Ingo F. schrieb:> Hatte diese hier gefunden.... Allerdings steht nur in der Titelzeile> 4,7mH. In der Beschreibung steht auch nur 4,7µH...>> Also habe ich dann doch keine gefunden...
Wie sieht es mit der
LB2012T4R7M => 0805, 4.7µH, 190mA, 0,10€
CB2012T4R7M => 0805, 4.7µH, 580mA, 0,15€
aus?
Grüße.
Hallo zusammen,
hat schonmal jemand versucht einer Logamatic 4xxx Daten zu entlocken?
Kennt jemand die Pinbelegung der 15-pol. HD-Sub-D-Buchse (sieht aus wie
eine VGA-Buchse)? Kann ich davon ausgehen, dass das Protokoll ähnlich
ist wie bei der RC30/35? Immerhin passt hier ja auch der Service Key
über einen beiliegenden HD-Sub-D-Klinken-Adapter.
Falls das so ist, will ich mir einen möglichst einfachen Pegelwandler
bauen. Ich denke das müsste auch ohne Komparator gehen. Ich würde
einfach einen PNP-Transistor nehmen, dessen Basis an die Datenleitung
hängen, den Emitter über einen 1k Widerstand an 12V und den Collector
über einen 3.3k Widerstand an Masse. Der Ausgang für die RS232
Schnittstelle wäre dann der Collector. Wenn auf der Datenleitung
12V+/-2V anliegen, sollten so am Ausgang ca. 5V oder 0V anliegen, was
auch für die RS232 Schnittstelle in Empfangsrichtung ausreichen sollte.
Evtl. muss man noch einen Inverter vorsehen, falls die Polarität nicht
stimmt. Kann das wirklich so einfach gehen, oder mache ich einen
Denkfehler?
Gruß
Sebastian
Niffko, danke für die Info. Was ich bisher verstanden habe ist, dass es
zwei unterschiedliche Protokolle gibt: EMS und ECO-CAN. Intern spricht
die Logamatic 4xxx wohl ECO-CAN, aber die Verbindung zur Fernbedienung
BFU läuft über EMS. Möglicherweise gibt es eine Art eingebauten Umsetzer
zw. EMS und ECO-CAN. Dann könnte u.U. auch der Service Key EMS sprechen.
Ich habe eine BFU in Betrieb. Könnte ich über die Verbindung zur BFU an
alle Daten kommen, oder ist zu erwarten, dass nur für den Heizkreis
relevante Daten übertragen werden, dem die BFU zugeordnet ist?
Gruß
Sebastian
Morus schrieb:> ... Logamatic 4xxx ... die Verbindung zur Fernbedienung> BFU läuft über EMS.
Das ist sehr unwahrscheinlich, da es die 4000er schon gab, als an EMS
noch nicht zu denken war.
Die Schnittstelle ECO-CAN / EMS wird über Funktionsmodule realisiert,
mit denen man, je nach verwendetem Modul, bis zu zwei oder bis zu 4
EMS-Kessel kaskadieren kann. Die kleinen Wandschaltkästen wie z.B.
Logamatic 41XX, besitzen eine interne Schnittstellenkarte für eine
Einzelkesselsteuerung, die übrigens auch mit Pre-EMS-Wandkesseln
(UBA1.5) kommuniziert.
//Niffko
Niffko _ schrieb:> Das ist sehr unwahrscheinlich, da es die 4000er schon gab, als an EMS> noch nicht zu denken war.
Ok, dann hab ich da was falsch verstanden. Physikalisch scheint das
Protokoll zur BFU aber ähnlich zu EMS zu sein, d.h. 12V+-2V.
Gruß
Morus
Ein Hallo an alle Experten,
ich habe die ganzen Informationen aufmerksam durchgelesen und dabei sehr
viel erfahren. Ich habe eine LogamaxPlus GB142 mit den Basiscontroller
RC10 und der RC30 mit Außentemperatursteuerung. Habe jetzt eine
Solaranlage mit Pufferspeicher einbauen lassen und möchte anstelle der
RC30 eine UVR1611 Regelung verwenden.
Was mir fehlt ist die PIN Belegung des 81 pin Konnektor in der GB142
Kann mir jemand schreiben wo ich die PIN Belegung herbekomme?
Sollte ich hier im Forum nicht richtig sein, bitte ich um Nachsicht.
Viele Grüße
JoSt
Moin,
na was wird gesendet? Zeig doch mal.
Grüße.
Morus schrieb:> Niffko _ schrieb:>> Das ist sehr unwahrscheinlich, da es die 4000er schon gab, als an EMS>> noch nicht zu denken war.>> Ok, dann hab ich da was falsch verstanden. Physikalisch scheint das> Protokoll zur BFU aber ähnlich zu EMS zu sein, d.h. 12V+-2V.>> Gruß> Morus
Jo Stetter schrieb:> ... anstelle der RC30 eine UVR1611 Regelung verwenden.> Was mir fehlt ist die PIN Belegung des 81 pin Konnektor in der GB142 ...
Welche Anschlussmöglichkeiten gedenkst du denn am 81 pin Konnektor zu
finden?
Dass dort sämtliche Sensoren und die Niederspannungsperipherie - wie
z.B. die Gasarmatur - angeschlossen und das Ganze somit
sicherheitsrelevant ist, weißt du ja sicherlich schon!?
Das Hauptproblem wird werden, den Brenner der GB142 mit der UVR
modulierend zu betreiben. Hierfür ist ist zwingend erforderlich, dem
Feuerungsautomaten (UBA3) per EMS-Bus einen entsprechenden Sollwert zu
übermitteln.
//Niffko
Guten morgen,
ich hab jetzt einiges aus diesem riesen Thread gelesen, bin aber noch
nicht so richtig schlau. Welche Schaltung ist denn 'die Beste' für die
Verbindung der Service-Key Schnittstelle mit einem Controller bzw.
Pegelwandler auf RS232?
Gruss
Norbert
Hallo Norbert.
ich würde mal sagen diese hier:
Beitrag "Re: Logamatic 2107 Schnittstelle"
die ist aus einer Schaltung von Buderus und habe ich in meinem
EMS-Gateway auch übernommen...
Gruß
IngoF
Ingo F. schrieb:> Hallo Norbert.>> ich würde mal sagen diese hier:> Beitrag "Re: Logamatic 2107 Schnittstelle">> die ist aus einer Schaltung von Buderus und habe ich in meinem> EMS-Gateway auch übernommen...
Allerdings sind auch Rudi's Kommentare dazu zu beachten:
Beitrag "Re: Logamatic 2107 Schnittstelle"
Die Originalschaltung scheint bei mir nicht so gut zu funktionieren
(Tastverhältnis zwischen Bus-Signal und Komparator-Ausgang verschiebt
sich stark) - zeigt sich bei mir darin, dass ich viele CRC-Fehler sehe.
Mit Rudi's Änderung sieht das Tastverhältnis deutlich besser aus, ich
hab's allerdings noch nicht am Bus getestet.
Danny Baumann schrieb:> (Tastverhältnis zwischen Bus-Signal und Komparator-Ausgang verschiebt> sich stark) - zeigt sich bei mir darin, dass ich viele CRC-Fehler sehe.
Das Tastverhältnis sollte sich dahingehend ändern, dass der Low-Pegel
etwas verspätet durchkommt - das unterdrückt Störsignale die deutlich
unterhalb einer Bitlänge liegen. Zu Datenfehlern sollte das aber nicht
führen. Ist evtl. mit deinen Kondensatoren (1nF/10µF) etwas nicht in
Ordnung - für den 10µ einen ungepolten Typ verwendet?
//Niffko
> Danny Baumann schrieb:>> (Tastverhältnis zwischen Bus-Signal und Komparator-Ausgang verschiebt>> sich stark) - zeigt sich bei mir darin, dass ich viele CRC-Fehler sehe.>> Das Tastverhältnis sollte sich dahingehend ändern, dass der Low-Pegel> etwas verspätet durchkommt - das unterdrückt Störsignale die deutlich> unterhalb einer Bitlänge liegen. Zu Datenfehlern sollte das aber nicht> führen. Ist evtl. mit deinen Kondensatoren (1nF/10µF) etwas nicht in> Ordnung - für den 10µ einen ungepolten Typ verwendet?
Ja, ist ein ungepolter Typ, und ja, das Tastverhältnis ändert sich
dahingehend, dass bei einem 50%-Rechteck am Eingang High so um die 70%
bekommt. Mit Rudi's Änderung sind's 60%.
Ich hab das allerdings auch noch nicht zu Ende debuggt (hab die Platine
erst gestern bekommen) und nur gesehen, was mir meine LEDs anzeigen.
Wenn mein Code komplett fertig ist, sag ich nochmal Bescheid ;)
War denn die Signalform mit der Originalschaltung o.k.? Rudi hatte ja
seinerzeit die Änderung vorgenommen, weil er nur Spikes am
Komparatorausgang hatte.
//Niffko
Niffko _ schrieb:> War denn die Signalform mit der Originalschaltung o.k.? Rudi hatte ja> seinerzeit die Änderung vorgenommen, weil er nur Spikes am> Komparatorausgang hatte.
Ja, Signalform war sauberes Rechteck.
Ich werd's jetzt mit der umgebauten Schaltung testen; sobald ich sehe,
dass ich sinnvolle Werte einlese (die CRC-Fehler können schließlich auch
in meinem Code entstehen), bau ich die Schaltung wieder zurück und
probier nochmal.
Danny Baumann schrieb:> Ich werd's jetzt mit der umgebauten Schaltung testen; sobald ich sehe,> dass ich sinnvolle Werte einlese (die CRC-Fehler können schließlich auch> in meinem Code entstehen), bau ich die Schaltung wieder zurück und> probier nochmal.
Ok, ich hab's jetzt mal mit einer normalen (PC-)UART getestet - der Code
ist einwandfrei. Das Signal am Komparator sieht auch exakt so aus, wie
man es erwarten würde (Dauer für die 2 Pollbytes 2.1ms, erst ein
Datenbyte, dann Low-Pegel). Da mein Board (Pollin NetIO) ohne
EMS-Zusatzplatine (oder mit Zusatzplatine, aber ohne angeschlossenen
EMS) einwandfrei funktioniert und sich sofort nach dem Anschließen
komisch verhält (z.B. massive Paketverluste am Ethernet), liegt ein
Masseproblem o.Ä. nahe.
Meine Schaltung ist die von Niffko gepostete Buderus-Schaltung. +5V und
GND kommen vom Pollin-Board, RX und TX gehen vom Komparator an die
USART1 des Atmega644p.
Hat einer von euch eine Idee, was da elektrisch schief laufen könnte?
Wie habt ihr die Massetrennung gelöst? Ethernet-Masse und
Gleichspannungsmasse habe ich auf dem NetIO schon mit 1nF getrennt (sind
normalerweise zusammengeklemmt), hat aber leider nix gebracht.
Danke,
Danny
Danny Baumann schrieb:> Meine Schaltung ist die von Niffko gepostete Buderus-Schaltung. +5V und> GND kommen vom Pollin-Board, RX und TX gehen vom Komparator an die> USART1 des Atmega644p.> Hat einer von euch eine Idee, was da elektrisch schief laufen könnte?> Wie habt ihr die Massetrennung gelöst? Ethernet-Masse und> Gleichspannungsmasse habe ich auf dem NetIO schon mit 1nF getrennt (sind> normalerweise zusammengeklemmt), hat aber leider nix gebracht.
Tja, da gab es mit einer anderen Netzwerklösung und einer anderen
Heizung auch schon Probleme, in diesem Thread. Der Mantel vom Netzwerk
sollte mit einem C oder erstmal garnicht verbunden werden. Die
restlichen Leitungen gehen "normal" an einen Übertrager, dann an den FEC
und erst dann an den uC. Der Übertrager und FEC sollten den uC
ausreichend vom Netz trennen.
Wer weiß welche Macken das Board so hat, vom 644 und Netzwerk mal ganz
abgesehen, wobei es auch nur die Schmerzgrenze vom Benutzer zeigt ;-).
Grüße.
Rudi schrieb:> Tja, da gab es mit einer anderen Netzwerklösung und einer anderen> Heizung auch schon Probleme, in diesem Thread. Der Mantel vom Netzwerk> sollte mit einem C oder erstmal garnicht verbunden werden. Die> restlichen Leitungen gehen "normal" an einen Übertrager, dann an den FEC> und erst dann an den uC. Der Übertrager und FEC sollten den uC> ausreichend vom Netz trennen.
Die Ethernet-Schirmung ist ja, wie schon geschrieben, mit 1nF von der
Masse getrennt.
Ich habe allerdings in der Zwischenzeit festgestellt, dass meine
Hypothese "Masseproblem" wirklich nur eine Hypothese war: Ein
Softwarebug hat dafür gesorgt, dass der Frame Error nicht erkannt wurde,
was einen weiteren Bug getriggert hat (Buffer Overrun), der das komische
Verhalten verursacht hat ;)
Ich hab jetzt noch ein paar CRC-Fehler drin, da muss ich aber erst mal
schauen, ob das eventuell auch nur Softwareprobleme sind.
Eine Frage noch zum Polling: Muss ich, wenn ich 0x0b als Antwort
gesendet habe, vor dem Senden des Break auf ein Echo des gesendeten
Bytes warten oder nicht? Die Aussagen im Thread sind da etwas
widersprüchlich...im Moment warte ich nicht, sehe aber Adresse 11 nicht
in der Busstatus-Ausgabe.
> Wer weiß welche Macken das Board so hat, vom 644 und Netzwerk mal ganz> abgesehen, wobei es auch nur die Schmerzgrenze vom Benutzer zeigt ;-).
Pfft :-P
Ich weigere mich, das Senden von ein paar UART-Bytes in einen TCP-Socket
mit einem ARM zu erschlagen ;-) Ethersex als AVR-Firmware ist wirklich
empfehlenswert für solche Zwecke.
Danny Baumann schrieb:> Muss ich, wenn ich 0x0b als Antwort> gesendet habe, vor dem Senden des Break auf ein Echo des gesendeten> Bytes warten oder nicht? Die Aussagen im Thread sind da etwas> widersprüchlich...
Also generell funktioniert das senden von den anderen Busteilnehmern
(außer die 0x08) immer gleich. Jedes Byte wird mit dem schwachen
Signalpegel gesendet und dann vom Busmaster (0x08) generell wiederholt.
Man musss also immer auf das Echo warten. Denke nicht dass man es
auswerten/kontrollieren muss. Das erledigt ja die Prüfsumme der
EMS-Telegramme.
Soweit ich mich erinnere sendet der Empfänger auf direkt an ihn
adressierte Telegramme auch noch eine positive oder negative
Bestätigung.
Danny Baumann schrieb:> im Moment warte ich nicht, sehe aber Adresse 11 nicht> in der Busstatus-Ausgabe.
Denke das wird das Problem sein.
Allerdings erscheint bei mir nicht sofort der "PC" mit der Adresse 11 im
Display, sondern erst nach der dritten Antwort auf das Polling (etwa
1Minute)
Bei erscheinen der 11 in der RC30 kommt dann das Polling auch mehrmals
in der Sekunde für die 0xb (11).
Gruß
Ingo
Ingo F. schrieb:> [Bus-Echo] Denke nicht dass man es auswerten/kontrollieren muss.
Ich lege in meiner "Bitmanufaktur" (Soft-Uart) zwischen jedem gesendeten
Zeichen - also auch vor dem Break - eine Pause von 30 Bitlängen (3 Byte)
ein, funktioniert prächtig.
//Niffko
Ingo F. schrieb:> Denke das wird das Problem sein.> Allerdings erscheint bei mir nicht sofort der "PC" mit der Adresse 11 im> Display, sondern erst nach der dritten Antwort auf das Polling (etwa> 1Minute)> Bei erscheinen der 11 in der RC30 kommt dann das Polling auch mehrmals> in der Sekunde für die 0xb (11).
Es sieht bei mir so aus, als ob der MC10 meine Antwort mitbekommen hat
(Polling ist mindestens 1x pro Sekunde), die RC30 allerdings nicht. Ich
werde mal das Echo abwarten und dann mal sehen.
Ich gehe mal davon aus, dass ich während des Sendens mein eigenes Echo
auch auf der RX-Leitung sehen werde, d.h. während TX muss ich RX
abschalten, richtig?
Der MC10 wiederholt auch das gesendete Break, d.h. das muss ich auch
abwarten, richtig?
Danke.
Danny Baumann schrieb:> Es sieht bei mir so aus, als ob der MC10 meine Antwort mitbekommen hat> (Polling ist mindestens 1x pro Sekunde)...
Ist das Polling denn vorher noch langsamer? 1x pro Sekunde ist
eigentlich inaktives Polling, aktives Polling hat kürzere Intervalle.
Das bezieht sich auf die EMS-Module. Könnte beim Service-Key anders sein
- glaube ich aber nicht.
> Ich gehe mal davon aus, dass ich während des Sendens mein eigenes Echo> auch auf der RX-Leitung sehen werde, d.h. während TX muss ich RX> abschalten, richtig?
Wenn du die von mir gepostete Schaltung verwendest, dürfte dein eigenes
TX den Komparator eigentlich nicht triggern. Wie das nach deiner
Modifikation der Schaltung aussieht, weiß ich nicht.
Sende doch einfach mal was und schau mit einem Oszi auf den
Komparatorausgang.
//Niffko
Niffko _ schrieb:> Danny Baumann schrieb:>> Es sieht bei mir so aus, als ob der MC10 meine Antwort mitbekommen hat>> (Polling ist mindestens 1x pro Sekunde)...>> Ist das Polling denn vorher noch langsamer? 1x pro Sekunde ist> eigentlich inaktives Polling, aktives Polling hat kürzere Intervalle.> Das bezieht sich auf die EMS-Module. Könnte beim Service-Key anders sein> - glaube ich aber nicht.
Ok, dann war das ein Missverständnis meinerseits und der MC10 hat's auch
nicht mitbekommen.
>> Ich gehe mal davon aus, dass ich während des Sendens mein eigenes Echo>> auch auf der RX-Leitung sehen werde, d.h. während TX muss ich RX>> abschalten, richtig?>> Wenn du die von mir gepostete Schaltung verwendest, dürfte dein eigenes> TX den Komparator eigentlich nicht triggern. Wie das nach deiner> Modifikation der Schaltung aussieht, weiß ich nicht.> Sende doch einfach mal was und schau mit einem Oszi auf den> Komparatorausgang.
Ich hab die Schaltung - nachdem ich jetzt weiß, dass es nicht daran lag
- wieder auf deine 'Original'-Variante zurückgebaut. Mit dem Oszi tue
ich mich dahingehend schwer, dass ich keinen sinnvollen Punkt zum
Triggern habe, weil auf dem Bus ja ständig was los ist.
Mal sehen, vielleicht geht's ja jetzt, wo ich den Code zum Warten
eingebaut habe, ja einfach - ansonsten melde ich mich nochmal ;-)
Danke für's Feedback auf alle Fälle schonmal.
Danny Baumann schrieb:> Muss ich, wenn ich 0x0b als Antwort> gesendet habe, vor dem Senden des Break auf ein Echo des gesendeten> Bytes warten oder nicht?
Du musst warten, da es sonst zu Kollisionen kommt. Wenn der Bus vom
Master getrieben wird (Echo), geht dein Sendestrom im rauschen unter.
Grüße.
Danny Baumann schrieb:> Mal sehen, vielleicht geht's ja jetzt, wo ich den Code zum Warten> eingebaut habe ...
Bad News ... es geht auch ohne Pausen - zumindest bei mir.
Habe mich erinnert, dass wir das Thema "warten oder nicht warten" schon
mal hatten. Ich hatte damals die Nicht-Warten-Fraktion gebildet, aber
dann doch mit Fortschreiten meines Projektes sicherheitshalber eine
Pause eingebaut. Interessehalber habe ich jetzt mal in meinem Code die
Pausen herausgenommen ... und es funktioniert weiterhin alles wie
gehabt. Wie es aussieht, scheint die Stromschnittstelle des Masters
unabhängig vom Buspegel zu funktionieren - eine mögliche Erklärung:
Beitrag "Re: Logamatic 2107 Schnittstelle"
Ich werde das mal eine Weile so bei mir laufen lassen.
//Niffko
Hallo Niffko,
Niffko _ schrieb:> Ich werde das mal eine Weile so bei mir laufen lassen.
Berichte dann mal von Deinen Ergebnissen...
Beim Polling dürfte das vermutlich nicht so ein Problem sein. Weil man
ja im Break sendet und dadurch das Sendesignal nicht unbedingt
verfälscht wird.
Aber Bei längeren Telegrammen dürfte das schon eher problematisch
werden. Mag ja auch sein dass eine Weile lang läuft und dann irgendwann
mal Probleme gibt und man dann nicht mehr dran denkt dass man die Pausen
rausgenommen hat.
Vielleicht ändert sich ja mal die Buslänge, es gibt eine neue Regelung,
neue Software, neue Busteilnehmer, anderes Timing ... Die Temperatur
oder Bauteilalterung/-toleranzen können ja auch irgendwann mal
zuschlagen...
Wenn es ja im Moment läuft muss es nicht heissen dass es immer läuft
Drei Byte Bause wäre vielleicht auch etwas zu lang. Aber 1Byte und ein
oder zwei Bits Aufschlag sollte schon reichen.
Aber es dürfte ja kein Problem geben die Pause einzubauen. Oder ist Dein
Controller so stark an der Auslastung dass da keine Zeit mehr für ist?
Gruß
Ingo
Sooo, jetzt geht's auch bei mir :-)
Ich habe
- die Schaltung wieder auf Niffko's Variante umgebaut
- Warten auf Echo eingebaut
- ganz wichtig: das Erzeugen des Breaks gefixt ;-) Ich hatte das Break
im UDRE-Interrupt getriggert, wodurch es im letzten gesendeten Byte
unterging und nur einen sehr kurzen Spike erzeugt hat. Jetzt triggere
ich es im TXC-Interrupt, was offensichtlich (und logischerweise) besser
funktioniert.
Wenn's jemand interessiert: Mein Ethersex-Fork mit EMS-Support ist hier:
https://github.com/maniac103/ethersex
Vielen Dank nochmal an Niffko, Rudi und Ingo F. für den Input.
Mirko Rüther schrieb:> kurze Frage: wo unterscheiden sich die Schaltungen von IngoF> (http://www.mikrocontroller.net/attachment/97902/EMS.gif)>> und die von niffko> (http://www.mikrocontroller.net/attachment/95287/EMS_Interface.png)?
Ingo's Schaltung ist vom genauen Spannungspegel auf dem EMS abhängig,
Niffko's Schaltung nicht. Von der µC-Seite sollten beide identisch sein.
> Würde mir gerne eine nachbauen und mit dem Code von Danny Baumann auf> einem Pollin Net I/0 betreiben.
Du musst allerdings beachten, dass du, um meinen Code 1:1 verwenden zu
können, einen Atmega644p brauchst (wegen der 2. UART). Das Ganze lässt
sich auch auf USART0 umbauen (von der Softwareseite sogar recht
einfach), allerdings ist beim Pollin-Board ja der MAX232 im Weg...
Danny Baumann schrieb:>> kurze Frage: wo unterscheiden sich die Schaltungen von IngoF>> (http://www.mikrocontroller.net/attachment/97902/EMS.gif)> Ingo's Schaltung ist vom genauen Spannungspegel auf dem EMS abhängig,> Niffko's Schaltung nicht. Von der µC-Seite sollten beide identisch sein.
Also Meine Schaltung hatte ich selbst entwickelt. Niffko hat dann die
Schaltung von Buderus herausbekommen.
Bei meiner Schaltung habe ich auch feststellen müssen dass sie beim
Senden das Empfangsignal beinflusst. Das hat sich aber nicht in Fehlern
bemerkbar gemacht.
Ich habe jetzt auf meinem EMS-Gateway auch die Niffko/Buderus-Schaltung
genommen. Kann das auch nur empfehlen. Habe das Senden aber bisher noch
nicht mit der neuen Schaltung testen können. Denke damit wird es aber
nicht diese Probleme geben
Gruß
Ingo
Hi,
ich habe Niffko's Schaltung aufgebaut, mit Optokopplern galvanisch
getrennt, dann auf 3,3V Pegel runter und auf einen FTDI UART USB Chip.
Das funktioniert irgendwie nicht, auch nicht das Terminalprogramm
einfach mitlaufen lassen, da kommt nichts raus und die Eco-Soft
verbindet sich auch nicht.
Habe ich bei der ganzen Sache noch irgendwas übersehen?
Gruss
Norbert
Norbert Schnitzler schrieb:> Das funktioniert irgendwie nicht, auch nicht das Terminalprogramm> einfach mitlaufen lassen, da kommt nichts raus und die Eco-Soft> verbindet sich auch nicht.
Liegt wohl irgendwie am Wetter. Für die ECO-Soft brauchst du einen
Dongle.
Grüße.
Hallo Norbert,
Die Schaltung ist eigentlich nur ein "Pegelwandler" mit USB-Anschluss.
Wenn alles richtig aufgebaut ist sollten massenhaft Daten rauskommen
wenn man ein Terminalprogramm anschließt.
Fehlerquellen gibt es genug...
Die schaltung selber kann nicht funktionieren...
Die Optokoppler könnten die Probleme sein....
Der USB-Chip könnte natürlich auch irgendwelche Probleme haben.
Den FTDI-Chip (FT245RL) kann man die Ausgänge mit der FTDI-Software
programmieren dass die Ausgänge einen höhren Strom liefern um z.B.
Optokoppler mit Strom zu versorgen..
Da hilft wohl nur einen Schaltungsteil nach dem anderen zu prüfen...
Das die Eco-Soft nicht funktioniert ist kein Wunder. Erstens bekommst Du
noch niemals auf dem Terminalprogramm Daten. Und zweitens benötigt die
EcoSoft noch zusätzlich einen "Protokollkonverter" Weil die Daten zur
EcoSoft anders übertragen werden.
Desweiteren gibt es noch Probleme das auf dem Bus jedes Telegramm mit
einem Break beendet wird. Der PC ist zu langsam um dieses Break
auszuwerten. Dazu müsste er jedes Zeichen einzeln empfangen können und
ist dazu einfach zu langsam.
Dann gibt es noch das Problem dass Du zwar alle möglichen Daten auf dem
PC mit dem Terminalprogramm empfangen kannst, aber das Break nur als
normale "0" übertragen wirde. Der FT245RL hat keine Möglichkeit das
Break zu senden oder zu empfangen. Denke der FT232 wird da das selbe
Problem haben.
Gruß
Ingo
Hallo,
Herbert schrieb:> Ist zwar etwas aus dem Zusammenhang gehört aber in diesen Thread:> Die Schnitstelle der Logamatic 2107 mit der Fernbedienung BFU:> http://wiki.neo-soft.org/index.php/Heizungsschnittstelle/BFU
danke für die Info. Ein paar Bilder wären nicht schlecht, falls du
darauf einen Einfluss hast ;-).
Grüße.
Rudi schrieb:> Hallo,>> Herbert schrieb:>> Ist zwar etwas aus dem Zusammenhang gehört aber in diesen Thread:>> Die Schnitstelle der Logamatic 2107 mit der Fernbedienung BFU:>> http://wiki.neo-soft.org/index.php/Heizungsschnittstelle/BFU>> danke für die Info. Ein paar Bilder wären nicht schlecht, falls du> darauf einen Einfluss hast ;-).>> Grüße.
Ich frag mal ganz blöd: Welche Bilder meinst Du ?
Hallo Ingo,
danke für die ausführliche Antwort,
welches ist denn, deiner Meinung nach, die beste Möglichkeit auf die
aktuellen Daten und evtl. auf Historiendaten per Heizung zuzugreifen.
Dazu wurde hier zwar einiges geschrieben, aber leider ist es ja etwas
unübersichtlich.
Gruss
Norbert
Hallo Norbert,
das Problem ist dass ein PC nicht jedes Zeichen einzeln annimmt. Die
Bytes werden in einen Zwischenbuffer abgelegt und dann wenn der PC mal
Zeit hat der Buffer geleert.
Das Break löst einen Frame-Error aus. Der PC kann also nur sehen dass
irgend ein Zeichen von den ganzen Zeichen das Break war. Kann aber nicht
feststellen welches Zeichen es war.
Es muss also ein Mikrocontroller sein der die Daten annimmt und die
Daten zum PC schickt. Wenn noch geschrieben werden soll muss auch das
Polling am Bus beantwortet werden.
Keine Ahnung ob es mit einem Linux-PC klappen könnte. Aber vermutlich
sind PCs generell dafür zu langsam.
Gruß
Ingo
Hallo Ingo,
meine Frage war in die Richtung gemünzt, ob hier einer der vielen
Autoren eine 'einfache' Hardwarelösung genutzt hat, bei der der Code
zugänglich ist, so dass man diese nur nachbauen muss und direkt ein
funktionierendes System hat, ohne selber alles zu entwickeln. Ich würde
mich zwar gerne tiefer in die Materie einarbeiten, aber mir geht es im
Moment nur darum, möglichst schnell ans Ziel zu kommen und Zugriff auf
die Daten zu bekommen.
Gruss
Norbert
Norbert Schnitzler schrieb:> Autoren eine 'einfache' Hardwarelösung genutzt hat
Na gut dann habe ich zumindest schon mal aufgeklärt ;o)
Fragt sich nur wie "Einfach" Du meinst. Denke die Schaltung ohne
Microcontroller nehmen wird wohl nicht aus den genannten Gründen gehen.
Niffko hat ja den kompletten Schaltplan schon gepostet. Also mit µC
nachbauen und dann sollte es laufen. Oder hast Du die Schaltung mit µC
nachgebaut und ich hatte das nicht so ganz verstanden.
Einfach mal Niffko fragen ob er seinen Quelltext oder das HEX-File
rausrückt.
Meinen Schaltplan hatte ich ja schon gepostet
( Beitrag "Re: Buderus EMS-"Gateway" mit PIC18F / Sammelbestellung" ) Aber der wird
Dir dann wohl zu komplex sein. Könnte man aber bis auf den FTDI-Chip auf
mit nicht-SMD Bauteilen nachbauen.
Das HEX-File kannst Du natürlich gerne bekommen...
Gruß
Ingo
Hallo Ingo,
bis jetzt hatte ich nur die Sende-/Empfangsstufe nachgebaut, ich schau
morgen mal auf der Arbeit, ob ich da einen passenden Pic finde, dann
wäre es ja kurz und schmerzlos auszubauen. Platinen hast du keine mehr
oder? Wie/In welchem Format schiebst du die Daten zur seriellen
Schnittstelle raus? welches Display kann man Anschließen (4x20Zeichen)?
Gruss
Norbert
Norbert Schnitzler schrieb:> ob ich da einen passenden Pic finde
Also wenn dann muss es schon der 18F4580 oder 4480 sein falls Du mein
Hex File benutzen möchtest.
Der FT245RL muss natürlich auch genauso angeschlossen werden und die
Analoge-Mode-Auswahl mit dem Dipschalter.
Und natürlich Die Sende-/Empfangsstufe, die ja noch nicht so ganz
funktioniert.
Das Display ist im Moment noch absolut egal. Habe im Moment ein 4X20
angeschlossen. Aber im Moment wird es noch nicht benutzt. Sind nur ein
paar Ausgaben zum testen für die Kommunikation mit dem USB-Chip.
Ausgabe ist in zwei Versionen verfügbar:
Hex:
0xAA 0x55 <EMS-Telegramm> 0x00 <Telegrammlänge> 0xAA 0x55
oder als Text das Telegramm in HEX mit Leerzeichen zum trennen und
<CR&LF> am Telegrammende.
Polling wird nicht übertragen. Soll aber zum debuggen bald möglich sein.
Gruß
Ingo
Wenn's nicht unbedingt ein PIC sein muss, habe ich weiter oben schon mal
einen Link zu meinem Code für den Atmega644p auch dem
Pollin-Net-IO-Board gepostet...
Nabend!
Werde in Kürze mal den Code für eine Read-Only-Minimalversion
posten - muss ihn noch ein wenig aufräumen und noch mal testen ;)
Hardware siehe: Beitrag "Re: Logamatic 2107 Schnittstelle"
//Niffko
Guten morgen,
Also ich habe einen Atmega 32 hier und PIC18F4620, würde dein Hex direkt
auf diesen PIC passen oder kann man den in MPLAB schnell passend
kompilieren, Ingo?
Wenn nicht würde ich umkompilieren mit dem Atmel versuchen.
Gruss
Norbert
Norbert Schnitzler schrieb:> Guten morgen,>> Also ich habe einen Atmega 32 hier und PIC18F4620, würde dein Hex direkt> auf diesen PIC passen oder kann man den in MPLAB schnell passend> kompilieren, Ingo?> Wenn nicht würde ich umkompilieren mit dem Atmel versuchen.>> Gruss> Norbert
Hallo Norbert,
also generell kann ich das nicht garantieren.
Sieht aber ganz gut aus.
Du musst allerdings alles so sbeschalten wie in meinem Schaltplan
angegeben.
Der CAN-Eingang (RB2) muss dann z.B. mit 10KOhm auf irgendeinen Pegel
gelegt werden.
Beim Mikrocontroller muss LVP in den Bits deaktiviert werden oder der
Pin (RB5??) muss auch mit 10kohm auf Low gezogen werden (nicht getestet,
bei mir deaktiviert)
Wichtig ist die analoge beschaltung beim Einschalten und reset. Etwa 0V
= AN1310 Bootloader >0V <0,2 Volt RAW-Daten mit 0xaa 0x55 >0,2V HEX als
Text mit CR&LF
Und es muss der FT245 sein. Der Ft232 funktioniert nicht mit meinem
HEX-File
(zweiter UART notwendig)
Kann allerdings nicht versprechen das es noch funktioniert wenn ich den
CAN-interupt bei späteren Versionen aktiviere. Vermutlich sollte das
aber gehen.
Das HEX-File kann ich aber vermutlich erst morgen posten.
Gruß
Ingo
IngoF schrieb:> Das HEX-File kann ich aber vermutlich erst morgen posten.
Hab es leider nicht schneller geschafft..
LED2 leuchtet wenn der PC über USB verbunden ist.
LED1 leuchtet wenn der Buffer des FT245 voll ist und sollte also bei
angeschlossenem PC nicht wirklich oft lange leuchten.
Im Bereich bis 0x3ff ist der modifizierte AN1310-Bootloader Ab 0x400 ist
da eigentliche Programm.
Bisher ist nur das weiterleiten vom EMS-Bus zum PC möglich.
Das Polling auf dem EMS-Bus wird nicht beantwortet.
Gruß
Ingo
Nabend!
Anhängend Schaltplan und Hex-File für einen EMS-Reader.
Funktion:
Das Bussignal wird über AC-Kopplung auf den internen Komparator eines
ATtiny2313 gegeben. Das Komparatorsignal triggert einen
interruptgesteuerten Soft-UART mit 100 Byte FIFO. Die Ausgabe läuft über
den Hard-UART des Tiny. Schnittstellenperipherie dann je nach Gusto als
FT232, MAX232, Optokoppler etc..
Optionen:
-Ausgabe ASCII Hex + <CR+LF>
-Ausgabe Raw ( Format: <AA><55><Frame-Länge><Frame-Data> )
-Ausgabe mit Polling
-Ausgabe ohne Polling
//Niffko
Mal eine Frage an die 'Sendenden': Reagiert die RC3x bei euch
zuverlässig auf Anfragen? Ich versuche im Moment den Fehlerspeicher
auszulesen und sende folgendes:
0x0b 0x90 0x12 0x00 0x0c <crc> (lese 1. Eintrag mit 12 Bytes)
... warte auf Antwort, die kommt in 100% der Fälle ...
0x0b 0x90 0x12 0x0c 0x0c <crc> (lese 2. Eintrag)
... die kommt eigentlich auch immer ...
0x0b 0x90 0x12 0x18 0x0c <crc> (lese 3. Eintrag)
... ab hier wird's unzuverlässig, oft bekomme ich da keine Antwort
0x0b 0x90 0x12 0x24 0x0c <crc> (lese 4. Eintrag)
... dito ...
Seht ihr so was bei euch auch (hieße für mich: Retry einbauen) oder eher
nicht (da müsste ich noch mal in meinen Ethersex-Code schauen)? Kann
einer von euch mal versuchen, das zu reproduzieren?
Danke.
Hi Danny,
eine Frage vorne weg: Lässt du zwischen den aufeinander folgenden
Abfragen Pausen oder prüfst du ob der RC3X geliefert hat?
Ich habe deine Abfrage mal in mein Anwendung hinein gehackt. Aus
Aufwandsgründen allerdings nur mit Pausen zwischen den Einzelabfragen.
Dein Problem konnte ich nachvollziehen. Kurz gesagt - es ist ein
Zeitproblem. Es sieht so aus, als wenn der RC3X, 4 kurz aufeinander
folgende Abfragen á 12 Byte nicht so schnell gebacken kriegt. Was 100%
immer funktioniert hat waren 2 Abfragen á 24 Byte - die müsstest du dann
halt noch auseinander pflücken. Andere Alternative: Jeden 12 Byte Block
auf eine neue Polling-Anfrage verteilen.
//Niffko
> eine Frage vorne weg: Lässt du zwischen den aufeinander folgenden> Abfragen Pausen oder prüfst du ob der RC3X geliefert hat?
Letzteres. Ich schicke jeweils eine Abfrage los und warte auf Antwort.
Mein Ethersex-Code macht die TCP-Verbindung eh so lange dicht, bis er
die Abfrage abgesetzt hat.
> Ich habe deine Abfrage mal in mein Anwendung hinein gehackt. Aus> Aufwandsgründen allerdings nur mit Pausen zwischen den Einzelabfragen.> Dein Problem konnte ich nachvollziehen. Kurz gesagt - es ist ein> Zeitproblem. Es sieht so aus, als wenn der RC3X, 4 kurz aufeinander> folgende Abfragen á 12 Byte nicht so schnell gebacken kriegt. Was 100%> immer funktioniert hat waren 2 Abfragen á 24 Byte - die müsstest du dann> halt noch auseinander pflücken. Andere Alternative: Jeden 12 Byte Block> auf eine neue Polling-Anfrage verteilen.
Das (1 Abfrage pro Polling) hatte ich halt schon getan. Final will ich
auch nur 2 Abfragen abschicken (schon aus Performance-Gründen, da ja
ordentlich Latenz reinkommt, da ich ja jedesmal erst mal auf's Polling
warten muss), allerdings will ich das Problem erst mal verstehen -
schließlich könnte es ja sein, dass meine Anfrage (aus welchen Gründen
auch immer) verlorengegangen ist. Wenn das aber normal wäre, dass der
RC3x (in meinem Fall: RC30) manchmal Aussetzer hat, müsste ich mir ja
keine größeren Sorgen machen. Allerdings frag ich mich grad, ob es dann
nicht besser wäre, alle Anfragen/Kommandos an 0x90/0x88 zu senden,
damit man wenigstens eine Rückmeldung hat, ob die Anfrage angekommen
ist.
Der interne Puffer der RC3x scheint ohnehin klein zu sein, wenn ich
'0x0b 0x90 0x12 0x00 0xff' sende, bekomme ich auch nur 25 oder 26 Byte
Nutzdaten zurück.
Danny Baumann schrieb:> Ich schicke jeweils eine Abfrage los und warte auf Antwort.
Um bei ausbleibender Antwort eine Hängepartie zu vermeiden, müsstest du
ja dann auch einen Timeout eingebaut haben - hast du? Nur mal so als
Hausnummer - ich musste die Pause zwischen der Einzelabfrage(12 Byte,
letzter Block) und dem abschließenden <0B> auf 200ms setzen um
zuverlässig eine Antwort zu bekommen. Wobei (bei mir) aber auch schon
ca. 20ms vergangen sind, bis der Master die Anfrage vollständig auf den
Bus geechot hat.
Danny Baumann schrieb:> ... schließlich könnte es ja sein, dass meine Anfrage (aus welchen Gründen> auch immer) verlorengegangen ist.
Glaube ich nicht. Ich hatte beim Testen zum Senden und Empfangen jeweils
separate Hardware und dürfte somit sicher alle Telegramme mitgeschnitten
haben. Das Anfragetelegramm wurde immer korrekt wiedergegeben, es kam
aber trotzdem sporadisch keine Antwort vom RC35.
Danny Baumann schrieb:> ... alle Anfragen/Kommandos an 0x90/0x88 zu senden,> damit man wenigstens eine Rückmeldung hat, ob die Anfrage angekommen> ist.
öhmm ... hier kann ich dir irgendwie nicht ganz folgen.
//Niffko
Niffko _ schrieb:> Danny Baumann schrieb:>> Ich schicke jeweils eine Abfrage los und warte auf Antwort.>> Um bei ausbleibender Antwort eine Hängepartie zu vermeiden, müsstest du> ja dann auch einen Timeout eingebaut haben - hast du? Nur mal so als
Nein, noch nicht, kann ich aber einfach tun.
> Hausnummer - ich musste die Pause zwischen der Einzelabfrage(12 Byte,> letzter Block) und dem abschließenden <0B> auf 200ms setzen um> zuverlässig eine Antwort zu bekommen. Wobei (bei mir) aber auch schon> ca. 20ms vergangen sind, bis der Master die Anfrage vollständig auf den> Bus geechot hat.
Das heißt, du schließt jedes Senden mit einem leeren Telegramm ab? Ich
hatte (hier im Thread) gelesen, dass dss nicht nötig sei.
>> Danny Baumann schrieb:>> ... schließlich könnte es ja sein, dass meine Anfrage (aus welchen Gründen>> auch immer) verlorengegangen ist.>> Glaube ich nicht. Ich hatte beim Testen zum Senden und Empfangen jeweils> separate Hardware und dürfte somit sicher alle Telegramme mitgeschnitten> haben. Das Anfragetelegramm wurde immer korrekt wiedergegeben, es kam> aber trotzdem sporadisch keine Antwort vom RC35.>
Ok, das beruhigt mich...das heißt also, dass das Verhalten, das ich
sehe, 'normal' ist.
> Danny Baumann schrieb:>> ... alle Anfragen/Kommandos an 0x90/0x88 zu senden,>> damit man wenigstens eine Rückmeldung hat, ob die Anfrage angekommen>> ist.>> öhmm ... hier kann ich dir irgendwie nicht ganz folgen.
Wenn man auf die Empfänger-Adresse 0x80 drauf-odert (d.h. 0x08 -> 0x88
und 0x10 -> 0x90) gibt man ja an, dass man eine Antwort erwartet. Wenn
man die bekommt, kann man sich sicher sein, dass das Kommando angekommen
(und verstanden) ist.
>>>>> //Niffko
Nabend,
ich habe mal ein frage zum EMS-collector. Habe die Quellen auf einem
std. Debian 6 mit den boost & mysql libs übersetzt
root@debian6:~/ems-collector/collector# make
g++ -Wall -c -O2 -I/usr/include/mysql -I../framer -MM main.cpp
SerialHandler.cpp Message.cpp Da
tabase.cpp Options.cpp PidFile.cpp > .depend
g++ -Wall -c -O2 -I/usr/include/mysql -I../framer main.cpp
g++ -Wall -c -O2 -I/usr/include/mysql -I../framer SerialHandler.cpp
g++ -Wall -c -O2 -I/usr/include/mysql -I../framer Message.cpp
g++ -Wall -c -O2 -I/usr/include/mysql -I../framer Database.cpp
g++ -Wall -c -O2 -I/usr/include/mysql -I../framer Options.cpp
g++ -Wall -c -O2 -I/usr/include/mysql -I../framer PidFile.cpp
g++ -lpthread -lboost_system -lboost_thread-mt -lboost_program_options
-lmysqlpp -o collectord
main.o SerialHandler.o Message.o Database.o Options.o PidFile.o
Wenn ich das ganze starte bekomme ich auch keine Fehlermeldung und die
DB ems_data wird auch schön angelegt.
./collectord -u root -p passwd -d all=/tmp/ems.log /dev/ttyUSB0
Die Datenbank füllt sich nur leider nicht. Im Logfile finden sich auch
nur die Daten vom SERIAL(port).
...
SERIAL: Got bytes 00 0x77 00 0x17 0xaa 0x55
SERIAL: Got bytes 0xaa 0x55 0x8 00 0x18 00 0x2b 0x1 0xb1 0x64 00 0x1 0x1
0x20 0x60 0x80 00 0x2 0x7 0x1 0xb1 00 00 0xf 0x30 0x59 00 0xcc 00 00 00
0x6f 00 0x1f 0xaa 0x55
SERIAL: Got bytes 0xaa 0x55 0x10 0x21 0xac 00 0x1d 0x64 0x3 0xa5 00 0x9
0xaa 0x55
...
Wie kann ich hier weiter debuggen woran könnte es scheitern?
Zweite Frage wir kann ich eine Binary erstellen die alle Libs direkt
enthält? Auf meinem Server läuft noch Debian Lenny und da will die boost
lib nicht :-(
Danke!
Kay F. schrieb:> SERIAL: Got bytes 00 0x77 00 0x17 0xaa 0x55> SERIAL: Got bytes 0xaa 0x55 0x8 00 0x18 00 0x2b 0x1 0xb1 0x64 00 0x1 0x1> 0x20 0x60 0x80 00 0x2 0x7 0x1 0xb1 00 00 0xf 0x30 0x59 00 0xcc 00 00 00> 0x6f 00 0x1f 0xaa 0x55> SERIAL: Got bytes 0xaa 0x55 0x10 0x21 0xac 00 0x1d 0x64 0x3 0xa5 00 0x9> 0xaa 0x55
Alles zwischen 0xaa 0x55 und <len> 0xaa 0x55 sind die Heizungsdaten. Die
"<len>" bezieht sich auf die EMS-Daten, also sind es insgesamt LEN+5
Bytes.
>> Wie kann ich hier weiter debuggen woran könnte es scheitern?> Zweite Frage wir kann ich eine Binary erstellen die alle Libs direkt> enthält? Auf meinem Server läuft noch Debian Lenny und da will die boost> lib nicht :-(
Versuch mal den Schalter -static für den gcc/g++. Mit ldd <appl> kannst
du sehen welche Lib noch dynamisch gelinkt ist.
Grüße.
Danny Baumann schrieb:> Das heißt, du schließt jedes Senden mit einem leeren Telegramm ab?
Ja klar ... genau wie alle anderen Busteilnehmer auch. Damit
signalisiert man dem Master: "habe fertig!".
> Ich hatte (hier im Thread) gelesen, dass dss nicht nötig sei.
Naja ... der Timeout wird's schon richten.
Danny Baumann schrieb:> Allerdings frag ich mich grad, ob es dann> nicht besser wäre, alle Anfragen/Kommandos an 0x90/0x88 zu senden,Danny Baumann schrieb:> Wenn man auf die Empfänger-Adresse 0x80 drauf-odert (d.h. 0x08 -> 0x88> und 0x10 -> 0x90) gibt man ja an, dass man eine Antwort erwartet.
Ja, das ist klar. Ich weiß nur nicht, wo du hier eine Wahlmöglichkeit
siehst. Wenn man von einem Teilnehmer Daten haben möchte, kommt die 0x80
mit drauf. Handelt es sich um eine Anweisung/Parametrierung, dann nicht.
Im letzten Fall bekommt man übrigens auch Rückmeldung, nämlich 0x01 für
"ok" und 0x04 für "Fehler".
//Niffko
Hi,
> Die Datenbank füllt sich nur leider nicht. Im Logfile finden sich auch> nur die Daten vom SERIAL(port).>> ...> SERIAL: Got bytes 00 0x77 00 0x17 0xaa 0x55> SERIAL: Got bytes 0xaa 0x55 0x8 00 0x18 00 0x2b 0x1 0xb1 0x64 00 0x1 0x1> 0x20 0x60 0x80 00 0x2 0x7 0x1 0xb1 00 00 0xf 0x30 0x59 00 0xcc 00 00 00> 0x6f 00 0x1f 0xaa 0x55> SERIAL: Got bytes 0xaa 0x55 0x10 0x21 0xac 00 0x1d 0x64 0x3 0xa5 00 0x9> 0xaa 0x55> ...>> Wie kann ich hier weiter debuggen woran könnte es scheitern?
Das Format sieht aber nicht nach meinem Atmega-Code aus. Es sieht aus
wie
0xaa 0x55 <ems data> <ems checksum> 0xaa 0x55
Der Collector erwartet aber
0xaa 0x55 <frametype> <length> <ems data> <running xor checksum>
Siehe das Unterverzeichnis framer/. Du kannst jetzt entweder deinen µC
entsprechend umstellen (wenn's ein Atmega ist, hab ich den Code ja
mitgeliefert) oder SerialHandler.cpp umbauen. Out-of-the-Box geht das so
nicht.
>> Das heißt, du schließt jedes Senden mit einem leeren Telegramm ab?>> Ja klar ... genau wie alle anderen Busteilnehmer auch. Damit> signalisiert man dem Master: "habe fertig!".>>> Ich hatte (hier im Thread) gelesen, dass dss nicht nötig sei.>> Naja ... der Timeout wird's schon richten.
Ok, dann jetzt mal Butter bei die Fische, um das mal aufzulösen :)
Wenn ich nix zu senden habe, passiert ja das hier:
<0x8b><brk>
<0x0b><brk>
(letzteres kommt von mir)
Wenn ich etwas zu sagen habe, muss also folgendes passieren?
<0x8b><brk>
<0x0b><data_1>...<data_n><brk>
<0x0b><brk>
Wenn dem so ist, bekomme ich dann auch ein Echo für das Break, d.h. kann
ich auf ein empfangenes Byte 0x00 warten?
>> Allerdings frag ich mich grad, ob es dann>> nicht besser wäre, alle Anfragen/Kommandos an 0x90/0x88 zu senden,>>> Wenn man auf die Empfänger-Adresse 0x80 drauf-odert (d.h. 0x08 -> 0x88>> und 0x10 -> 0x90) gibt man ja an, dass man eine Antwort erwartet.>> Ja, das ist klar. Ich weiß nur nicht, wo du hier eine Wahlmöglichkeit> siehst. Wenn man von einem Teilnehmer Daten haben möchte, kommt die 0x80> mit drauf. Handelt es sich um eine Anweisung/Parametrierung, dann nicht.> Im letzten Fall bekommt man übrigens auch Rückmeldung, nämlich 0x01 für> "ok" und 0x04 für "Fehler".
Das ist interessant, genau diese Rückmeldung scheine ich nicht zu
bekommen. Ich sende z.B. zum Ändern des Warmwasser-Modus (aus/an/auto)
0x0b 0x10 0x37 0x02 0x02 <crc> <brk>
Ich sollte also eine Antwort bekommen, die so aussieht?
0x10 0x0b 0x1 <crc> <brk>
Genau das scheint nicht zu passieren. Der Modus wird aber korrekt
geändert, das sehe ich ja an der RC30. Wenn ich die 0x10 in der Anfrage
durch 0x90 ersetze, bekomme ich eine Antwort, die sich allerdings
scheinbar eher auf die gesetzten Daten bezieht, als dass sie 0x1/0x4
zurückliefern würde.
Hallo,
danke für die Antworten. Jetzt verstehe ich das Konstrukt ein wenig
besser. Ich nutze das EMS-Gateway von Ingo (PIC), somit kann ich den
Framer nicht verwenden. Wenn es okay ist, würde ich den Quelltext von
Danny mißbrauchen und umbauen. Wenn ich das gerade auf die schnelle
richtig gesehen habe, sind die Formate ja nicht so unterschiedlich:
0xaa 0x55 <ems data> <length> 0xaa 0x55
0xaa 0x55 <frametype> <length> <ems data> <running xor checksum>
<frametype> ist immer 0 (FRAME_TYPE_DATA) da der PIC keine Statistik
hat.
Also muss ich nur die SerialHandler::readComplete(..) verstehen und
anpassen.....
Gruß Kay
> danke für die Antworten. Jetzt verstehe ich das Konstrukt ein wenig> besser. Ich nutze das EMS-Gateway von Ingo (PIC), somit kann ich den> Framer nicht verwenden. Wenn es okay ist, würde ich den Quelltext von> Danny mißbrauchen und umbauen. Wenn ich das gerade auf die schnelle
Das ist ok, ist ja Open Source - vergiss nur nicht, deine Änderungen
wieder zur Verfügung zu stellen ;)
> richtig gesehen habe, sind die Formate ja nicht so unterschiedlich:>> 0xaa 0x55 <ems data> <length> 0xaa 0x55
Ja, wobei Ingo die EMS-Prüfsumme über RS232 weiterreicht, was ich nicht
tue (ich prüfe die im Atmel). Das Break scheint auch enthalten zu sein,
d.h. das Format wäre
0xaa 0x55 <ems data> <ems checksum> <0x00=brk> <length between markers>
0xaa 0x55
> 0xaa 0x55 <frametype> <length> <ems data> <running xor checksum>>> <frametype> ist immer 0 (FRAME_TYPE_DATA) da der PIC keine Statistik> hat.
Hmm? Frametype gibt's nur in meinem Format, was hat das mit dem PIC zu
tun?
> Also muss ich nur die SerialHandler::readComplete(..) verstehen und> anpassen.....
Richtig, sollte aber nicht übermäßig schwierig sein :)
>> Ok, dann jetzt mal Butter bei die Fische ...>> Aber gerne ...
Danke :)
> Abfrage:>
1
> RX: <0x8b> <brk>
2
> TX: <0x0b> <0x88> <content> <crc> <brk>
3
> RX: <0x08> <0x0b> <content> <crc> <brk>
4
> TX: <0x0b> <brk>
5
>
Ok, verstehe. Das sollte sich ja recht leicht einbauen lassen.
> Anweisung:>
1
> RX: <0x8b> <brk>
2
> TX: <0x0b> <0x08> <content> <crc> <brk>
3
> RX: <0x01> <brk>
4
> TX: <0x0b> <brk>
5
>
>>> Ich schätze mal, die 0x01 versackt bei dir im Polling - oder?
In der Tat. Alle Nachrichten mit nur 1 Byte sehe ich als Polling an.
Sieht so aus, als ob ich 0x01 und 0x04 speziell behandeln muss. Vom
Protokoll her sieht das aber echt bekloppt aus - wenn man eine
Status-Antwort gibt, warum schickt man die dann nicht an den Absender
der Anweisung? seufz
Naja, jammern nützt nix, ändern können wir es eh nicht, also muss ich
das wohl einbauen ;)
Danke aber auf alle Fälle für die Infos. Weißt du, ob das Break vom MC10
'geechot' wird?
Danny Baumann schrieb:> Weißt du, ob das Break vom MC10 'geechot' wird?
Überleg' mal ... alle Telegramme die du auf dem Bus siehst, sind - mit
Ausnahme derer vom Master selbst - alles Echos. Und alle haben ein
Break ... also?! ;)
//Niffko
Niffko _ schrieb:> Danny Baumann schrieb:>> Weißt du, ob das Break vom MC10 'geechot' wird?>> Überleg' mal ... alle Telegramme die du auf dem Bus siehst, sind - mit> Ausnahme derer vom Master selbst - alles Echos. Und alle haben ein> Break ... also?! ;)
Hast ja recht, da hätte man mit etwas nachdenken drauf kommen können :)
Ich werd jetzt mal meinen Atmel-Code umbauen...
Nabend ;)
Ich habe jetzt noch mal den ganzen Thread durchgesehen, aber nix
gefunden. Habt ihr mittlerweile herausgefunden wie sich die
Außentemperatur im Minusbereich berechnen lässt?
Gruß
Jens
> Ich habe jetzt noch mal den ganzen Thread durchgesehen, aber nix> gefunden. Habt ihr mittlerweile herausgefunden wie sich die> Außentemperatur im Minusbereich berechnen lässt?
Ja klar ;)
Direkt aus meinem Code (von hier:
Beitrag "Re: Logamatic 2107 Schnittstelle" -
Message.cpp):
1
/* treat values with highest bit set as negative
2
* e.g. size = 2, value = 0xfffe -> real value -2
3
*/
4
if (m_buffer[offset] & 0x80) {
5
value = value - (1 << (size * 8));
6
}
D.h.: gelesen 0xffdd -> Wert = 0xffdd - (1 << 16) = 0xffdd - 0x10000 =
65501 - 65536 = -35
Wenn ich mich recht entsinne, ist die Außentemperatur als 16-bit-Wert
mit einer Nachkommastelle gespeichert, d.h. im Beispielfall wären das
-3.5°C.
Jens H. schrieb:> ... Außentemperatur im Minusbereich berechnen ...
Das ist ein ganz normaler signed Integer16. Ich stopfe meine
empfangenen Bytes z.B. alle per Byte-Pointer in die entsprechenden
Variablen.
Pseudocode:
1
uint8_t*pointer;
2
int16_touttemp;// 1/10 °C
3
4
pointer=(uint8_t*)&outtemp;
5
*pointer++=emsOuttempLow;
6
*pointer=emsOuttempHigh;
Und wie Danny schon richtig bemerkte, wird die reale Außentemperatur
in 1/10°C ausgegeben. Bei der gedämpften AT sind es hingegen ganze
°C in 8 Bit.
// Niffko
Ok, danke für den Hinweis zu den Minustemperaturen, aber was is denn die
"normale" und was die "gedämpfte" Außentemp? Das geht scheinbar ein
wenig unter .. zumindest in den Listen die ich hier im Thread gefunden
habe.
Auf diverse Codeschnipsle hatte ich jetzt nicht so geachtet, da ich vor
habe das mit PHP zu lösen.
Gruß
Jens
Jens H. schrieb:> Ok, danke für den Hinweis zu den Minustemperaturen, aber was is denn die> "normale" und was die "gedämpfte" Außentemp? Das geht scheinbar ein> wenig unter .. zumindest in den Listen die ich hier im Thread gefunden> habe.
Die gedämpfte AT wird zur Regelung benutzt und durch mehrere Parameter
berechnet (AT/Gebäudeart etc.).
Grüße.
Die gedämpfte AT vollzieht Änderungen der realen AT mit einer gewissen
zeitlichen Verzögerung nach. Hiermit soll die thermische Trägheit des
Baukörpers berücksichtigt werden. Die Intensität der Dämfung ist
abhängig von der eingestellten Gebäudeart. Im Gegensatz zum RC30 ist die
Dämpfung mit dem RC35 auch komplett abschaltbar. Wie Rudi schon schrieb,
wird mit der gedämpften AT über die Heizkennlinie die
Vorlaufsolltemperatur berechnet. Für die So/Wi-Umschaltung ist sie
übrigens auch verantwortlich.
//Niffko
Hallo,
ich habe irgendwie Probleme den Quellcode von Danny zuverstehen, was an
meiner fehlenden Erfahrung im Bereich c++ liegen kann ;-)
Ich habe versucht die SerialHandler::readComplete() Funktion anzupassen,
was ich eigentlich als nicht so schwierig erachtet habe. Im Debug Mode
erkennt man das die Funktion mit dem richtig erkannten Anfang & Ende
aufgerufen wird:
SERIAL: Got bytes 0xaa 0x55 0x8 00 0x34 00 0x32 0x1 0xfd 0x1 0xfd 0x21
00 0x5 0x3 00 00 0x8b 0xef 00 0x8 0xfc 00 0xe 00 0x17 0xaa 0x55
Die EMS Daten stehen ja in m_recvBuffer die ich jetzt von 2 bis
(bytesTransferred -3) in DataMessage kopieren muss und gut ist.
Irgenwie haut das aber nicht hin und ich bekomme segvaults und andere
unschöne sachen :-(
Ich habe die Funktion mal angehängt. Ist das mit den einfachen nullen so
okay, oder was paßt nicht?
Danke und Gruß
Kay
Hi,
> ich habe irgendwie Probleme den Quellcode von Danny zuverstehen, was an> meiner fehlenden Erfahrung im Bereich c++ liegen kann ;-)> Ich habe versucht die SerialHandler::readComplete() Funktion anzupassen,> was ich eigentlich als nicht so schwierig erachtet habe. Im Debug Mode> erkennt man das die Funktion mit dem richtig erkannten Anfang & Ende> aufgerufen wird:> SERIAL: Got bytes 0xaa 0x55 0x8 00 0x34 00 0x32 0x1 0xfd 0x1 0xfd 0x21> 00 0x5 0x3 00 00 0x8b 0xef 00 0x8 0xfc 00 0xe 00 0x17 0xaa 0x55
Das ist nicht 'richtig erkannt', dass ist Glück, dass mit 1x lesen genau
ein Paket zurückkam. Es hätte auch sein können, dass 2 Pakete mit einem
mal gelesen werden, oder dass ein Paket in 2 Teilen ankommt. Aus diesem
Grund hatte ich ja die State Machine gebaut, die jedes Byte einzeln
anschaut...
> Die EMS Daten stehen ja in m_recvBuffer die ich jetzt von 2 bis> (bytesTransferred -3) in DataMessage kopieren muss und gut ist.> Irgenwie haut das aber nicht hin und ich bekomme segvaults und andere> unschöne sachen :-(>> Ich habe die Funktion mal angehängt. Ist das mit den einfachen nullen so> okay, oder was paßt nicht?
Bei mir kommt <Start-Marker> <Länge> <Daten>, bei Ingo <Start-Marker>
<Daten> <Länge> <End-Marker>. m_recvBuffer[2] ist bei dir also nicht die
Länge, sondern das erste Nutzbyte. Du allokierst also 8 Byte in der
Message und füllst dann 23 oder 24 Bytes rein ... nicht gut. Es hätte
funktioniert (d.h. wäre nicht gecrasht), wenn die Nachricht vom Mischer
gekommen wäre ;)
Du musst also etwas umbauen (Nachricht in std::vector<uint8_t> in
SerialHandler aufsammeln und komplett an Message übergeben, anstatt
addByte und isFull zu benutzen); oder alternativ Ingo überzeugen, das
Streaming-Format sinnvoll zu gestalten ;)
Danny Baumann schrieb:> Du musst also etwas umbauen (Nachricht in std::vector<uint8_t> in> SerialHandler aufsammeln und komplett an Message übergeben, anstatt> addByte und isFull zu benutzen); oder alternativ Ingo überzeugen, das> Streaming-Format sinnvoll zu gestalten ;)
Ich hatte das damals aus Speichermangel (bei Fehlern max. 256 Bytes),
wegen der Geschwindigkeit und Raw-Daten so festgelegt (mega8). Das
genaue EMS-Format war zu der Zeit noch etwas schleierhaft und es war
einfacher den Puffer, Parser und die Fehlerauswertung auf dem PC zu
schreiben als auf dem uC.
Egal wie man es macht, man muss immer auf die kompletten Daten warten
und dann die Länge + CRC checken, da das Pattern auch in den Daten
vorhanden sein kann. Bei der "nicht so" eleganten Methode braucht der uC
keinen Zwischenspeicher ;-).
Grüße.
>> Du musst also etwas umbauen (Nachricht in std::vector<uint8_t> in>> SerialHandler aufsammeln und komplett an Message übergeben, anstatt>> addByte und isFull zu benutzen); oder alternativ Ingo überzeugen, das>> Streaming-Format sinnvoll zu gestalten ;)>> Ich hatte das damals aus Speichermangel (bei Fehlern max. 256 Bytes),> wegen der Geschwindigkeit und Raw-Daten so festgelegt (mega8). Das> genaue EMS-Format war zu der Zeit noch etwas schleierhaft und es war> einfacher den Puffer, Parser und die Fehlerauswertung auf dem PC zu> schreiben als auf dem uC.
Ist ja richtig, aber deswegen muss man das heute doch nicht mehr so
machen :)
> Egal wie man es macht, man muss immer auf die kompletten Daten warten> und dann die Länge + CRC checken, da das Pattern auch in den Daten> vorhanden sein kann. Bei der "nicht so" eleganten Methode braucht der uC> keinen Zwischenspeicher ;-).
Korrekt. Nach allem, was wir inzwischen wissen, reicht aber ein Atmega8
für 2,15€ bei Reichelt für Zwischenspeicherung +
EMS-Checksummen-Überprüfung dicke aus ;)
Ich wollte ja auch nicht sagen, dass das alles komplett daneben ist,
sondern nur, dass Ingo's (bzw. dein) Framing-Format nicht 1:1 zu meinem
Daemon passt, weil ich das Format so gewählt habe, dass es leicht zu
parsen ist.
Mir ist natürlich klar, dass ihr jetzt nicht ohne Not das Format bei
euch ändert, weil es - wenn man einmal eine lauffähige Lösung hat - im
Prinzip sinnlose Arbeit ist...
Danny Baumann schrieb:> Mir ist natürlich klar, dass ihr jetzt nicht ohne Not das Format bei> euch ändert, weil es - wenn man einmal eine lauffähige Lösung hat - im> Prinzip sinnlose Arbeit ist...
Hallo,
hatte auch schon mal vorgehabt das Format etwas zu ändern. Wollte es
eigentlich um zwei Byte kürzen die eigentlich Sinnlos sind. Das wären
das letzte 0-Byte wo inzwischen klar ist dass es nicht zu den Daten
gehört sondern nur ein Break ist. Und dann das Längenbyte am Ende.
Werden bei mir eigentlich auch ignoriert.
Die Telegramme haben ja eine Prüfsumme. Wenn die Prüfsumme nicht stimmt
ist das Telegramm falsch oder unvollständig und nutzlos.
Aber irgendwie macht es ja nicht wirklich Sinn noch mein PC-Programm zu
ändern. Außerdem könnte es ja theoretisch passieren das die Zeichen AA
55 hintereinander in den Daten stecken und dann als Fehlerhaftes
Trennzeichen verstanden werden.
Dann macht es schon mehr Sinn die Daten Hexadezimal(text) mit CR/LF am
Ende zu senden oder eben das 3964R-Protokoll.
Aber habe bisher noch kein einziges mal diese AA 55 in den Daten
gesehen. Außerdem habe ich noch genug andere baustellen.
Schön dass sich hier mal wieder ewas mehr tut...
Gruß
Ingo
Nabend,
ich wollte erstmal versuchen einzelne Telegramme zuempfangen bevor ich
die CRC & Länge auswerte. Aber daran scheitere ich gerade. Die
Telegramme die ich bisher gesehen habe wurden immer sauber m_recvBuffer
erkannt. Kann sein das es an Ingo's PIC SW liegt ;-)
Werde mich da mal weiter reinfuchsen und versuchen C++ zulernen ;-)
Ist nicht einfach sich in "fremden" Quelltext einzulesen wenn man die
Sprache nicht kenn und alles erst googeln muss..
Da ich in Zukunft gerne auch einfache Sachen ändern wollen würde, fände
ich es gut wenn wir uns auf ein (Sende-)Format einigen könnten...
Wenn ich die Diskussion hier richtig verstanden habe, sind die
Nachrichtenformat (länge, etc.) von der HW & SW abhängig. Macht es da
Sinn das in den MC zupacken?
Gruß Kay
Hallo,
guten Tag und zuerst mal vielen Dank für die viele Arbeit, die ihr in
das Vorhaben steckt.
Wäre es euch möglich, ein paar Forenbeiträge zu pinnen, und zwar die, in
denen lauffähige Hardware und passende Software vorgestellt wird? Grund:
Für den Quereinsteiger ist es schwierig, in diesem riesigen Thread (und
den damit verlinkten) den Überblick zu bekommen.
Wäre schön, wenn das realisiert werden könnte.
heiner
Nachtrag zu meinem obigen Beitrag:
Ich benötige eine "einfache" Schaltung, um am Servicekey die Daten
auslesen und eine Software, um diese auswerten zu können. Als
Nichtelektroniker (der aber löten kann) mit geringer
Programmiererfahrung (Delphi / Lazarus, Java) habe ich die passenden
Beiträge nicht gefunden.
Bei mir liegt noch ein USB 2 seriell-Adapter rum, den müßte ich doch
eigentlich verwenden können, oder? (Einen Rechner mit
RS232-Schnittstelle hab ich nicht mehr)
Vielen Dank für eure Hilfe.
heiner
heiner2904 schrieb:> Bei mir liegt noch ein USB 2 seriell-Adapter rum,
Hallo Heiner,
sorry, das wird vermutlich nciht gehen. Auf dem EMS-Bus werden
Telegramme mit BREAK beendet. Ein PC ist definitiv zu langsam um das
Break Zeichengenau zu erkennen.
Mein FTDI-USB-RS232-Wandler kann das Break über den USB-Bus nicht
übermitteln. Vermutluch wird das Dein USB-Seriell-Wandler das auch nciht
können.
Also wird es ohne einen Mikrocontroller der das Break auswertet nicht
gehen.
Gruß
Ingo
Nabend,
hat jemand schon die Daten der SM10 decodiert?
src dest type 1 2 3 4 5 6 7 8 9 10111213141516
30 00 97 00000002011e01c50301f6ff00000800
30 00 97 00000001f43c01d80301f71400008e00
30 00 97 00000001680001d40101f74500008400
Byte 4 & 5 sind die Kollektor Temperatur
Byte 6 die Solarpumpe in %
Byte 7 & 8 Speichertemperatur unten
Byte 10,11,12 Betriebszeit Solar
Was mir noch fehlt ist die Speichertemperatur mitte (45 Grad in den
oberen beiden Werten). In der Anzeige gibt es noch einen
Solarenzugewinn....
Wie habt Ihr die Werte der anderen Module ermittelt bzw. heraus
gefunden?
Danke und Gruß
Kay
Kay F. schrieb:> Nabend,>> hat jemand schon die Daten der SM10 decodiert?>> src dest type 1 2 3 4 5 6 7 8 9 10111213141516> 30 00 97 00000002011e01c50301f6ff00000800> 30 00 97 00000001f43c01d80301f71400008e00> 30 00 97 00000001680001d40101f74500008400>> Byte 4 & 5 sind die Kollektor Temperatur> Byte 6 die Solarpumpe in %> Byte 7 & 8 Speichertemperatur unten> Byte 10,11,12 Betriebszeit Solar
Byte 2 ist der Betriebszustand
Byte 3 ist der Fehlercode
Byte 9 ist der Betriebsstatus
... sagt zumindest das Buderus-Dokument, das ich hier habe.
> Was mir noch fehlt ist die Speichertemperatur mitte (45 Grad in den> oberen beiden Werten). In der Anzeige gibt es noch einen> Solarenzugewinn....
Das Buderus-Dokument sagt dazu:
Die Speicher 1 Mitte Temperatur erhalten Sie über die
Standard-Warmwasserparameter.
Diesen Temperaturwert erhalten Sie unter dem Offset 1 + 2
... das wäre dann die Warmwasser-Isttemperatur aus den WW-Monitordaten.
Solarer Zugewinn ist in dem Dokument nicht enthalten.
> Wie habt Ihr die Werte der anderen Module ermittelt bzw. heraus> gefunden?
Größtenteils kollaboratives Reverse Engineering ;)
Ein paar Details hat das erwähnte Buderus-Dokument beigesteuert. Das
habe ich von Buderus zugeschickt bekommen, als ich einfach mal per Mail
angefragt hatte. Alles steht da aber auch nicht drin, nur Kram, der
'User servicable' ist.
Was hast Du denn genau bei Buderus angefragt? Als Endkunde?
Würde dann auch mal eine Anfrage starten um dich nicht ständig nerven zu
müssen ;-)
Gibt es in dem Dokument auch eine Auflistung des Byte 9
(Betriebsstatus)?
Ich würde vermute das das 2. Bit für die Pumpe ist. Bei den ersten
beiden Daten war die aktiv (30% bzw. 60%) beim letzen aus 00 %. Aber
wofür sind die anderen Bits???
Es gibt auch noch eine andere Meldung wenn die Solar Pumpe aktiv ist.
Der Inhalt war heute konstant der selbe.
src dest type 1 2 3 4 5 6
30 08 35 00000000ce00
Hallo,
bin gerade fleissig dabei meiner PCSoftware und der PIC-Firmware das
Senden beizubringen und habe gerade meine Heizung nicht dabei ;-)
Generell ist der EMS-Telegrammaufbau ja folgender:
Hi Niffko,
ich habe deine Schaltung nachgebaut und in Betrieb genommen, aber leider
kommt übers Terminal (9600 8N1) nichts, hast du Debugbefehle oder so
etwas definiert, das man den Controller testen kann? Oder gibt es
bestimmte Fuses die man noch setzen mußte?
Gruss
Norbert
Hi Norbert,
was macht denn die LED (die du natürlich entgegen dem Schaltplan richtig
herum eingelötet hast)? Sie müsste bei jedem erkannten BREAK toggeln.
//Niffko
Norbert Schnitzler schrieb:> 5V und GND vom Atmel vertauscht.
WTF ... warum ist an dem AVR-Schaltsymbol GND denn oben!? Typischer Fall
von selektiver Wahrnehmung meinerseits ...
Norbert Schnitzler schrieb:> hast du Debugbefehle oder so etwas definiert
nope ... aber sag' mir was du haben möchtest - schicke ich dir per
Email.
Norbert Schnitzler schrieb:> gibt es bestimmte Fuses die man noch setzen mußte?
... wenn das Umstellen auf externen Takt und das Abschalten des
Clockdividers für dich bestimmte Fuses sind dann - ja.
Richtiger Quarz?
//Niffko
IngoF schrieb:> heiner2904 schrieb:>> Bei mir liegt noch ein USB 2 seriell-Adapter rum,>> Hallo Heiner,>> sorry, das wird vermutlich nciht gehen. Auf dem EMS-Bus werden> Telegramme mit BREAK beendet. Ein PC ist definitiv zu langsam um das> Break Zeichengenau zu erkennen.>> Mein FTDI-USB-RS232-Wandler kann das Break über den USB-Bus nicht> übermitteln. Vermutluch wird das Dein USB-Seriell-Wandler das auch nciht> können.>> Also wird es ohne einen Mikrocontroller der das Break auswertet nicht> gehen.>> Gruß> Ingo
ich habe zwei USB-RS232, eine FTDI und eine PL2303 .
Ich glaube das die PL2303 compatibel ist mit die SErviceKey und the
Buderus SW.
Ich will es ausprobieren später.
Ich wolle die USB-RS232 mit eine Synology NAS brauchen, und damit die
data von Buderus speichern, aber ist er eine program zuma analysieren?
Besser wird die Synology auch einfach Ein/Aus command stueren, dan kann
ich es verbinden mit Home automation :)
Nicht Einfach ...
danke zu help
> ich habe zwei USB-RS232, eine FTDI und eine PL2303 .> Ich glaube das die PL2303 compatibel ist mit die SErviceKey und the> Buderus SW.> Ich will es ausprobieren später.>
Es geht mit dit PL2303 & service Key
Ups... hatte das wohl falsch verstanden.
Dachte Du wolltest einfach nur den USB-Adapter an die Heizung mit dem
"Pegelwandler" klemmen...
Wenn Du den nur als Verbindung zwischen Service-key und PC benutzen
möchtes gibt es natürlich keines von meinen genannten Problemen...
Gruß
IngoF
Hallo,
ich habe mich nun durch den für mich verständlichen Teil dieser extrem
riesigen Informationssammlung gelesen und muss gestehen dass ich da
wirklich etwas Defizite habe.
Ich habe so eine Buderus anlage mit einem Klinken-Steckeranschluss und
würde eigentlich gerne die Daten die da kommen loggen. Steuern wäre zwar
nett aber nicht zwingend nötig.
Nun bin ich komplett durcheinander durch die Flut an Informationen hier
und frage mich ob das für mich als elektronisch komplett unbeleckten
möglich sein könnte ohne Gefahr für meine Heizungselektronik ein
Interface zu bauen oder zu kaufen welches mit entweder auf USB oder
RS232 die Daten rausgibt. Auf Softwareseite wäre ich dann wieder etwas
bewanderter und würde z.B. mit einem Raspberry Pi die Daten loggen und
ins Netzwerk weiterreichen.
Kann mir jemand dein einfachsten/schnellsten Weg aus der Fülle an Wegen
(so sieht es für mich aus) nennen wie ich von dem Klinkenstecker auf
RS232/USB kommen könnte?
gruß,
Daniel
Moin,
es geht hier um 2 unterschiedliche Anlagen, um deine geht es auch ;-).
Daniel Kirstenpfad schrieb:> Kann mir jemand dein einfachsten/schnellsten Weg aus der Fülle an Wegen> (so sieht es für mich aus) nennen wie ich von dem Klinkenstecker auf> RS232/USB kommen könnte?
Es wurden im Thread 3 Möglichkeiten für den Abgriff beschrieben. Eine
Platine mit PIC von Ingo:
Beitrag "Buderus EMS-"Gateway" mit PIC18F / Sammelbestellung", back to the roots von
Niffko: Beitrag "Re: Logamatic 2107 Schnittstelle" ,
Beitrag "Re: Logamatic 2107 Schnittstelle" und meine Wenigkeit
(damals) Beitrag "Re: Logamatic 2107 Schnittstelle" mit
ADCMP370 und jetzt einer etwas erweiterten Version mit Opto und
TX-Möglichkeit.
Die Buderus-EMS ist eine Stromschnittstelle auf der "TX-Seite", wobei
der Master jeweils jedes Telegramm auf einer Spannungsschnittstelle
wiederholt. Sprich, du greifst das Echo zum Loggen ab, dieses Signal ist
TTL-Level, aber mit einem Offset von ~10V.
Ich werde demnächst noch eine (oder mehrere) Platinen für einen Receiver
bauen, der Prototyp läuft soweit und ist weitgehend digital realisiert.
Die Anbindung erfolgt per 3V3/GND und RX/TX-Uart.
Grüße.
Hallo,
ich bin immernoch auf der Suche nach einer Möglichkeit meine Daten der
GB162 abzugreifen. Ich hatte bereits mit IngoF gesprochen, leider fehlen
ihm für eine zweite Revision seiner Platine noch ein paar Sachen, daher
meine Bitte an dich, Rudi.
Solltest du in nächster Zeit mal eine Platine bauen bzw. über haben
würde ich sie dir gerne abkaufen.
Melde dich bitte mal einfach bei mir spooniester(AET)gmailDOTcom ,
vielleicht können wir uns per Mail etwas mehr austauschen!
Vielen Dank!!
Fast richtig.. Eigentlich ist noch die Zeit bei mir knapp und noch zu
gutes Wetter draußen...
Aber es sind auch nur drei Leute auf der Warteliste. Unter zehn lohnt
sich das nicht wirklich der ganze Aufwand.
Bei der zweiten Version würde das allerdings dann nur über 100% Vorkasse
laufen können.
Will nicht noch mal teilweise dem Geld hinterherlaufen.
Gruß
IngoF
Hallo,
ich habe probiert das BF Bus zu sniffen und war erfolgreich. Ich kann
Nachrichten ohne Probleme abhören. Ich kann auch die Information zurück
gewinnen mit Hilfe von der Beschreibung hier:
http://wiki.neo-soft.org/index.php/Heizungsschnittstelle/BFU .
Nun wollte ich das 2. Schritt machen und Nachrichten senden. Dafür fählt
mir aber das CRC byte. Ich habe den Thread durchgelesen und habe
gesehen, dass ihr auch das Problem mit der CRC-Berechnung bei der EMS
Bus hattet. Ich habe ihr Lösung versucht bei dem BF Bus anzuwenden, aber
leider ohne Erfolg. Ich habe auch die meist verbeiteten CRC 8-bit
Berechnungen ausprobiert - auch ohne Erfolg.
Meine Bitte an euch ist, wenn ihr Zeit habt mir zu helfen. Ich mache als
Anhang eine Datei mit gespeicherten Nachrichten, wo das letzte Byte die
CRC sein soll.
Ich habe bemerkt, dass ich auch den CRC-Wert 00 als Resultat bekomme.
Soll das bedeuten, dass den Initial Wert 00 ist??
Es gibt auch Nachrichten, wo den CRC-Wert gleich ist bei
unterschiedlichen Nachrichten.
Vielen Dank im Voraus!
Gruss
Kostadin.
Hallo,
warum??? Die Nachrichten sind so aufgebaut:
<FA> <00> <IST_TEMP MSB> <IST_TEMP_LSB> <00> <SOLL_TEMP_TAG>
<SOLL_TEMP_NACHT> <STATUS> <CRC>
insg. 9 Bytes. Vielleicht ich soll sagen, dass die Nachrichten sind
schon gefiltert, d.h. sie sind nur die BFU Nachrichten, die an die
Therme gesendet werden. Die zahlen da wie 15->16 bedeutet nur 15->16
Grad SOLL_TEMP. Ich habe mit der SOLL_TEMP gespielt, einfach die
Raumfühler gedreht und geschaut was passiert mit dem CRC-Wert.
Normalerweise sieht ein Datentausch so aus:
1: af 84
2: ac
1: a0
2: fa 00 01 07 00 1c 14 01 90 af 04
1: a4
af 84
2: a0
1: fa 06 01 f2
af 04
2: a4
und ich habe gefiltert nur die BFU Nachrichten.
Ich hoffe jetzt ist klarer geworden.
Grüße.
Norbert Schnitzler schrieb:> wärst du so nett uns deine aktuelle Schaltung zu zeigen?
Kann ich die Tage mal tun. Ich habe von der Schaltung bisher nur einen
Prototypen am laufen ohne Sendefunktion.
Rudi schrieb :
> Sorry, falscher Bus ;-). Evtl. passt die CRC vom EMS-Bus?
1. Macht nichts ;)
2. Tja, leider nicht. Das war meine erste Gedanke. Ich habe auch
versucht irgendwie von EMS-CRC zu BF-CRC (mit XOR) zu kommen - leider
ohne Erfolg.
Bruteforce hat auch keine Lösung gefunden. Ich habe ausprobiert alle
mögliche Kombinationen mit:
- Startwert: 0 bis 255
- Initialwert: 0 bis 255
- final XOR: 0 bis 255.
Fehler sind nicht ausgeschlossen.
Ich bin auch nicht sicher, ob ich die CRC über die ganze Nachricht (11
bytes) machen soll, über die Bytes vor dem CRC Wert (9 bytes) oder nur
über die Nutzdaten (das sind IST_TEMP, SOLL_TEMP Tag, SOLL_TEMP Nacht,
Status): ???
- 11 bytes komplette Nachricht "2: fa 00 01 07 00 1c 14 01 CRC af 04"
- 9 bytes Nachricht: "2: fa 00 01 07 00 1c 14 01 CRC .. .."
- nur die Nutzbytes: "2: .. .. 01 07 .. 1c 14 01 CRC .. .."
Ich weiß, dass wenn man nur ein Bit geändert wird in die Nachricht, dann
ändert sich auch die CRC. Es gibt aber auch unterschiedliche
Nachrichten, welche die gleich CRC haben.
Kann ich irgendwie 3-4 Nachrichten nehmen, bei der nur ein Bit sich
ändert und das Algorithmus irgendwie rauskriegen??? :)
Vielen Dank im Voraus!
Grüße
Kostadin.
Der Ansatz mit dem einen bit ist garnicht mal so verkehrt.
So kann man auf jedem Fall schon mal herausbekommen ob bei der
CRC-Berechnung noch irgendwas rotiert wird.
Am besten mal eine Menge an Telegrammen loggen und dann aus der ganzen
Wust mehrere Telegramme herasusuchen wo sich nur ein Bit ändert. Am
besten auch mehrer verschiedene Telegrammpärchen nehmen wo sich nur das
einzige Bit ändert.
Dannach dann andere Telegramme heraussuchen wo sich dann ein anderes Bit
ändert.
Wenn sich jedes mal genau das Bit in der Prüfsumme ändert was sich in
den Daten geändert hat dann ist schon mal keine Rotation mit drin.
Wenn sich ein ganz spezielles Bit (z.B. Byte 7 Bit5) ändert und sich in
der CRC mehrere Bits ändern oder immer ein anderes Bit in der CRC ändert
dann kann es keine simple Verknüpfung mehr sein sondern irgend was mit
Generatorpolynom. (CRC4,CRC16 und was es da alles so gibt..)
Das ist zumindest die Meinung die ich mir so zurecht gelegt habe. Hoffe
das es auch der Relität entspricht ;-D
Gruß
IngoF
Achso... am besten ein Bit aus den Daten nehmen was sich ändert und
nicht aus dem Header. dann ist es zumindest egal ob die Prüfsumme nur
über die Daten oder die komplette Nachricht ist...
Gruß
Ingo
Sieht nicht nach einfach aus:
0xFA 0x00 0x00 0xFC 0x00 0x30 0x28 0x01 0x79
0xFA 0x00 0x00 0xFB 0x00 0x30 0x28 0x01 0x41
Scheint wieder eine "richtige" crc zu sein.
Hallo Rudi,
Klingt noch ganz logisch. Muss also keine "richtige" CRC sein...
Von 0xFB nach 0xFC ändern sich drei zusammen hängende Bits und in der
Prüfsumme ändern sich auch drei zusammenhängende Bits
Datenbyte:
FB = 1111 1011
FC = 1111 1100
==============
XOR 0000 0111
Prüfsumme:
79 = 0111 1001
41 = 0100 0001
==============
XOR 0011 1000
Die Bits sind entweder 3 mal nach links rotiert oder 5 mal nach rechts.
Ich tippe auf 5 mal rechts rotiert. Das geänderte Byte ist 5 Zeichen vor
der Prüfsumme.
Gruß
Ingo
Ingo F. schrieb:> Die Bits sind entweder 3 mal nach links rotiert oder 5 mal nach rechts.> Ich tippe auf 5 mal rechts rotiert. Das geänderte Byte ist 5 Zeichen vor> der Prüfsumme.
So einfach ist es leider nicht. Ist evtl. doch ein schlechtes Beispiel
gewesen ;-).
Hier ein besseres (g):
0xFA 0x00 0x00 0xFB 0x00 0x2E 0x26 0x01 0x01
0xFA 0x00 0x00 0xFB 0x00 0x2E 0x26 0x02 0x98
Die Daten sind noch verpackt in einem Pre-/Suffix:
=> 0xAF <ADRESSE-EMPÄNGER> ; HELLO BFU
<= 0xAC ; Richtungsumkehr
=> 0xA0 ; REQ
<= <DATEN-BFU> ... 0xfa ....... <crc>
<= 0xAF <ADRESSE-SENDER>
=> 0xA4 ; OK
Wenn ich das richtig verstanden habe.
Am Sichersten ist es wenn sich auch nur ein Bit verändert Also z.B 0x33
>> 0x37
Wenn man das ganze an Verschiedenen Bits aus verschiedenen Datenbytes
macht könnte man feststellen ob sich auch nur wirklich immer ein
bestimmtes Bit in der Prüfsumme ändert.
Oder einfach nach der Prüfsumme sortieren bei der sich ein bestimmtes
Bit ändert und dann sehen wo sich Bits ändern können. Das sollte
zumindest bei einer XOR-Prüfsumme mit weiteren Verknüpfungen und
rotationen funktionieren.
Hänge mal die OpenOffice Datei an. Die lässt sich bestimmt dafür
gebrauchen.
Dort werden die Hex-Werte in Binärwerte umgewandelt.
Viel Spasß beim Forschen....
Gruß
Ingo
Hallo Leute,
vielen Dank für den Vorschägen. So was habe ich heute versucht und etwas
gefunden. :)
Ich habe zum Erst untersucht was passiert, wenn man das letzte Byte vor
dem CRC Wert um einen Bit ändert und das Ergebnis ist folgendes:
Status Byte (letzte Byte vor dem CRC) CRC
Bits Bits
x x x x x x x x x x x x x x x x
|^ CRC(neu) = CRC(alt) XOR 0x80
i 6 5 4 3 2 1 0| CRC(neu) = CRC(alt) XOR (19h << i)
z.B. :
Datenbyte : F0 = 11110000 CRC = 10000110
Datenbyte : F1 = 11110001 CRC = 00000110 (CRC(f0) XOR 0x80)
Datenbyte : F3 = 11110011 CRC = 00011111 (CRC(f1) XOR (0x19<<0))
Datenbyte : F4 = 11110100 CRC = 10110100 (CRC(f0) XOR (0x19<<1))
usw.
So, dann habe ich gleich dasselbe mit dem IST_TEMP untersucht:
MSB IST_TEMP CRC
x x x x x x x x x x x x x x x x
^ ^
CRC(neu) = CRC(alt) XOR (0x04)
Bemerkung: bei dem MSB ändert sich nur das erste Bit.
LSB IST_TEMP CRC
x x x x x x x x x x x x x x x x
|^ ^ ^ ^ ^ ^ ^ ^ ^ ^
d.h. wenn sich das erste Bit(bit=0) ändert toggelt sich beim CRC das
vierte Bit(bit=3)
bit1 -> bit4
bit2 -> bit5
bit3 -> bit6
bit4 -> bit7 und noch
x x x x x x x x
i 2 1 0| CRC(neu) = CRC(old) XOR (19h << i)
z.B. :
Datenbyte : F8 = 11111000 CRC = 11001100 CC
Datenbyte : FA = 11111010 CRC = 11011100 DC
Datenbyte : D8 = 11011000 CRC = 11010101 D5
Datenbyte : F8 = 11111000 CRC = 11001100 CC CRC(d8) XOR (0x19 << 0)
So war ich begeistert, dass das gleiche war wie oben.
Dann aber beim SOLL_TEMP taucht wieder dieses (19<<i), aber die Bits
vorne haben andere Einflüsse:
SOLL_TEMP_TAG CRC
x x x x x x x x x x x x x x x x
^ ^
^ ^
^ ^
i 4 3 2 1 0| CRC(neu) = CRC(alt) XOR (19h << i)
z.B. :
Datenbyte : 28 = 00101011 CRC = 10011100
Datenbyte : 2B = 00101000 CRC = 10011100
Datenbyte : 29 = 00101001 CRC = 00000111
Datenbyte : 2D = 00101101 CRC = 10000111
usw.
Was ich auch noch gefunden habe ist wie man die Stelle in Datenbyte
findet, bei der dieses XOR (19<<i) beginnt:
Stelle(bit number) = 8 - (n.Byte vom Nachricht - 1)
Stelle(bit number) = 0x80 >> (n. Byte - 2)
z.B. :
Status Byte ist das 8.Byte in der Nachricht -> Stelle ist bit1.
SOLL_TEMP_TAG ist 6. Byte -> Stelle ist bit3
SOLL_TEMP_NACHT ist 7.Byte -> Stelle ist bit4
LSB IST_TEMP ist 4. Byte -> Stelle ist bit5
MSB IST_TEMP ist 3. Byte -> Stelle ist bit6
So konnte ich auch feststellen an welche Stelle sich das erste Bit
(bit0) jedes Datenbytes sich an welche Bitstelle in CRC sich wirkt:
CRC Bit Stelle bitX, welche sich ändert, wenn das bit0 von dem
Datenbyte sich ändert:
bitX = 0x80 >> (8 - n. Byte + 1)
z.B. :
SOLL_TeMP_TAG 6.Byte -> Das Bit7 toggelt sich wenn beim SOLL_TEMP_TAG
bit0 sich toggelt.
Ich glaube wir sind kurz davor das zu knacken..aber irgendwie weiss ich
nun nicht mehr was zu machen. Vielleicht jemand von euch hat eine Idee?
Grüße.
Kostadin schrieb:> Ich habe zum Erst untersucht was passiert, wenn man das letzte Byte vor> dem CRC Wert um einen Bit ändert und das Ergebnis ist folgendes:
Kannst du bitte mal die Reihe von 0x00-0xff aufnehmen? Also Letztes
Datenbyte und CRC, bitte beide als Hex-Werte. Dann hätten wir etwas wie
die CRC-Table.
Leider es ist nicht möglich das letzte Datenbyte von 00-ff aufzunehmen.
Es gibt nur folgende Möglichkeiten:
DB CRC
00 C1
01 41
02 D8
03 58
04 F3
05 73
06 AF
07 6A
12 10
13 90
16 22
17 A2
;)
Hallo,
habe mich seinerseits auch mit der CRC der BFU beschäftigt und bin auch
nicht weiter gekommen. Vielleicht helfen euch meine aufgenommen Daten
weiter. (ohne leading 0xFA 0x00 ).
Ich denke der einfachste Ansatz wäre die CRC-Tabelle zu rekonstruieren.
Kostadin schrieb:> Leider es ist nicht möglich das letzte Datenbyte von 00-ff aufzunehmen.> Es gibt nur folgende Möglichkeiten:
Sind die Daten vor dem letzten Byte wirklich immer gleich?
Rudi schrieb:> Sind die Daten vor dem letzten Byte wirklich immer gleich?
Ja, leider das letzte Byte ist quasi das Betriebsbyte (Status) und es
gibt nicht so viele Möglichkeiten dabei - Tag/Nacht, Automatik/Manuell,
Sommer/Winter und Urlaub. Sogar einige Werte habe ich gekriegt nur beim
Umschalten zwischen einzelnen Betrieben.
Ich hänge auch eine Excel-Datei mit aufgezeichneten Daten und deren
"Dekodierung" ;)
Ich schreibe gerade Funktionen, die die von mir oben genannten
Algorithmen umsetzten, so dass ich nur von einer Nachricht+CRC die neue
CRC für eine beliebige gewünschte Nachricht bauen kann. Ich sag
Bescheid, wenn das funktioniert ;)
Herbert Nachbagauer schrieb:> Hallo,> habe mich seinerseits auch mit der CRC der BFU beschäftigt
Hallo, hast du zufällig eine BFU mit Funkuhr?? Weil, die BFU, die ich
benutzte ist ohne und ich frage mich, ob die Bytes <0x00> und <0x00>
zwischen den
0xFA <0x00> MSB_IST_TEMP LSB_IST_TEMP <0x00> SOLL_TEMP_TAG....
immer 0x00 bleiben oder nicht? Ich kann mir schon vorstellen das das 2.
<0x00> Byte die Zeit überträgt.
Grüße.
Kostadin schrieb:> Hallo, hast du zufällig eine BFU mit Funkuhr?? Weil, die BFU, die ich> benutzte ist ohne und ich frage mich, ob die Bytes <0x00> und <0x00>> zwischen den>> 0xFA <0x00> MSB_IST_TEMP LSB_IST_TEMP <0x00> SOLL_TEMP_TAG....>> immer 0x00 bleiben oder nicht? Ich kann mir schon vorstellen das das 2.> <0x00> Byte die Zeit überträgt.
BFU/F habe ich keine. Ein byte is aber auch schon für minutengenaue
Werte 24*60 = 1440 zu klein. Ich vermute es gibt eher einen eigenen
Message Typ mit Header 0xFA ?? (analog er 2107 Antwort mit 0xFA 0x06)
und zwei (drei) Nutzdatenbytes HH, MM, (SS).
Hallo wieder,
nun habe ich die Funktionen umgesetzt und nach ein paar Änderungen, die
funktionieren ohne Probleme. :)) Leider das ist nicht die CRC Berechnung
selbst, aber zumindest können wir jetzt Nachrichten senden..(vermute ich
mal).
>@Rudi
ich habe mittels die Funktionen für das letzte Byte (00-FF) die CRC
berechnet. Die DB und dazugehörige CRCs sind in die 2. Datei. Ich hoffe
du kannst die CRC-Tabele restaurieren. Ich weiß nicht was zu machen mit
diesen Werten. Vorschläge?
Grüße.
Hallo,
Hab gerade mit optokoppler und 3.5mm klinke meine Buderus daten
entlockt. Interface ist ATmega8 mit etwas geanderter firmware (macht
clear text).
Danke fuer die super (wenn auch wusselige) info ;-) ohne eure arbeit
waere das bei mir etwas laenger gewesen. Einen scope hatte ich schon
dran aber dann stiess ich auf diesen tread.
Eine Frame die ich noch nicht viel info hier lese ist diese:
Sun Oct 14 07:40:47 UTC 2012 : 1000A30008010100CA00D000D07D007D00FC00
Daraus habe ich gefunden:
00CA = inside temp = 20.2°C ??? ==> Confirmed 00C9 = 20.1
Gibt es irgendwo eine uptodate liste?
Schoenen Sonntag
Edward
Hallo Niffko _,
ich programmiere z.Z. meine Rücklaufanhebung und habe ein paar Fragen
bezüglich Heizungsinterna. Evtl. könntest du mir etwas auf die Sprünge
helfen.
Bei einer relativ hohen VL Solltemperatur (z.Z. 52°) und großem dT
zwischen RL und VL (z.Z. 20°C) wollte ich den Rücklauf nicht ganz
anheben, sondern nur soweit dass die Heizung im unteren Leistungsbereich
mitläuft.
Gibt es einen Richtwert für VL soll/VL/RL wann die Heizung wieder
einschaltet?
Was gibt die Heizungsleistung (in %) aus den Logdaten genau an, aus
welchen Heizungsparameter wird diese errechnet?
Korreliert der gemessene Flammenstrom mit dem Gasverbrauch?
Danke & Grüße.
Hallo Rudi,
na, Saison eröffnet? Bei mir geht's auch schon wieder los ^^
Rudi schrieb:> Gibt es einen Richtwert für VL soll/VL/RL wann die Heizung wieder> einschaltet?
Die Einschalthysterese des Brenners beträgt -6K.
Rudi schrieb:> Was gibt die Heizungsleistung (in %) aus den Logdaten genau an, aus> welchen Heizungsparameter wird diese errechnet?
Das ist die momentane Brennerleistung bezogen auf die Nennleistung
deines Heizkessels. Errechnet wird sie über die Drehzahl des Gebläses
(Tachosignal). Das ist möglich, weil die Gasarmatur die Gasmenge
entsprechend des vom Gebläse erzeugten Unterdruckes regelt. Der UBA
macht die Leistungsregelung mittels PWM-Signal für das Gebläse und
erhält als Rückkopplung das Tachosignal derselbigen - welches dann auf
Ist-Leistung umgerechnet wird.
Rudi schrieb:> Korreliert der gemessene Flammenstrom mit dem Gasverbrauch?
Prinzipiell ja - stärkere Flamme, mehr Flammensrom. Ist aber nur als
Tendenz zu gebrauchen. Zu viele Unbekannte ... Übergangswiderstände,
Belag auf der Elektrode. Solltest du den Gasverbrauch erfassen wollen,
nimm die Ist-Leistung. Ich lasse meinen µC alle 5s die Ist-Leistung
aufaddieren und errechne in der PC-Applikation über Nennleistung und
Heizwert[kWh/m³] den Gasverbrauch. Ist für meine Zwecke genau genug.
//Niffko
Hallo Niffko,
Niffko schrieb:> na, Saison eröffnet? Bei mir geht's auch schon wieder los ^^
Ja und der Umbau für die Rücklaufanhebung ist auch fertig geworden :-).
> nimm die Ist-Leistung. Ich lasse meinen µC alle 5s die Ist-Leistung> aufaddieren und errechne in der PC-Applikation über Nennleistung und> Heizwert[kWh/m³] den Gasverbrauch. Ist für meine Zwecke genau genug.
Ich lese den Gaszähler direkt aus und bekomme die Impulse und kann somit
die Tages/Stunden ... Ration für den Brenner berechnen.
Nun ein weiteres Problem, was ich erfolgreich verdrängt habe. Die
Heizungspumpe bleibt bei 100%iger Rücklaufanhebung bei bescheidenen 55%
und die Heizkörper werden jetzt sehr sehr Träge warm VL: 52°C/RL 35°C.
Der Heizkreis schiebt also nicht genug Wärme nach bzw. der Unterdruck im
RL fehlt :-/.
Bei der RC30 konnte man die Pumpe nicht ansteuern oder? Bei der RC35
konnte die Pumpe über das EMS-Interface umgeschaltet werden oder evtl.
auch geregelt!? Von welchen Parametern hängt die Pumpleistung eigentlich
ab?
Grüße.
Hallo,
so sieht z.Z. meine mobile "Heizungsüberwachung" aus. Der Server stellt
die Seite im Netz bereit (jquery mobile) und die Daten werden per Ajax
regelmäßig neu geladen.
Wen es interessiert ;-).
Grüße.
Moin Rudi,
Rudi schrieb:> Heizungspumpe bleibt bei 100%iger Rücklaufanhebung bei bescheidenen 55%> [...]> Von welchen Parametern hängt die Pumpleistung eigentlich> ab?
Die Pumpenmodulation ist bei der GB152 an die Brennerleistung gekoppelt.
Demzufolge läuft die Pumpe bei 'Brenner AUS' auf Minimum.
Rudi schrieb:> Bei der RC30 konnte man die Pumpe nicht ansteuern oder? Bei der RC35> konnte die Pumpe über das EMS-Interface umgeschaltet werden oder evtl.> auch geregelt!?
Geht leider bei GB152 nicht ... egal mit welcher Regelung. Die Arten der
Pumpenansteuerung werden durch das Heizgerät definiert. GB142, GB162 und
GB172 können z.B. auch Differenzdruckregelung. Damit hättest du das
Problem nicht.
Mögliche Optionen:
- Steuerkabel der Pumpe abziehen, dann läuft sie Volllast
- Steuersignal(PWM) der Pumpe hacken und Pumpe mit eigener Hardware
ansteuern
Wie hast du denn die WW-Bereitung in die Rücklaufanhebung eingebunden?
Es kann da bei Kombipuffern fiese Fehlzirkulationen geben. Hängt damit
zusammen, dass der GB152 das 3-Wege-Umschaltventil im Rücklauf hat und
Heizungs- und WW-Vorlauf verbunden sind.
//Niffko
Rudi schrieb:> Hier der Code:> poly = 12> crc1 = 0x00>> for i in range(0,len(a)-1):> crc1 = crc1 ^ int(a[i],16)> crc2 = crc1> if crc1 & 0x80: crc1 ^= poly>> d = 0> if crc1 & 0x80: d = 1> crc1 = crc1 << 1> crc1 &= 0xfe> crc1 |= d>> => crc2
Hallo Rudi, ich versuche mich gerade daran diese Formel umzusetzen,
stehe aber etwas auf dem Schlauch. Wie würde das aussehen, wenn ich die
Daten übergebe und CRC zurück bekommen möchte? Also diese Formel als
Funktion in PHP umsetzen!?
Gruß
Thorsten
Moin Niffko,
Niffko schrieb:> Rudi schrieb:>> Heizungspumpe bleibt bei 100%iger Rücklaufanhebung bei bescheidenen 55%>> [...]>> Von welchen Parametern hängt die Pumpleistung eigentlich>> ab?>> Die Pumpenmodulation ist bei der GB152 an die Brennerleistung gekoppelt.> Demzufolge läuft die Pumpe bei 'Brenner AUS' auf Minimum.
Dann aber per Software bzw. Regelung und nicht hart verdrahtet.
> Rudi schrieb:>> Bei der RC30 konnte man die Pumpe nicht ansteuern oder? Bei der RC35>> konnte die Pumpe über das EMS-Interface umgeschaltet werden oder evtl.>> auch geregelt!?>> Geht leider bei GB152 nicht ... egal mit welcher Regelung. Die Arten der> Pumpenansteuerung werden durch das Heizgerät definiert. GB142, GB162 und> GB172 können z.B. auch Differenzdruckregelung. Damit hättest du das> Problem nicht.>> Mögliche Optionen:> - Steuerkabel der Pumpe abziehen, dann läuft sie Volllast> - Steuersignal(PWM) der Pumpe hacken und Pumpe mit eigener Hardware> ansteuern
Ich habe eine andere Option getestet. Über den Relais-Test springt die
Pumpe mit 100% an, bleibt dann aber bei 100% bis der Brenner wieder
anspringt. Es gab dort auch eine Fehlermeldung, die ich mir mal genauer
anschauen muss. Der Test sollte ja auch per EMS funktionieren!?
> Wie hast du denn die WW-Bereitung in die Rücklaufanhebung eingebunden?> Es kann da bei Kombipuffern fiese Fehlzirkulationen geben. Hängt damit> zusammen, dass der GB152 das 3-Wege-Umschaltventil im Rücklauf hat und> Heizungs- und WW-Vorlauf verbunden sind.
Keine großen Änderungen damit alles so läuft wie gehabt. Das KW für WW
geht über den Puffer und im Rücklauf des HK steckt jetzt zusätzlich ein
Mischer. Nebenzirkulationen habe ich noch nicht beobachtet.
Das WW ist in diesem Setup eher nebensächlich und wird nicht direkt über
den Puffer geladen, nur über das KW bei WW-Abnahme. Man könnte jetzt
noch eine Pumpe installieren und dann über KW und WW zirkulieren und die
Wärme in den WW-Puffer transportieren, ist aber erst mal nicht
vorgesehen.
Danke für die Infos!
Grüße.
Thorsten schrieb:> Hallo Rudi, ich versuche mich gerade daran diese Formel umzusetzen,> stehe aber etwas auf dem Schlauch. Wie würde das aussehen, wenn ich die> Daten übergebe und CRC zurück bekommen möchte? Also diese Formel als> Funktion in PHP umsetzen!?
Das ist Python und sollte meiner Meinung nach keine Probleme bei der
Portierung bereiten.
Grüße.
Ok, aber könntest du mir trotzdem auf die Sprünge helfen?
Hier hast du das ja noch einmal vereinfacht:
1
for i in range(0,len(a)-1):
2
d = 0
3
if crc1 & 0x80:
4
crc1^=12
5
d = 1
6
crc1 = crc1 << 1
7
crc1 &= 0xfe
8
crc1 |= d
9
crc1 = crc1^int(a[i])
Welches sind denn die Daten die an die Funktion übergeben werden und was
sind "i", "a" und "crc1" ?
Ich nehme an crc1 wird nur innerhalb der Formel benutzt und ist
letztendlich das Ergebnis!? Aber du hast vorher schon ne "IF" Bedingung
auf crc1, obwohl das noch nicht definiert ist? Irgendwie verstehe ich
den Code nicht :(
Gruß
Thorsten
Moin Niffko,
das sieht schon etwas verständlicher aus, aber wofür ist das u8, wenn du
es es gleich auf 0 setzt und gar nicht erst benutzt ??
Und du übergibst in "buffer" das Byte Array und in "pos" die Anzahl
Bytes!?
Wie sieht ein Beispielinhalt deines Arrays aus?
Gruß
Thorsten
Thorsten schrieb:> Welches sind denn die Daten die an die Funktion übergeben werden und was> sind "i", "a" und "crc1" ?
"a" ist der "String" in der die Datenbytes übergeben werden
"i" ist der Schleifenzähler
"d" ist
"crc1" ist der Zwischenspeicher für die Prüfsumme
"^" ist ein XOR
">>" ist ein rotieren nach links.
Mit ein wenig googlen sollte man das aber auch selber herausbekommen.
Die Routine macht nichts anderes als die Bytes mit XOR zu verknüpfen und
zu rotieren. Wenn der Zwischenwert 0x80 oder größer ist wird nochmals
zusätzlich mit 0x12 verknüpft.
Kann ja auch mal meinen Java-code anhängen.
Bei mir wird die CRC nach jedem Byte berechnet Am Ende wird dann einfach
nur die CRC abgespeichert. Der mittlere Block wird also für jedes Byte
wiederholt.
Bin noch nicht dazu gekommen das umzuschreiben. Aber im Moment habe ich
noch keinen Grund dazu.
Hallo Thorsten,
Thorsten schrieb:> aber wofür ist das u8
ist keine Variable, sondern nur der Datentyp der nachstehenden
Variablen, unsigned char
Thorsten schrieb:> Und du übergibst in "buffer" das Byte Array und in "pos" die Anzahl> Bytes!?
richtig und richtig. "pos" ist gleichzeitig auch die nullbasierte
Einfügeposition der CRC im Array.
Thorsten schrieb:> Wie sieht ein Beispielinhalt deines Arrays aus?
Wie jedes beliebige Datentelegramm hier im Thread. Bei manchen kommt
noch 0x00(BREAK) hinter der CRC, die musst du dir dann wegdenken.
//Niffko
Falls es jemanden interessiert: Ich habe meinen EMS-Daemon, den ich
weiter oben schon mal gepostet habe, bei Github hochgeladen:
https://github.com/maniac103/ems-collector
Der Daemon kann entweder per UART oder via TCP (mittels NetIO o.Ä. +
Ethersex) mit dem EMS sprechen. Im letzteren Fall kann er auch Kommandos
via telnet empfangen und an die Heizung schicken.
Wenn jemand noch interessante Sendesequenzen hat: Nur her damit ;)
Danny Baumann schrieb:> Ich habe meinen EMS-Daemon, den ich> weiter oben schon mal gepostet habe, bei Github hochgeladen:
Was macht man denn mit den ganzen Dateien? Kann mann die auch komplett
herunterladen?
Was brauch man denn zum kompilieren? Oder muss man das einfach in einen
Ordner schieben und alles läuft von selber?
IngoF schrieb:> Was brauch man denn zum kompilieren? Oder muss man das einfach in einen> Ordner schieben und alles läuft von selber?
Nee, kompilieren musst du schon noch ;)
Dependencies sind mysql++ und boost.
Danny Baumann schrieb:> Nee, kompilieren musst du schon noch ;)> Dependencies sind mysql++ und boost.
Na dann muss ich das noch ein oder zwei Jahre verschieben ;-)
Habe bei mir eine Synology DiskStation212 auf der ich das vermutlich
auch gut laufen lassen könnte... Oder kann man deinen EMS-Daemon nicht
auf Linux kompilieren?
Habe mich damit leider noch nicht richtig beschäftigt... Der
FTDI-SerialPort habe ich im ersten Anlauf noch nicht zum laufen
bekommen..
Gruß
Ingo
IngoF schrieb:> Danny Baumann schrieb:>> Nee, kompilieren musst du schon noch ;)>> Dependencies sind mysql++ und boost.>> Na dann muss ich das noch ein oder zwei Jahre verschieben ;-)>> Habe bei mir eine Synology DiskStation212 auf der ich das vermutlich> auch gut laufen lassen könnte... Oder kann man deinen EMS-Daemon nicht> auf Linux kompilieren?
Doch, sicher, warum auch nicht? Ich lasse den Daemon (wie weiter oben
schon mal erwähnt...) auf einem SheevaPlug mit Debian Squeeze laufen. Da
habe ich allerdings den Vorteil, eine volle Linux-Distro zu haben. Ich
hab keine Ahnung, ob es Synology-Pakete für boost und mysql++ gibt.
Hi,
dank Danny bekomme ich jetzt auch Daten meiner GB162. Ich lasse den
Daemon von Danny auf einem Raspberry mit Rapsbian laufen, klappt
wunderbar. Dort liegt auch die MySql Datenbank, keinerlei Performance
Probleme!
Sogar senden klappt ohne Probleme!
Gruß
spooniester
Hallo,
Niffko schrieb:> Mögliche Optionen:> - Steuerkabel der Pumpe abziehen, dann läuft sie Volllast
Werde ich mal Testen. Hast du zufällig eine Belegung des Steuerkabels?
> - Steuersignal(PWM) der Pumpe hacken und Pumpe mit eigener Hardware> ansteuern
Bist du sicher das PWM benutzt wird? Ich hatte im Zusammenhang Buderus
Pumpe mal etwas von 0-10V gelesen. Wenn dem wirklich so ist könnte ich
einen analog Schalter/Multiplexer benutzen und dann etwas "einfacher"
die Pumpe über feste Spannungen modulieren.
Z.Z. -7°C werden die Heizkörper im unteren Bereich nicht richtig warm.
Ich steh da jetzt total auf dem Schlauch wie die Heizung erkennt ob
Wärme gebraucht wird oder nicht. Die Spreizung VL/RL ist im Mischer-
oder Heizungsbetrieb nur marginal unterschiedlich 2-3K. Wie wird denn
die Brennerleistung bzw. Pumpenleistung bei der GB152 festgelegt, machen
diese 2-3K schon den großen Unterschied?
Danke & Grüße,
Rudi
Moin Rudi,
Rudi schrieb:> Hast du zufällig eine Belegung des Steuerkabels?
Nein habe ich nicht. Dürfte aber mit einem Oszi nicht so schwierig sein.
Rudi schrieb:> Bist du sicher das PWM benutzt wird?
Jep.
Rudi schrieb:> Wie wird denn die Brennerleistung bzw. Pumpenleistung> bei der GB152 festgelegt ...
Die alleinige Führungsgröße für den Brenner liefert der Vorlaufsensor.
Nähert sich die Vorlauftemperatur dem Sollwert, beginnt der Brenner -
und damit auch die Pumpe - bis auf min. Leistung herunterzumodulieren.
Bei Sollwertüberschreitung von 6K schaltet der Brenner ab und die Pumpe
verbleibt auf min. Modulation.
//Niffko
Hallo,
Niffko _ schrieb:> Rudi schrieb:>> Hast du zufällig eine Belegung des Steuerkabels?>> Nein habe ich nicht. Dürfte aber mit einem Oszi nicht so schwierig sein.
Es ist eine Grundfos UPER 15-60 verbaut, zum Glück ohne Rückkanal, mit
einer 2 adrigen Leitung. Nach einem kleinen Umbau kann ich jetzt per
Schalter die Pumpe auf 100% setzen, funktioniert also. Ich werde morgen
mal mit dem Oszi ran und messen.
Gibt es in der Therme irgendwo eine zentrale Stromversorgung
(Niederspannung) oder einen Punkt für Ground? Was befindet sich
eigentlich unter der UBA3 in dem hellgrauen Kasten, in den alle Kabel
hineingehen?
Grüße.
Hallo,
so PWM habe ich gemessen. Für PWM werden etwa 14V benötigt. Ein
Pulspaket, bestehend aus einen high und low Pulse, ist genau 2ms lang.
Die Änderung der Pulsbreite scheint linear zur Pumpenleistung zu sein.
Anbei noch die Scopebilder und die gemessenen Pulsbreiten/Prozent in
einem Diagramm.
Grüße.
Hallo,
ich würde gerne bei meiner neuen Therme GB172 Daten aufzeichnen. Als
Hardware habe ich mir den EMS-Reader von Niffko ausgesucht:
Beitrag "Re: Logamatic 2107 Schnittstelle"
Die Schaltung ist ja relativ simpel und Firmware ist auch verfügbar.
Ich würde gerne wissen ob den Reader schon jemand erfolgreich aufgebaut
hat und ob er für GB172 geeignet ist.
Vielen Dank im Vorraus!
Gruß
Heisenberg
Hallo,
Heisenberg schrieb:> ob er für GB172 geeignet ist.
nicht getestet, aber mit an Sicherheit grenzender Wahrscheinlichkeit -
ja ;)
In der ursprünglich geposteten Schaltung, hatte ein wenig der
Fehlerteufel zugeschlagen - deshalb im Anhang nochmal eine revidierte
Version.
//Niffko
Hallo,
erst mal ein Riesen Chapeau !! für Eure Arbeit am EMS.
Ich habe eine Logamatic 2107M und den Verdacht, dass ich noch vieles
optimieren kann.
Dazu möchte ich zuerst den Ist-Zustand loggen - idealerweise mit einem
Raspberry Pi.
Bin ich mit diesem Plan hier richtig?
Nach zwei Tagen in diesem Monsterfred bin ich verloren, deswegen als
Frage formuliert.
Weitere Fragen:
EMS basiert auf I2C?
EMS liegt auf dem Kabel zum Display/Bedieneinheit und auf der
Hauptplatine der 2107M am 12poligen Stecker, wo ihn auch das KM271
abgreift?
Das KM271 ist "nur" ein Pegelwandler EMS auf RS232 plus Anschluss für
Abgastemperatur?
An der Klinkenbuchse von RC3x wird das EMS Protokoll auf eine
Gleichspannung von 12V moduliert, um Bedieneinheiten mit Spannung und
Daten zu versorgen?
Sprechen 2107M und RC3x beide (das gleiche) EMS (Protokoll)?
Gilt alles, was in den letzten 3 Jahren um EMS erforscht wurde auch für
die 2107M?
Ich frage deswegen, weil Ingo F. am 25.2.2011, sagt: "Hat ja schon lange
nichts mehr mit der Buderus 2107 zu tun."
Den Zusammenhang zwischen Service Key, ECO-CAN und EMS erschliesst sich
mir nicht.
Das 4000er System scheint ein Vorläufer der 2107M zu sein, für mich
nicht relevant.
Nach meinem Verständnis gibt es folgende Zapfpunkte an der 2107M:
1) Rudi experimentierte im November 2009 mit einem 2107 Bedienteil, was
am 24.11.2009 zu einer Platine mit Atmel 644 führte.
Diese zapft Daten vom Flachbandkabel zum Display ab.
Was kann diese Platine, wo ist sie im Thread dokumentiert? Ich habe es
nicht gefunden.
Inwieweit ist Rudis Platine vergleichbar mit der von Michael Meyer vom
29.8.2010?
2) KM271 oder Clon
Mit Hilfe von Joachim K./himtronics und chipshuffler hat Malte
Bayer/hellraiser einen KM271 Clon entwickelt. Der auf der Platine
befindliche XPORT stört die Temperaturwerte, wird nur der 232 Zweig
bestückt, ist alles OK. Angeblich ist die Version C nicht korrekt, D
wurde nie veröffentlicht?
3) EMS Gateway mit PIC18F von Ingo F. Da ich ein Atmel-Kind bin, komme
ich da nicht weiter. @Ingo: Klasse Idee mit dem CAN Bus, bin ich auch
ein Fan von!
4) EMS UART Konverter von Rudi - wie funktioniert der?
5) EMS Reader von niffko.
Wie komme ich am besten, einfachsten, sichersten an die Daten der 2107M
und zu einer Langzeit Protokollierung und Darstellung?
Gerne trage ich was zum Projekt bei, ich kann:
Layouten mit Eagle 5
Platinen doppelseitig herstellen
Platinen bestücken - am liebsten bedrahtet, nach 'nem Bier geht auch SMD
0,85 Pitch :-)
Atmels programmieren/compilieren/flashen
Und demnächst auch Raspberrien...
Was ist auf Dauer sinnvoll?
2107M behalten oder ersetzen?
Durch was?
Sind andere Steuerungen so viel besser, dass der Austausch sich absehbar
amortisiert?
Ich wünsche Euch allen einen guten Start in 2013!
PS: Ich unterstütze den Vorschlag von Malte Bayer/hellraiser vom
17.8.2010 diesen Thread in einen neuen zu überführen!
Vielleicht können die Antworten auf meine Fragen als abschliessende
Zusammenfassung dienen... :-)
Erstmal allen ein Frohes neues Jahr 2013.
Jörg Hermann schrieb:> Ich habe eine Logamatic 2107M und den Verdacht, dass ich noch vieles> optimieren kann.> Dazu möchte ich zuerst den Ist-Zustand loggen - idealerweise mit einem> Raspberry Pi.> Bin ich mit diesem Plan hier richtig?
Ja.
> Nach zwei Tagen in diesem Monsterfred bin ich verloren, deswegen als> Frage formuliert.>> Weitere Fragen:> EMS basiert auf I2C?
Nein. Es ist eine Strom-/Spannungsschnittstelle die die Daten mehr oder
weniger in einem UART kompatiblen Format überträgt.
> EMS liegt auf dem Kabel zum Display/Bedieneinheit und auf der> Hauptplatine der 2107M am 12poligen Stecker, wo ihn auch das KM271> abgreift?
Ja, aber bei der 2107M wird wohl ECO-CAN gesprochen, nicht EMS.
> Das KM271 ist "nur" ein Pegelwandler EMS auf RS232 plus Anschluss für> Abgastemperatur?
Ja, wobei der Interface nur eingeschaltet wird wenn ein Abgassensor
vorhanden ist.
> An der Klinkenbuchse von RC3x wird das EMS Protokoll auf eine> Gleichspannung von 12V moduliert, um Bedieneinheiten mit Spannung und> Daten zu versorgen?
Nein. 12V/GND/Daten, diese 3 Leitungen gibt es dort.
> Sprechen 2107M und RC3x beide (das gleiche) EMS (Protokoll)?
Nein, siehe oben (ECO-CAN?).
> Gilt alles, was in den letzten 3 Jahren um EMS erforscht wurde auch für> die 2107M?
Nein.
> Ich frage deswegen, weil Ingo F. am 25.2.2011, sagt: "Hat ja schon lange> nichts mehr mit der Buderus 2107 zu tun."> Den Zusammenhang zwischen Service Key, ECO-CAN und EMS erschliesst sich> mir nicht.> Das 4000er System scheint ein Vorläufer der 2107M zu sein, für mich> nicht relevant.>> Nach meinem Verständnis gibt es folgende Zapfpunkte an der 2107M:>> 1) Rudi experimentierte im November 2009 mit einem 2107 Bedienteil, was> am 24.11.2009 zu einer Platine mit Atmel 644 führte.> Diese zapft Daten vom Flachbandkabel zum Display ab.
Auf dem Kabel gibt es Adressleitungen und eine Messleitung. Die
eigentlichen "Messwerte" werden in eine Frequenz konvertiert und von mir
nur gemessen.
> Was kann diese Platine, wo ist sie im Thread dokumentiert? Ich habe es> nicht gefunden.
Garnicht.
> Inwieweit ist Rudis Platine vergleichbar mit der von Michael Meyer vom> 29.8.2010?
???
> 2) KM271 oder Clon> Mit Hilfe von Joachim K./himtronics und chipshuffler hat Malte> Bayer/hellraiser einen KM271 Clon entwickelt. Der auf der Platine> befindliche XPORT stört die Temperaturwerte, wird nur der 232 Zweig> bestückt, ist alles OK. Angeblich ist die Version C nicht korrekt, D> wurde nie veröffentlicht?
...
> 3) EMS Gateway mit PIC18F von Ingo F. Da ich ein Atmel-Kind bin, komme> ich da nicht weiter. @Ingo: Klasse Idee mit dem CAN Bus, bin ich auch> ein Fan von!>> 4) EMS UART Konverter von Rudi - wie funktioniert der?
Der Empfangsteil arbeitet mit einem Komparator der ohne viel
Analogelektronik auskommt.
>> 5) EMS Reader von niffko.
Wurde aus der original Hardware extrahiert.
> Wie komme ich am besten, einfachsten, sichersten an die Daten der 2107M> und zu einer Langzeit Protokollierung und Darstellung?
Ich würde es an der KM271 Schnittstelle probieren. Das Problem was ich
sehe ist der Abgassensor, k.A. wie diese Werte dann in die
Heizungsregelung eingreifen. Aus diesem Grund bin ich auch einen anderen
Weg gegangen.
Grüße.
Hallo,
Habe meine Buderus Gasterme mal vor ein paar Tagen einen Druckabfall da
kleines Leck (muss den Installateur noch her rufen da neue Installation
- 6 Monate) aber der Punkt nachdem ich alles in Ordung gebracht habe
(ohne neustart) ist:
Das Display zeight Fehler: "OY" wenn ich den "Schraub Schluessel" Knopf
ein paar mal druecke. Aber alles laeuft wieder normal und wenn Flamme da
ist habe ich "-H" wie gehabt (anstelle "OY") aber nur solange Flamme da
ist.
Erste Frage: Ist "OY" jetzt nur im "Fehler Speicher" ?
(Ich denke sonst waere die Terme ja nicht in betrieb)
List der Fehler unter:
http://www.buderus.de/sixcms/media.php/1156/05492_KUP_BUD_EMS_Handbuch_L.121878.pdf
Denn:
Ich habe folgendes telegram:
080018003802CF641C09012560800001B9029D00E40F2D4800_C8_00200F000
C8 ist doch alles OK.
Dann habe ich geforscht (in dem Dokument) und "OY" ist entweder 276 dec
oder 277 dec, also 0114 oder 0115 hex und habe danach in meinen
Telegrammen gesucht und nur hier vom RC35 gefunden:
Mon Jan 7 19:30:35 UTC 2013 : 100006000D_0114_07243700003100
Kann es sein dass der RC35 den Fehler auch gespeichert hat?
Bevor der Service Man die Terme resetted gibt es hier wohl
Gelegenheitsmoeglichkeiten ...
Irgend jemand der das nachvollziehen kann?
(Oder rede ich als Englaender nur exentrisches Zeug)
Edward
Nachtrag: Wenn der Brenner nicht Laeuft habe ich:
0800180038022A640001010060800001B7022300000D305900_CC_0000000C00
CC = 204 dec
Im Doku:
BetriebsCode "0Y" 204 Die aktuelle Kes-sel wasser tempera-tur ist höher
als
die Sollkessel was-ser temperatur.
Die aktuelle Kesselwasser-temperatur ist höher als die
Soll kessel wasser tempe ra-tur. Der Kessel wird abge-schaltet.
"Keine Massnahme"
Also kein Fehler?
Hallo Edwart,
Edward Cardew schrieb:> Also kein Fehler?
Nein, kein Fehler ... alles in Ordnung. Dieses 0Y-204 ist vollkommen
harmlos und ein normaler Bertiebszustand.
//Niffko
Hi Niffko,
Ich denk auch, alles OK.
Noch ne Frage da ich gerade Telegramme decodiere ... ist der Code nur
ein byte oder die 00 davor noch dazu? Die dokus hier in den Excel
dateien sind "not obvious" ;-)
Ed
Edward Cardew schrieb:> ist der Code nur> ein byte oder die 00 davor noch dazu?
Gegenfrage: Wie willst du z.B. 276 oder 277 mit einem Byte darstellen ;)
Edward Cardew schrieb:> Dann habe ich geforscht (in dem Dokument) und "OY" ist entweder 276 dec> oder 277 dec
//Niffko
PS: @all ... nur für die Akten - mein Post vor diesem war der 1000ste.
Glöckwoooonsch an alle Beteiligten :))
Niffko schrieb:> PS: @all ... nur für die Akten - mein Post vor diesem war der 1000ste.> Glöckwoooonsch an alle Beteiligten :))
:-)
Edward Cardew schrieb:> Noch ne Frage da ich gerade Telegramme decodiere ... ist der Code nur> ein byte oder die 00 davor noch dazu? Die dokus hier in den Excel> dateien sind "not obvious" ;-)
failure: 2 bytes (ASCII your favorite encoding ;-))
error code: 2 bytes
...
Gibt es ausser die Excel files oben im Thread no signifikante
Forschritte bei dem Mapping von den Telegram Codes?
Bei mir huscht so vieles durch den Parser durch und am anderen Ende raus
... ;-)
Ed
Edward Cardew schrieb:> Gibt es ausser die Excel files oben im Thread no signifikante> Forschritte bei dem Mapping von den Telegram Codes?> Bei mir huscht so vieles durch den Parser durch und am anderen Ende raus
Was genau? Die Wochenzeitschaltung z.B. wurde hier nur im Ansatz
geklärt.
Niffko schrieb:> Mögliche Optionen:> - Steuerkabel der Pumpe abziehen, dann läuft sie Volllast> - Steuersignal(PWM) der Pumpe hacken und Pumpe mit eigener Hardware> ansteuern
Nochmal danke für den Tipp :-). Z.Z. läuft Methode 1. gesteuert, werde
aber die Methode 2. umsetzen um bei einer Teilrücklaufanhebung (Mischer
mischt und Brenner läuft) etwas besser Steuern zu können. Wenn nur der
Mischer läuft ist es auch etwas suboptimal immer von 55% auf 100% zu
springen.
Wenn ich fertig bin habe ich mir eine zweite Heizung gebaut ... man man.
Grüße.
Hallo Jungs,
Ist dieses Thema noch aktuell?
Ich versuche auch aktuell unseren GB162 anzuzapfen.
Wir haben hier ein RC35 im Wohnzimmer.
Da ich aktuell sehr viel mit den RFM70 Modulen arbeite, war meine Idee:
Ein Atmega8 mit einem MAX232N dran hängen, die Daten vom EMS über das
RFM70 Modul in unseren Hausbus einzuspeisen.
Bin aktuell mit dem Schaltplan beschäftigt, die Grundschaltung mit
Max232n und RFM70 steht bereits... nun die Frage:
Die RFM70 Module arbeiten mit 3,3V die Digital Input Pins kann ich mit
Max 5.25V beschalten, also könnte ich den Atmega8 mit +5V laufen lassen,
die RFM kriegt dann Ihre 3,3V und hat keine Probleme mehr.
Nun die frage, gibt es einen aktuellen Schaltplan?
Prinzipiel kann ich ja EMS+ und EMS- direkt an die Eingänge vom MAX232N
hängen und die Ausgänge an den Atmega8?
Grüße,
Daniel
Den GB162 habe ich auch. Den habe ich einfach am 3.5mm Klinke abgehorcht
(Service Buchse hinter scharzen Kappe am Front Pannel). Da sind wie oben
irgenwo :-) erwaehnt 12 Volt, Gnd und Signal. Mit einem Transistor auf
nen Optokoppler laeuft bei mir seit 6 Monate ohne Probleme. Eingriff ins
Geraet fuer EMS + und - nicht noetig. Auch Max232 entfaellt und der
ATmega Seriel Eingang kann direct an den Opto Ausgang. Aufpassen muss
man nur bein reinstecken des Klinken steckers wegen der +12V? Einmal hat
es mein Brenner resetet und seitdem mache ich Strom aus bevor ich den
rein mache oder raus ziehe. Die info hier im Thread ist gut und viel,
doch weit verstreut ...
Ed
Hallo Leute,
ich habe mir hier ein Setup aufgebaut, um meine Buderus Heizung per EMS
auszulesen. Ziel der Sache ist es eigentlich die Tag/Nachtschaltung
umzuschalten und somit das vorhandene RC25 zu "emulieren". Die
Bedieneinheit soll natürlich weiterhin bleiben. Ich habe hier das
Ethersex Modul von maniac103 am laufen. Damit habe ich nun mal ne halbe
Stunde oder so mitgeloggt und eine Statistik erstellt. Weiterhin habe
ich etwas in der Übertragung rumgestochert und folgendes
"herausgefunden":
Sonne drücken: AA 55 06 17 08 35 00 11 11 2A
Mond drücken: AA 55 06 17 08 35 00 01 01 2A
Ansonsten war das Langzeitlog im Sonnemodus und der Referenzraum hatte
21.4 - 21.9°C soweit ich das überblicken konnte.
Nun meine frage: Wie kann ich auf den Bus senden? Mit einem
Logikanalyzer an der Interfaceplatine mit dem Komparator komme ich nicht
wirklich weiter weil ich nur 32k Ram habe... Muss ich das ganze noch
einmal bauen um auf dem Bus zu sniffen? Oder könnt ihr mir weiterhelfen?
LG Floppy
SysRun schrieb:> Hier übrigens "meine" Werte: https://cosm.com/feeds/87491 :)
Hast du mal über eine Nachtabsenkung von ein paar Grad nachgedacht? Eine
VL-Temp von 63.8°C bei AT 1°C ist meiner Meinung etwas zuviel des Guten,
die Heizung kann doch die Pumpe hochmodulieren und dann geht es auch mit
etwas weniger Heizleistung. Wie sieht denn dein RL-Temp. aus?
Grüße.
Hallo!
Ich würde gerne die Heizung in OpenHab einbinden
(http://code.google.com/p/openhab/). Hat jemand Interesse, an einem
Interface (für Rasberry PI) und an dem nötigen Binding für OpenHab
mitzumachen?
vg
Jürgen
Hallo,
ich habe das PIC Gateway von Ingo und nutze ein Python Script um die raw
Daten auszulesen.
Von Zeit zu Zeit habe ich falsche Werte in meiner DB so das ich gerne
die CRC checken würde.
Habe hier auch die beiden Python Beispiele von Rudi gefunden, die bei
mir so nicht laufen.
Das Format müsste ja so aussehen:
0xaa 0x55 <ems data> <ems checksum> <0x00=brk> <length between markers>
0xaa 0x55
Wenn ich versuche die CRC berechnung über die <ems data> zumachen
bekomme ich folgende Fehlermeldung:
Hallo,
Die Prüfsumme wird nur aus den EMS-Daten berechnet. Wenn ich deinen
Quelltext richtig verstanden habe nimmst du alle Daten von Index 0
bis-1.
Gruß
Ingof
Sorry,
auf dem Handy hatte ich wohl nicht alles richtig sehen können.
Also der Bereich ist ja wohl doch der richtige.
Ich würde jetzt einfach mal sagen dass dort irgendwelche Zeichen in HEX
oder DEZ umgewandelt werden sollen die nicht als Eingabe akzeptiert
werden.
Bei der ersten Fehlermeldung würde "\x08" dem Backspace entsprechen und
beim zweiten Fehler kann er das Ausrufezeichen nicht in eine Zahl
umwandeln.
Vermute in A[i] ist ein fehlerhaftes Zeichen.
Aber diese Konvertierung benötigst Du doch nicht, oder?
Wenn die zeichen als RAW ankommen sind es keine ASCII-Zeichen die mit
INT(a[i],16) umgewandelt werden müssen.
statt INT(a[i],16 dann einfach a[i] nehmen.
Kenne zwar kein Phyton, aber sieht genauso wie JAVA aus...
Gruß
IngoF
Hi Rudi,
danke für den Link,
hatte mich verlesen, der mit dem Pi war sysrun,
ich hätte auch Interesse an einer Anbindung an Openhab, wie jschmied.
Gruss
Norbert
Hallo!
Ich bringe dem EMS-GW im Moment TCP/IP und JSON bei. Damit dürfte sich
auch die OpenHAB Anbindung einfach ohne ein spezielles Binding
realisieren lassen.
Ob ich mir noch einen OpenHAB Server hinstelle, wenn das GW alles selbst
macht (incl. WebGUI und Logs schreiben) weiß ich noch nicht. ;)
vg
Jürgen
Hallo!
Mit ein paar Web-Seiten ohne JSON bin ich bei 31K ROM und 1366 RAM. Der
PIC18F4580 hat 32 KB ROM. Ohne Webseiten würde das JSON Interface
warscheinlich reinpassen. Es wäre (zumindest für mich) aber einfacher
den PIC zu wechseln, als X Versionen der Firmware zu pflegen. In die
96KB des PIC18F4685 passt alles rein.
Ich habe ein Board (wg. Blitzschaden) bereits umgebaut, den PIC zu
wechseln geht schnell. Ich habe den alten mit einem Dremel weggefräßt,
um das Board nicht zu beschädigen ;). Dann kann man die Reste der
Beinchen einzeln auslöten.
vg
Jürgen
Du kannst bist auf die index.html alles auf einem Webserver auslagern.
Dann fragst du nur direkt die Werte ab und die restlichen Seiten änderst
du auf dem Webserver.
Hallo!
Ja, man kann alles auf einen externen Websserver packen und das GW nur
JSON sprechen lassen. Da muss dann jeder für sich einen Webserver
einrichten und die URL auf das GW konfigurieren.
Nachteil:
Es ist dann ein extra Gerät oder Webspace im Internet nötig
Vorteil:
Man kann leicht erweitern, andere Geräte einbinden, Design ändern,
Grafik einbinden usw.
vg
Jürgen
Hallo,
an alle die einen EMS-Gateway oder eine andere Hardware für den EMS-Bus
haben:
Es gibt jetzt eine Wiki zum EMS-Gateway (nicht Logamatic 2107):
http://ems-gateway.myds.me:8001/dokuwiki/
Es kann so gut wie alles gelesen werden.
Nur zum lesen einiger Bereiche (Telegramme des EMS-Bus) wird eine
Registrierung benötigt.
Um Mithilfe bei der Entschlüsselung der EMS-Telegramme wird gebeten.
Da in diesem Thread auch der EMS-Gateway entstanden ist poste ich es
auch hier...
Gruß
IngoF
Ingo F. schrieb:> Es gibt jetzt eine Wiki zum EMS-Gateway (nicht Logamatic 2107):> http://ems-gateway.myds.me:8001/dokuwiki/>> Es kann so gut wie alles gelesen werden.> Nur zum lesen einiger Bereiche (Telegramme des EMS-Bus) wird eine> Registrierung benötigt.>> Um Mithilfe bei der Entschlüsselung der EMS-Telegramme wird gebeten.
Vielleicht bin ich einfach zu blind, aber: Wie meldet man sich an? Eine
Registrierungsseite habe ich nicht gefunden...
(Davon mal abgesehen: Warum der Registrierungszwang für die
EMS-Telegramme?)
Danny Baumann schrieb:> aber: Wie meldet man sich an?
Ganz einfach... oben rechts auf registrieren ;-)
Aber lag nicht daran dass Du blind warst.. Habe wohl zuviel an der
Konfiguration herumgespielt. Und schwups war die Registrierung futsch...
Gruß
Ingo
So der Winter naht wieder... und ich habe dass Geraffel wieder hervor
geholt. Nach längerem durchforsten der EMS Protocol Plugin Codes von
Ethersex habe ich es nun auf einem ATMega 644P (wieder) laufen.
Dazu musste in der ems_uart.h folgendes hinzugefügt werden:
#define PORTEMS_UART_TX_PORT PORTD
#define EMS_UART_TX_PIN PIND
#define DDREMS_UART_TX_PORT DDRD
Nun haut das Netio auch per TCP/IP die Daten raus. Mit Wireshark habe
ich mal reingeschaut, wobei man ja nicht all zu viel sieht. Wie wertet
ihr die Daten aus? (Ich hatte ja mal was laufen, kann mich aber zum
Teufel nicht mehr erninnern wie/was).
Weiterhin gibt http://192.168.0.90/ecmd?ems%20stats folgendes aus:
Bytes total:37301
Bytes good:528
Bytes dropped:0
Packets good:83
Packets bad:1959
Packets 1byte:25524 501
Packets ack:0 nack:0
Overflow:0
Max fill:2
Könnt Ihr mir weiterhelfen?
LG Floppy
Tante Edit:
So, habe noch Realterm probiert und inerhalb von so ca. 5 Minuten
folgendes mitgelogt:
AA 55 05 08 13 05 22 00 3C
AA 55 06 17 08 35 00 11 11 2A
AA 55 08 17 08 1A 00 00 00 00 00 05
AA 55 05 17 00 AD 03 01 B8
AA 55 02 17 FC EB
AA 55 05 08 13 05 22 00 3C
AA 55 05 08 13 05 22 00 3C
AA 55 06 17 08 35 00 11 11 2A
AA 55 08 17 08 1A 00 00 00 00 00 05
AA 55 05 08 13 05 22 00 3C
AA 55 05 08 13 05 22 00 3C
AA 55 15 08 00 34 00 28 00 D6 80 00 80 00 04 01 00 00 15 BC 00 30 B7 00
E9
AA 55 02 17 FC EB
AA 55 05 08 13 05 22 00 3C
AA 55 15 08 00 34 00 28 00 D4 80 00 80 00 04 01 00 00 15 BC 00 30 B7 00
EB
Such mal in meinen Postings in diesem Thread nach ems-collector ... das
ist die Gegenseite dazu, die die von ethersex gelieferten Daten
auswerten und in eine mysql-Datenbank schreiben kann.
Hallo,
ja daran habe ich mich auch schon versucht. Das ganze habe ich nach ein
paar installierten Dev-Libs auf einer Debian Kiste kompiliert bekommen.
Nun klemmts am Aufruf... Mysql Username und Datenbank sind erstellt,
aber ich bekomme weiterhin fehlermeldungen dass das Device nicht gültig
ist. gibt es hiezu Doku? Bis auf die kleine Help Ausgabe habe ich im
Dunkeln gestochert und mich an Fehlermeldungen entlang gehangelt.
./collectord -u ems -p xxx -d5 -f 192.168.0.90
Exception: Target 192.168.0.90 is invalid.
LG
./collectord -u ems -p pass -d all -f tcp:192.168.0.90:7100 sollte
funktionieren (evtl. must du den Port anpassen). Dass die Hilfe für das
Target nicht angezeigt wird, ist eine Limitierung in
boost::program_options (oder meiner Unfähigkeit geschuldet, das Zeug
richtig zu benutzen).
Nun kommt was :) Danke schonmal
./collectord -u ems -p ems -d all -f tcp:192.168.0.90:7950
IO: Got bytes 0xaa 0x55 0x5 0x8 0x13 0x5 0x22 00 0x3c
MESSAGE[14.09.2013 09:58:39]: source 0x08, dest 0x13, type 0x05, data
0x22 0x00
DATA: Unhandled message received(source 0x08, type 0x05).
IO: Got bytes 0xaa 0x55 0x2 0xb8 0xfe 0x46
MESSAGE[14.09.2013 09:58:41]: source 0x00, dest 0x00, type 0x00, data
0xb8 0xfe
IO: Got bytes 0xaa 0x55 0x5 0x8 0x13 0x5 0x22 00 0x3c
MESSAGE[14.09.2013 09:58:59]: source 0x08, dest 0x13, type 0x05, data
0x22 0x00
DATA: Unhandled message received(source 0x08, type 0x05).
Nun müsste man nur noch was damit anfangen können. Wie kann ich nun
aktiv eingreifen? Ich will im endefekt von Tag auf Nacht umschalten
können. Wie stelle ich das Webinterface ein dass es daten anzeigt?
LG
Tante Edit:
so die Website liefert ein Bild nachdem ich username/password angepasst
habe (in sensor_utils.php.inc), wobei mit total wirren Informationen...
da passt garnichts
Tag/Nacht umstellen sollte damit gehen:
telnet localhost 7777
hk1 mode night (oder hk2 mode auto, oder...)
Die Webseite ist mehr oder weniger ein Quick Hack, da musst du im
Zweifelsfall mal etwas frickeln. Stimmen denn die Werte in der
Log-Ausgabe und/oder der Datenbank?
Ich habe mal bis hk4 durchprobiert... kommt immer ERRTIMEOUT :(
Die datenbank füllt sich auch kaum... kann es sein dass ich irgendwo
zuordnungstabellen anpassen muss? Es ist halt leider ein RC25 und kein
RC35 Panel.
Bei ERRTIMEOUT hat sich die RC nicht angesprochen gefühlt ... bei den
Unterschieden zwischen RC25, RC30 und RC35 bin ich allerdings überfragt.
Selbst habe ich ein RC30, damit funktioniert es.
Zwei Dinge kommen mir aber komisch vor: der Bus-Slave 0x17 (ist das die
RC25?) und die sehr hohe Anzahl an Bad packets, d.h. CRC-Fehlern.
Letzteres deutet darauf hin, dass an der Schaltung noch etwas nicht in
Ordnung ist. Bei mir ist das Verhältnis good-bad z.B. im Moment
817000-24.
Hmmmm okay.... aber die Kesselsolltemperatur stimmt schonmal. 40°C sind
an der Heizung eingestellt (durchlauferhitzer).
Wie komme ich dem ganzen am besten bei? So etwas zu Debuggen ist ja
nicht gerade trivial.
So, ich war noch ein paar Daten sammeln ;)
Heizung: Buderus U154-20k
Bedieneinheit: RC25
Daten in dem RC25:
P1 -> 0 (Master ohne weitere Programmiergeräte)
P2 -> 1 (Roomflow Mode / Regelkreis auf die Durchflussrate)
P3 -> 0.0°C (Raumkalibrierung)
P4 -> 1 (DHW Heating True)
P5 -> 1 (Internal Boiler Pump)
P6 -> 5 (Nachlaufzeit Boiler Pump)
P8 -> 0 (Time Adjustment)
P9 -> 0 (No thermal disinfection)
P10-> 401 (Software Version)
P13-> 75°C (Maximum Flow Temperature)
Vllt. hilfts ;) Mensch wär ich happy wenn ich irgendwie die f**k Heizung
per TCP/IP ein/aus schalten kann. Geht sowas überhaupt? Es kann ja auch
sein dass der RC25 als 2-Punkt Regler funktioniert und nur Brenner
ein/aus Kommandos gibt. Somit wäre die komplette Steuerung in dem RC25
und der Zustand Auto/Sonne/Mond kommt nie über den Bus und ist somit
auch nicht beeinflussbar... (ANGST :p)
Da das Modul nicht mir ist (Mietshaus) würde ich Ungern direkt auf die
Taster gehen (wobei ich immer mehr dazu tendiere).
LG :)
Das kennst Du?
http://www.buderusdaten.ch/webseite/joomla/index.php?option=com_remository&Itemid=38&func=fileinfo&id=1814
Auf alle Fälle muss die RC25 dem UBA (Brenner) regelmäßig bestimmte
Pakete senden, ansonsten schaltet sich die Heizung nach einer Weile ab.
Da die UBA bestimmt nur ein Protokoll spricht, sind es bestimmt die
gleichen Pakete wie auch die RC35 senden würde.
Hat jemand mit einem EMS-GW einen RC25 als Master und kann einen
Busmitschitt machen? Am besten incl. Boot-Sequenz dre Anlage.
vg
Jürgen
Ja das Dokument hab ich in Englisch per Google gefunden ;) Aber deutsch
ist mir auch lieber.
Also muss ich nun als nächstes erst mal das bad/good Verhältniss
aufpeppeln? Nur wie? Ich flashe gleich mal eine erweiterte Debug
Software in das NetIO. Werde dann auch gleich mal den Schaltplan des
Adapter-Moduls heraussuchen und hochladen.
Tante Edit:
So nun mit Schaltplan. das Adapterkabel schaut wie folgt aus:
EMS Board - EXT Netio
1 (VCC) - 10 (5V)
2 (RX Out)- 1 (PD2)
3 (TX in) - 2 (PD3)
4 (U Ref) - NC
5 (GND) - 9 (GND)
Hallo!
Prüfe mal die Taktfrequenz des Mikrocontrollers und die Baudrate der
UART. Ein Fehler dort bring alles durcheinander.
Kritisch sind eigentlich nur C3/R4, da deren Zeitkonstanate nahe an der
Baudrate ist, wirken sich Änderungen der Teile direkt auf die
Tastverhältnisse an der UART aus.
Der + des OPV müsse ca. 0,6 V haben, der - ungefähr 0,05 V weniger.
Ansonsten ist an der Schaltung nicht viel falsch zu machen ...
vg
Jürgen
Ra Sp schrieb:> Heizung: Buderus U154-20k
Der U154 ist, wenn man's genau nimmt, mehr Junkers als Buderus
(Bosch-Synergieeffekt). Die Steuerplatine wird auch nicht als UBA
bezeichnet. Kann was bedeuten, muss aber nicht. Auf jeden Fall könnte es
Unterschiede geben.
//Niffko
Ra Sp schrieb:> [U_REF]> Ja ist herausgeführt um evtl. mal zu erkennen ob der Bus angeschlossen> ist.
[ironie]
Achso ... dafür sind die ~0,6V natürlich geradezu ideal.
[/ironie]
... nicht bös' gemeint ;)
//Niffko
niffko schrieb:> [ironie]> Achso ... dafür sind die ~0,6V natürlich geradezu ideal.> [/ironie]
Tjoa... um ganze Bytefolgen zu übertragen reichts ja wohl.... dann werde
ich wohl auch ein Bit heraus bekommen. Wo ein Wille da ein Gebüsch oder
so :p
Wenns denn nötig wäre könnte man auf einen ADC Eingang gehen (für was
anderes sind die AVR ADCs eh nicht zu gebrauchen)
LG
Es gibt Neues... Auch wenn es nur ein Bild ist :p
Messaufbau:
Grün: EMS - High side
Gelb: RX Out der Adapterplatine
Masse hole ich am Steckverbinder NetIO-Adapterplatine
Nur woher kommen die Drifts? Denke das sind meine
Kommunikationsprobleme.
Nein, das ist völlig normal.
Wenn man sendet wird nur das kleine Signal auf dem Bus erzeugt. Dannach
wird das gesendete Byte vom Busmaster (0x08) widerholt. Erst dannach
kann das nächste Byte gesndet werden.
Also nach jedem gesendeten Byte mindestens ein Byte abwarten..
Bild 2 ist also voll OK.
Nur das erste Bild sieht seltsam aus. Ist das bei jedem Sendeversuch so?
Gruß
Ingo
IngoF schrieb:> Nein, das ist völlig normal.
war vermutlich zu schnell beim lesen und schreiben....
Es ging um den Drift in Bild1 oder? Das sihet nicht so gut aus.
Ist das schon auf dem Bus wenn Deine paltine nicht angeschlossen ist?
Gruß
IngoF
Hmm... die Datenübertragung ohne NetIO schaut gut aus. Diese Ausläufer
treten ohne Platine nicht mehr auf. Ob ich das Notebook beim Messen
einstecke oder nicht ändert daran wohl nichts. Nun ist die Frage wo ich
sonst die Masseschleife her bekomme (ich gehe nun einfach mal davon
aus). Evtl übers Ethernet?! Probiere ich gleich noch einmal aus.
So, hole ich mir nun die Masse vom Bus, driftet das gelbe Logiksignal
umher. Zwischen beiden Massen liegt ja eigentl. nur eine Diode. Klemme
ich Ethernet ab, sind die Drifts weg.Nun kann ich leider die Sache nicht
mehr debuggen.
Tante Edit:
Der RS232 Ausgabe entnehme ich dass es wohl geht.
Die CRC stimmt mit der berechneten über ein.. Ich bekomme im
Sekundentakt Meldungen folgender Art:
D: ems: No client connected, dropping 5 bytes
D: ems: Packet CRC a2 calc a2
Nun muss ich zusehen wie ich die Masseschleife unterbinde.
Ra Sp schrieb:> Der RS232 Ausgabe entnehme ich dass es wohl geht.> Die CRC stimmt mit der berechneten über ein.. Ich bekomme im> Sekundentakt Meldungen folgender Art:>> D: ems: No client connected, dropping 5 bytes> D: ems: Packet CRC a2 calc a2
Ja, ds sieht gut aus. Das 'dropping X bytes' passiert ja nur, weil er
die Daten nirgendwo hin weiterleiten kann.
> Nun muss ich zusehen wie ich die Masseschleife unterbinde.
Hmm. Hast du an deinem NetIO schon irgendeine Modifikation durchgeführt?
Ich musste eine ganze Menge Elkos um den ENC28J60 verteilen, damit der
langzeitstabil wurde und sich nicht nach einer Woche oder so weggehängt
hat (Anleitungen dazu findet man im Netz). Ich meine, mich dunkel
erinnern zu können (ist ja schon 1,5 Jahre her), dass ich in diesem Zuge
auch die Masse der Ethernet-Buchse des NetIO galvanisch getrennt habe:
Lotflächen für die Schirmung von der entsprechenden GND-Plane getrennt
(mit einem Cuttermesser weggeritzt) und mit einem C wieder verbunden.
Das dürfte bei dir dann wahrscheinlich auch helfen. Warum Pollin da
nicht selbst drauf gekommen ist, weiß aber kein Mensch...
So... nun geht es sogar mit Ethernet :p
Bytes total:93010
Bytes good:20370
Bytes dropped:0
Packets good:1058
Packets bad:3
Packets 1byte:71628 1377
Packets ack:0 nack:0
Overflow:0
Max fill:6
Das schaut ja soweit gut aus. Nun bleiben noch folgende Punkte offen:
1.) Tag/Nacht umschalten
2.) Tag/Nacht auslesen
3.) evtl. Raumtemperatur auslesen (eher unwichtig)
Ich versuche gleich erstmal den TX am µC aufzuzeichnen.
Kann ich direkt (per ecmd oder ähnlich) Hex-Bytes versenden?
LG
Tante Edit:
Also das hk1 mode night kommando erzeugt das zweite Bild (gelb RX, grün
bus), und dann kommen noch im x Sek Takt die Signale aus Bild 1.
Aufgrund falscher Bilder habe ich den letzten Beitrag gelöscht
Bitte beachte die Bildformate!
Und Bitmaps als JPG abzuspeichern macht kein Sinn.
Mit z.B. IrfanView hats soetwas schnell als png abgespeichert(geht sogar
auch mit MS Paint)
Uh... sorry. Nun sehe ich es auch. Das macht die billige Hantech
Software. Dort kann ich zwar zwischen JPG und BMP wählen, was aber wohl
nicht implementiert ist. Dann verwende ich ab jetzt das Snippingtool von
Windows.
Ra Sp schrieb:> Ich versuche gleich erstmal den TX am µC aufzuzeichnen.
Wenn du mal ein git pull im ems-collector machst, siehst du danach die
gesendeten Bytes direkt in dessen Debugausgabe ;)
> Kann ich direkt (per ecmd oder ähnlich) Hex-Bytes versenden?
Nein. Ich hab mir für solche Zwecke immer schnell den collector gehackt.
Es wäre aber in der Tat wahrscheinlich mal eine sinnvolle Idee.
> Also das hk1 mode night kommando erzeugt das zweite Bild (gelb RX, grün> bus), und dann kommen noch im x Sek Takt die Signale aus Bild 1.
Ich glaube, vom elektrischen Debugging kannst du jetzt weggehen. Was
sagt den die Debugausgabe von ems-collector, wie sehen die empfangenen
Pakete zu diesem Zeitpunkt (dekodiert) aus?
So,
heute erstmal den tftp-Kram vorbereitet. Morgen verfrachte ich das Teil
mal an die Heizung. Kann mir jemand Service Unterlagen geben? Finde nix
zur U154-20k
LG
So,
habe jetzt genug an der Wiki rumgefummelt.
Jetzt hat sich zum letzten mal die Adresse geändert. Der Port (:8001)
kann und muss jetzt weggelassen werden. Neue Adresse:
http://ems-gateway.myds.me/dokuwiki/
Sonst hat sich auch noch was geändert:
Unregistrierte Benutzer können jetzt auch alles lesen.
Registrierte Benutzer können jetzt per Mail bei Änderungen informiert
werden.
Gruß
IngoF
IngoF schrieb:> habe jetzt genug an der Wiki rumgefummelt.
Sieht doch gut aus ... zum Glück kann man wenigstens alles lesen.
Hat zufällig jemand ein Zeitmodul am laufen und ein Log vom EMS-Format?
Dann könnte man direkt die immer wieder falsch laufende RC
synchronisieren.
---
Die Firmware für das neue Board soll das können, sie besorgt sich per
NTP die genaue Zeit.
Ich habs noch nicht probiert, aber ich denke:
0B 10 06.00 0D 09 14 13 00 00 <CRC>
............YY.mm.hh.dd.mi.ss
sollte die Zeit auf den 13.09.2013 20:00 setzen.
PS: Wir sollten mal einen neuen Thread auf machen. Mein UMTS
Datenkontigent ist sonst mit 3 Mal hier rein gucken alle ;)
vg
Jürgen
Jürgen Schmied schrieb:> Wir sollten mal einen neuen Thread auf machen.
^^finde ich gut.
Ich lese schon lange den Thread mit. Mit meiner langsamen DSL-Verbindung
dauert es ewig das sich die Seite öffnet. Gibt es eine Möglichkeit nur
die letzten Texte zu lesen?
#############################################################
*** Bitte hier nicht mehr posten ***
... wegen Überlänge ...
Bitte hier weiter machen:
Beitrag "Faktensammlung Buderus EMS"
#############################################################
Hallo zusammen,
habe bereits das NetIo-Board zusammengelötet.
Wollte statt dem 644p den 1284p einsetzen.
Wollte mir dann das Ethersex-File für den Atmega zusammenstellen.
Allerdings kann ich das EMS-Protokoll nicht auswählen.
Bei kommt immer die Meldung "EMS not available. No free USART. (0/0)" -
egal, ob ich als CPU den 644p oder den 1284p auswähle.
Hat jemand einen Tipp, was ich falsch mache?
Vielen herzlichen Dank schon mal im Voraus!
Andreas S. schrieb:> Allerdings kann ich das EMS-Protokoll nicht auswählen.> Bei kommt immer die Meldung "EMS not available. No free USART. (0/0)" -> egal, ob ich als CPU den 644p oder den 1284p auswähle.>> Hat jemand einen Tipp, was ich falsch mache?
Ja - du brauchst einen 644PA. Das A ist entscheidend, denn nur der A hat
eine 2. UART.
Danny B. schrieb:> Andreas S. schrieb:>> Allerdings kann ich das EMS-Protokoll nicht auswählen.>> Bei kommt immer die Meldung "EMS not available. No free USART. (0/0)" ->> egal, ob ich als CPU den 644p oder den 1284p auswähle.>>>> Hat jemand einen Tipp, was ich falsch mache?>> Ja - du brauchst einen 644PA. Das A ist entscheidend, denn nur der A hat> eine 2. UART.
Ich hab nur den Atmega644 sowie 644p zur Auswahl im ethersex. Wie bringe
ich den Atmega 644pa in die Liste rein?
Andreas S. schrieb:> Danny B. schrieb:>>>> Ja - du brauchst einen 644PA. Das A ist entscheidend, denn nur der A hat>> eine 2. UART.>> Ich hab nur den Atmega644 sowie 644p zur Auswahl im ethersex. Wie bringe> ich den Atmega 644pa in die Liste rein?
Mea culpa. Ich nehme alles zurück; der 644p sollte gehen. Die 2. UART
ist der Unterschied zwischen 644 und 644p, nicht zwischen 644p und
644pa.
Bei mir geht aber die Konfugiuration auch mit dem 644p: Load a default
configuration -> NetIO, dann den 644p auswählen, dann unter Protocols ->
EMS anschalten und '1' als 'EMS USART' auswählen.
Wie genau gehst du bei der Konfiguration vor?
Danny B. schrieb:> Andreas S. schrieb:>> Danny B. schrieb:>>>>>> Ja - du brauchst einen 644PA. Das A ist entscheidend, denn nur der A hat>>> eine 2. UART.>>>> Ich hab nur den Atmega644 sowie 644p zur Auswahl im ethersex. Wie bringe>> ich den Atmega 644pa in die Liste rein?>> Mea culpa. Ich nehme alles zurück; der 644p sollte gehen. Die 2. UART> ist der Unterschied zwischen 644 und 644p, nicht zwischen 644p und> 644pa.>> Bei mir geht aber die Konfugiuration auch mit dem 644p: Load a default> configuration -> NetIO, dann den 644p auswählen, dann unter Protocols ->> EMS anschalten und '1' als 'EMS USART' auswählen.>> Wie genau gehst du bei der Konfiguration vor?
Hallo Danny,
ich habe mir unter CentOS 7 die benötigten Pakete heruntergeladen.
Anschließend habe ich das gitlab-Archiv auf meinen Rechner kopiert.
Anschließend mit make menuconfig gestartet
Dort dann Load a default configuration -> NetIO und als CPU den Atmega
644p ausgewählt.
Wollte dann unter Protocols das EMS anschalten, jedoch erhalte ich die
besagte Fehlermeldung, das kein UART frei ist.
Ich könnte mir höchstens vorstellen, das es am OS liegt (CentOS 7)
Hallo Danny,
Entwarnung, habs jetzt mal auf meinem Firmennotebook ausgeführt
(ebenfalls CentOS 7)
Hier funktionierts jetzt.
Komisch, das es dann auf meinem Werkstatt-PC nicht funktioniert hat.
Vielen herzlichen Dank für deine Unterstützung!
Konnte jetzt alle bis auf eine Einstellung von
https://emswiki.thefischer.net/doku.php?id=wiki:ems:net_io vornehmen.
Das Feld "[-] Onewire device detection support" kann ich leider nicht
auswählen. Hängt dies evtl. von einer Einstellung ab, die Standardmäßig
vielleicht ausgewählt ist?
Hast du hier für mich zufällig noch einen kleinen Tipp?
Andreas S. schrieb:> Konnte jetzt alle bis auf eine Einstellung von> https://emswiki.thefischer.net/doku.php?id=wiki:ems:net_io vornehmen.>> Das Feld "[-] Onewire device detection support" kann ich leider nicht> auswählen. Hängt dies evtl. von einer Einstellung ab, die Standardmäßig> vielleicht ausgewählt ist?>> Hast du hier für mich zufällig noch einen kleinen Tipp?
Nach langem Testen und probieren habe ich jetzt den Blockierer gefunden:
Wenn ich Debugging aktiviere "[*] Enable Debugging --->" dann kann ich
die Option auswählen.
Dieser Punkt hatte im Wiki leider gefehlt.
Hallo,
gibt es von der KM271 einen "erfolgreichen" Nachbau?
Chipshuffler hat einen Schaltplan veröffentlicht:
Beitrag "Re: Logamatic 2107 Schnittstelle"
Die RS232 Schnittstelle ist dort ja nicht das Problem.
Ansonsten würde ich mich daran machen...
Malte war hier auch aktiv, hat seine Versuche zwar in seinem Wiki
gepostet, ist leider aber nicht mehr online. Wer hier noch Daten hat
kann mir gerne zukommen lassen.
Hallo,
ich habe aus allen verfügbaren Informationen aus diesem Forum einen
Adapter entwickelt, der die Steuerung der Heizung über eine serielle
Schnittstelle ermöglicht.
Alles natürlich auf eigene Gefahr nachmachen.
Der Adapter ist simpel. 5V, GND, RX und TX stehen als Lötkontakt zur
Verfügung und können mit einem USB-Serial-Wandler verbunden werden. Ein
10k Widerstand sorgt dafür, dass das Modul erkannt wird. Es erscheint
dann der zusätzliche Menüpunkt Abgastemperatur ohne Wert im Display.
Die Seite die mit Front beschriftet ist muss zum Display zeigen. Die
Beschriftung habe ich nachträglich eingefügt, deshalb fehlt sie auf dem
Foto. Bilder und die CAM-Datei findet ihr im Anhang.
Eine dauerhafte Lösung zum Auslesen und Steuern habe ich noch nicht
entwickelt. Ich nutze einen Raspberry-Pi und die Python-Skripts vom
Nutzer Black aus folgendem Thread:
https://homematic-forum.de/forum/viewtopic.php?t=26955
Ich kann die Werte erfolgreich auslesen und auch erfolgreich Werte
setzen. Es mangelt allerdings noch an der Stabilität und eigentlich
würde ich das ganze auch mithilfe eines ESP8266 bzw. ESP32 lösen.
Es wurden doch Fertigungsdaten gepostet, mit diesen wendet man sich an
den Chinamann seines vertrauens und bekommt für wenige Euronen fertige
Platinen.
Hi,
ich hab mir die Platine erstellen lassen - war kein Hexenwerk. Ich bin
aus Zeitgründen noch nicht dazu gekommen weiter zu machen :-(
Eine Frage in die Runde: Hat sich schon jemand an die Umsetzung mittels
ESP8266 gemacht?
Ich habe mir damals zwei Platinen machen lassen und eine liegt hier noch
rum (ohne Wiederstand).
Viele Grüße
Jens K. schrieb:> Hi,> ich hab mir die Platine erstellen lassen - war kein Hexenwerk. Ich bin> aus Zeitgründen noch nicht dazu gekommen weiter zu machen :-(> Eine Frage in die Runde: Hat sich schon jemand an die Umsetzung mittels> ESP8266 gemacht?>> Ich habe mir damals zwei Platinen machen lassen und eine liegt hier noch> rum (ohne Wiederstand).>> Viele Grüße
Hallo Jens,
nach was muss ich googlen zum Erstellen der Platinen?
Bisher scheitere ich daran, die Daten aus dem ZIP bei gängigen
Platinenherstellern einlesen zu lassen.
Also wie finde ich den ChinaMann?
Gruß
Ingo
Hallo Jens. Weil nach 20 Jahren das Display streikt (s. Bild), bin ich
via Google hier gelandet - weil ich die Systemzeit nicht mehr einstellen
bzw. ablesen kann. Wie du beschreibst, kannst du erfolgreich Werte
schreiben. Hast du evtl. herausgefunden, ob/wie man die Systemzeit über
die Schnittstelle setzen kann?
Ich habe mir die Platine hier bestellt:
https://bbqkees-electronics.nl/?lang=de
Preis finde ich ok - es gibt sogar ein komplettpaket mit ESP8266 und der
EMS-ESP software
Nutze die jetzt seit monaten zusammen mit einem ESP8266 und MQTT
Moin,
hat schon jemand eine Lösung um die Raumtemperatur via Funk (WLAN) zur
Heizungsanlage bzw. RC300 zu transportieren? Ggf. via zwei ESP8266 als
Kabelersatz?
Folgendes Problem: ich kann kein Kabel verlegen, möchte aber neben der
Außentemperaturregelung auch die Raumtemperatur als Regelgröße nutzen.
Grüße
Peter
Hallo und Frage an die Spezialisten:
Im Schaltplan der 2107 gibt es einen Anschluss 230V Signal Brenner:
Betrieb BR 8/B4 und Störung BR 9/S3 sowie 4/N (Nulleiter). Kann ich dort
parallel ein 230V monostabiles Relais(Finder 13.31.8.230.4300) zum
potentialfreien Schalten eines WIFI Aktors (Sonoff MiniR2) anschließen,
der mir dann eine Pushnachricht in die App schickt. Das funktioniert
(getestet) am heimischen Bewegungsmelder. Bin aber unsicher, ob das BR
Signal genug Leistung zum Schalten des Relais bringt. Im Schaltplan wird
an der Stelle Brenneranschluß Stufe 1 max.8A angegeben, was vielleicht
reichen dürfte??
Hallo,
ich weiß, der Thread ist ein wenig älter, aber ich habe noch eine
Logamatic, die ich noch eine Zeit lang betreiben muss und brauche
dringend den Zugang über die serielle Schnittstelle, weil mein Brenner
häufig auf Störung geht (Flammwächter spinnt manchmal) und ich nicht
jede Woche kalt duschen möchte. Deswegen habe ich mir ein paar aus
diesem Thread zusammengesucht und die KM217 mit WiFi/Bluetooth-Anbindung
nachentwickelt und werde diese in den nächsten Wochen auch mit ESPhome
und Home Assistant realisieren.
Genauere Infos gibt es hier:
https://the78mole.de/reverse-engineering-the-buderus-km217/
Wer ebenfalls eine haben möchte, kann mich gerne kontaktieren. Ich werde
ein paar PCBs mehr bestellen und zum Selbstkostenpreis (ich schätze ca.
2-3 € pro PCB) abgeben.
Grüße,
Daniel
Fred G. schrieb:> Ich habe mir die Platine hier bestellt:> https://bbqkees-electronics.nl/?lang=de>> Preis finde ich ok - es gibt sogar ein komplettpaket mit ESP8266 und der> EMS-ESP software>> Nutze die jetzt seit monaten zusammen mit einem ESP8266 und MQTT
Ich hab mich grad auf der Seite umgesehen, das ist echt interessant und
ich würde mir das Modul mit WLAN gern zulegen. Wie krieg ich raus, ob
meine Steuerung damit kompatibel ist, sprich diese Bus-Schnittstelle
hat? Weiß jemand von euch das anhand des Fotos?
Gruß - Markus
Hallo Marcus,
eigentlich solltest Du im Beitrag auf meinem Blog sehr schön die
Schnittstelle erkennen, die es für das KM217 benötigt (siehe auch Bild
anbei). Der andere Anschluss sieht zwar identisch aus, aber da ist 1.
nicht genug Platz und 2. weiß ich nicht, ob die Belegung die Gleiche
ist.
Auf Deinem Bild ist die Schnittstelle auch zu erkennen, aber ob das die
gleichen Abmessungen und die gleiche Belegung hat, weiß ich natürlich
nicht.
Grüße,
Daniel
Daniel G. schrieb:> Hallo Marcus,>> eigentlich solltest Du im Beitrag auf meinem Blog sehr schön die> Schnittstelle erkennen, die es für das KM217 benötigt (siehe auch Bild> anbei). Der andere Anschluss sieht zwar identisch aus, aber da ist 1.> nicht genug Platz und 2. weiß ich nicht, ob die Belegung die Gleiche> ist.>> Auf Deinem Bild ist die Schnittstelle auch zu erkennen, aber ob das die> gleichen Abmessungen und die gleiche Belegung hat, weiß ich natürlich> nicht.>> Grüße,> Daniel
Hallo Daniel,
vielen Dank dir für die Erläuterung. Ich dachte, dass ich mit der
fertigen Lösung von dem Online Shop eventuell auch arbeiten könnte. Aber
da ich die Schnittstelle nicht habe, brauche ich deine Lösung um Zugriff
auf die Daten zu bekommen, soweit ist mir das jetzt klar 👍
Ich hatte dir auch schon eine Email geschrieben, dass ich Interesse an
der Platine von dir habe. Ich nehm auf jeden Fall eine!
Gruß - Markus
Hi Daniel,
perfekt! Meld dich einfach wenn du die Platinen hast dann können wir uns
wegen Versand und Zahlung austauschen.
Hab nur den EPS32 lagernd 😉 hab bisher maximal SMD 0805 gelötet. Die
Sachen muss ich also noch besorgen, irgendwie alles komplett bei einem
Anbieter bestellen geht vermutlich nicht oder?
Gruß - Markus
Hallo Markus,
das Hühnerfutter für den Minimalausbau kann ich Dir noch dazu legen. Die
MOSFETs (Level-Shifter) sind hoffentlich garnicht nicht nötig und das
EEPROM ist ja auch nur da, falls man lokal was speichern möchte...
Falls Du Dir ein kleines Sortiment zulegen willst, ich hab vor vielen
Jahren mit den Family-Packs von CSD
(https://csd-electronics.de/Passive-Bauteile/Widerstaende/FamilyPacks:::10_57_181.html)
angefangen, weil ich schon ein modulares, erweiterbares Sortiersystem
hatte und diesen Röhrchenkram immer gehasst habe.
Grüße, Daniel
Hi Daniel,
das wär natürlich perfekt! Lokal speichern will ich in der Tat nicht,
EEPROM brauch ich also nicht. Pack die Sachen dazu und ich bezahl die
natürlich auch!
Bei CSD schau ich mich mal um, da find ich mir bestimmt was 😉
Danke schon mal vorab, hoffentlich kommen die Platinen dann bald...
Gruß - Markus
Hallo,
die Platinen sind da und ich hab auch schon eine auf- und eingebaut.
Spannungsversorgung passt, LEDs kann ich mittels HomeMatic und ESPhome
ein- und ausschalten. Firmware-Update über OTA funktioniert ebenfalls
einwandfrei. Jetzt fehlt NUR NOCH die Software, um die serielle
Schnittstelle in Betrieb zu nehmen, die Buderus-Steuerung zum Reden zu
bringen und die Daten zu dekodieren :-P
Den Blog-Post habe ich auch nochmal für alle Interssierten aktualisiert:
https://the78mole.de/reverse-engineering-the-buderus-km217/
Die komplette Konfiguration für ESPhome werde ich bei Gelegenheit auch
noch pushen. Wer mich bei der Software unterstützen will ist jederzeit
willkommen.
Das Repo findet sich hier:
https://gitlab.com/the78mole/logamatic_2107_wifi_comm
Viel Spaß :-)
PS: Wer eine Platine will, bitte noch die postialische Adresse an mich
schicken. Entweder per PM oder über Email (findet sich auch im Impressum
meines Blogs).
Hallo Zusammen!
Vielen Dank an alle die hier mitgeholfen haben, die nötigen
Protokollinformationen zu erarbeiten.
Falls Interesse besteht, ich habe auf GitHub ein Projekt hochgeladen,
welches wunderbar zusammen mit der Platine von Daniel funktioniert.
Es liefert alle mir bisher bekannten Werte per MQTT und kann auch einige
Werte per MQTT Befehle anpassen und steuern.
Ihr findet es hier: https://github.com/dewenni/ESP_Buderus_KM271
Grüße Sven
Sven T. schrieb:> Ihr findet es hier: https://github.com/dewenni/ESP_Buderus_KM271
Hallo Sven,
1000x Danke an dich! Ich bin da schon länger dran und hatte bisher auch
keine Hardware dazu. Bestellung ist schon raus - das iiiiiideale
Weihnachtsprojekt 👍🤣👏
Schöne Grüße!
Hallo Jungs,
ich habe nun fast keine Module mehr und sammele gerade Ideen, die ich
noch mit umsetzen könnte... Aktuell auf der Liste:
- OneWire Interface connector
- Add-On Connectors (some I/Os, I2C, SPI)
Wer noch gute Ideen hat, die mit den recht generischen beiden Sachen
nicht abgedeckt sind, einfach hier rein :-)
Grüße,
Daniel
Daniel G. schrieb:> Hallo Jungs,>> ich habe nun fast keine Module mehr und sammele gerade Ideen, die ich> noch mit umsetzen könnte... Aktuell auf der Liste:>> - OneWire Interface connector> - Add-On Connectors (some I/Os, I2C, SPI)>> Wer noch gute Ideen hat, die mit den recht generischen beiden Sachen> nicht abgedeckt sind, einfach hier rein :-)>> Grüße,> Daniel
Hallo Daniel,
an dieser Stelle einfach mal danke dir für deine Arbeit und Mühen die du
in dieses Projekt steckst 👍👌
(Hatte fast schon befürchtet, du hast keine Zeit mehr gefunden um an dem
Projekt weiter zu machen)
Gruß - Markus
Hi Markus,
tatsächlich hatte ich kaum Zeit, deswegen habe ich ja bestückte Platinen
bestellt. Dass ich dann so viele Bestellung in so kurzer Zeit
wegarbeiten muss, im Gegenzug aber drei tolle Personen (Sven, Jens,
Bascht) aus der Community mir dann die Arbeit in der Firmware abnehmen,
damit hatte ich nicht gerechnet.
Vermutlich werde ich noch vor Weihnachten noch ein paar neue Features in
die Hardware einarbeiten und dann bestellen.
Ich bin auch echt begeistert, was da für eine Resonanz auf das Projekt
kam... Ich hatte Bestellungen aus Deutschland, USA, Lettland, Polen,
Ungarn, Litauen, Belgien, Spanien und Estland. Völlig crazy :-P
Grüße,
Daniel
Das Projekt ist auch für mich hochgradig interessant. Vor einigen
Monaten war ich schon darauf gestoßen, als ich die Logamatic wegen eines
defekten Brennerrelais reparieren musste und (mal wieder...) Ausschau
nach einer Kommunikationskarte hielt.
Grundsätzlich würde ich aber lieber dem bewährten Motto "Wer Funk kennt,
nimmt Kabel!" folgen, obwohl sich der relevante WLAN-AP direkt über dem
Heizungskeller befindet. Daher hatte ich auch schon darüber nachgedacht,
Deine Leiterplattenkontur zu "klauen" und als Grundlage für eine
Ethernetversion zu verwenden. Ggf. wäre es durchaus interessant, den
Ethernet-Teil mit IP101 an "Deinen" ESP32 dranzuknüppern, ähnlich wie
hier:
https://docs.espressif.com/projects/esp-idf/en/latest/esp32/hw-reference/esp32/get-started-ethernet-kit.html
Offenbar scheint ja die Spannungsversorgung von Buderus nicht auf ein
WLAN-Modul (oder auch Ethernet) ausgelegt zu sein, so ich erwäge, auch
eine separate Stromversorgung vorzusehen oder zumindest eine höhere
Spannung an anderer Stelle der Logamatic abzugreifen.
Nachdem mir Altium ein Ultimatum bezüglich einer möglichen
Wiederaufnahme/Verlängerung von Wartung und Software-Updates gestellt
hat, ist für mich auch endgültig klar, auf KiCad umzustellen. Somit wäre
das o.a. ohnehin schon für KiCad vorliegende Projekt auch ein schöner
Testballon (neben anderen beruflichen und privaten Projekten).
Hallo Daniel,
ein sehr interessantes Projekt :-)
Für mich wäre der OneWire Anschluss sehr interessant - dann würde ich
mir meine aktuelle Platine für meinen Pufferspeicher + Temperaturen vor
& nach der Systemtrennung mit 8 x DS18B20 sparen :-) - falls die
Spannungsversorgung der Logamatic das mitmacht..
Viele Grüße
Hallo Jens,
hallo Andreas,
also mit dem WLAN des ESP32-WROOM-32D hab ich bisher nur gute
Erfahrungen gemacht, was die Reichweite und Zuverlässigkeit angeht. Der
Charme liegt ja gerade darin, dass ich keine Leitungen ziehen muss.
Grundsätzlich könnte man aber auch einen ENC28J60 an die
SPI-Schnittstelle andödeln. Für ESP32 gibt es da durchaus Quellcode.
https://github.com/tobozo/ESP32-ENC28J60
Ethernet (über MII) direkt am WROOM verbrät halt unglaublich viele
GPIOs.
Bezüglich Spannungsversorgung hatten meines Wissens bisher nur zwei
Bastler Probleme. Bei den anderen (mehr als 50 Personen) lief alles wie
am Schnürchen. Und auch bei mir bisher keinerlei Probleme. Ich vermute
fast, dass bei den beiden Problem-Steuerungen entweder irgendwas
angeschlossen ist, das viel Saft braucht oder das Netzteil ein
Montagsmodell ist. Natürlich könnte man auch einen DC/DC verbauen. Der
würde die Sache sicher deutlich entspannen, verbraucht aber auch wieder
Platz und kostet deutlich mehr als der kleine LDO. Und die paar zehn
Milliwatt Verluste sind auch nicht der Rede wert.
Die OneWire-Sensoren ziehen auch praktisch keinen Strom. Würden sie das
tun, würden sie sich auch selbst zu stark aufheizen, um noch anständig
zu messen.
KiCad kann ich tatsächlich nur empfehlen. Habe damit nun schon etliche
Projekte gemacht und wenn man sich an ein paar Regeln hält, dann ist es
eines der besten PCB-Tools, die ich je verwendet habe. z.B. die
Original-Bibliotheken per GIT holen und in Ruhe zu lassen, die eigenen
Symbole und Packages dann in ein eigenes GIT zu stecken. Außerdem sollte
man für die Pfade entsprechend Variablen definieren.
Mal sehen, ob ich es noch vor Weihnachten schaffe oder dann "zwischen
den Jahren" dazu komme.
Grüße,
Daniel
Daniel G. schrieb:> Der> Charme liegt ja gerade darin, dass ich keine Leitungen ziehen muss.
Der Charme von Ethernet liegt ja gerade darin, dass man bei einem
Gerätetausch eines Switches nur die Patchkabel umstecken muss. Bei WLAN
muss man wiederum alle Clients in den neuen Access Point einbuchen, was
ja gerade bei Geräten ohne eigenes GUI o.ä. mit ziemlicher Bastelei
verbunden sein kann. Und irgendwelche Smart-Home-Komponenten sind ja
auch defür prädestiniert, bei solch einer Aktion vergessen zu werden.
Hi Andreas,
wenn man das WLAN gleich konfiguriert sollte alles wie vorher laufen,
selbst mit Consumer-Geräten. Wenn ich bei mir einen AP tausche oder
einen neuen dazu hänge, wird der automatisch provisioniert und alle
Clients können den wie gehabt nutzen.
Wer Ethernet haben möchte, der kann meine "bare PCB-Variante" und einen
Raspi oder irgend einen anderen Ethernet-UART-Konverter kaufen. Den
wenigen noch verfügbaren Platz auf dem Board nutze ich lieber für andere
Dinge als einen Ethernet-Anschluss (Stecker, Übertrager, Hühnerfutter),
den gerade mal 1% der Interessenten nutzen will. Zumal der ESP ja gerade
für WLAN (und vielleicht noch Bluetooth) prädestiniert ist.
Grüße,
Daniel
Daniel G. schrieb:> Den> wenigen noch verfügbaren Platz auf dem Board nutze ich lieber für andere> Dinge als einen Ethernet-Anschluss (Stecker, Übertrager, Hühnerfutter),> den gerade mal 1% der Interessenten nutzen will.
Genau, das verlange ich ja auch gar nicht. Oben hatte ich ja
geschrieben, dass ich vermutlich Deine Leiterplattenkontur usw. für
meine eigene Variante verwenden werde. Sofern ein Interesse besteht,
wäre ich dann durchaus auch bereit, das ganze wieder zuveröffentlichen,
ggf. auch in einem gemeinsamen Git-Repository.
> Zumal der ESP ja gerade> für WLAN (und vielleicht noch Bluetooth) prädestiniert ist.
In der Tat wäre er - ohne "Projektaltlasten" nicht der Controller erster
Wahl, wenn man WLAN gar nicht nutzen will.
Hi Andreas,
gerne kannst Du das Design nutzen und Dein eigenes veröffentlichen. Ich
verlinke natürlich auch gerne Dein Repo auf meinen Seiten (GitLab,
GitHub, mein Blog,...) und würde mich auch freuen, wenn Du mich
umgekehrt verlinkst.
Grüße,
Daniel
Hallo zusammen,
meine Platine ist heute angekommen 👍👌😁
Ich gerade dabei, die Version von Sven auf das Modul zu laden. Das
klappt soweit auch, allerdings bootet das Modul dann nicht mehr. Die
LEDs leuchten auch nicht mehr. Im Serialmonitor seh ich nur, dass das
Modul in einer Bootschleife hängt:
Kommt der Brownout weil das Modul momentan nur an der seriellen
Schnittstelle des Rechners hängt? Sprich: muss das Modul zur
Inbetriebnahme im Sockel der Heizungssteuerung stecken?
Okay, in meiner Teststeuerung leuchten jetzt mal alle LEDs und kurz ist
das Modul auch mit WLAN verbunden. Bricht aber nach einiger Zeit ab und
connectet sich dann neu.
Was mach ich noch falsch? Muss an den Jumperleisten noch was umgesteckt
werden? Hab ich so gelassen, wie sie im Lieferzustand waren.
Das könnte an einer nicht funktionierenden MQTT Verbindung liegen.
Es ist im Code so implementiert, dass bei WiFi und MQTT 5
Verbindungsversuche mit jeweils 5s Abstand erfolgen. Nach 5 erfolglosen
Versuchen sich mit dem WLAN oder MQTT Server zu verbinden, macht der ESP
einen Restart.
WiFi und MQTT müssen also funktionieren.
Hi Markus,
> Vielen Dank für deine Tipps! Werde ich morgen gleich testen 👍👌
Falls Du weiter Probleme mit Brown-Out hast, in seltenen Fällen (bisher
2 von 70) scheint die Buderus aus unerfindlichen Gründen eine schwache
Stromversorgung zu haben. Kann sein, dass da irgendwelche
Zusatzkomponenten drin sind, die mehr Strom ziehen. Bei mir funktioniert
das Modul nun seit Monaten in diversen Entwicklungsstufen einwandfrei.
Nur anfangs hatte ich noch Probleme, als auf der 3,3V-Schiene zu wenig C
(nur 100 nF) verbaut war. Auch die neueste Stufe mit den Level-Shiftern
auf der seriellen Schnittstelle zum Buderus, wie ich sie auch verkaufe,
läuft ohne einen einzigen Aussetzer.
Um dem Problem auf den Grund zu gehen, kannst Du einfach mal den
5V-Jumper raus nehmen und das Modul mit 3,3V über die
Programmierschnittstelle versorgen. Da eignet sich auch der
USB-seriell-TTL-Adapter gut, wenn dieser 3,3V zur Verfügung stellt
(Achtung: Keine 5V, die könnten den ESP beschädigen).
Wenn es dann funktioniert würde mich brennend interessieren, woran das
liegt :-)
Ursache gefunden! Ich habe meinen mqtt Server auf einem anderen Port
laufen und in deinem Code war der Port 1883 fest vorgegeben.
Ich habe die Credentials.h um die Angabe
1
#define MQTT_PORT 1884
erweitert sowie die mqtt.cpp geändert
1
mqtt_client.setServer(MQTT_SERVER,MQTT_PORT);
Damit funktioniert der Aufbau der Verbindung auf Anhieb. Danke nochmal
für deinen Hinweis 👍🙋♂️
Daniel G. schrieb:> Hi Markus,>>> Vielen Dank für deine Tipps! Werde ich morgen gleich testen 👍👌>> Falls Du weiter Probleme mit Brown-Out hast, in seltenen Fällen (bisher> 2 von 70) scheint die Buderus aus unerfindlichen Gründen eine schwache> Stromversorgung zu haben. Kann sein, dass da irgendwelche> Zusatzkomponenten drin sind, die mehr Strom ziehen. Bei mir funktioniert> das Modul nun seit Monaten in diversen Entwicklungsstufen einwandfrei.> Nur anfangs hatte ich noch Probleme, als auf der 3,3V-Schiene zu wenig C> (nur 100 nF) verbaut war. Auch die neueste Stufe mit den Level-Shiftern> auf der seriellen Schnittstelle zum Buderus, wie ich sie auch verkaufe,> läuft ohne einen einzigen Aussetzer.>> Um dem Problem auf den Grund zu gehen, kannst Du einfach mal den> 5V-Jumper raus nehmen und das Modul mit 3,3V über die> Programmierschnittstelle versorgen. Da eignet sich auch der> USB-seriell-TTL-Adapter gut, wenn dieser 3,3V zur Verfügung stellt> (Achtung: Keine 5V, die könnten den ESP beschädigen).>> Wenn es dann funktioniert würde mich brennend interessieren, woran das> liegt :-)
Hi Daniel,
ich habe den Jumper gezogen, hat aber keinen Unterschied gemacht! In der
seriellen Konsole kamen trotzdem die Brownout Meldungen. Steckt das
Modul aber in der Steuerung, läuft das ganze ohne Aussetzer!
Die nächsten Tage werden dann zeigen, wie stabil es läuft. Sehe aber
auch keine Einschränkungen hinsichtlich der Stabilität.
Gruß
Hi Markus,
> ich habe den Jumper gezogen, hat aber keinen Unterschied gemacht! In der> seriellen Konsole kamen trotzdem die Brownout Meldungen. Steckt das> Modul aber in der Steuerung, läuft das ganze ohne Aussetzer!> Die nächsten Tage werden dann zeigen, wie stabil es läuft. Sehe aber> auch keine Einschränkungen hinsichtlich der Stabilität.
Achso, der Programmieradapter liefert nicht genug Saft... Na dann bringt
Jumper-Ziehen natürlich wenig. Der trennt den LDO ja nur auf der
5V-Seite ab. Die Ausgangsseite ist immer verbunden, sollte aber nicht
viel ausmachen, wenn man "von hinten" versorgt.
Wenn Du die Situation öfter hast, dass Du außerhalb der Buderus was
testen willst, dann solltest Du evtl. über den Debug-Header die 5V z.B.
von USB versorgen.
Grüße,
Daniel
Daniel G. schrieb:> Wenn Du die Situation öfter hast, dass Du außerhalb der Buderus was> testen willst, dann solltest Du evtl. über den Debug-Header die 5V z.B.> von USB versorgen.>> Grüße,> Daniel
Ich hab auch noch andere Adapter, mit verschiedener Bauart. Ich teste
einfach mal mit einem anderen. Aber das ist für mich auch nicht wirklich
entscheidend, die Programmierung läuft sauber und in der Steuerung
funktioniert dann auch alles 👍
Was mir gestern auf die Schnelle aufgefallen ist: die ganzen Stati der
Werte beziehen sich immer nur auf den Heizkreis 1. Bei mir an der
Teststeuerung als auch an der "richtigen" Steuerung ist Heizkreis 2
aktiv. Warum weiß ich ehrlich gesagt nicht. Kann ich dann damit
überhaupt meine Steuerung ansprechen sprich auch den Heizkreis 2
abfragen und steuern?
Gruß - Markus
Ich habe jetzt die Doku zu meiner HS 2105M gewälzt und rausgefunden,
warum da HK2 aktiviert ist. Weil nur am HK2 der Mischerbetrieb möglich
ist.
Auf meiner Teststeuerung habe ich nun HK1 aktiviert und kann auch per
Befehl die Einstellungen steuern, funktioniert perfekt. Aber eben nur
für den HK1.
Hab ich mit der Lösung eine Chance die Daten von HK2 irgendwie
abzugreifen? Anscheinend müsste hier die Protokollauswertung erweitert
werden oder?
Das Uhrzeit Stellen hat an meiner Logamatic 2107 funktioniert.
Es wird dann die Uhrzeit gesetzt, die per NTP Server ermittelt wurde.
Die Uhrzeit die im ESP aktuell verwendet wird, siehst du auch in der
WiFi Struktur die per MQTT gesendet wird.
Möglicherweise hat die HS 2105M aber auch andere Adressen dafür. Das
kann ich nicht sagen.
Bezüglich HK1 und HK2:
Ich habe mich bei der Software auf HK1 konzentriert, weil ich nur den
HK1 habe und mich die Werte von dem nicht vorhandenen HK2 nicht
interessiert haben.
Natürlich könnte man den HK2 auch noch mit dazu nehmen und es ggf.
konfigurierbar machen.
Dokumentiert ist der HK2 hier auch:
https://github.com/mhop/fhem-mirror/blob/master/fhem/FHEM/00_KM271.pm
Der Aufwand dürfte sich in Grenzen halten. Ich kann dir aber nicht
versprechen das ich das kurzfristig schaffe. Muss mal schauen.
Vielleicht am kommenden Wochenende.
Grüße Sven
Sven T. schrieb:> Das Uhrzeit Stellen hat an meiner Logamatic 2107 funktioniert.> Es wird dann die Uhrzeit gesetzt, die per NTP Server ermittelt wurde.
Ich würde das ganze sogar fast umkehren und die Logamatic als Zeitserver
verwenden. Ich fragte mich übrigens jahrelang, warum das Datum und die
Uhrzeit immer korrekt waren. Erst bei der diesjährigen Renovierung
unseres Wohnzimmers öffnete ich die Fernbedienung und entdeckte darin
den DCF-77-Empfänger.
Hat eigentlich jede 2107-basierte Heizungsanlage einen DCF-77-Empfänger?
Hallo Andreas,
> Hat eigentlich jede 2107-basierte Heizungsanlage einen DCF-77-Empfänger?
Also meine sicherlich nicht :-P
Es gäbe aber auch noch eine andere Variante, wie man eine sehr genaue
Zeitbasis haben kann: Die 50 Hz Netzfrequenz. Früher wurde die mal genau
nach Atomuhr ausgeregelt. Heute ist das aber meines Wissens nicht mehr
so scharf, aber vermutlich noch immer besser als jeder billige
Uhrenquartz.
Übrigens, in "meiner" ESPhome-Variante ist auch HK2 bereits zum größten
Teil integriert, allerdings sind wir in anderen Bereichen noch nicht so
weit wie Sven.
Grüße,
Daniel
Sven T. schrieb:> Natürlich könnte man den HK2 auch noch mit dazu nehmen und es ggf.> konfigurierbar machen.> Dokumentiert ist der HK2 hier auch:> https://github.com/mhop/fhem-mirror/blob/master/fhem/FHEM/00_KM271.pm
Danke für den Link! Ich schau da mal selber und versuche, die Werte
selber einzubauen. Denke dass ich da viel spicken kann. Muss ja nicht
immer nur einer die ganze Arbeit machen 🤣😉
Das mit der Uhrzeit ist auch ned so tragisch, nützlich wäre es halt.
Aber erstmal ist der HK2 für mich wichtiger, sonst bringt mir das ganze
Projekt nicht viel.
Grüße - Markus
Daniel G. schrieb:> Es gäbe aber auch noch eine andere Variante, wie man eine sehr genaue> Zeitbasis haben kann: Die 50 Hz Netzfrequenz.
Es wäre mir neu, dass auch die Uhrzeit über die Netzfrequenz übertragen
wird. Das ganze taugt eben nur als Frequenznormal und nicht als
Zeitnormal.
> Früher wurde die mal genau nach Atomuhr ausgeregelt.
Offenbar verwechselst Du die Netzfrequenz mit der Zeilenfrequenz der
analogen öffentlich-rechtlichen Fernsehsender.
Bezüglich der Netzfrequenz werden jedoch nach wie vor die
Einzelschwingungen aufsummiert und nach Möglichkeit im Laufe einiger
Monate so weit ausgeglichen, dass sich der Fehler
netzfrequenzsynchronisierter Uhren nicht immer weiter kumuliert, sondern
auf insgesamt nur einigen Minuten begrenzt bleibt.
> Heute ist das aber meines Wissens nicht mehr> so scharf, aber vermutlich noch immer besser als jeder billige> Uhrenquartz.
Genau das trifft auf die Zeilenfrequenz zu. Wie die Synchronisation
aller Fernsehsender, die bei DVB-x zu einem Bouquet gebündelt werden,
ist mir aber nicht bekannt. Früher(tm) lief ja die gesamte
Produktionskette streng synchron, d.h. vom primären Frequenz- und
Timinggenerator bis hin zu den Studiokameras. Dadurch konnte man dann
auch mit sehr wenig Aufwand zwischen verschiedenen Kameras auch weich
überblenden.
Irgendwann gab es dann sog. digitale Time Base Correctors, d.h.
Bildspeicher, mit denen sich Phasen- und Frequenzunterschiede
asynchroner Videoquellen wieder ausbügeln ließen.
Lieber Daniel,
Deine Platine habe ich diese Woche erhalten, super! Am Wochenende kommt
mit der Installation der Moment der Wahrheit...
Verflixt, ich meine entweder hier, auf github oder tindie gelesen zu
haben, dass die Platine 1mm zu breit für den Slot ist. Ich find´s nicht
mehr.
Wenn ja, trifft das auch für die bestückte Platine zu? Muss ich feilen?
Achim
Achim W. schrieb:> Lieber Daniel,> Deine Platine habe ich diese Woche erhalten, super! Am Wochenende kommt> mit der Installation der Moment der Wahrheit...>> Verflixt, ich meine entweder hier, auf github oder tindie gelesen zu> haben, dass die Platine 1mm zu breit für den Slot ist. Ich find´s nicht> mehr.>> Wenn ja, trifft das auch für die bestückte Platine zu? Muss ich feilen?>> Achim
Hi Achim, ich glaub das war mal in einer der ersten Versionen der
Platine. Habe meine vor ein paar Tagen bekommen, die passte ohne
Anpassung in den Slot!
Gruß
So, ich habe den Heizkreis 2 jetzt in meinem Code ergänzt.
Sowohl bei den Config Werten als auch bei den Status Werten und den
Befehlen.
https://github.com/dewenni/ESP_Buderus_KM271
Markus: es wäre gut wenn du das mal testen könntest und mir Rückmeldung
geben würdest ob es funktioniert.
Hallo Achim,
> Verflixt, ich meine entweder hier, auf github oder tindie gelesen zu> haben, dass die Platine 1mm zu breit für den Slot ist. Ich find´s nicht> mehr.>> Wenn ja, trifft das auch für die bestückte Platine zu? Muss ich feilen?
Das ist Vergangenheit (Version 0.0.1). Die 0.0.5 sollte perfekt passen.
Zumindest hat sie das bei mir und gehört habe ich auch nichts mehr :-)
Grüße,
Daniel
Sven T. schrieb:> So, ich habe den Heizkreis 2 jetzt in meinem Code ergänzt.> Sowohl bei den Config Werten als auch bei den Status Werten und den> Befehlen.>> https://github.com/dewenni/ESP_Buderus_KM271>> Markus: es wäre gut wenn du das mal testen könntest und mir Rückmeldung> geben würdest ob es funktioniert.
Hallo Sven,
vielen Dank für deine Arbeit 👌 Ich war auch schon fast fertig bzw. war
grad beim testen. Ich habe mir deine neue Version gezogen und getestet.
Funktioniert soweit ich es getestet habe alles wie gewünscht! Lediglich
Uhrzeit stellen mag er immer noch nicht?!? Was mir dabei auffällt, da
kommt auch keine Bestätigungsnachricht zurück. Wenn ich z.B. die
Betriebsart ändere, dann kommt eine received Bestätigung zurück. Bei der
Uhrzeit aber nicht. Oder ist das doch eine Registersache?
Gruß - Markus
Okay - ich hab den Fehler gefunden wegen der Uhrzeit! 😂🤣
Ein Blick in die mqtt.cpp hat mir verraten, dass das Topic so aussehen
muss:
/esp_heizung/cmd/setdatetime
Bei dir im Github stehts anders:
esp_heizung/setvalue/setdatetime
Kannst du ja mal bei Gelegenheit ändern. Andererseits schadet es nicht,
dann geht man auch mal selber auf die Suche und ruht sich nicht auf der
Arbeit anderer aus. 😁😉
Nochmals vielen Dank an dich für deine viele Arbeit!
Gruß - Markus
perfekt, genau das habe ich auch gerade festgestellt.
Dann ändere ich das im Code am besten auch mal auf "setvalue".
Am besten schicke ich auch in der Antwort dann Uhrzeit und Datum mit
zurück:
message: datetime set to: 17.12.2022 - 16:07:35
Sven T. schrieb:> perfekt, genau das habe ich auch gerade festgestellt.>> Dann ändere ich das im Code am besten auch mal auf "setvalue".>> Am besten schicke ich auch in der Antwort dann Uhrzeit und Datum mit> zurück:>> message: datetime set to: 17.12.2022 - 16:07:35
Supi! Habe das Modul gerade in meine produktive Steuerung eingebaut.
Funktioniert super und die gelieferten Werte passen auch alle. Jetzt
muss ich das alles noch in mein NodeRed reinbasteln und die Märsche in
den Keller runter sind Vergangenheit! 👌
Geniales Projekt - sowohl Hardware als auch Software.
so, ist geändert auf "/setvalue/setdatetime"
und als Antwort kommt: "message: date and time set to: 17.12.2022 -
16:22:28 - DST:0"
DST zeigt an ob das Sommerzeit Flag in der Logamatic gesetzt wurde
Falls sonst noch was auffällt oder Wünsche bestehen, bitte melden.
Entweder hier oder als "Issue" im GitHub.
Sven T. schrieb:> Falls sonst noch was auffällt oder Wünsche bestehen, bitte melden.> Entweder hier oder als "Issue" im GitHub.
Ja mir ist jetzt tatsächlich noch was aufgefallen! In der km271.cpp hast
du in den Abschnitten für den Hk2 die mqtt Topics von HK1 kopiert und
dann den Text nicht geändert. So werden jetzt auch bei HK2 alle
Statusmeldungen als HK1 ausgeliefert.
Daniel G. schrieb:
[...]
>> Wenn ja, trifft das auch für die bestückte Platine zu? Muss ich feilen?>> Das ist Vergangenheit (Version 0.0.1). Die 0.0.5 sollte perfekt passen.
Hallo Daniel, hallo Leute,
die Platine passt, super!
Nach Einbinden ins Haus-WLAN und ESPHome/Homeassistant kamen auch
plausible Werte, aber nur kurzzeitig. Nach kurzer Zeit keine Werte mehr.
Ich habe noch versucht die YAML anzupassen (im Abschnitt ESPHome oder
Configuration.yaml?). Jedenfalls war dann ein Ausrufezeichen beim
km271-for-friends. Dann noch das Modul dort "gelöscht" und jetzt komme
ich an nichts mehr ran. Auch nicht über den FallbackHotspot.
Bislang habe ich nur mit ESP32DevKits gearbeitet und musste vorhin
erstmal einen Programmer ordern.
Dann gibts eine neue Firmware drauf für einen definierten Zustand -->
damit alles auf Anfang.
Schönen 4. Advent
Achim
Kleine Ergänzung, bisserl OT:
Ich habe mit einem ESP32 Devkit, einem Ultraschall-Entfernungssensor und
einem selbstgedruckten Gehäuse ein Projekt für einen Ölstandssensor im
ESPHome/Homeassistant nachgebaut. Läuft seit 10 Monaten einwandfrei in
einem Schütz-Öltank.
Link zum Projekt und herzlichen Dank an den Projektersteller:
https://forum.iobroker.net/topic/30434/%C3%B6lstandsmesser-selfmade
Achim
Achim W. schrieb:
[...]>
> Dann gibts eine neue Firmware drauf für einen definierten Zustand -->> damit alles auf Anfang.
Kleiner Erfahrungsbericht, eher ESPHome/HomeAssistant bezogen:
1. möglicherweise war das km271-for-friends-Modul von Daniel von mir
nicht sauber im Steckplatz eingerastet, wäre ein Grund für die
ausbleibenden Werte (hat aber grün geblinkt);
2. neu Flashen ging nur mit ESPTool.exe (Windows 11, HomeAssistant ohne
SSL, bin-File aus den Repos);
3. das ESPHome-Addon in HA hat dann fortwährend Devices als "adoptable"
gezeigt, ohne dass das funktioniert hätte. Händisches Einbindungen des
neu geflashten und ins WLAN eingebundenen km271-for-friends führte zu
einem Gerät ohne Entities. Mein ESP32-Ölstandsmesser (siehe Post drüber)
funktionierte nach stundenlangem rumtüfteln auch nicht mehr;
4. testweise eine Homeassistant in einem Dockercontainer gestaret. Zwar
keine Addons, aber sofortige Einbindung des ESP32-Ölstandsmessers UND
des km271-for-friends und Anzeige der Werte im Dashboard.
Kleines Problem: die Abgastemperatur ist nicht plausibel und steht
ohne Brennertätigkeit bei 255°C, bei Brennertätigkeit sind niedrige
einstellige °C Temperaturen. So als wäre der Wert umgekehrt. Habt ihr
das auch? Das Bild in der Anlage zeigt die UNterschiede. Bei den
niedrigen Temperaturen war der Brenner in Betrieb, bei 255 °C nicht.
ToDo:
--> ursprüngliche Homeassistant-Installation auf einem Raspi muss wohl
neu aufgesetzt werden, denn leider fehlen im HA-Container die
Add-On-Möglichkeiten für DeConz - für mich essentiell.
--> heute nicht mehr
Achim
@Sven T.:
Hi Sven,
nachdem ich mit Verzückung deine Aktualisierungen heute gesehen habe,
wollte ich diese gleich nutzen. Nachdem Upload der Version kam aber
schnell die Ernüchterung! Nachdem ich gesehen habe, dass sowohl die
WLAN-Verbindung als auch die mqtt-Verbindung ständig abbrechen, vermute
ich dass der ESP mit der Version ständig einen Reboot macht. In der
kurzen Zeit mit WLAN Verbindung kamen nur die wifi und die info Message
rein, sonst nichts. Das aktivierte debug spuckte folgendes aus:
1
03_00_01_09_44_55_82_ba
Ich hab jetzt wieder die v1.0.0 drauf, mit der läuft alles stabil. Keine
Aussetzer bei WLAN als auch am mqqt-Broker.
Bei dir läuft das stabil nehme ich mal an oder? Hat sonst jemand die
aktuelle Version getestet?
Gruß - Markus
Hallo Markus,
evtl. wäre es geschickter, Probleme als Issue auf GitHub zu posten...
Dieser Thread ist ohnehin schon viel, viel zu lang ;-)
Grüße,
Daniel
Hallo Markus,
danke für das Feedback, auch wenn es nicht erfreulich ist.
Ja bei mir läuft die neuste Version natürlich.
Der Hinweis mit der der letzten empfangenen Debug Message hilft mir auch
schon mal weiter.
Die 03 00 ist der erste von den 4 Fehlereinträgen aus der Logamatic die
ich zuletzt noch ergänzt habe.
1
03 00 ...
2
03 07 ...
3
03 0e ...
4
03 15 ...
Ich habe das anhand dem FHEM Code umgesetzt.
Ein von mir provozierter Fehler liefert dann z.B. folgende Nachricht:
1
03_00_31_13_2a_00_13_2a_04_00_00
1
03_00 = erster Eintrag
2
31 = "Kesselvorlauffuehler defekt"
3
13 = 19 Uhr
4
2a = 42min
5
00 = Tage (muss später addiert werden)
6
13 = 19 Uhr
7
2a = 42min
8
04 = 4 Tage
Ergebnis:
Kesselvorlauffuehler defekt (>> 19:42 -4 Tage | << 19:42 -4 Tage)
Wenn ich mir aber deine Nachricht anschaue, dann passt das nicht:
1
03_00_01_09_44_55_82_ba
Das geht schon bei der Fehlerummer "01" los. Die ist gar nicht
definiert.
1
0 => "Kein Fehler",
2
2 => "Aussenfuehler defekt",
3
3 => "HK1-Vorlauffuehler defekt",
4
4 => "HK2-Vorlauffuehler defekt",
5
....
Könnte also sein das die HS 2105M hier etwas anders funktioniert bzw.
andere Werte liefert.
Wäre schön wenn du nochmal was testen könntest.
Nimm nochmal den letzten Stand und kommentiere die Stellen mit den 4
Fehlermeldungen aus.
In der km271.cpp
vor der ersten case mit 0x0300 bis nach der case 0x0315
1
/*
2
case 0x0300: // 0x0300 : Error Buffer 1
3
...
4
case 0x0307: // 0x0307 : Error Buffer 2
5
...
6
case 0x030e: // 0x030e : Error Buffer 3
7
...
8
case 0x0315: // 0x0315 : Error Buffer 4
9
10
*/
Lade aber bitte nochmal den aktuellsten Commit runter den ich gerade
eben hochgeladen habe. Dort habe ich die Anzahl der Elemente in der
Debug Nachricht wieder erhöht. Versionsnummer ist die v1.3.2
Schick mir dann bitte mal den Inhalt aller 4 Fehlermessages:
1
03 00 ...
2
03 07 ...
3
03 0e ...
4
03 15 ...
Dann schauen wir mal weiter. Einerseits sollte egal welcher Inhalt nicht
zu einem Absturz führen. Da muss ich meinen Code dann nochmal prüfen.
Andererseits hätte ich gedacht das die Nachrichten auch bei der HS 2105M
so aufgebaut sind wie bei einer R2107.
Aber schauen wir dann mal.
Grüße Sven
Hallo zusammen,
wir (jensg, qschneider, the78mole) haben im Rahmen meines
KM271-WiFi-Projektes mal die Parameter der Logamatic M2107
zusammengetragen und in ein Spreadsheet gepresst:
https://docs.google.com/spreadsheets/d/1W-oVek6CUZ5GJo_8_TkeF2YykQjmGvg-QrWh0w_4kFQ/edit?usp=sharing
Evtl. hilft das dem Ein- oder Anderen für seine Implementierung z.B. in
FHEM oder Arduino/MQTT. Es ist zwar noch nicht 100%-ig komplett und
sicher ist noch der ein oder andere fehler versteckt, aber daran lässt
sich ja arbeiten :-)
Grüße,
Daniel (the78mole)
Hallo,
ich habe ein originales M404 KM2.0 Kommunikations-Modul für die Buderus
Ecomatic 4000.
Mit diesem Modul möchte ich gerne meine Heizung in Home Assistant
einbinden.
@Daniel Glaser (mailto:me@the78mole.de) Falls Du Interesse hast ein
"Buderus Ecomatic 4000 Smart Home WiFi Modul" zu entwickeln, dann kann
ich gerne detaillierte Fotos vom M404 Modul bereitstellen.
Gruß
Gernot
Gernot schrieb:> Hallo,> ich kann gerne detaillierte Fotos vom M404 Modul bereitstellen.
Das ist ein Foto vom gesamten Modul. Es wird immer nur in einen
Platinen-Stecker auf der Ecomatic 4000 (HS4201) Haupt-Platine
eingesteckt.
Gernot
Hallo Gernot,
wozu soll denn die M404 überhaupt gut sein? Ist das einfach ein
Kommunikationsmodul wie die Original-KM271 für eine andere
Buderus-Steuerung?
EDIT: Found your comment on my blog :-)
Sorry to say, but since I don't have your logamatic unit, it is almost
impossible to do all the engineering for another control unit. I think,
the easiest way is to:
- attach a USB-RS485-cable to the comm-module to see if the Logamatic is
talking a similar protocol than my one
If this is successful, attach an ESP32 with a RS485-Converter to the
header of your communication module.
And if this also succeeds, I could give it a try to reverse engineer the
remaining parts and build a PCB for the HS4201.
Cheers,
Daniel (the78mole)
Hallo Daniel,
ja, das KM404 ist für die Ecomatic 4000 das Kommunikationsmodul. So wie
das KM271 für die Logamatic 2107.
Die Buderus Ecomatic 4000 (meine Heizung ist Baujahr 1996) ist sozusagen
die Vorgänger-Generation.
Das Kommunikationsmodul "M404 / KM2.0" ist nur sehr selten verkauft
worden.
EDIT:
Yes, i will try to connect the M404 module via RS232 or RS485 and check
the communication protocol.
I will keep you updated...
Fingers crossed :)
Grüße,
Gernot
Hi Gernot,
oh yes, I'm so, so, so looking forward to the results... If your control
unit speaks the same "ugly language" like mine, then the chances are
good, that we can attach many more Buderus control units and maybe even
the newer ones.
Regards,
Daniel
Heute ist das KM2.0 M404 Kommunikationsmodul eingetroffen.
Als erstes habe ich die Kontakte des Platinen-Stecker ausgemessen und
die Signale anhand der IC-Datenblätter ermittelt.
Bisherige Erkenntnisse siehe Foto.
Gernot
Heute ist das KM2.0 M404 Kommunikationsmodul über RS232 (mit 2400 Baud)
an eine ESP8266 angeschlossen und über den UART die Kommunikation im
Debugger-Log angeschaut.
Es wird von der Steuerung regelmäßig "\x02" ausgegeben.
Wenn darauf "\x10" gesendet wird antwortet die Steuerung
mit "\b\x03\x85\x10\x03\x9D"
oder "\x11\x05:\x10\x03="
oder "a\x16\xFE\x10\x03\x9A"
oder "B\x0F!\x10\x03"
Kann jemand erkennen, ob die Kommunikation die selbe ist wie beim KM271
Modul.
Gruß
Gernot
Hallo Gernot,
das sieht ganz stark nach dem 3964R-Protokoll aus, das auch die KM271
verwendet. Allerdings wird es sicher einige kleine Unterschiede in den
Parametern geben. Aber das ist dann auch schon fast trivial und
hauptsächlich Fleißarbeit: An der Steuerung umstellen und beobachten,
was über die Schnittstelle kommt...
Ich denke, die schnellste Vorgehensweise wäre, unsere KM271-Komponente
für ESPhome zu nehmen und erst mal alles aus der YAML rauszuwerfen und
dann ins Log zu schauen. Ich vermute aber, der ESP8266 ist schnell an
seinen Grenzen, aber für erste Versuche könnte es reichen.
Grüße,
Daniel
Hallo Daniel,
danke für die rasche Rückmeldung. Das hört sich gut an :)
Für die weiteren Versuche habe ich mir schon einen ESP32 D1 Mini
bestellt.
So wie du angeraten hast, hatte ich eh vor mit eurer KM271-Komponente
weiterzumachen.
Die externe Beschaltung des ESP32 wird mit dem nötigsten ausgeführt -
nach Vorlage der KM271-WiFi Karte.
Gruß
Gernot
Hallo Gernot,
genau. Und im YAML einfach erst mal nur die Sections angeben, ohne
Verweis auf die Datenpunkte. Leider gibt es einen fehler, wenn man die
Sections (button, number,...) weg lässt (zumindest war das noch vor ein
paar Tagen so).
Hallo Daniel,
inzwischen habe ich die Kommunikation über die RS232-Schnittstelle zum
Laufen gebracht und die gesendeten Daten mit protokolliert.
Aus der Analyse der Daten konnte ich ein paar erste Codes von
Temperatur-Messwerten herausbekommen.
Das ist echt eine Fleißarbeit...
Gruß
Gernot
Hi Gernot,
die ganzen Parameter und möglichen Settings kannst Du Dir ganz einfach
aus dem Code des KM271-Moduls rausziehen. Wir werden das demnächst auch
noch etwas ausführlicher dokumentieren...
Grüße,
Daniel
Hallo,
inzwischen habe ich ein paar weitere Codes für Ist- und
Soll-Temperaturen, sowie die Bedeutung ein paar Bits aus einem
regelmäßig gesendeten Staus-Codes aus dem Datenprotokoll der HS4201
Steuerung entschlüsseln können und diese in Home-AssistAnt eingebunden.
Die Codes der Ecomatic 4000 HS4201 Steuerung sind leider komplett anders
und weniger Strukturiert als die Codes der Logamatic Steuerung.
Gruß
Gernot
Hallo Jungs,
mir ist noch nicht ganz klar, was die Schnittstelle an Funktionen
bietet.
Mein Use Case wäre, die Heizkurve bequem auf der Couch mit dem Notebook
auf dem Schoss einzustellen.
Laut Bedienungsanleitung geht das ja nur mit der Kugelschreibermethode
am Gerät.
Gruß Matthias
Hallo Matthias,
Du kannst über die Raumsolltemperatur (Parallelverschiebung) und die
Auslegungstemperatur (Steigung) die Heizkurve bequem über das SmartHome
verstellen, zumindest für alle Firware-Varianten, die ich kenne, die auf
meinem Modul laufen. Leider bin ich aktuell leer-geräubert und werde
frühestens im September wieder eine Charge der KM-271-ESP32-Module
bestellen. (Verfügbar dann etwa einen Monat später).
Unbestückte Platinen hätte ich noch ein paar wenige in der Schublade.
Grüße,
Daniel
Hallo Daniel,
unbestückte Platine würde reichen. Hast Du einen Link auf Dein Projekt
zwecks Aufbau und Inbetriebnahme?
Gibts eine "API"-Beschreibung zu den verfügbaren Funktionen?
Gruß Matthias
Hallo Matthias,
muss mich kurz fassen, Urlaub ist stressig 🤣... Hier solltest Du alles
finden: https://the78mole.de/projects/km271-wifi-howto/, auch die Links
zu GitLab und GitHub.
Grüße,
Daniel
Hallo zusammen,
ich muss mal kurz diesen Thread kapern 😉
Ich hab auch Daniels Platine in der aktuellen 0.0.6 Variante im Betrieb.
Hatte vorher eine andere Revision in Verwendung. Irgendwann kam mal
durch Update bzw. Tausch der Platinen eine Fehlermeldung auf der Buderus
Steuerung (sieh Bild). Und die bring ich nicht mehr weg, hab folgendes
versucht:
- Stromversorgung des Moduls über die USB Buchse -> Fehler immer noch da
- Module ausgebaut, Steuerung in Betrieb genommen -> Fehler immer noch
da
- aktuelle 3.2.4 von Sven's Software installiert (per USB bzw. seriell)
-> Fehler immer noch da
Ansonsten funktioniert übrigens alles, sowohl mit der Heizung als auch
mit dem Module. Es werden alle Parameter wie gewünscht per mqtt
übertragen und die Steuerung via Webinterface funktioniert auch.
Etwas Suche im Web brachte den Hinweis, dass man wohl auf Ebene 2 der
Steuerung Module ein- bzw. ausprogrammieren kann. Kennt sich wer damit
aus wie das geht? Im "normalen" Setup Modus find ich jedenfalls nix
dazu.
Grüße
Gernot A. schrieb:> Hallo Markus,> der Fehler deutet auf ein defektes oder fehlendes FM242 hin.> https://www.manualslib.de/manual/15526/Buderus-Logamatic-2107.html?page=63>> Hat deine Steuerung ein "2-Stufen Brenner Modul" FM242 ?> Falls nur ein "1-Stufen Brenner Modul" FM241 eingebaut ist, dann> solltest Du versuchen die Einstellungen entsprechend zu ändern.>> Siehe Service-Anleitung:> https://www.manualslib.de/manual/15526/Buderus-Logamatic-2107.html?page=1>> Gruß> Gernot
Hi Gernot,
danke für den Hinweis, ich hab das mal auf 1-stufig umgestellt und nun
ist die Anzeige bzw. der Fehler weg. Ich weiß allerdings nicht wirklich,
welches Modul da verbaut ist. Weißt du, wo ich das sehe? Ist das in der
Steuerung oder am Brenner zu sehen?
Gruß - Markus
Hallo Markus,
da musst du in die Logamatic 2107 reinschauen.
Das FM241 ist das Mischer-Modul für den Heizkreis 2 (siehe Bild).
Das FM242 wäre zur Ansteuerung eines 2-stufigen oder modulierenden
Brenners nötig...
Gruß
Gernot
Gernot A. schrieb:> Hallo Markus,> da musst du in die Logamatic 2107 reinschauen.> Das FM241 ist das Mischer-Modul für den Heizkreis 2 (siehe Bild).> Das FM242 wäre zur Ansteuerung eines 2-stufigen oder modulierenden> Brenners nötig...> Gruß> Gernot
Nochmals danke 👍
Diese Modul ist bei mir nicht verbaut, von daher passt jetzt alles wie
es eingestellt ist.
Gruß - Markus