Forum: Haus & Smart Home Logamatic 2107 Schnittstelle


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Rudi (Gast)


Lesenswert?

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.

von Rudi (Gast)


Lesenswert?

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.

von Fred G. (sysrun)


Lesenswert?

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.

von Rudi (Gast)


Lesenswert?


von Rudi (Gast)


Lesenswert?

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?

von Fred G. (sysrun)


Lesenswert?

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)...

von Rudi (Gast)


Lesenswert?

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) )
16
                {
17
                        ems_cnt = 0;
18
                        ems_adr = dr;
19
                }
20
                /* ignore frame error */
21
                if ( !(sr & (UART_SR_FE)) )
22
                {
23
                        ems_cnt++;
24
                }
25
                else
26
                {
27
                        if ( ems_adr == 0x8b )
28
                        {
29
                                tx_data = 0x0b;
30
                                ems_flag |= 1;
31
                        }
32
                }

von Paul (Gast)


Lesenswert?

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?

von AndyF (Gast)


Lesenswert?

Habt Ihr schon das Neueste gesehen? Buderus web KM200

Gruß
Andreas

von Helmut (Gast)


Lesenswert?

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

von Matthias (Gast)


Lesenswert?

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

von Helmut (Gast)


Lesenswert?

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

von Jürgen (Gast)


Lesenswert?

Helmut schrieb:
> Dann hat mich gestört, das es 890 Eintragungen gibt aber keine Lösung,
> die als brauchbar erkennbar ist.

Wie jetzt?

von Niffko _. (niffko)


Angehängte Dateien:

Lesenswert?

Endlich ... es gibt jetzt ein Buderus EMS-Schnittstellenmodul mit 
USB-Anschluss.



//Niffko

von Niffko _. (niffko)


Angehängte Dateien:

Lesenswert?

... 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

von Ein staunender (Gast)


Lesenswert?

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......

von WernerBrösel (Gast)


Lesenswert?

Der Helmut ist wieder unterwegs ...


Schöne Sache @ niffko!

von Niffko _. (niffko)


Lesenswert?

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

von Thorsten (. (picknicker)


Lesenswert?

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

von Joerg W. (joerg42)


Lesenswert?

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.

von Norbert D. (norbert21059)


Lesenswert?

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.

von OlafTezlaf (Gast)


Lesenswert?

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

von Fred G. (sysrun)


Lesenswert?

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?

von OlafTezlaf (Gast)


Lesenswert?

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

von Fred G. (sysrun)


Lesenswert?

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.

von OlafTezlaf (Gast)


Lesenswert?

Super, dann ists klar. Vielen Dank!

Gruß
Olaf

von Charlie (Gast)


Lesenswert?

Matthias schrieb:
> Den Code kann ich gerne posten.

Servus Matthias,

...habe ich was übersehen ;-)

Danke im Voraus!

Gruß aus der Wetterau
Karl M.

von Matthias (Gast)


Angehängte Dateien:

Lesenswert?

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

von Charlie (Gast)


Lesenswert?

Hallo Matthias,

... das war flott :)

Na, dann wollen wir mal ein bisschen Basteln!

Danke nochmal!

Gruß
Karl M.

von Danny B. (maniac103)


Angehängte Dateien:

Lesenswert?

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 ;-)

von Charlie (Gast)


Lesenswert?

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.

von Danny B. (maniac103)


Lesenswert?

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.

von Ingo F. (ingof)


Lesenswert?

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

von Michael D. (nospam2000)


Lesenswert?

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=005
http://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

von Rudi (Gast)


Lesenswert?

Hallo,

warum benutzt du nicht einfach Ferritbeads? Die sollten die Störungen 
auch ausreichend unterdrücken.


Grüße.

von charlie (Gast)


Lesenswert?

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.

von Danny B. (maniac103)


Lesenswert?

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

von charlie (Gast)


Lesenswert?

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.

von Ingo F. (ingof)


Lesenswert?

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

von Rudi (Gast)


Lesenswert?

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.

von Niffko _. (niffko)


Lesenswert?

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.

von Ingo F. (ingof)


Lesenswert?

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

von Rudi (Gast)


