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?
Thread beobachten
Seitenaufteilung abschalten