Angehängte Dateien:

Lesenswert?

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.

von Morus (Gast)


Lesenswert?

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

von Niffko (Gast)


Lesenswert?

Morus schrieb:
> einer Logamatic 4xxx Daten zu entlocken ...
> Kann ich davon ausgehen, dass das Protokoll ähnlich
> ist wie bei der RC30/35?

Eher nicht - anderes Protokoll.
Schau mal hier: 
http://www.ip-symcon.de/forum/f23/buderus-logamatic-4000-rs232-gateway-15960/#post137704. 
Da gibts einige Infos.


//Niffko

von Morus (Gast)


Lesenswert?

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

von Niffko _. (niffko)


Lesenswert?

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

von Morus (Gast)


Lesenswert?

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

von Jo Stetter (Gast)


Lesenswert?

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

von Rudi (Gast)


Lesenswert?

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

von Niffko _. (niffko)


Lesenswert?

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

von Norbert S. (norbert)


Lesenswert?

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

von Ingo F. (ingof)


Lesenswert?

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

von Danny B. (maniac103)


Lesenswert?

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.

von Niffko _. (niffko)


Lesenswert?

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

von Danny B. (maniac103)


Lesenswert?

> 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 ;)

von Niffko _. (niffko)


Lesenswert?

War denn die Signalform mit der Originalschaltung o.k.? Rudi hatte ja 
seinerzeit die Änderung vorgenommen, weil er nur Spikes am 
Komparatorausgang hatte.


//Niffko

von Danny B. (maniac103)


Lesenswert?

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.

von Danny B. (maniac103)


Lesenswert?

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

von Rudi (Gast)


Lesenswert?

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.

von Danny B. (maniac103)


Lesenswert?

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.

von Ingo F. (ingof)


Lesenswert?

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

von Niffko _. (niffko)


Lesenswert?

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

von Danny B. (maniac103)


Lesenswert?

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.

von Niffko _. (niffko)


Lesenswert?

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

von Danny B. (maniac103)


Lesenswert?

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.

von Rudi (Gast)


Lesenswert?

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.

von Niffko _. (niffko)


Lesenswert?

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

von Ingo F. (ingof)


Lesenswert?

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

von Danny B. (maniac103)


Lesenswert?

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.

von Mirko R. (Firma: none) (votava)


Lesenswert?

Hallo,

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)?

Würde mir gerne eine nachbauen und mit dem Code von Danny Baumann auf 
einem Pollin Net I/0 betreiben.

Gruß
Mirko

von Danny B. (maniac103)


Lesenswert?

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...

von Ingo F. (ingof)


Lesenswert?

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

von Norbert S. (norbert)


Lesenswert?

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

von Rudi (Gast)


Lesenswert?

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.

von Herbert (Gast)


Lesenswert?

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

Herby

von Ingo F. (ingof)


Lesenswert?

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

von Rudi (Gast)


Lesenswert?

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.

von Herbert (Gast)


Lesenswert?

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 ?

von Norbert S. (norbert)


Lesenswert?

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

von IngoF (Gast)


Lesenswert?

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

von Norbert S. (norbert)


Lesenswert?

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

von Ingo F. (ingof)


Lesenswert?

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

von Norbert S. (norbert)


Lesenswert?

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

von Ingo F. (ingof)


Lesenswert?

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

von Danny B. (maniac103)


Lesenswert?

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...

von Niffko _. (niffko)


Lesenswert?

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

von Norbert S. (norbert)


Lesenswert?

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

von IngoF (Gast)


Lesenswert?

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

von Ingo F. (ingof)


Angehängte Dateien:

Lesenswert?

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

von Niffko _. (niffko)


Angehängte Dateien:

Lesenswert?

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

von Niffko _. (niffko)


Lesenswert?

argh ... LED1 ist falsch herum eingezeichnet ... sorry.


//Niffko

von Danny B. (maniac103)


Lesenswert?

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.

von Niffko _. (niffko)


Lesenswert?

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

von Danny B. (maniac103)


Lesenswert?

> 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.

von Niffko _. (niffko)


Lesenswert?

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

von Danny B. (maniac103)


Lesenswert?

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

von Kay F. (jaykay)


Lesenswert?

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!

von Rudi (Gast)


Lesenswert?

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.

von Niffko _. (niffko)


Lesenswert?

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

von Danny B. (maniac103)


Lesenswert?

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.

von Danny B. (maniac103)


Lesenswert?

>> 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.

von Kay F. (jaykay)


Lesenswert?

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

von Danny B. (maniac103)


Lesenswert?

> 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 :)

von Niffko _. (niffko)


Lesenswert?

Danny Baumann schrieb:
> Ok, dann jetzt mal Butter bei die Fische ...

Aber gerne ...

Abfrage:
1
RX: <0x8b> <brk>
2
TX: <0x0b> <0x88> <content> <crc> <brk>
3
RX: <0x08> <0x0b> <content> <crc> <brk>
4
TX: <0x0b> <brk>


Anweisung:
1
RX: <0x8b> <brk>
2
TX: <0x0b> <0x08> <content> <crc> <brk>
3
RX: <0x01> <brk>
4
TX: <0x0b> <brk>


Ich schätze mal, die 0x01 versackt bei dir im Polling - oder?



//Niffko

von Danny B. (maniac103)


Lesenswert?

>> 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?

von Niffko _. (niffko)


Lesenswert?

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

von Danny B. (maniac103)


Lesenswert?

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...

von Jens H. (sevensworld)


Lesenswert?

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

von Danny B. (maniac103)


Lesenswert?

> 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.

von Niffko _. (niffko)


Lesenswert?

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_t outtemp;          // 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

von Jens H. (sevensworld)


Lesenswert?

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

von Rudi (Gast)


Lesenswert?

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.

von Niffko _. (niffko)


Lesenswert?

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

von Jens H. (sevensworld)


Lesenswert?

Danke für die Erklärung!

von Kay F. (jaykay)


Angehängte Dateien:

Lesenswert?

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

von Danny B. (maniac103)


Lesenswert?

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 ;)

von Rudi (Gast)


Lesenswert?

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.

von Danny B. (maniac103)


Lesenswert?

>> 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...

von Rudi (Gast)


Lesenswert?

Das könnte so funktionieren:
1
unsigned char dataByte;
2
debug << "new DataMessage "<< std::setfill('0') << std::setw(2) << std::showbase << std::hex << (unsigned int) m_recvBuffer[i] << " ";
3
dataByte = m_recvBuffer[bytesTransferred-3];
4
m_message = new DataMessage(m_db, dataByte);
5
6
for (size_t i = 2; i < (bytesTransferred-5); i++) {
7
      debug << std::setfill('0')  << std::showbase << std::hex << std::setw(2) << (unsigned int) m_recvBuffer[i] << " ";
8
  dataByte = m_recvBuffer[i];
9
      m_message->addData(dataByte);
10
  if (m_message->isFull()) {
11
    debug << std::endl;
12
    m_state = Checksum;
13
  }
14
}  // end only data

von Ingo F. (ingof)


Lesenswert?

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

von Kay F. (jaykay)


Lesenswert?

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

von heiner2904 (Gast)


Lesenswert?

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

von heiner2904 (Gast)


Lesenswert?

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

von IngoF (Gast)


Lesenswert?

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

von Kay F. (jaykay)


Lesenswert?

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

von Danny B. (maniac103)


Lesenswert?

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.

von Kay F. (jaykay)


Lesenswert?

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

von Ingo F. (ingof)


Lesenswert?

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:
1
<Absender> <Empfänger> <Telegrammtyp> <Daten ..... Daten> <CRC> <Break>

Wenn ich jetzt z.B. von der RC30 Zeit und Datum haben will sende ich:
1
<Absender> <Empfänger> <Telegrammtyp> <CRC> <Break>
2
=> 0x0B 0x90 0x06 0x3A <BRK>

Als Antwort bekomme ich dann das komplette Telegramm.

Wenn ich jetzt z.B. nur den zweiten Wert des Telegramms haben möchte 
sende ich:
1
<Absender> <Empfänger> <Telegrammtyp> <Offset> <Anzahl> <CRC> <Break>
2
=> 0x0B 0x90 0x06 0x02 0x01 0xED <BRK>

Ist das OK so, oder habe ich da einen kleinen oder größeren Denkfehler?

Hoffe die CRC ist auch richtig berechnet.

Gruß
Ingo

von Norbert S. (norbert)


Lesenswert?

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

von Niffko _. (niffko)


Lesenswert?

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

von Norbert S. (norbert)


Lesenswert?

Hi,

die Led macht nichts,
du hast auch die 5V und GND vom Atmel vertauscht.

von Niffko _. (niffko)


Lesenswert?

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

von Norbert S. (norbert)


Lesenswert?

Hi Niffko,

abschalten des Clockdividers könnte ich vergessen haben.
Muss ich am Montag mal prüfen.

Gruss
Norbert

von christophe (Gast)


Lesenswert?

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

von christophe (Gast)


Lesenswert?

> 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

von christophe (Gast)


Lesenswert?

PL2003 working example with servicekey (eb)
http://cgi.befr.ebay.be/ws/eBayISAPI.dll?ViewItem&item=170833794884

von IngoF (Gast)


Lesenswert?

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

von Daniel K. (danielbtk)


Lesenswert?

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

von Rudi (Gast)


Lesenswert?

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.

von spooniester (Gast)


Lesenswert?

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!!

von IngoF (Gast)


Lesenswert?

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

von Norbert S. (norbert)


Lesenswert?

Hallo Rudi,

wärst du so nett uns deine aktuelle Schaltung zu zeigen?

Gruss
Norbert

von Kostadin (Gast)


Angehängte Dateien:

Lesenswert?

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.

von Rudi (Gast)


Lesenswert?

Die Nachrichten sind nicht richtig. Sieht nach Polling und Datenmüll 
aus.

Grüsse.

von Kostadin (Gast)


Lesenswert?

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.

von Rudi (Gast)


Lesenswert?

Kostadin schrieb:
> warum??? Die Nachrichten sind so aufgebaut:

Sorry, falscher Bus ;-). Evtl. passt die CRC vom EMS-Bus?


Grüße.

von Rudi (Gast)


Lesenswert?

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.

von Kostadin (Gast)


Lesenswert?

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.

von IngoF (Gast)


Lesenswert?

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

von IngoF (Gast)


Lesenswert?

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

von Rudi (Gast)


Lesenswert?

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.

von Ingo F. (ingof)


Lesenswert?

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

von Rudi (Gast)


Lesenswert?

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

von Rudi (Gast)


Lesenswert?

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.

von IngoF (Gast)


Lesenswert?

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

von Kostadin (Gast)


Lesenswert?

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.

von Rudi (Gast)


Lesenswert?

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.

von Kostadin (Gast)


Lesenswert?

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

 ;)

von Herbert N. (herby74) Flattr this


Angehängte Dateien:

Lesenswert?

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  ).

von Rudi (Gast)


Lesenswert?

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?

von Kostadin (Gast)


Lesenswert?

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.

von Kostadin (Gast)


Angehängte Dateien:

Lesenswert?

..und die verspochene Datei.. ;)

von Herby (Gast)


Lesenswert?

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).

von Kostadin (Gast)


Angehängte Dateien:

Lesenswert?

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.

von Edward C. (teddy)


Lesenswert?

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

von Rudi (Gast)


Lesenswert?

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.

von Niffko (Gast)


Lesenswert?

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

von Rudi (Gast)


Lesenswert?

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.

von Rudi (Gast)


Angehängte Dateien:

Lesenswert?

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.

von SysRun (Gast)


Lesenswert?

Nabend :)

Wo gibt es denn die aktuelle Telegramliste?

von Niffko (Gast)


Lesenswert?

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

von Thorsten (Gast)


Lesenswert?

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

von Rudi (Gast)


Lesenswert?

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.

von Rudi (Gast)


Lesenswert?

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.

von Thorsten (Gast)


Lesenswert?

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

von Niffko (Gast)


Lesenswert?

Moin Thorsten,

nachfolgend ein Schnipsel aus meinem C-Code(AVR).
Vielleicht hilft's ...

//Niffko

1
/** Einfügen der EMS-Checksum in ein Byte-Array
2
 *
3
 * @param *buffer  Startadresse Byte-Array(global)
4
 * @param pos    Einfügeposition der CRC im Byte-Array
5
 * @return       void
6
 *
7
 * Bemerkung:     Einfügeposition nullbasiert.
8
 */
9
void InsertCRC( u8 *buffer, u8 pos ){
10
  u8 i,d,crc = 0;
11
12
  for(i=0; i <= pos-1; i++){
13
    d = 0;
14
    if ( crc & 0x80 ){
15
      crc ^= 0x0C;
16
      d = 1;
17
    }
18
    crc  = (crc << 1) & 0xfe;
19
    crc |= d;
20
    crc ^= buffer[i];
21
  }
22
  
23
  buffer[pos] = crc;
24
}

von SysRun (Gast)


Lesenswert?

Hier übrigens "meine" Werte: https://cosm.com/feeds/87491 :)

von Thorsten (Gast)


Lesenswert?

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

von Ingo F. (ingof)


Lesenswert?

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.
1
   int NextByte;
2
   int tmpCRC = 0x00;
3
   int CRC = 0x00;
4
5
   NextByte=0x1b;
6
   bOutput.write(NextByte);
7
   tmpCRC ^= (NextByte);
8
   CRC=tmpCRC;
9
   if (tmpCRC >= 0x80) {tmpCRC ^= 0x0c;}
10
   tmpCRC = rotateLeft(tmpCRC);
11
12
   .
13
   .
14
   .
15
16
   NextByte=CRC;
17
   bOutput.write(NextByte);


Gruß
Ingo

von Niffko (Gast)


Lesenswert?

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

von Jens H. (sevensworld)


Lesenswert?

Nabend zusammen,

ich beschäftige mich auch gerade mit dem Thema.
Das hier sollte eigentlich als Umsetzung in PHP passen, oder?
1
function CRC16($String)
2
{
3
  $crc = 0;
4
  $d = 0;
5
  $pos = count($String);
6
  
7
  for($i=0; $i <= $pos-1; $i++)
8
    {
9
       $d = 0;
10
       if ( $crc & 0x80 )
11
         {
12
            $crc ^= 0x0C;
13
            $d = 1;
14
         }
15
    $crc  = ($crc << 1) & 0xfe;
16
    $crc |= $d;
17
    $crc ^= $String[$i];
18
    
19
  }
20
21
  $x = $crc;
22
  return $x;
23
}
24
25
$String = array(0x0b,0x10,0x3d,0x04,0x01);
26
27
$Ergebnis = CRC16($String);
28
echo dechex($Ergebnis);


Gruß
Jens

von Danny B. (maniac103)


Lesenswert?

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 ;)

von IngoF (Gast)


Lesenswert?

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?

von IngoF (Gast)


Lesenswert?

IngoF schrieb:
> Kann mann die auch komplett
> herunterladen
Ups.. habe gerade gesehen dass es einen Knopf gibt um alles als ZIP 
herunter zu laden.

von Danny B. (maniac103)


Lesenswert?

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.

von IngoF (Gast)


Lesenswert?

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

von Danny B. (maniac103)


Lesenswert?

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.

von spooniester (Gast)


Lesenswert?

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

von Rudi (Gast)


Lesenswert?

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

von Niffko _. (niffko)


Lesenswert?

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

von Rudi (Gast)


Angehängte Dateien:

Lesenswert?

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.

von Rudi (Gast)


Angehängte Dateien:

Lesenswert?

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.

von Rudi (Gast)


Angehängte Dateien:

Lesenswert?

Hallo,

anbei mal ein Bild von meinem EMS<->UART-Konverter ;-). Ich hatte heute 
endlich mal Zeit für die Bestückung.



Grüße.

von Heisenberg (Gast)


Lesenswert?

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

von Niffko _. (niffko)


Angehängte Dateien:

Lesenswert?

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

von Jörg H. (dr_coolgood)


Lesenswert?

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... :-)

von Rudi (Gast)


Lesenswert?

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.

von Edward C. (teddy)


Lesenswert?

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

von Edward C. (teddy)


Lesenswert?

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?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.